Proposed udpates policy change

[Dan Horák]

Matthew Garrett píše v Po 08. 03. 2010 v 21:59 +0000: 
> This is the policy that I expect to be discussed during the Fesco 
> meeting tomorrow. This is entirely orthogonal to the ongoing discussions 
> regarding whether updates in stable releases should be expected to 
> provide features or purely bugfixes, and I don't see any conflict in 
> introducing it before those discussions have concluded.
> 
> Introduction
> ------------
> 
> We assume the following axioms:

I think first should come the answer on "what problem is this proposal
trying to solve?". Is it the plain number of updates? Is it the quality
of updates? What updates failed?

> 1) Updates to stable that result in any reduction of functionality to 
> the user are unacceptable.
> 
> 2) It is impossible to ensure that functionality will not be reduced 
> without sufficient testing.
> 
> 3) Sufficient testing of software inherently requires manual 
> intervention by more than one individual.
> 
> Proposal
> --------
> 
> The ability for maintainers to flag an update directly into the updates 
> repository will be disabled. Before being added to updates, the package 
> must receive a net karma of +3 in Bodhi.

Unfortunately this tries to use the "one size fits all" method, but this
can't work in the recent Fedora with the number of source packages
attacking the 10000 mark. And for sure there are packages with many
users (millions?) and on other side packages with few users (dozens or
even less). And as others said, sometimes it's hard to get even a
response from the reporter on his own bug ...

> It should be noted that this does not require that packages pass through 
> updates-testing. The package will appear in Bodhi as soon as the update 
> is available. If sufficient karma is added before a push occurs, and the 
> update is flagged for automatic pushing when the karma threshold is 
> reached, the update will be pushed directly to updates.
> 
> It is the expectation of Fesco that the majority of updates should 
> easily be able to garner the necessary karma in a minimal space of time. 
> Updates in response to functional regressions should be coordinated with 
> those who have observed these regressions in order to confirm that the 
> update fixes them correctly.

Yes, this can again work for the mainstream packages and not for the
rest. And as result the only way to get a newer version of a
non-mainstream package will be only to upgrade the whole distro with a
waiting time up to 6 months. The new release contains both bugfixes and
new features, because the author can't maintain multiple branches at a
time and is doing releases every few months - one of the open source
principles was release early, release often.

So what are the options if the situation is so serious that something
must be done:
- start automated testing of updates - let the machine work, it can do a
lot
- divide packages into more tiers - add one(?) level between critpatch
and the rest that would require better testing (for example containing
libraries used by another package), some statistics how much are
packages installed would be needed
- start creating personal repos with updated stuff - and I always
thought this is the wrong way that is used by other distros and their
users ...
- improve the updates delivery mechanism so the user can easily consume
the regular updates and also test and comment the non-stable ones, this
would also require educating the users that there can be a newer version
in updates-testing when they are not satisfied with the stable one
- every package must have a QA person, well at least 3 ...

And yes, there are some not very nice options too ...


Dan