[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: 182 pending F11 stable updates. WTF?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]