182 pending F11 stable updates. WTF?

Ralf Corsepius rc040203 at freenet.de
Fri May 8 04:56:04 UTC 2009


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




More information about the fedora-devel-list mailing list