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