Fedora 13 has been branched!!

[Jesse Keating]

That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who "you" are, here are some "you"s
that we wrote about:
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases

The real take away here is explained at
https://fedoraproject.org/wiki/Branch_Freeze_Policy

The upshot is that if you want to get a build into Fedora 13, you gotta
build from F-13/ and you gotta put it in bodhi. The good news is that
if your package isn't critical path, it's just like any other update in
bodhi, you decide when it goes stable. If it's critical path, releng or
QA will have to give it karma, but that means somebody will look at it!
(We're working on ways to make it more visible to the user that your
package is critical path).

There are new paths on the mirrors too:

pub/fedora/linux/development/rawhide <-- this is the new home of
rawhide. Builds from devel/ go here. This is now the F-14 development
ground.

pub/fedora/linux/development/13 <-- this is the branched Fedora 13.
Builds from F-13/ that make it through bodhi as stable show up here.
This is what we'll use to make the Alpha, Beta, Final release and all
the snapshots in between and the nightly attempt at instllable images.

pub/fedora/linux/updates/testing/13 <-- this is where the testing
updates go for the branched 13. Test 'em here before they go to stable.

For a better picture, see
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Tree.2FRepo_Overview

I have disabled the rsync part of the rawhide compose process so that I
can do things by hand tomorrow and ensure we don't screw up the mirrors,
so you'll see a delay in things. We'll also do the branched tree
compose by hand as well and then sync the output at the same time to
preserve hardlinks. It'll be a fun day! Hop by #fedora-devel if you've
got questions and somebody will try to help you.

Welcome to the world of No Frozen Rawhide!!!
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100216/b728864d/attachment.bin
-------------- next part --------------

[Mamoru Tasaka]

Post by Jesse Keating
That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who "you" are, here are some "you"s
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
From me currently two questions.

A. How does this affect http://koji.fedoraproject.org/static-repos/ ?
B. As other person already asked, will daily "rawhide changes" report
(containing broken deps) be reported also for F-13 to devel list,
or just changes for F-14 only will be reported (i.e. daily broken
deps report will no longer be available for F-13)?

Regards,
Mamoru

[Jesse Keating]

Post by Mamoru Tasaka
A. How does this affect http://koji.fedoraproject.org/static-repos/ ?

static-repos will act as it normally does for a released Fedora. The
repo seen is what is in the buildroot, which is what is tagged for
release, and anything we've tagged "override" to make it available in
the buildroot for further builds.

There is one small wrinkle. I've "broken" the dist-rawhide static repo,
because I've made dist-rawhide a real build target to be used by builds
from devel/. I'll be making a symlink soon that will keep
"dist-rawhide" static repos pointed to the right location.

Post by Mamoru Tasaka
B. As other person already asked, will daily "rawhide changes" report
(containing broken deps) be reported also for F-13 to devel list,
or just changes for F-14 only will be reported (i.e. daily broken
deps report will no longer be available for F-13)?

There will be a Rawhide Report and a Branched Report. Rawhide will be
F-14 now, Branched is F-13. There will also be Fedora 13 Updates
Testing announcements over on the test list.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100216/b8f0f8df/attachment.bin

[Frank Murphy]

On 17/02/10 04:31, Jesse Keating wrote:
--snipped--

Post by Jesse Keating
There will be a Rawhide Report and a Branched Report. Rawhide will be
F-14 now, Branched is F-13. There will also be Fedora 13 Updates
Testing announcements over on the test list.

When will there be a "branched.repo" config for testers.
So they won't be getting "rawhide.repo".
It that's what they want\need.

[Jesse Keating]

Post by Frank Murphy
When will there be a "branched.repo" config for testers.
So they won't be getting "rawhide.repo".
It that's what they want\need.

The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right place. There is an updated
fedora-release that will be published into the branched dir that testers
who want to stick with F13 can install. Those who start with Alpha will
stay on Fedora 13.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/4609ff9e/attachment.bin

[Mathieu Bridon]

Post by Frank Murphy
When will there be a "branched.repo" config for testers.
So they won't be getting "rawhide.repo".
It that's what they want\need.

The branched repo config is the fedora.repo file. ?Mirrormanager will be
making sure that goes to the right place. ?There is an updated
fedora-release that will be published into the branched dir that testers
who want to stick with F13 can install. ?Those who start with Alpha will
stay on Fedora 13.

I think Frank's question was:
In F12, I have a rawhide.repo I can use if I want to move to Rawhide.
What do I use if I want to move to F13?

At least, that's what I am wondering.


----------
Mathieu Bridon

[Jesse Keating]

Post by Mathieu Bridon
In F12, I have a rawhide.repo I can use if I want to move to Rawhide.
What do I use if I want to move to F13?
At least, that's what I am wondering.

You'd install fedora-release from the branched repo, or you'd upgrade
using the Fedora 13 Alpha. We might even do pre-upgrade for getting
from a stable release to the branched release.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/18352436/attachment.bin

[Till Maas]

Post by Jesse Keating
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right place. There is an updated

Is this http://mirrors.fedoraproject.org/publiclist/Fedora/ the url for
mirrormanager? I have to ask, because it does not contain any hint, that
it is. If it is, it seems not to know F13, because F13 is not on the
list.

Regards
Till

[Matt Domsch]

Post by Till Maas

Post by Jesse Keating
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right place. There is an updated

Is this http://mirrors.fedoraproject.org/publiclist/Fedora/ the url for
mirrormanager? I have to ask, because it does not contain any hint, that
it is. If it is, it seems not to know F13, because F13 is not on the
list.

http://mirrors.fedoraproject.org/publiclist/Fedora/13/
shows 80 mirrors right now...

The F13 URL for use in yum is exactly the same as before, as long as
you have fedora-release-13 installed.

[fedora]
name=Fedora $releasever - $basearch
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

e.g.:

https://mirrors.fedoraproject.org/metalink?repo=fedora-13&arch=x86_64

but whoops - MM had fedora-13 repos directing to rawhide. I just
dropped that redirect, so after an hour or so it should direct to
development/13/ as expected.

Thanks,
Matt

[Till Maas]

Post by Matt Domsch

Post by Till Maas

Post by Jesse Keating
The branched repo config is the fedora.repo file. Mirrormanager will be
making sure that goes to the right place. There is an updated

Is this http://mirrors.fedoraproject.org/publiclist/Fedora/ the url for
mirrormanager? I have to ask, because it does not contain any hint, that
it is. If it is, it seems not to know F13, because F13 is not on the
list.

http://mirrors.fedoraproject.org/publiclist/Fedora/13/
shows 80 mirrors right now...

