On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: > 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? I've asked some of these groups to do that, but it's like asking any other upstream. A lot of the problem stems from things like anaconda using more and more of other bits in the distro, which change significantly right at the freeze date, breaking anaconda. So while we're waiting for anaconda, it's really because something else changed late. I tried to mitigate this by setting the feature freeze back a week from the beta freeze, so that the nasty changes land a week before we freeze for beta, giving folks like anaconda time to survive. It almost worked, and maybe we need to extend that back even farther. > - 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) That's a fair point. We don't well document or communicate the "points of no return" as it were. We've also had to discuss how we set those. In the past it was the last point at which we could compose and upload the bits to the master mirror in order to have enough mirrors synced at release day. Now it seems more that we have to make that decision within enough time to spin up (or down) the marketing machine, which looks to require more leadtime than the mirrors do. > - 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? That's a bit hard to determine easily and programaticaly. I've all but given up on my quest to reduce the number of updates. It's just doesn't seem to be in line with the desires of the package maintainers, whether or not it's in line with the desires of (some of) the project leaders. > - 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? If there was a way to do it without adding stress and work needed to teams like releng, installer, etc.. that would be possible, also if they were done without freezes. But the overwhelming requests I get are of /less/ of these test releases rather than more. If our release cycle were 9 months or even 12~24 months it would make a lot more sense to have more milestones. But with only a 6 month cycle it gets hard to find time to do development in between all the already existing milestones. > > - 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" That's what we hoped to have with the post-beta snapshots. Hard to say if it's had any real impact, likely due to the short amount of time between beta and the final freeze/preview release. If we attempted to do snapshots leading up to the beta that might make it more noticeable, but then we're back in the realm of more milestones instead of less. > > - how about doing something like a "cp -l development devel-snapshot" > now and then (once a week) when we know rawhide is mostly working? > The rawhide trees for at least the past month are kept in the Fedora infrastructure and are even available by a public url. We haven't tagged any of them as "stable" though. > - 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) If we didn't care to let the mirrors sync up we could "release" it earlier. However what good does that do when nobody can /get/ to the release because none of the mirrors have it, and the ones that do can't help sync to those that don't because users are tying up all the bandwidth? > - 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? > Less snapshots for them to worry about, taking time away from the development and bugfixing effort. Automated testing. Better bug management. > - 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) What looks more unprofessional? Delaying the release, or hitting our date and releasing with bugs that eat people's data? Or releasing with broken graphics for large swaths of users? > - 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? The marketing machine has very strongly requested that we only do releases on Tuesdays. > - 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). At first the plan was just Alpha, Beta, and release. But people really wanted a final snapshot after the final freeze to base their tests on, so Preview came to be. Now we're talking about dropping Alpha because of it's dubious value at that point in the release cycle, which would reduce us back down to 2 major snapshots during the cycle, Beta and Preview. That's what the F12 schedule has right now. > > - 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 You'll have to enumerate why that is. One reason I've avoided this is added confusion as to when the "release" happens. If we created that directory and put content in there, would we have then released Fedora 12? When does it become "released" and thus trusted? > > CU > knurd -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
