FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-09-2010, 11:46 PM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-10-2010, 04:03 PM
Bruno Wolff III
 
Default To semi-rolling or not to semi-rolling, that is the question...

On Tue, Mar 09, 2010 at 14:06:12 -0500,
Doug Ledford <dledford@redhat.com> wrote:
>
> 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

I lived through the libata change and a coordinated release of updates is
not all that was needed in that case. For that change guinea pigs were needed
to test specific hardware. In my case my ATA card was having problems because
there were similarly identified cards that needed different drivers and it took
a while before the two sets were correctly identified. For a significant
part of that rawhide development the set of cards that worked switched back
and forth.

See https://bugzilla.redhat.com/show_bug.cgi?id=227281 for the saga.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 10:03 AM
psmith
 
Default To semi-rolling or not to semi-rolling, that is the question...

On 09/03/10 19:06, Doug Ledford wrote:
> 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.
>
>
god you don't half talk a lot of nonsense! if you want another ubuntu go
work for canonical and be done with it, fedora is great the way it is,
and if you asked your users instead of assuming you know what they want
you will find this out!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 08:39 PM
Doug Ledford
 
Default To semi-rolling or not to semi-rolling, that is the question...

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@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-11-2010, 11:35 PM
Kevin Kofler
 
Default To semi-rolling or not to semi-rolling, that is the question...

Doug Ledford wrote:
> 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.

There are many more changes which require user intervention, even if it's
not as obvious (as in "don't intervene and your system won't boot"). For
example, after upgrading from F8 to F9, i.e. moving from KDE 3 to KDE 4, I
had to tweak my desktop configuration in a few places. And even less blatant
changes sometimes require some sort of user intervention (such as recreating
some configuration because it's represented differently in the new version
and upstream didn't provide a way to migrate it automatically).

And required user intervention is not the only source of trouble, things
like feature regressions, data (e.g. savegame) compatibility etc. are, too.

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

Except it's not a mini-release. You can't just stay on the old branch (and
still get security, bugfix and other nondisruptive updates) if you aren't
ready for the change as you can with our releases.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 08:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org