When I wrote the mail, it did not appear in the "Mirror list filter"
list, but it does now.
Btw. I opened a ticket about mirrormanager not identifying itself in
trac:
https://fedorahosted.org/mirrormanager/ticket/25

Thanks
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/585b0d14/attachment.bin

[Christoph Wickert]

Post by Jesse Keating
static-repos will act as it normally does for a released Fedora. The
repo seen is what is in the buildroot, which is what is tagged for
release, and anything we've tagged "override" to make it available in
the buildroot for further builds.

This means that chainbuilds are no longer possible and this slows
development down dramatically. Think of a feature like Xfce 4.8 with
it's tight schedule [1]. E.g. we only have 8 days to build one of the
pre-releases.

When I made the Xfce 4.4.3 update for F-9, it took 7 days to build
everything due to the long dependency chain that required a lot of
overrides from rel-eng [2].

This means that large updates like Gnome, KDE or Xfce will get massively
delayed after alpha. They might not make it into one of the prereleases,
which means they get less testing. A lot of features will no longer be
possible in their current state.

How do we address this issue?

Regards,
Christoph

[1] https://fedoraproject.org/wiki/Features/Xfce48#Detailed_Description
[2] https://fedorahosted.org/rel-eng/ticket/1429

[Michal Schmidt]

Post by Christoph Wickert
This means that chainbuilds are no longer possible and this slows
development down dramatically. Think of a feature like Xfce 4.8 with
it's tight schedule [1]. E.g. we only have 8 days to build one of the
pre-releases.
When I made the Xfce 4.4.3 update for F-9, it took 7 days to build
everything due to the long dependency chain that required a lot of
overrides from rel-eng [2].
This means that large updates like Gnome, KDE or Xfce will get
massively delayed after alpha. They might not make it into one of the
prereleases, which means they get less testing. A lot of features
will no longer be possible in their current state.
How do we address this issue?

Would it help to use a special Koji tag for this?
Let's say you'd get a tag 'dist-f13-xfce48' where all packages built
there would be immediately available for building dependend packages.
And then when you're done, you'd ask rel-eng to tag them all at once
into 'dist-f13-updates-candidate'.

Jesse, does it make sense?

Michal

[Christoph Wickert]

Post by Michal Schmidt

Post by Christoph Wickert
This means that chainbuilds are no longer possible and this slows
development down dramatically. Think of a feature like Xfce 4.8 with
it's tight schedule [1]. E.g. we only have 8 days to build one of the
pre-releases.
When I made the Xfce 4.4.3 update for F-9, it took 7 days to build
everything due to the long dependency chain that required a lot of
overrides from rel-eng [2].
This means that large updates like Gnome, KDE or Xfce will get
massively delayed after alpha. They might not make it into one of the
prereleases, which means they get less testing. A lot of features
will no longer be possible in their current state.
How do we address this issue?

Would it help to use a special Koji tag for this?

We were planning to do this with a custom tag anyway, but I'm not sure
if this also affects whether they go straight into the repos or not.

And what about the updates that don't have a custom tag?

Regards,
Christoph

[Till Maas]

Post by Christoph Wickert
And what about the updates that don't have a custom tag?

If the update is big enough, that a lot of packages require a rebuild,
using a custom tag seems to be the best approach, so if there is none,
ask of it. If there is no need for one, then the buildroot overwrite
approach seems to be good enough. Or what is the specific problem you
are seeing?

The advantage of using a custom tag is also, that it does not touch the
buildroots of all packages and therefore makes it possible to still push
updates for the affected dependent packages, if they are required to fix
a bug. Afaik currently kde does not use a custom tag, and therefore if
one wants to update a kde/qt dependent package, it would be build with
a incompatible kde/qt version and therefore cannot be pushed to stable.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/c466279d/attachment.bin

[Christoph Wickert]

Post by Till Maas

Post by Christoph Wickert
And what about the updates that don't have a custom tag?

If the update is big enough, that a lot of packages require a rebuild,
using a custom tag seems to be the best approach, so if there is none,
ask of it. If there is no need for one, then the buildroot overwrite
approach seems to be good enough. Or what is the specific problem you
are seeing?

Both approaches have their ups and downs, but both slow down
development:
* Asking rel-eng for overwrites takes time.
* Asking rel-eng for a tag takes some time too. And I'm afraid
that with an inflationary number of tags things get unclear for
other maintainers. They don't know what to build their packages
against or when to use which tag. It requires a lot of
coordination between the different parties.

Post by Till Maas
The advantage of using a custom tag is also, that it does not touch the
buildroots of all packages and therefore makes it possible to still push
updates for the affected dependent packages, if they are required to fix
a bug.

The major advantage of a custom tag for me is that we have a consistency
plan. If something goes wrong, we can just throw away all these builds
and turn back to a previous state without downgrading packages and
introducing epochs.

So we both agree about the advantages of custom tags, but we are talking
about the development versions here and not about stable releases. In
the branches that are under development we would not do a bugfix against
the "stable" tag. Instead, all updates are supposed to target
development. If we really needed a bugfix in a development branch, this
could easily be done with early branching.

Post by Till Maas
Afaik currently kde does not use a custom tag, and therefore if
one wants to update a kde/qt dependent package, it would be build with
a incompatible kde/qt version and therefore cannot be pushed to stable.

Again, we are not talking about stable releases. But if someone does
large updates in the stable releases, I agree they should use a custom
tag.

Post by Till Maas
Regards
Till

Regards,
Christoph

[Till Maas]

Post by Christoph Wickert
Both approaches have their ups and downs, but both slow down
* Asking rel-eng for overwrites takes time.
* Asking rel-eng for a tag takes some time too. And I'm afraid
that with an inflationary number of tags things get unclear for
other maintainers. They don't know what to build their packages
against or when to use which tag. It requires a lot of
coordination between the different parties.

Usually when some of mine packages need to be rebuild because of updated
dependencies, the communication is usually one-way. I get informed that
the packages needs to be rebuild and then it happens soon afterwards,
therefore I do not even have to know how the tag is called. There are
also scripts that help to do this easily afaik. This is also the
advantage of using a tag, because then I can still create bugfixes by
myself without being disturbed my the buildroots. Off course then the
package also needs to be rebuilt in the staging tag, but this can be
easily automated and already might be.

Post by Christoph Wickert
So we both agree about the advantages of custom tags, but we are talking
about the development versions here and not about stable releases. In
the branches that are under development we would not do a bugfix against
the "stable" tag. Instead, all updates are supposed to target
development. If we really needed a bugfix in a development branch, this
could easily be done with early branching.

I am confused here, since there is no early branching, because branching
already happened and F-13 is now stabilizing and afaik should be treated
more like it was stable than like it is rawhide. E.g. major updates
should now break rawhide first and if the fallout is handled, then it
could be done for F-13.

