Tom Lane wrote:
Even for security updates? My experience says that this requirement
will prevent me from*ever* pushing updates. Case in point: libtiff,
which is a critpath package, has been in testing with a significant
security update for a week now. Its karma is still zero. When I get
the "old package" warning in another week, I am going to push it stable
... and if bodhi won't let me, I am going to come looking for a neck to
wring.
The proposed policy might be workable if we had a surplus of
proventester manpower available, but we obviously have not got that.
If you follow the test list, there are many new proventester applications.
I would suggest a timeout: once the package has been in testing for two
weeks, the maintainer may push it stable regardless of whether
proventesters have fallen down on the job. Or if you really think
maintainers of critpath packages cannot be trusted to make these
decisions, I would be willing to accept*negative* karma from more than
one proventester as being an override. But it is utterly unacceptable
for inaction to represent a veto.
Time isn't the issue. It's man power. Updates that stay in testing for
months with no one looking at them and then get pushed to stable have
broken things before.
Should the bodhi whine mail be CC'd to the test mailing list in a
digest-type mail like the updates-testing pushes? Then all proventesters
(and non-proventesters) are informed that there is a critpath pkg that
is needing some TLC?