Updates Criteria Summary/Brainstorming

[Mike Fedyk]

On Mon, Nov 22, 2010 at 9:04 AM, Till Maas <opensource at till.name> wrote:
> On Mon, Nov 22, 2010 at 09:57:40AM +0100, Henrik Nordström wrote:
>> sön 2010-11-21 klockan 11:00 +0100 skrev Till Maas:
>>
>> > I guess this can be somehow automated. E.g. change Bodhi to drop the
>> > karma requirements for packages that had e.g. two subsequent updates
>> > without any Bodhi feedback and re-enable it if they get feedback.
>>
>> That would be somewhat counter productive for the goal of actually
>> having testers, as it discourages maintainers looking for testers as a
>> way to improve their release process.
>
> I do not see how this discourages maintainers. I do not know of any
> package maintainer that stated that he did not want his updates tested.
> This would at least encourage people that want better tested updates to
> commit into testing them. The current problem is not that package
> maintainers do not want their packages tested, but that updates are
> delayed without any visible testing.
>

The result is that if you have several updates without any karma
points (positive or negative) in bohdi, your updates get out faster.
Once someone does start giving it karma (again, positive or negative)
your update is not subject to getting more karma points in order to
hit the updates repo.  Thus you punish the maintainer by giving
testing their packages.  It may work better if karma enforcement only
comes into effect if negative karma is given to an update.

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.

Simply because we can't trust that maintainer anymore.

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.