On Wed, May 4, 2011 at 5:09 PM, Ben Walton <[email protected]> wrote: >... > Objections to this type of automation in the past have focused on the > benefits of the human inspection that we have currently. Nobody is > disputing that having other eyes on a package is a good thing. We > hope that people will continue poking at the packages in unstable and > filing bug reports.
"hoping", never leads to good quality process. when you switch to this, virtually all packages will have no-one but the maintainer looking at them before release. We're attempting to address the following issue > with the current process without reducing the ability for human QA: > > 1. Inconsistent application of policy. Multiple tools that implement > different standards or the same standards differently are self > defeating. If you switch to this method, then the release toolchain, effectively becomes both "release manager", and "policy enforcer". What process are you going to put in place, to restrict changes to the behaviour of those things, without being effectively "at the whim of one person", albeit a DIFFERENT person than it has been up until now? > All policy issues will require discussion on the list where all voices > are equal. Votes will be held when required to decide issues, but in > many cases, we hope they aren't necessary as consensus will be reached > quickly. Does this translate to,, "maciej will put in any changes as soon as he feels like it. They will be backed out, only if someone complains, AND the board agrees to put up a vote on the issue"? I would suggest that this is poor quality practice, and that ALL changes must be reviewed and approved by more than just the person coding the change. (given that, as I point out above, the code becomes effectively interchangable with "policy") _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
