From Fedora Project Wiki
(Answer some discussions) |
No edit summary |
||
| (3 intermediate revisions by 3 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: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: | |||
* https://www.redhat.com/archives/fedora-devel-list/2009-May/msg02342.html | |||
* https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00017.html | |||
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.
- 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: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.
Email threads regarding this topic: