From Fedora Project Wiki

No edit summary
No edit summary
 
(2 intermediate revisions by 2 users not shown)
Line 3: Line 3:
* [[User:Bruno]]: For discussion at the event: What might have been done to avoid the two one week slips that happened very close to the release of F11?
* [[User:Bruno]]: For discussion at the event: What might have been done to avoid the two one week slips that happened very close to the release of F11?
** [[User:jkeating]]: Unfortunately the only thing that would have prevented these was earlier detection of the bugs in question, and earlier understanding of the severity of the bugs.  We have made a change that any crasher bug in anaconda land is immediately proposed as a blocker, which should get the attention of more people to determine the severity and better plan the release.
** [[User:jkeating]]: Unfortunately the only thing that would have prevented these was earlier detection of the bugs in question, and earlier understanding of the severity of the bugs.  We have made a change that any crasher bug in anaconda land is immediately proposed as a blocker, which should get the attention of more people to determine the severity and better plan the release.
* [[User:thl]]: <code>A few random thoughts/suggestions:
*** [[User:Bruno]]: Are there other things that could be done to encourage people to do test installs earlier? For example having an install / update test day much earlier in the development cycle? This may have been an especially problematic development cycle for Anaconda because of the scope of the changes. If comparable (in scope) changes are planned for future development cycles, is there anything special you'd want to do? For example start very early or split off a parallel version that is developed over two cycles instead of one.
**** [[User:Cra]]: I know for myself at least I'd like to test installs earlier, but especially with the major changes in the anaconda rewrite it was a bit scary to let it loose on an important system, even to just install the new release in parallel with the stable release.  Unfortunately, that limits testing to "test" systems which don't necessarily have the same varied partition layouts and block device stacks, graphics cards, etc.  If only there was a quick and easy way to backup a production system, or clone its layout onto a test system (perhaps under virtualization) so that testing could be done every day without worry...  Also, after getting the install to work once, it is somewhat of a drag to blow it away to test tomorrow's installer.  One likes to get on with life and test the release itself at that point, rather than expose the system you use every day to more risk of installer issues losing your whole system.


- should we set an way earlier freezes date for things like anaconda, kernel, isolinux, grub and other crucial pieces to make sure they are in better shape a bit earlier and thus are less likely a reason for release slips?
Email threads regarding this topic:
 
* https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02342.html
- do we need better communication/more detailed release schedule? I've seen you writing this in #fedora-kernel recently:
* https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00017.html
 
> 18:52:18 <        f13> | so here's the deal
> 18:52:25 <        f13> | I need a kernel today, that fixes those bugs on the blocker list
> 18:52:34 <        f13> | or we decide that those bugs are not worth fixing
> 18:52:40 <        f13> | or we slip the release, again.
> 18:52:53 <        f13> | and by "today" I mean building in the next hour or so
 
From the discussion after that it looked a whole lot like as if some important kernel developers where *not* aware that the kernel for the release was needed on that day, which I find quite alarming... (even if you got a proper kernel after you wrote the text quoted above)
 
- how about reducing the number or zero day updates (which is ridiculous high for F11) by setting a different, later freeze date for all packages that are neither on the install DVD or on a Spin?
 
- other distributions seems to manage a whole lot more test releases (e.g. alphas, beta, RC, milestones, ...) per devel cycle; is that something we should aim for as well?
 
- at least it sometimes feels like "rawhide installation using boot.iso feels like broken for weeks or months". That annoying and confusing even for people like me. How about targetting "rawhide must be install-able using boot.iso every Friday; crazy new stuff (like a new python release) must get imported on Mondays with the goal to have things in a good shape by Friday"
 
- how about doing something like a "cp -l development devel-snapshot" now and then (once a week) when we know rawhide is mostly working?
 
- how can we reduce our time between finishing a (test) release and releasing it dramatically? It seems other distributions get new (test) release out to the users a lot quicker then the three to five days days we require, which seems a whole lot for a devel cycle that takes 180 days in total (and we all know how much rawhide can move on with a few days)
 
- the anaconda storage rewrite was a bit bumpy and created lot of trouble this devel cycle; what will get taken to make things like that more smooth in the future?
 
- I'd be glad if we could stick to our release targets a lot better. Delaying releases looks quite unprofessional. Delaying also creates trouble for those depending on our releases. Take computer magazines (which have hard deadlines for productions) that might want to ship with a new release on a CD or DVD together with the next issue -- due to our fame in missing deadlines it seems to me that we are a lot more unattractive than Ubuntu (which afaics is on the shelf's here in Germany with new computer magazines just a few days after it has been released)
 
- why do we have to slip by a whole week most of the time? can't we find ways to slip just a day or two if there really is no way around a delay?
 
- I like the idea to "keep rawhide (nearly) always moving" a lot
 
- until a year or a bit more ago we had three test releases, now we have alpha, beta and preview -- were the changes done together with the renaming worth it (btw, for me it feels a lot like "not much changed" apart from the names).
 
- I'd be glad if the final release directories (e.g. release/12/Everything" could be available earlier, even if what is in them is not yet what "12" actually will become</code>

Latest revision as of 23:19, 3 June 2009

  • User:Bruno: One thing I would like to see is rawhide look more like the version it is becoming. For example the $releasever string doesn't work as expected (at least to me) in repo definitions. So perhaps when creating fedora-release the version could be (for say the F11 rawhide) -11-0.rawhide.1 instead of -10.91 .
    • User:jkeating: This is something I've been thinking about as well. The numbers used to match up with where they would land on the mirrors, releases/test/10.91 or so, but now they don't, so we should re-think that strategy. Thanks for bringing it up!
  • User:Bruno: For discussion at the event: What might have been done to avoid the two one week slips that happened very close to the release of F11?
    • User:jkeating: Unfortunately the only thing that would have prevented these was earlier detection of the bugs in question, and earlier understanding of the severity of the bugs. We have made a change that any crasher bug in anaconda land is immediately proposed as a blocker, which should get the attention of more people to determine the severity and better plan the release.
      • User:Bruno: Are there other things that could be done to encourage people to do test installs earlier? For example having an install / update test day much earlier in the development cycle? This may have been an especially problematic development cycle for Anaconda because of the scope of the changes. If comparable (in scope) changes are planned for future development cycles, is there anything special you'd want to do? For example start very early or split off a parallel version that is developed over two cycles instead of one.
        • User:Cra: I know for myself at least I'd like to test installs earlier, but especially with the major changes in the anaconda rewrite it was a bit scary to let it loose on an important system, even to just install the new release in parallel with the stable release. Unfortunately, that limits testing to "test" systems which don't necessarily have the same varied partition layouts and block device stacks, graphics cards, etc. If only there was a quick and easy way to backup a production system, or clone its layout onto a test system (perhaps under virtualization) so that testing could be done every day without worry... Also, after getting the install to work once, it is somewhat of a drag to blow it away to test tomorrow's installer. One likes to get on with life and test the release itself at that point, rather than expose the system you use every day to more risk of installer issues losing your whole system.

Email threads regarding this topic:

Retrieved from "https://fedoraproject.org/w/index.php?title=Talk:Fedora_Activity_Day_Fedora_Development_Cycle_2009&oldid=105988"