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(a)redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband