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