On 03/01/2010 11:57 AM, Tom "spot" Callaway wrote:
On 03/01/2010 11:52 AM, Peter Jones wrote:
> If you think this isn't the right way
> to provide a safety net for package maintainers - what is?
With the understanding that you're not specifically asking me that
question, I'd say that I'd prefer to first try to automate checks for
the most frequent update issues:
* Causes broken deps
* Breaks clean upgrade path between releases
* Has ABI/API change (and is a Critical Path package)
* Fails to pass any package specific sanity tests (as written by either
the maintainer, QA, rel-eng, or qualified contributors)
AutoQA has the potential to do this. I'd rather see energy and effort
spent on taking out these low hanging fruit. If, after that, we're still
having broken updates pushed directly to stable, then I'd be willing to
consider a policy with an enforced delay in "testing".
I *absolutely* agree that we need something like autoqa to let maintainers
know when they've made an error with the (relatively) simple things it can
detect. I'd also like a policy in place to help us avoid situations like the
recent dnssec unpleasantness.
--
Peter
RFC 882 put the dots in .com.