Updates Criteria Summary/Brainstorming

Till Maas opensource at till.name
Wed Nov 24 23:13:39 UTC 2010

On Mon, Nov 22, 2010 at 03:04:30PM -0800, Mike Fedyk wrote:

> This still builds a reactive system instead of a preventative system.
> An only reactive system will not help prevent bad updates from getting
> out in the first place.
> That said, adding a reactive component to a preventative system would
> be a good thing.  If a maintainer releases one package that puts
> regressions into the stable updates repo, then the minimum karma
> doubles on all of their packages doubles for 2 months or something
> like that.
> So feel free to push directly to stable as often as you want, but once
> you introduce one regression, you have to satisfy 10 karma on every
> package you update.  The second time, you have to satisfy 20 karma on
> every package you update and so on.

Fedora could as well just stop published updates at all, then no bad
updates will hit stable ever.

> Simply because we can't trust that maintainer anymore.

How is it the fault of the maintainer when ten testers certified that
the update is ok even when it was not?

> Really, allowing regressions to make it to stable is so costly simply
> because it has to be fixed several magnitudes more times than if it is
> caught by people actually testing packages before they're released to
> the masses.

In general I have to more often experience the same bugs that others
already found because of old package than I have to fix regressions. At
least during a release, when I have to update to a new Fedora release,
bugs tend to come back.

But to prevent this I would like to have automatic tested instead of
lots of error prone manual testing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101125/d38e3e09/attachment.bin 

More information about the devel mailing list