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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