Regards
Till

[Christoph Wickert]

Post by Till Maas

...

Usually when some of mine packages need to be rebuild because of updated
dependencies, the communication is usually one-way. I get informed that
the packages needs to be rebuild and then it happens soon afterwards,

You are lucky. In the past people broke my package without further
notice and I had to take care of fixing them. On the other hand there
are maintainers, that announce changes in advance and ask me if I'm fine
with them rebuilding my packages or if I want to take care of this
myself. This is how it should be but only proven packagers will be able
to do this.

Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
KDE app is always aware of the changes before they happen. If things
still seem to be working in F-13 or rawhide, he might not even be aware
of the custom tag.

Post by Till Maas
therefore I do not even have to know how the tag is called. There are
also scripts that help to do this easily afaik. This is also the
advantage of using a tag, because then I can still create bugfixes by
myself without being disturbed my the buildroots. Off course then the
package also needs to be rebuilt in the staging tag, but this can be
easily automated and already might be.

Honestly, I don't recall automated updates of my packages except for the
mass rebuilds from rel-eng. If the people that break things and/or
requested the custom tag will take care of this, we are fine, bug FWIW
it's not like this in rawhide. Let's see how it turns out in F-13.

Post by Till Maas
I am confused here, since there is no early branching, because branching
already happened

Right, now there no longer is early branching for selected packages onn
demand but a general early branches for all packages.

Post by Till Maas
and F-13 is now stabilizing and afaik should be treated
more like it was stable than like it is rawhide. E.g. major updates
should now break rawhide first and if the fallout is handled, then it
could be done for F-13.

I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze. If we need to do things
in rawhide first and only push these changes to F-13 afterwards, a
feature with a tight schedule like Xfce 4.8 is lost. That's just what I
said.

Post by Till Maas
Regards
Till

Regards,
Christoph

[Jesse Keating]

Post by Christoph Wickert
Right, now there no longer is early branching for selected packages onn
demand but a general early branches for all packages.

Except it's not really early. We're now in bugfix/polish mode for
Fedora 13, not in rapid development mode. Rapid development for Fedora
14 started now.

Post by Christoph Wickert

Post by Till Maas
and F-13 is now stabilizing and afaik should be treated
more like it was stable than like it is rawhide. E.g. major updates
should now break rawhide first and if the fallout is handled, then it
could be done for F-13.

I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze.

The beta milestone is when we're supposed to have all the bugs fixed,
not when we stop throwing in development builds.

Post by Christoph Wickert
If we need to do things
in rawhide first and only push these changes to F-13 afterwards, a
feature with a tight schedule like Xfce 4.8 is lost. That's just what I
said.

Of course you'll need to do things in a way that makes sense for your
schedule. It's encouraged that things hit rawhide first, but not
mandatory.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/87cfdab0/attachment.bin

[Christoph Wickert]

Post by Jesse Keating

Post by Christoph Wickert
Right, now there no longer is early branching for selected packages on
demand but a general early branches for all packages.

Except it's not really early. We're now in bugfix/polish mode for
Fedora 13, not in rapid development mode. Rapid development for Fedora
14 started now.

This only works for things developed in Fedora or for projects like
Gnome, because we are closely following their schedule. Other projects
have other schedules and we need to be flexible. I really like no frozen
rawhide, but IMO we have lost some flexibility for the n+1 release.
There is more flexibility for n+2 but I doubt that anybody will/can make
use of it. We not even have a feature process for F14, so why would
anyone start a feature now?

Post by Jesse Keating

Post by Christoph Wickert
I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze.

The beta milestone is when we're supposed to have all the bugs fixed,
not when we stop throwing in development builds.

Right, but upgrading from Xfce 4.8 pre1 to pre2 *is* bugfixing.

Regards,
Christoph

[Jesse Keating]

Post by Christoph Wickert
This only works for things developed in Fedora or for projects like
Gnome, because we are closely following their schedule. Other projects
have other schedules and we need to be flexible. I really like no frozen
rawhide, but IMO we have lost some flexibility for the n+1 release.
There is more flexibility for n+2 but I doubt that anybody will/can make
use of it. We not even have a feature process for F14, so why would
anyone start a feature now?

Because often the work of a feature needs more time than the short 3
months we've seen before between N release and N+1 feature freeze. And
often times the features are done or near done by the time FESCo votes
on them, starting early is a good thing.

Post by Christoph Wickert

Post by Jesse Keating

Post by Christoph Wickert
I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze.

The beta milestone is when we're supposed to have all the bugs fixed,
not when we stop throwing in development builds.

Right, but upgrading from Xfce 4.8 pre1 to pre2 *is* bugfixing.

Yes, that may be true. It is unfortunate that you'll now have to do a
buildroot override task, but that was a negative impact we were willing
to take. As I said in other mails, if you're seeing a long lag in tag
requests, we can try to grow the list of folks with tag rights to cover
other time zones. Use of koji wait-repo can help here, and nearly
replicate chain-build.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/1700698a/attachment.bin

[Kevin Kofler]

Post by Jesse Keating
Yes, that may be true. It is unfortunate that you'll now have to do a
buildroot override task, but that was a negative impact we were willing
to take.

The question is, wouldn't it have been possible to, yes, branch early so
Rawhide could move on (as we did), but have builds from F-13 land directly
in dist-f13 until the Beta Freeze (as was done in the past and worked quite
well)?

Post by Jesse Keating
As I said in other mails, if you're seeing a long lag in tag
requests, we can try to grow the list of folks with tag rights to cover
other time zones.

I think that'd be a good idea. My tag requests for buildroot overrides
usually only get processed when rdieter is up, even if I file them in the
rel-eng Trac. ;-)

Kevin Kofler

[Jesse Keating]

Post by Kevin Kofler
The question is, wouldn't it have been possible to, yes, branch early so
Rawhide could move on (as we did), but have builds from F-13 land directly
in dist-f13 until the Beta Freeze (as was done in the past and worked quite
well)?

While it would have been possible, it would have been counter-productive
to our effort to keep the branched tree stable. History has shown that
developers don't always make the best decisions and ruin the party for
everybody. Now we're providing a public sandbox to test things before
they hit the tree.

Post by Kevin Kofler

Post by Jesse Keating
As I said in other mails, if you're seeing a long lag in tag
requests, we can try to grow the list of folks with tag rights to cover
other time zones.

I think that'd be a good idea. My tag requests for buildroot overrides
usually only get processed when rdieter is up, even if I file them in the
rel-eng Trac. ;-)

You're in Austria right? Rex wakes up before I do, which is why he's
hitting them before me. Finding somebody on the other side of the pond
who's interested in doing releng work would help.

