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

[Doug Ledford]

On 03/09/2010 07:46 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> Things like the libata kernel change and KDE 3 to 4 migration are
>> intentional events
> 
> That's the whole problem. Under our current model, we have places and times 
> where to perform those intentional disruptive changes, they're called 
> "releases". In a "consumable" Rawhide, we don't (*), and that's an 
> unavoidable limit to its consumability. Rawhide is a poor substitute for our 
> current release model.
> 
> (*) Sure, we can add "flag days" as you propose, but that's too often for 
> users (at least 6 times as often, anything less frequent would make 
> development basically impossible)

You're assuming that each "flag day" will in fact be one where the user
has to do something.  That's not necessarily true.  The hda->sda switch
happened, what, 2 years or more ago?  Yeah, it was a big deal.  We've
not really had an event like that since, and don't currently have one on
the horizon.  So, the FUD that 1 flag day per month means we'll actually
have 1 user intervention required event per month is highly unlikely.

> No amount of testing, coordination etc. is going to make it acceptable to 
> e.g. dump KDE 4 on KDE 3 users overnight.

You handle a flag day like a mini-release.  It's coordinate, users know
about it ahead of time, there is no dumping things on people overnight.

> Jesse is proposing to have automated QA as the ONLY filter for packages to 
> go to a supposedly "consumable" repository. So I replied that this cannot 
> work because it cannot catch all issues. At the very least, the maintainer 
> must be able to manually flag things as not being suitable for the 
> "consumable" repository just yet.

Sure.

> And to have something consumable enough to 
> replace (at least for a class of users) releases, something like updates-
> testing is needed.

Sure.  All you have to do is build into rawhide-unstable then tell users
to yum --enablerepo=rawhide-unstable upgrade foo to get that behavior if
you want.  You could split things out into two repos, but I'm not sure
it's entirely worth it.  But in general, yes, a testing repo would be
wise to have.

> No, my argument is that Rawhide cannot even meet what is the CURRENT bar of 
> our released products. For example, in KDE SIG, we DO NOT push changes we 
> know to be disruptive, e.g.:
> * KDE 4 as an update to a release which shipped with KDE 3,
> * Amarok 2 as an update to a release which shipped with Amarok 1,
> * KDevelop 4 as an update to a release which shipped with KDevelop 3,
> and similarly the kernel maintainers DID NOT enable libata in update kernels 
> for releases which shipped without libata, even when they pushed a new 
> kernel where upstream enabled libata by default. We also do not push feature 
> upgrades such as KDE 4.4 without long and tedious testing (as I explained 
> further up).
> 
> The current update system is NOT the free-for-all you seem to think it is. 
> The updates are actually very carefully weighed for risks vs. benefits. It's 
> NOT a "consumable Rawhide", and any attempt to replace them with a Rawhide 
> made "consumable" is bound to fail.

In your opinion.  I say it *could* succeed, and could be consumable.  I
say you lack the desire to see how things could be instead of how things
are.  You say I have rose colored glasses on.  We get it.

>> 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.
> 
> But I think you're entirely missing my point!

No, I very much get your point, I just think you are wrong.

-- 
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/20100311/e37d43bc/attachment.bin