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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
