On Mon, Jun 01, 2009 at 11:14:26AM -0700, Jesse Keating wrote: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: [...snip...] > > 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. And release day parties, moving translation deadlines for zero-day updates, and so on... There are a lot of moving parts to fit together. > > - 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. To what extent do these other distributions: (1) ...offer a set of tools by which anyone can produce something roughly equivalent to a milestone release, as I can do with pungi any day that the installer is working properly?* Honest question, not snark. (2) ...consume their content from another integrated packaging source upstream? * I realize that's a question unto itself, which Thorsten asked about later. Or rather, sooner: > > - 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. I didn't even know this last part. But I think many people, including me, rel-eng and QA, are interested in having a more consistently testable Rawhide. > > - 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? I'm getting out of my ken here, but could this be done in stages with I2 connected hosts getting the bits early/first and then moving on to others? [...snip...] > > - 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. There is a group of resources inside Red Hat that we're able to call on for enhancing press coverage of our releases. They've given us their expert opinion that Tuesdays are the best day for that. While it's not a concrete requirement to make use of those services, we tend to listen to the experts. In quite a number of cases, though, a slip necessitates additional testing which itself takes a number of days. Putting in a bug fix and respinning can have its own undesired effects.... > > - I like the idea to "keep rawhide (nearly) always moving" a lot It will be interesting to hear the brainstorming around this at the FAD. I think many people would be happy if that moving Rawhide train ended up serving the dual purpose of decreasing late changes in a release cycle, but I'm not sure there's a 1:1 fit there. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