Other options are to have dist-f13-build feed directly from
dist-f13-updates-candidate. There is some risk there though, of things
being built against other things but not pushed together.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/48c2e28b/attachment-0001.bin

[Kevin Kofler]

Post by Jesse Keating
You're in Austria right?

Yes. But my wake times tend to be very chaotic. ;-)

Post by Jesse Keating
Rex wakes up before I do, which is why he's hitting them before me.
Finding somebody on the other side of the pond who's interested in doing
releng work would help.

Right, having somebody who's consistently available at European morning and
early afternoon times process tag requests would be nice. I don't think I
would be a good choice myself, see the previous paragraph. ;-)

Quite often, when we do KDE builds, Rex and I get up around the same time,
we coordinate builds and buildroot overrides on IRC and then I end up going
to sleep an hour or two *after* him. ;-)

Kevin Kofler

[Till Maas]

Post by Jesse Keating
You're in Austria right? Rex wakes up before I do, which is why he's
hitting them before me. Finding somebody on the other side of the pond
who's interested in doing releng work would help.

I volunteer to help with buildroot overrides assuming that it does not
take that much time. I am located in CET/UTC+1, too. Is there maybe a
schedule about how well the timeslots are covered?

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100218/866b5791/attachment.bin

[Jesse Keating]

Post by Till Maas
I volunteer to help with buildroot overrides assuming that it does not
take that much time. I am located in CET/UTC+1, too. Is there maybe a
schedule about how well the timeslots are covered?

Great!

We don't really have a coverage list, but most of the people who have
been doing tagging are all in the US time zones, so anything outside of
that is welcome.

https://fedoraproject.org/wiki/Buildroot_override_SOP is the working SOP
we have for this, although I notice it doesn't say what to do with the
tickets. We typically assign the ticket to ourself, whoever is doing
the tag, so that when the reporter says the build is done we see it and
can do the untag and close the ticket.

https://fedorahosted.org/rel-eng/report/3 can help you somewhat see the
open tickets, if there is a tag request ticket assigned to rel-eng@ that
means it likely hasn't been operated on.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100218/e867bf02/attachment.bin

[Christoph Wickert]

Post by Jesse Keating
We typically assign the ticket to ourself, whoever is doing
the tag, so that when the reporter says the build is done we see it and
can do the untag and close the ticket.

If the ticket is assigned to a single person, I doubt we can do the
overwrites in a timely manner. Remember, I'm wasn't talking about a
single overwrite but about large build chains that require 8 or 9 rounds
of builds and up to 15 overwrites. And if the requester is in a
different timezone then the ticket assignee, it surely will take several
days.

Regards,
Christoph

[Jesse Keating]

Post by Christoph Wickert
If the ticket is assigned to a single person, I doubt we can do the
overwrites in a timely manner. Remember, I'm wasn't talking about a
single overwrite but about large build chains that require 8 or 9 rounds
of builds and up to 15 overwrites. And if the requester is in a
different timezone then the ticket assignee, it surely will take several
days.

New tickets for each override, make tag-request helps here.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100218/a2152139/attachment.bin

[Till Maas]

Post by Jesse Keating
We don't really have a coverage list, but most of the people who have
been doing tagging are all in the US time zones, so anything outside of
that is welcome.

Ok.

Post by Jesse Keating
https://fedoraproject.org/wiki/Buildroot_override_SOP is the working SOP
we have for this, although I notice it doesn't say what to do with the
tickets. We typically assign the ticket to ourself, whoever is doing
the tag, so that when the reporter says the build is done we see it and
can do the untag and close the ticket.

I updated it to mention the ticket handling.

I just wonder, is there no verification done one the request, e.g. is
everybody allowed to request a build override or is it restricted to
package (co)maintainers and provenpackagers?
I only found this regarding verification:

| Buildroot overrides usually means that something is soname bumping. Be
| sure this is a sane update to do in Fedora

How is this handled?

Post by Jesse Keating
https://fedorahosted.org/rel-eng/report/3 can help you somewhat see the
means it likely hasn't been operated on.

This query only reports tickets assigned to rel-eng@ in the component
koji, I guess it is more accurate or are there many tag requests that
are not in the koji component?
https://fedorahosted.org/rel-eng/query?status=new&status=assigned&status=reopened&component=koji&owner=rel-eng%40lists.fedoraproject.org&order=priority

I added this to the SOP as well.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100219/87424ca6/attachment.bin

[Jesse Keating]

Sorry for the delay in getting back.

Post by Till Maas
I updated it to mention the ticket handling.
I just wonder, is there no verification done one the request, e.g. is
everybody allowed to request a build override or is it restricted to
package (co)maintainers and provenpackagers?
| Buildroot overrides usually means that something is soname bumping. Be
| sure this is a sane update to do in Fedora
How is this handled?

