To semi-rolling or not to semi-rolling, that is the question...

[Doug Ledford]

On 03/09/2010 11:45 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> Slight variation on this.  All builds from devel/ (or master in the new
>> git world) would go to the koji tag dist-rawhide-candidate.  Builds
>> which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
>> the nature "rawhide acceptance" (this would have to get fleshed out at
>> some point, but it'd be something that builds upon the tests we would
>> already do post-build).  Builds that pass rawhide acceptance would get
>> tagged into dist-rawhide, would show up in the build roots, and would be
>> part of the nightly rawhide compose.  Builds that do not remain in
>> dist-rawhide-candidate.  A maintainer can review the failed cases and
>> make a decision, override the system or do a new build.  Egregious use
>> of system overriding would trigger FESCo attention and perhaps some sort
>> of retraining or sanctioning.
> 
> The assumption is that automated QA catches all possible breakage, which is 
> not true. In fact *no* QA will catch all the Rawhide breakage as some is 
> caused by the mere fact of things being different, which is intentional and 
> part of what Rawhide is about (e.g. the libata change in the kernel, the 
> change from KDE 3 to 4 etc.). Releases are needed to handle this kind of 
> changes in a smooth way. But automated QA will also miss many actual bugs.

Things like the libata kernel change and KDE 3 to 4 migration are
intentional events and all that's needed to make the transition smooth
is to coordinate the release of a seamless upgrade package set.  You
make it sound like these things are impossible when nothing could be
further from the truth.  And it's expected that a responsible maintainer
is aware of these sorts of intentional update events and all that needs
to be done is for them to conscientiously build their packages into the
rawhide-candidate dist repo and coordinate a release of a complete set
of packages.  Automated QA need not catch this type of event.

And automated QA *will* catch many more bugs than it misses (speaking
from the mouth of experience knowing all the automated QA checks my rhel
packages must pass prior to each update), and there was never an
assumption that it would catch *all* issues.  In fact the suggestion
that automated QA would need to catch *all* issues before the proposal
meets your approval makes it very apparent how disingenuous your stance
on this proposal is.

FACT: the semi-rolling update model you so love today is not foolproof
and does not keep users from experiencing periodic, occasional breakage
(see KDE update thread).
FACT: you are strongly in support of the current semi-rolling model that
you practice today (see multiple threads).
FACT: you have purported that even with things occasionally breaking as
they did on the recent KDE update, that these things are impossible to
prevent 100% and that the system is working "as designed" (see KDE thread).

So, for you to say this automated QA wouldn't catch *all* issues and
therefore this proposal is unworkable, and then on the other hand say
that major updates in RELEASED products that cause breakage are OK and
working "as designed" puts your hypocrisy very much in the spotlight.

A consumable rawhide need only meet the level that our released products
do today (a level that you personally have helped to drag down BTW) and
at that point you have *NO* valid grounds to object to it.  And if we
made rawhide meet that level of consumability, we should at the same
time be *raising* the bar for our released products.  Your argument
appears to be that since we can't make rawhide meet what should possibly
be the raised bar of the released products then the idea won't work so
lets lower the bar across the board and give up.

I'm sorry Kevin, but you and I will simply have to agree to disagree.  I
will *not* capitulate to your stance on this issue.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100309/46c7c5ad/attachment-0001.bin