From Fedora Project Wiki

(Answer some discussions)
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:
- 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?
- do we need better communication/more detailed release schedule? I've seen you writing this in #fedora-kernel recently:
> 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>

Revision as of 17:48, 1 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:thl: A few random thoughts/suggestions:

- 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?

- do we need better communication/more detailed release schedule? I've seen you writing this in #fedora-kernel recently:

> 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