Not very well (: It's very vague and not helpful I understand. We
don't really do any verification that the person requesting the override
is the person owning the package, we've just assumed that the requester
knew what they were doing for the most part. As far as "sane update",
we've seen recently that this is a very... varied meaning, so it's
probably best to remove this and instead reference the current update
guidelines we have. I think it's something of a gut feeling as far as
whether the update should be questioned. Updating something like python
and requiring everything to be built against it would not be OK, but
that's a pretty extreme end of the spectrum.

Post by Till Maas

Post by Jesse Keating
https://fedorahosted.org/rel-eng/report/3 can help you somewhat see the
means it likely hasn't been operated on.

koji, I guess it is more accurate or are there many tag requests that
are not in the koji component?

Because the releng trac is a webform, and we have more than one
component, users have accidentally picked the wrong component for the
tag requests, and have accidentally forced assignment of the tickets.
For those reasons I thought it best to look at every ticket and examine
the subject line to see if it's a tag request or not, as humans cannot
be trusted to not make mistakes :/

Post by Till Maas
https://fedorahosted.org/rel-eng/query?status=new&status=assigned&status=reopened&component=koji&owner=rel-eng%40lists.fedoraproject.org&order=priority
I added this to the SOP as well.

--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100308/4d7a68a6/attachment-0001.bin

[Bruno Wolff III]

On Thu, Feb 18, 2010 at 01:32:33 +0100,

Post by Christoph Wickert
There is more flexibility for n+2 but I doubt that anybody will/can make
use of it. We not even have a feature process for F14, so why would
anyone start a feature now?

Because it didn't make it for F13?

I have stuff I want to start doing for F14 or F13 updates. There is a
dependency on something in linux-next, though I can start doing some stuff
before the 2.6.34 kernel lands in F14.

[Till Maas]

Post by Christoph Wickert

Post by Till Maas

...

Usually when some of mine packages need to be rebuild because of updated
dependencies, the communication is usually one-way. I get informed that
the packages needs to be rebuild and then it happens soon afterwards,

You are lucky. In the past people broke my package without further
notice and I had to take care of fixing them. On the other hand there
are maintainers, that announce changes in advance and ask me if I'm fine
with them rebuilding my packages or if I want to take care of this
myself. This is how it should be but only proven packagers will be able
to do this.

I guess a recommended procedure for this is not really documented in the
wiki, but since I was never in the situation to rebuild a bunch of
dependent packages, I do not really know.

Post by Christoph Wickert
Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
KDE app is always aware of the changes before they happen. If things
still seem to be working in F-13 or rawhide, he might not even be aware
of the custom tag.

Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.

Post by Christoph Wickert

Post by Till Maas
therefore I do not even have to know how the tag is called. There are
also scripts that help to do this easily afaik. This is also the
advantage of using a tag, because then I can still create bugfixes by
myself without being disturbed my the buildroots. Off course then the
package also needs to be rebuilt in the staging tag, but this can be
easily automated and already might be.

Honestly, I don't recall automated updates of my packages except for the
mass rebuilds from rel-eng. If the people that break things and/or
requested the custom tag will take care of this, we are fine, bug FWIW
it's not like this in rawhide. Let's see how it turns out in F-13.

I remember this for python and openssl and I believe the haskell or
ocaml SIG did this for their packages, too.

Post by Christoph Wickert

Post by Till Maas
and F-13 is now stabilizing and afaik should be treated
more like it was stable than like it is rawhide. E.g. major updates
should now break rawhide first and if the fallout is handled, then it
could be done for F-13.

I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze. If we need to do things
in rawhide first and only push these changes to F-13 afterwards, a
feature with a tight schedule like Xfce 4.8 is lost. That's just what I
said.

It would be sad to loose the feature, only because of the schedule, but
I guess there will always be some feature that needs to be postponed
because of missing some deadline shortly. Nevertheless it would be good
to speed up procedures to get as much features as possible. So maybe you
can already request the tag you will need once Xfce 4.8 is released to
start building it as soon as it is released.

Regards
Till

[Kevin Kofler]

Post by Till Maas

Post by Christoph Wickert
Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
KDE app is always aware of the changes before they happen. If things
still seem to be working in F-13 or rawhide, he might not even be aware
of the custom tag.

Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.

The solution there is to talk to us, we can get the Qt 4.6 stuff off the
buildroot for a while so he can build his bugfix update. That's what
#fedora-kde is for. (IRC is the best communication method for this stuff
because it's real time, please use it!)

Kevin Kofler

[Sven Lankes]

Post by Kevin Kofler

Post by Till Maas
Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.

The solution there is to talk to us, we can get the Qt 4.6 stuff off the
buildroot for a while so he can build his bugfix update. That's what
#fedora-kde is for. (IRC is the best communication method for this stuff
because it's real time, please use it!)

I'm assuming that Till is talking about my comment
https://bugzilla.redhat.com/show_bug.cgi?id=549717#c2 on merkaartor
(which he co-maintains).

So nothing to see here - please move on. This is about not being able to
do a scratch build of an svn-snapshot of merkaartor. Nothing that I
would ever push to a stable release.

I am well aware of the possibility to un-push qt from the buildroot but
this was not a situation where that was needed.

[Kevin Kofler]

Post by Sven Lankes
I'm assuming that Till is talking about my comment
https://bugzilla.redhat.com/show_bug.cgi?id=549717#c2 on merkaartor
(which he co-maintains).
So nothing to see here - please move on. This is about not being able to
do a scratch build of an svn-snapshot of merkaartor. Nothing that I
would ever push to a stable release.
I am well aware of the possibility to un-push qt from the buildroot but
this was not a situation where that was needed.

Yeah, fiddling with buildroot for a scratch build is a bit overkill. :-)

(That said, if the SVN snapshot fixes some important bug, I'd consider
pushing it, depending on how long it is until the release.)

Kevin Kofler

[Till Maas]

Post by Sven Lankes

Post by Kevin Kofler

Post by Till Maas
Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.

The solution there is to talk to us, we can get the Qt 4.6 stuff off the
buildroot for a while so he can build his bugfix update. That's what
#fedora-kde is for. (IRC is the best communication method for this stuff
because it's real time, please use it!)

I'm assuming that Till is talking about my comment
https://bugzilla.redhat.com/show_bug.cgi?id=549717#c2 on merkaartor
(which he co-maintains).
So nothing to see here - please move on. This is about not being able to
do a scratch build of an svn-snapshot of merkaartor. Nothing that I
would ever push to a stable release.

Yes, this was the comment I meant. Since it seems to be easily possible
to push an updated merkaartor package, I am more in favor to push it.
The bug is already two months old and renders the Fedora package for the
reporter useless. Also merkaartor upstream provides windows binary
releases based on snapshots:
http://www.merkaartor.org/

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100218/5994aff1/attachment.bin

[Till Maas]

Post by Kevin Kofler

Post by Till Maas

Post by Christoph Wickert
Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
KDE app is always aware of the changes before they happen. If things
still seem to be working in F-13 or rawhide, he might not even be aware
of the custom tag.

Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.

The solution there is to talk to us, we can get the Qt 4.6 stuff off the
buildroot for a while so he can build his bugfix update. That's what
#fedora-kde is for. (IRC is the best communication method for this stuff
because it's real time, please use it!)

I'll remember this. But why don't you use a special tag for this instead
of a buildroot override? I believe this question is not answered and I
even might have asked it once in IRC. ;-)

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100218/6f981ec0/attachment-0001.bin

[Kevin Kofler]

Post by Till Maas
I'll remember this. But why don't you use a special tag for this instead
of a buildroot override? I believe this question is not answered and I
even might have asked it once in IRC. ;-)

Because, as has been said earlier in this thread, special tags also have
their problems:
* explosion of special tags. If we had used a special tag for all the KDE
upgrades (which all needed buildroot overrides, or would have under the
current procedure) since F12 Alpha (which had 4.3.0), we'd now have:
dist-f12-kde431
dist-f12-kde432
== beta was here (so the above didn't need buildroot overrides under the old
system), F12 final also shipped with 4.3.2 ==
dist-f12-kde433
dist-f12-kde434
dist-f12-kde435
dist-f12-kde440
For F11, (counting from Beta because that was the old system with
Alpha/Beta/Preview), we'd have all these plus 4 more (4.2.2, 4.2.3, 4.2.4,
4.3.0).
If every grouped update did that, Koji would be littered with special tags.
* problems with merging from the special tags (what if dist-f12-kde440 and
dist-f12-someotherlib123 both carry their own rebuilds of, say, compiz? It
might not even get noticed if they're on different special tags. Depending
on which of the builds "wins", one or the other dependency will be broken)

Kevin Kofler

