Updates Criteria Summary/Brainstorming

[Kevin Kofler]

Till Maas wrote:
> All of this could be combined. E.g. packages with enough testers get
> test cases and need to fulfill stronger criteria. Packages with not so
> many testers get test cases and only need to fulfil that similar
> updates need to receive good karma on one Fedora release.
> 
> Off course more automated testing is missing instead of all the manual
> requirements.
> 
> Another idea would be to add a flag in bodhi to track whether a certain
> testing update has been installed and then have a tool to report this
> automatically back to Bodhi. Then there would be some information about
> silent testers, which can be used as a criterion, too.

All this stuff would really complicate Bodhi a lot, and make it even more 
bug-prone than it already is.

Why do we need to code this in software? Why can't we just make use of the 
wonderful deduction machine called a "brain", which every maintainer SHOULD 
have?

> Also it could be made easier for maintainers to identify problematic
> updates, e.g. by warning that the dependencies or provides of an update
> changed when the update is created.

That's something useful, and in fact AutoQA is supposed to do that (and 
we're still waiting for that!).

Doing repetitive consistency checks and warning the maintainer about 
potential or definite problems is what software is good at. Taking decisions 
is not!

        Kevin Kofler