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_O...
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 wrote, at 02/17/2010 01:10 PM +9:00:
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
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
On Wed, 2010-02-17 at 13:27 +0900, Mamoru Tasaka wrote:
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.
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.
On 17/02/10 04:31, Jesse Keating wrote: --snipped--
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.
On Wed, 2010-02-17 at 08:26 +0000, Frank Murphy wrote:
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.
On Wed, Feb 17, 2010 at 15:11, Jesse Keating jkeating@redhat.com wrote:
On Wed, 2010-02-17 at 08:26 +0000, Frank Murphy wrote:
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
On Wed, 2010-02-17 at 15:50 +0100, Mathieu Bridon wrote:
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.
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.
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote:
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
On Wed, Feb 17, 2010 at 04:40:33PM +0100, Till Maas wrote:
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote:
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/Ever... mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=... 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
On Wed, Feb 17, 2010 at 11:52:57AM -0600, Matt Domsch wrote:
On Wed, Feb 17, 2010 at 04:40:33PM +0100, Till Maas wrote:
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote:
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
Am Dienstag, den 16.02.2010, 20:31 -0800 schrieb 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
On Wed, 17 Feb 2010 10:04:13 +0100 Christoph Wickert wrote:
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
Am Mittwoch, den 17.02.2010, 10:34 +0100 schrieb Michal Schmidt:
On Wed, 17 Feb 2010 10:04:13 +0100 Christoph Wickert wrote:
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
On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote:
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
Am Mittwoch, den 17.02.2010, 12:18 +0100 schrieb Till Maas:
On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote:
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.
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.
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.
Regards Till
Regards, Christoph
On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
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.
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.
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
Am Mittwoch, den 17.02.2010, 15:07 +0100 schrieb Till Maas:
On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
...
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.
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 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.
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.
Regards Till
Regards, Christoph
On Wed, 2010-02-17 at 15:28 +0100, Christoph Wickert wrote:
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.
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.
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.
Am Mittwoch, den 17.02.2010, 06:45 -0800 schrieb Jesse Keating:
On Wed, 2010-02-17 at 15:28 +0100, Christoph Wickert wrote:
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?
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
On Thu, 2010-02-18 at 01:32 +0100, Christoph Wickert wrote:
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.
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 wrote:
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)?
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
On Thu, 2010-02-18 at 04:18 +0100, Kevin Kofler wrote:
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.
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 wrote:
You're in Austria right?
Yes. But my wake times tend to be very chaotic. ;-)
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
On Wed, Feb 17, 2010 at 07:44:30PM -0800, Jesse Keating wrote:
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
On Thu, 2010-02-18 at 12:59 +0100, Till Maas wrote:
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.
Am Donnerstag, den 18.02.2010, 07:36 -0800 schrieb 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
On Thu, 2010-02-18 at 18:22 +0100, Christoph Wickert wrote:
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.
On Thu, Feb 18, 2010 at 07:36:09AM -0800, Jesse Keating wrote:
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.
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?
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.
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&st...
I added this to the SOP as well.
Regards Till
Sorry for the delay in getting back.
On Fri, 2010-02-19 at 20:05 +0100, Till Maas wrote:
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?
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.
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.
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?
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 :/
https://fedorahosted.org/rel-eng/query?status=new&status=assigned&st...
I added this to the SOP as well.
On Thu, Feb 18, 2010 at 01:32:33 +0100, Christoph Wickert christoph.wickert@googlemail.com wrote:
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.
On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote:
Am Mittwoch, den 17.02.2010, 15:07 +0100 schrieb Till Maas:
On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
...
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.
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.
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.
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
Till Maas wrote:
On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote:
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
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote:
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.
Sven Lankes wrote:
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
On Thu, Feb 18, 2010 at 12:24:45AM +0100, Sven Lankes wrote:
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote:
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
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote:
Till Maas wrote:
On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote:
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
Till Maas wrote:
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
On Thu, 2010-02-18 at 04:30 +0100, Kevin Kofler wrote:
Till Maas wrote:
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
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.
On Thu, Feb 18, 2010 at 04:30:31AM +0100, Kevin Kofler wrote:
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
Christoph Wickert wrote:
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.
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!
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
On Wed, 2010-02-17 at 10:34 +0100, Michal Schmidt wrote:
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.
On Wed, 2010-02-17 at 10:04 +0100, Christoph Wickert wrote:
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.
On Wed, 2010-02-17 at 10:04 +0100, Christoph Wickert wrote:
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...
Matthias Clasen wrote:
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
Christoph Wickert wrote:
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
Jesse Keating wrote:
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
On Wed, 2010-02-17 at 23:21 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
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.
On 02/17/2010 05:10 AM, Jesse Keating wrote:
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_O...
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
On Wed, 2010-02-17 at 05:45 +0100, Ralf Corsepius wrote:
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.
On 02/17/2010 03:16 PM, Jesse Keating wrote:
On Wed, 2010-02-17 at 05:45 +0100, Ralf Corsepius wrote:
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
On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
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.
On 03/03/2010 05:17 AM, Jesse Keating wrote:
On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
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.
Ralf Corsepius wrote:
On 03/03/2010 05:17 AM, Jesse Keating wrote:
On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
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
On Tue, Mar 2, 2010 at 10:54 PM, Kevin Kofler kevin.kofler@chello.at wrote:
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...
On 03/03/2010 05:54 AM, Kevin Kofler wrote:
Ralf Corsepius wrote:
On 03/03/2010 05:17 AM, Jesse Keating wrote:
On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
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
On Wed, Mar 03, 2010 at 06:47:23AM +0100, Ralf Corsepius wrote:
On 03/03/2010 05:54 AM, Kevin Kofler wrote:
Ralf Corsepius wrote:
On 03/03/2010 05:17 AM, Jesse Keating wrote:
On Wed, 2010-03-03 at 03:34 +0100, Ralf Corsepius wrote:
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.
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=1570...
On Tue, Feb 16, 2010 at 08:10:17PM -0800, Jesse Keating wrote:
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
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
On Wed, 2010-02-17 at 16:33 +0100, Till Maas wrote:
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!
On Wed, Feb 17, 2010 at 07:36:00AM -0800, Jesse Keating wrote:
On Wed, 2010-02-17 at 16:33 +0100, Till Maas wrote:
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?
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
On Wed, 2010-02-17 at 17:57 +0100, Till Maas wrote:
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.
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!