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

[Kevin Kofler]

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) and there's also no way for a user to say 
"I'm not ready for a flag day now, I'll just skip one or move at some point 
between this flag day and the next one" and still get updates, unlike now 
where they can skip a release and still get updates all along.

> and all that's needed to make the transition smooth is to coordinate the
> release of a seamless upgrade package set.

No. The problem with the above changes is not the consistency of the update 
set, it's that they do major changes to the user's machine, such as feature 
regressions, new bugs, requiring manual adjustment of settings (e.g. 
s/hda/sda/ in some config files) etc.

Let's call the old state (e.g. KDE 3) S and the new state (e.g. KDE 4) S'. 
The big issue here is not the consistency, quality or whatever attributes of 
the new state S', but the state transition from S to S'. Even if we fix all 
the inherent problems of S', that still doesn't make it a valid state for S 
to transition into.

> You make it sound like these things are impossible when nothing could be
> further from the truth.

I only make those things sound impossible which actually ARE impossible. See 
above.

No amount of testing, coordination etc. is going to make it acceptable to 
e.g. dump KDE 4 on KDE 3 users overnight. If my only 2 alternatives are to 
get that kind of updates ("consumable" Rawhide) or to get no new features 
(and quite possibly even only limited bugfixes) at all (conservative 
updates), there is no alternative suitable for me. Nor for the dozens of 
users who voted "adventurous" in Adam Williamson's poll. (No matter whether 
you consider that sample representative or not, you can't argue away the 
over a hundred users who voted that way in the sample itself! Claiming they 
were all misled by the question is also not really credible.)

> 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.

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. And to have something consumable enough to 
replace (at least for a class of users) releases, something like updates-
testing is needed. (No, I don't think ALL updates need to go through 
updates-testing. There are several cases where I think pushing directly to 
stable is the correct solution. But that doesn't mean that updates-testing 
is useless nor that users who want non-conservative updates want untested 
updates!)

> 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).

I still think we did the right thing pushing KDE 4.4.0. It fixed a lot more 
issues than it caused. (Upstream counts thousands of fixed bugs.) And for 
many people it just works. There's that slight annoyance in the form of a 
message box when starting up kdepim apps which can be easily worked around 
(either just click it away, or enable Nepomuk and have it gone for good), 
and which should be solved for good with the kde-settings update we're 
pushing (Nepomuk will be enabled by default), but other than that, I haven't 
seen any widespread issues. It's NOT an update like KDE 3 to 4 which would 
be insane to push to a stable release.

I'll also point out that 4.4.0 has been through a lot of testing, we've had 
prereleases in Rawhide and kde-redhat unstable, then 4.4.0 itself was also 
tested for more than 2 weeks before we declared it stable. During all this 
time, we fixed several regressions (and a few other bugs). The stuff which 
was in Rawhide is NOT something I'd have wanted on my production machines! 
The 4.4.0 release is.

> 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.

Sorry, I still consider KDE 4.4.0 a NON-disruptive update. See above.

> 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.

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.

I am NOT proposing to lower the bar. In fact, it can't really be lowered, 
e.g. pushing updates of the above type would make having releases 
essentially useless. I'm just proposing not to raise it, as the current 
setting of the bar is already optimal.

> 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!

        Kevin Kofler