Post by Ralf CorsepiusPost by Jesse KeatingWe're going to be pushing an initial set of F11 updates in the next day
or so.
Why has this not be done earlier?
Partly due to attention spent elsewhere, and partly because we'd rather
our tester base focused on the bits we're proposing for the release,
rather than the bits we're proposing to replace the release.
Post by Ralf CorsepiusI am already facing a pretty nice package queue jam on my part because
F11 is frozen and hasn't received any update for some time. None of
these updates are critical nevertheless they contain bug fixes and are
prerequisites for future development.
Post by Jesse KeatingPost by Ralf Corsepius* to prevent NEVR issues resulting from F-9, F-10 and F-12 being open,
while F-11 is frozen.
Won't help at all, as the F11 release repo doesn't change, nor do the
contents of the DVD, so F9/10 will always move ahead of the release.
You are missing the point: F11 updates would be open NOW!
Which doesn't help the DVD at all.
Post by Ralf CorsepiusF11 GA development would be decoupled from F11 updates!
Which doesn't help the situation where F10 updates will quickly grow NVR
higher than the F11 release.
Post by Ralf Corsepiusrel-eng would cherry-pick the packages they want to put on CD/DVD, while
F11 updates would move on and would already carry what otherwise would
hit GA after "release".
releng is a terrible place to "cherry pick". We can't watch each and
every build and decide what is good and what is bad to have in the
release. We have to rely on the informed maintainer proposing a package
break the freeze and be brought into the release.
Post by Ralf CorsepiusPost by Jesse KeatingPost by Ralf Corsepius* rawhide/testing would also help wrt. test rawhide for
experimental/unsafe stuff, which would help improving stability when
rel-eng brands a rawhide snapshot "Fedora release".
So you want a rawhide, and a rawerhide?
Neither, all I am saying is that your work flow _is not designed to help
stability_, but encourages prematurely shipping broken/untested "crap
stuff".
That's only if maintainers don't actually take the schedule and
development effort into consideration, completely ignoring the cycle and
only having "crap" packages in rawhide at the time of the freeze. If
they actually used good development practices, the packages in rawhide
at the time of the freeze would not be "crap", they would be the
packages they want in the release, and any changes would be to fix
unexpected bugs in those packages.
Post by Ralf CorsepiusThis consideration shows, when packages are being added to rawhide or
undergo substanticial changes, right before your freeze.
And how is this releng fault, when the maintainers are just plain not
following good development practices?
Post by Ralf CorsepiusYou end up with untested/likely broken packages in your release and
with Fedora releases which are not much more than "rawhide snapshots",
and CD/DVDs which aren't worth using.
Untested... that's why we compose rawhide from the frozen bits, rawhide
that is used by large numbers of people who are testing the software in
their every day use... That's why we find and fix numerous bugs that
improve the release. That's why good maintainers slow down their
changes prior to the freeze to lessen the risk and to increase the
chance that the release has good quality packages.
Post by Ralf CorsepiusPost by Jesse KeatingPost by Ralf CorsepiusThere would be one major difference: rel-eng, would have to herry-pick
and move around packages between F11 GA and F11/updates before the release.
We already do that based on maintainers and testers who propose and test
packages during freezes.
As having been said many times before: You can't and will never be able
to so - You are cheating to yourselves, all you can do is to test for
very few, very isolated issues, on packages you are familiar with.
Perhaps you're just not willing to use good development practices, and
are trying to find a reason to blame our development cycle when this
doesn't work out for you. I can't help but not agree with you.
--
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090508/04884f37/attachment.bin