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@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