[Jesse Keating]

Post by Kevin Kofler

Post by Till Maas
I'll remember this. But why don't you use a special tag for this instead
of a buildroot override? I believe this question is not answered and I
even might have asked it once in IRC. ;-)

Because, as has been said earlier in this thread, special tags also have
* explosion of special tags. If we had used a special tag for all the KDE
upgrades (which all needed buildroot overrides, or would have under the
dist-f12-kde431
dist-f12-kde432
== beta was here (so the above didn't need buildroot overrides under the old
system), F12 final also shipped with 4.3.2 ==
dist-f12-kde433
dist-f12-kde434
dist-f12-kde435
dist-f12-kde440
For F11, (counting from Beta because that was the old system with
Alpha/Beta/Preview), we'd have all these plus 4 more (4.2.2, 4.2.3, 4.2.4,
4.3.0).
If every grouped update did that, Koji would be littered with special tags.
* problems with merging from the special tags (what if dist-f12-kde440 and
dist-f12-someotherlib123 both carry their own rebuilds of, say, compiz? It
might not even get noticed if they're on different special tags. Depending
on which of the builds "wins", one or the other dependency will be broken)
Kevin Kofler

We don't keep the tags around, we can remove them once the builds have
been merged.

As far as a special tag carrying a build different from the main tag, we
have scripts that check for this situation so that integration folks
like me can sort it out.

We obviously don't want to do special tags for every single set of
updates, but for larger sets it does make sense. Release Engineering is
here to serve that need and take care of these issues.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/d2cb8236/attachment.bin

[Till Maas]

Post by Kevin Kofler
If every grouped update did that, Koji would be littered with special tags.
* problems with merging from the special tags (what if dist-f12-kde440 and
dist-f12-someotherlib123 both carry their own rebuilds of, say, compiz? It
might not even get noticed if they're on different special tags. Depending
on which of the builds "wins", one or the other dependency will be broken)

KDE grouped updates are usually a lot bigger than most of the other
grouped updates, e.g. this has 60 packages in it:
https://admin.fedoraproject.org/updates/F11/FEDORA-2010-1850

Sometimes I create also a grouped update, which only contains two
packages, a library and the only package depending on it. So there is a
huge range that obviously needs to handled differently. If all packages
in an update set are maintained by the same group, there is no harm in
using a buildroot override. But as soon as several different maintainers
and there are a lot of packages to be updated and the buildroot
override is there for a long time, then using custom tags seem to be
appropriate for me.

Regards
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100218/0bf8c44a/attachment.bin

[Kevin Kofler]

Post by Christoph Wickert
You are lucky. In the past people broke my package without further
notice and I had to take care of fixing them. On the other hand there
are maintainers, that announce changes in advance and ask me if I'm fine
with them rebuilding my packages or if I want to take care of this
myself. This is how it should be but only proven packagers will be able
to do this.
Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
KDE app is always aware of the changes before they happen. If things
still seem to be working in F-13 or rawhide, he might not even be aware
of the custom tag.

In KDE SIG, for releases, we normally identify packages needing a rebuild
ourselves and will just rebuild them and include them in our update set.
(The branched F13 will also work like that, though I don't think we'll need
to bump another KDE-related soname from now to the F13 release, we're
tracking the stable 4.4.x branch now, even stuff like the kipi framework in
kdegraphics with unstable ABI keeps it stable in release branches.) For
Rawhide, we'll also rebuild stuff if the maintainer doesn't do it by
himself, but usually we'll give the maintainer a chance to do it first.

We also announce the new versions and warn about the presence of buildroot
overrides in devel-announce, as well as on our own mailing list and IRC
chan. If people don't read even devel-announce, there's nothing we can do
about that, we aren't telepathic. ;-) It also helps to be on #fedora-kde on
IRC if you maintain KDE/Qt packages, but the important announcements go to
devel-announce as well.

Post by Christoph Wickert
Honestly, I don't recall automated updates of my packages except for the
mass rebuilds from rel-eng. If the people that break things and/or
requested the custom tag will take care of this, we are fine, bug FWIW
it's not like this in rawhide. Let's see how it turns out in F-13.

I'll do what I can to fix broken dependencies (as I did in the past; I fixed
all the remaining broken dependencies for the F12 release), but I hope I
won't be the only one! I can probably fix all broken dependencies alone if
there are at most a dozen, but not if there are a hundred!

Post by Christoph Wickert
I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze. If we need to do things
in rawhide first and only push these changes to F-13 afterwards, a
feature with a tight schedule like Xfce 4.8 is lost. That's just what I
said.

You can build the stuff in F13 right away, you'll just need rel-eng help
with buildroot overrides.

Kevin Kofler

[Jesse Keating]

Post by Michal Schmidt
Would it help to use a special Koji tag for this?
Let's say you'd get a tag 'dist-f13-xfce48' where all packages built
there would be immediately available for building dependend packages.
And then when you're done, you'd ask rel-eng to tag them all at once
into 'dist-f13-updates-candidate'.

Yes, we can do a custom tag that self updates for update sets like this.
It just takes some coordination.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/5c5338bf/attachment.bin

[Jesse Keating]

Post by Christoph Wickert
How do we address this issue?

The same way we address it for updates to a stable Fedora.

Release Engineering is an open group, if there are significant delays in
getting tagging done we can certainly try to get more taggers into the
group.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/e44580e5/attachment.bin

[Matthias Clasen]

Post by Christoph Wickert
This means that large updates like Gnome, KDE or Xfce will get massively
delayed after alpha. They might not make it into one of the prereleases,
which means they get less testing. A lot of features will no longer be
possible in their current state.
How do we address this issue?

I don't use chain builds when updating gnome, so it can be done.
Please just complain for yourself...

[Kevin Kofler]

Post by Matthias Clasen
I don't use chain builds when updating gnome, so it can be done.
Please just complain for yourself...

The problem is that in KDE, the application modules from 4.x.n need to be
built against at least kdelibs 4.x.n, not 4.x.n-1 (and likewise for other
dependencies). (Often 4.x.n-1 works, but not always, and upstream doesn't
support it, so we always use matching releases. This requires buildroot
overrides in a non-self-populating buildroot.) This can be due to several
reasons: fixes in macros or inline functions, new APIs backported because
they were required to fix a bug, API change in something like kdebase-
workspace which doesn't have a guaranteed API/ABI (requiring e.g. kdeplasma-
addons to be built against the latest kdebase-workspace) etc.

XFCE may be similar.

Kevin Kofler

[Kevin Kofler]

Post by Christoph Wickert
This means that large updates like Gnome, KDE or Xfce will get massively
delayed after alpha. They might not make it into one of the prereleases,
which means they get less testing. A lot of features will no longer be
possible in their current state.
How do we address this issue?

