Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

Tom Lane tgl at redhat.com
Sun Nov 4 15:57:43 UTC 2012


Panu Matilainen <pmatilai at laiskiainen.org> writes:
> On 11/04/2012 12:17 PM, Michael Scherer wrote:
>> And I am doubting that changing the release model will suddenly make
>> people do QA.

> Adam's point is that reducing the number of branches requiring QA should 
> permit more thorough QA with the scarce resources available, resources 
> which currently are spread too wide and too thin with the current model.

I understand his hope that it would help, but TBH I think it would make
things worse not better.  Consider:

* Currently, we get barely-adequate QA on the frontmost Fedora branch
and none to speak of on the back branches.  (Certainly for my packages,
the standard update cycle is "push update to testing, wait however long
bodhi makes me wait, push to stable" because nobody ever adds any karma
except maybe in the latest branch.)  That's tolerable, actually, because
you're not supposed to push anything but low-risk bugfix updates into
the back branches.  If you think it needs testing you probably shouldn't
be pushing it there.

* In a rolling release model, however, major changes are supposed to
eventually get pushed into all the branches.  Each time one gets pushed
further back, an appropriate amount of QA would need to get done, if you
want to have any expectation of not breaking that branch.  This looks
like *more* QA to me, not less.

The core problem I see here is that in a rolling-release environment,
there's nothing to ensure that major multiple-package-affecting changes
hit the "stable" branches in a consistent order.  That means that each
time you push one back, you are creating a unique new package set with a
unique new set of potential issues, and that's why QA would actually be
needed.  Now it's easy to see how to avoid that: force consistency.
But that idea leads you right back to the series-of-releases approach
that we have now.

			regards, tom lane


More information about the devel mailing list