Announcing Fedora Activity Day - Fedora Development Cycle 2009

Thorsten Leemhuis fedora at leemhuis.info
Mon Jun 1 17:49:44 UTC 2009


On 29.05.2009 22:57, Jesse Keating wrote:
> 
> Please feel free to use the discussion page on the wiki to express your
> thoughts about the event and what problems you're having with the
> development cycle.  Even thoughts on the initial proposal I drew up at
> the bottom of the wiki page would be welcome, although I do believe that
> this event will result in a proposal different from what is currently
> listed.

Find a few random thoughts/suggestions I added to the wiki below. I send
them here as well, because the page in the wiki feels to me like a place
in a corner where nearly nobody looks -- thus it's unlikely that a real
discussion evolves.

- 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

CU
knurd




More information about the fedora-devel-list mailing list