Jeremy's Thoughts - Brrr. Freezes suck.
Cycling, Fedora, MIT SDM and Miscellany

Jeremy Katz
Date: 2007-09-05 16:36
Subject: Brrr. Freezes suck.
Security: Public
As we work towards getting another test release out the door, we've again hit the case where we end up not being ready at freeze time and thus dragging out the freeze. I think it's time to sit back and brainstorm a little bit about our freeze process, as clearly, it has hit a bit of strain point as the distribution has grown.

How things work today is that when we get to a freeze for a test release or a final release, we create a new tag to use to reference all of the builds which are going to be used for that release. Every package that's been built at that point gets the tag applied. From that point on, the only packages accepted for the release have to be explicitly requested and tagged. While we're frozen, we also point the developent/rawhide tree at the freeze tag -- this is to help maximize testing of the bits that are going to be the test release.

This has some nice upsides. One is that it gives us a relatively stable base to build a release from. Without locking down what we look at, then the number of changes makes getting things working even more difficult than it already is. A second is that rawhide matches what we're composing. That means the world of pre-test-release testers are looking at the same bits and finding the problems which inevitably exist, reporting them and helping to make the test release as smooth and clean as possible.

Unfortunately, there are some downsides too. One is that there's a lot of work that continues to go on and so when we unfreeze the world, there's a massive pile of changes that lands destabilizing the development tree. Another is that people make fixes intended for the test release but don't notify that it should be pulled in; this means that we end up with bugs going out that could have been trivially fixed. A third is that developers get frustrated by not being able to get testing on further changes (fixes or development) with quick turnaround.

Clearly, this isn't entirely optimal and the growing number of components, spins and length of freezes just makes that more obvious. The increasing amounts of concerns about the process also makes me hope that people have some ideas. So do you have any? Leave a comment or send me mail.

Some ideas I have just off the top of my head:

  • Keep things as they are

  • Don't freeze, just keep things rolling and try to spin a test release off of that (of course, I don't see that being very successful for getting test releases out...)

  • Introduce another repository beyond just the rawhide repo. Let that repo normally track rawhide very closely (day of lag? no lag?). At freeze time, the new repo follows a similar path to the current policy.

  • The above new repo plus auto-moving packages which have been in the development tree unchanged for n time period. This tries to catch the "I forgot to ask for the new package I built" while still making sure that it soaked and didn't have anything too terrible crop up

  • ...


Suggestions greatly appreciated :)
Post A Comment | 4 Comments | Share | Link






User: (Anonymous)
Date: 2007-09-05 21:17 (UTC)
Subject: only freeze the core packages
My suggestion would be to only freeze the packages that would be on the desktop live CD.
Reply | Thread | Link



Jeremy Katz
User: katzj
Date: 2007-09-05 21:46 (UTC)
Subject: Re: only freeze the core packages
But what about things which are on any of the other built-by-default composes (the normal Fedora installable DVD, KDE live image, the new FEL and Developer live images).

Also, doing that at the repo level becomes pretty difficult as the repo is just composed of "big pile of packages" :-/
Reply | Parent | Thread | Link



User: (Anonymous)
Date: 2007-09-05 23:04 (UTC)
Subject: A new core...
Well I would say that we need to learn from other groups on this one... Debian looks to be a good one... and to keep the rawhide theme, lets try the naming scheme:

Rawhide === Sid
Rowdy === Testing
Gil === Stable


Rawhide is where development is done... and new stuff can come/go/die all the time.

Rowdy gets forked at the first testing release. I would say that the first test release would essentially be a new 'core' with it containing just works for the anaconda install of @core,@base, @base-X: kernel, glibc, python, anaconda, etc. These would be frozen until release date except for fixes.
If a core feature didnt make it in by then.. well thats a management decision but it probably should go to the next release.

Everything else is driven towards getting into test-2... anything not ready for test-2 doesnt make it into F-X at release time.. Then you would have a final test and then ship... at which it becomes Gil. After it becomes Gil, then however items get 'updated' occurs..

Probably not workable :).. but hey I can armchair quarterback from NM

Smooge


Reply | Thread | Link



User: salimma
Date: 2007-09-10 22:23 (UTC)
Subject: (no subject)
Use Bodhi for pushing updates to Rawhide when it is in a frozen state?
Reply | Thread | Link



browse
my journal
September 2013