Jesse Keating wrote:
On Fri, 2009-05-08 at 06:05 +0200, Ralf Corsepius wrote:
I am suggesting that you implement rawhide/testing, f11/testing and
f11/updates right now and get rid of "trac" (replace buildroot overrides
with button in koji or treat "push to stable" as "buildroot overrides").
I eventually do want to have the ability for maintainers to self service
buildroot overrides. We just don't have the code in place, nor enough
people to work on the code while we work on other things too.
Although while we're trying to finish up a release, I would ask where we
should publish the next rawhide, or what you mean by rawhide/testing.
This would resolve several issues packagers have been facing (and now
hit you) at once.
In particular would it help
* to prevent packages from queuing up on the packager's side, which
would have been released very soon/immediately after GA in any case.
We're going to be pushing an initial set of F11 updates in the next day
or so.
Why has this not be done earlier?
I 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.
* 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!
F11 GA development would be decoupled from F11 updates!
rel-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".
* 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".
This consideration shows, when packages are being added to rawhide or
undergo substanticial changes, right before your freeze.
You 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.
There 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.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