For KDE, the same way as always, we'll just work with buildroot overrides,
we've done it during other freeze periods already. Even in the past, the
buildroots stopped being self-populating at final devel freeze. The only
change now is that this is happening 1 month earlier now.

That said, I wonder if it wouldn't make more sense to leave the buildroots
(and presumably the dist-f13 tag as well) to self-populate until the Beta
Freeze (formerly "final devel freeze"). It'd be perfectly possible to do
this even with the F13 branch existing. But I guess the decision has already
been made.

Kevin Kofler

[Kevin Kofler]

Post by Jesse Keating
There is one small wrinkle. I've "broken" the dist-rawhide static repo,
because I've made dist-rawhide a real build target to be used by builds
from devel/. I'll be making a symlink soon that will keep
"dist-rawhide" static repos pointed to the right location.

Why not use dist-f14?

Kevin Kofler

[Jesse Keating]

Post by Kevin Kofler

Post by Jesse Keating
There is one small wrinkle. I've "broken" the dist-rawhide static repo,
because I've made dist-rawhide a real build target to be used by builds
from devel/. I'll be making a symlink soon that will keep
"dist-rawhide" static repos pointed to the right location.

Why not use dist-f14?
Kevin Kofler

It makes some configs more simple, and helps a bunch with dist-git.
With dist-git we can assume that a build from master goes to
dist-rawhide, and a build from a branch goes to
dist-f##-updates-candidate and the ## comes from a 'branch' file within
the branch.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/a81bfc91/attachment.bin

[Ralf Corsepius]

Post by Jesse Keating
That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who "you" are, here are some "you"s
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
The real take away here is explained at
https://fedoraproject.org/wiki/Branch_Freeze_Policy
The upshot is that if you want to get a build into Fedora 13, you gotta
build from F-13/ and you gotta put it in bodhi. The good news is that
if your package isn't critical path, it's just like any other update in
bodhi, you decide when it goes stable. If it's critical path, releng or
QA will have to give it karma, but that means somebody will look at it!
(We're working on ways to make it more visible to the user that your
package is critical path).
pub/fedora/linux/development/rawhide<-- this is the new home of
rawhide. Builds from devel/ go here. This is now the F-14 development
ground.
pub/fedora/linux/development/13<-- this is the branched Fedora 13.
Builds from F-13/ that make it through bodhi as stable show up here.
This is what we'll use to make the Alpha, Beta, Final release and all
the snapshots in between and the nightly attempt at instllable images.
pub/fedora/linux/updates/testing/13<-- this is where the testing
updates go for the branched 13. Test 'em here before they go to stable.
For a better picture, see
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Tree.2FRepo_Overview
I have disabled the rsync part of the rawhide compose process so that I
can do things by hand tomorrow and ensure we don't screw up the mirrors,
so you'll see a delay in things. We'll also do the branched tree
compose by hand as well and then sync the output at the same time to
preserve hardlinks. It'll be a fun day! Hop by #fedora-devel if you've
got questions and somebody will try to help you.
Welcome to the world of No Frozen Rawhide!!!

Am I correct in assuming, wcorresponding mock setups for and yum
mirrorlists reflecting this new setup will be in place in time when
these repos go on-line?

Ralf

[Jesse Keating]

Post by Ralf Corsepius
Am I correct in assuming, wcorresponding mock setups for and yum
mirrorlists reflecting this new setup will be in place in time when
these repos go on-line?

yes. MirrorManager should already be working for these repos, I'll be
working on a mock update today.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/b8ace18a/attachment.bin

[Ralf Corsepius]

Post by Jesse Keating

Post by Ralf Corsepius
Am I correct in assuming, wcorresponding mock setups for and yum
mirrorlists reflecting this new setup will be in place in time when
these repos go on-line?

yes. MirrorManager should already be working for these repos, I'll be
working on a mock update today.

Where is the mock update?

It's been nearly 2 weeks since you've promissed to do so, but this
hasn't happened.

There still are no mock configurations providing setups for fedora-13
(/etc/mock/fedora-13-{i386,x86_64}.cfg)

Ralf

[Jesse Keating]

Post by Ralf Corsepius
Where is the mock update?
It's been nearly 2 weeks since you've promissed to do so, but this
hasn't happened.
There still are no mock configurations providing setups for fedora-13
(/etc/mock/fedora-13-{i386,x86_64}.cfg)

mock-1.0.5 was pushed into updates-testing a number of days ago that
includes the new 13 configs. They'll get moved over to the various
stables shortly.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100302/800b42e4/attachment.bin

[Ralf Corsepius]

Post by Jesse Keating

Post by Ralf Corsepius
Where is the mock update?
It's been nearly 2 weeks since you've promissed to do so, but this
hasn't happened.
There still are no mock configurations providing setups for fedora-13
(/etc/mock/fedora-13-{i386,x86_64}.cfg)

mock-1.0.5 was pushed into updates-testing a number of days ago that
includes the new 13 configs. They'll get moved over to the various
stables shortly.

Too late, you failed to provide them in time.

[Kevin Kofler]

Post by Ralf Corsepius

Post by Jesse Keating

Post by Ralf Corsepius
Where is the mock update?
It's been nearly 2 weeks since you've promissed to do so, but this
hasn't happened.
There still are no mock configurations providing setups for fedora-13
(/etc/mock/fedora-13-{i386,x86_64}.cfg)

mock-1.0.5 was pushed into updates-testing a number of days ago that
includes the new 13 configs. They'll get moved over to the various
stables shortly.

Too late, you failed to provide them in time.

+1

Yet another perfect example of an update which should have been pushed
directly to stable.

Kevin Kofler

[Jeffrey Ollie]

Post by Kevin Kofler
Yet another perfect example of an update which should have been pushed
directly to stable.

No, it's an example of an update that should have been pushed to
updates-testing sooner...

[Ralf Corsepius]

Post by Kevin Kofler

Post by Ralf Corsepius

Post by Jesse Keating

Post by Ralf Corsepius
Where is the mock update?
It's been nearly 2 weeks since you've promissed to do so, but this
hasn't happened.
There still are no mock configurations providing setups for fedora-13
(/etc/mock/fedora-13-{i386,x86_64}.cfg)

mock-1.0.5 was pushed into updates-testing a number of days ago that
includes the new 13 configs. They'll get moved over to the various
stables shortly.

Too late, you failed to provide them in time.

+1
Yet another perfect example of an update which should have been pushed
directly to stable.

No, this package should have been in place ("in updates") at the same
time, the F-13 branch had been activated in Fedora's CVS.

This wasn't the case, and thus likely caused:

