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 :)