182 pending F11 stable updates. WTF?

Ralf Corsepius rc040203 at freenet.de
Sat May 9 00:50:24 UTC 2009


Jesse Keating wrote:
> On Fri, 2009-05-08 at 06:56 +0200, Ralf Corsepius wrote:
>>> 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?
> 
> 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.
> 
>> 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!
> 
> Which doesn't help the DVD at all.

Pardon, but composing the DVD is solely YOUR problem, YOU need to find a 
solution for.

>> F11 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.
> 
>> 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".
> 
> 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.
... the informed "maintainers" did "submit packages through koji/bodhi" ...


>>>> * 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.
> 
>> This 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?
Quite simple: Your schedules and practices are widely irrelevant to 
contributors.

It's you who needs to synchronize your job with what contributors, 
upstreams and the rest of the worlds provides to you. It's naive of you 
to expect the rest of the world to synchronize with you!

>>   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.
> 
> 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.
Well, F11-Preview spoke a different language.

Even elementary key features were/are simply plain "unusable" and didn't 
even survive basic test.

Examples: anaconda, preupgrade, dbus, ...

>>>> 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.
> 
> Perhaps you're just not willing to use good development practices,

Rubbish - Perhaps your development practices are far from being "good"? 
Perhaps you're too close to be able to comprehend this? Perhaps your ego 
is in your way to comprehend?

> 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.
No, I want you to understand that there are other demands but yours and 
that your are better off taking them into account.

Ralf







More information about the fedora-devel-list mailing list