* maintainers wanting to "make mockbuild" F-13 package in CVS to hit
build failures (I did so) or to test-build against the wrong repository
(building against rawhide instead of F-13).

* maintainers having to waste their time on reimplementing local
versions of /etc/mock/fedora-13-<*>.cfgs (I did so).

* third parties (e.g. rpmfusion) building packages against the wrong
repos, because they didn't notice they need to branch and away from rawhide.


It's a mistake, ... mistakes happen, ...

The only things making me angry about this, is this particular mistake
(mock *.cfg not being in place in time) not having happened for the
first time and when taking into account the responsible person's
attitude and position in Fedora.

Ralf

[Paul W. Frields]

Post by Ralf Corsepius

Post by Kevin Kofler

Post by Ralf Corsepius

Post by Jesse Keating

Post by Ralf Corsepius
Where is the mock update?
It's been nearly 2 weeks since you've promissed to do so, but this
hasn't happened.
There still are no mock configurations providing setups for fedora-13
(/etc/mock/fedora-13-{i386,x86_64}.cfg)

mock-1.0.5 was pushed into updates-testing a number of days ago that
includes the new 13 configs. They'll get moved over to the various
stables shortly.

Too late, you failed to provide them in time.

+1
Yet another perfect example of an update which should have been pushed
directly to stable.

No, this package should have been in place ("in updates") at the same
time, the F-13 branch had been activated in Fedora's CVS.
* maintainers wanting to "make mockbuild" F-13 package in CVS to hit
build failures (I did so) or to test-build against the wrong repository
(building against rawhide instead of F-13).
* maintainers having to waste their time on reimplementing local
versions of /etc/mock/fedora-13-<*>.cfgs (I did so).
* third parties (e.g. rpmfusion) building packages against the wrong
repos, because they didn't notice they need to branch and away from rawhide.
It's a mistake, ... mistakes happen, ...
The only things making me angry about this, is this particular mistake
(mock *.cfg not being in place in time) not having happened for the
first time and when taking into account the responsible person's
attitude and position in Fedora.

I looked up the rel-eng SOP for mass branching and added this item to
it, which I'm betting took no more time than writing unnecessarily
hostile email. Be part of the solution.

https://fedoraproject.org/w/index.php?title=Mass_Branching_SOP&diff=157055&oldid=152747

[Till Maas]

Post by Jesse Keating
That's right folks, we are now branched for Fedora 13. What does this
mean to you? Well that depends on who "you" are, here are some "you"s
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases
The real take away here is explained at
https://fedoraproject.org/wiki/Branch_Freeze_Policy

Is the branch freeze a week late or is it now the same as the alpha
freeze? In the "Important Release Milestones" wiki page[0], the branch
was scheduled for 2010-02-09, but on the F13 Schedule[1], the "Alpha
Freeze" links to the "Alpha Freeze Policy", which redirects to the
"Alpha Milestone", that then says the "Branch Freeze Policy" has to be
followed. The schedule itself does not say anything about branching.
It would help a lot to avoid duplicating content in the wiki, because it
only leads to out-of-sync contents and makes it harder to update it.

Regards
Till

[0] https://fedoraproject.org/wiki/Important_Release_Milestones
[1] https://fedoraproject.org/wiki/Releases/13/Schedule

[Jesse Keating]

Post by Till Maas
Is the branch freeze a week late or is it now the same as the alpha
freeze? In the "Important Release Milestones" wiki page[0], the branch
was scheduled for 2010-02-09, but on the F13 Schedule[1], the "Alpha
Freeze" links to the "Alpha Freeze Policy", which redirects to the
"Alpha Milestone", that then says the "Branch Freeze Policy" has to be
followed. The schedule itself does not say anything about branching.
It would help a lot to avoid duplicating content in the wiki, because it
only leads to out-of-sync contents and makes it harder to update it.

We are trying to track down the duplication and make canonical linkings.

The branch freeze happens at the branch event, which is a week after
Feature freeze. It's no longer an "Alpha Freeze" per se, because the
tree remains "frozen" even after alpha.

Originally we thought we'd branch at feature freeze, but then that would
mean we froze at feature freeze which was counter productive to moving
feature freeze a week earlier to allow last minute integration work to
happen unhindered.

Unfortunately we're going to have some rough times with documentation as
most of the documentation in the wiki isn't updated for how things work
with no frozen rawhide, but we're working on it. If you find more
places that need updating, please add them to
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan thanks!
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/3f591df9/attachment.bin

[Till Maas]

Post by Jesse Keating

Post by Till Maas
Is the branch freeze a week late or is it now the same as the alpha
freeze? In the "Important Release Milestones" wiki page[0], the branch
was scheduled for 2010-02-09, but on the F13 Schedule[1], the "Alpha
Freeze" links to the "Alpha Freeze Policy", which redirects to the
"Alpha Milestone", that then says the "Branch Freeze Policy" has to be
followed. The schedule itself does not say anything about branching.
It would help a lot to avoid duplicating content in the wiki, because it
only leads to out-of-sync contents and makes it harder to update it.

We are trying to track down the duplication and make canonical linkings.
The branch freeze happens at the branch event, which is a week after
Feature freeze. It's no longer an "Alpha Freeze" per se, because the
tree remains "frozen" even after alpha.

So how is the package set determined that builds the Alpha release? Is
it everything which is pushed to F13 in Bodhi for 2010-02-24 at 20:00
UTC, which is the time of the GO/NOGO meeting? Or is the Alpha release
first composed and then it is decided, whether it will be synced to the
mirrors?

Post by Jesse Keating
Unfortunately we're going to have some rough times with documentation as
most of the documentation in the wiki isn't updated for how things work
with no frozen rawhide, but we're working on it. If you find more
places that need updating, please add them to
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan thanks!

I added the differences between the F13 Schedule and the key milestones
there.

Regards
Till

[Jesse Keating]

Post by Till Maas
So how is the package set determined that builds the Alpha release? Is
it everything which is pushed to F13 in Bodhi for 2010-02-24 at 20:00
UTC, which is the time of the GO/NOGO meeting? Or is the Alpha release
first composed and then it is decided, whether it will be synced to the
mirrors?

It'll work a lot like how it worked before. The things which make it
through bodhi (instead of releng tag requests) and wind up in the
pub/fedora/linux/development/13/ directory the day of the compose
attempt. If it's broken, we'll push more things, if not, we'll ship the
Alpha.

Post by Till Maas

Post by Jesse Keating
Unfortunately we're going to have some rough times with documentation as
most of the documentation in the wiki isn't updated for how things work
with no frozen rawhide, but we're working on it. If you find more
places that need updating, please add them to
https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan thanks!

I added the differences between the F13 Schedule and the key milestones
there.

Thanks, that's very helpful!
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100217/a5383740/attachment.bin