Excerpts from Philip Brown's message of Fri May 06 17:22:47 -0400 2011: > On Thu, May 5, 2011 at 10:37 AM, Ben Walton <[email protected]> wrote: > > Excerpts from Philip Brown's message of Wed May 04 20:43:53 -0400 2011: > >> 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. > > > > Feel free to file bugs on packages pushed to future/unstable. This > > change will _not_ restrict the ability for humans to QA packages. It > > just changes the handling of the QA process. > > > > It seems that you missed.. or ignored... my point. > but I'll save further conversation about that, to voting time.
No, I understand what you're saying quite clearly. The 'all packages must be inspected' argument has been your historical position on this. Again, nobody that thinks the automated solution is better thinks that human inspection _can't_ help. I happen to know that not all package submitted for release are subjected to the same level of scrutiny though. Some are passed immediately without inspection. I also know that although checkpkg would pass a package, packages are not pushed for release. This is what I call a non-policy block. csw-upload-pkg solves these problems. All packages are equal in the eyes of checkpkg. They either pass policy or they don't. Can csw-upload-pkg release bad packages? Absolutely. Can the human release manager release bad packages? See libneon. csw-upload-pkg has a distinct advantage in turn around for correction here as it's not subject to time zones and sleep requirements, etc. > >> 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"? > > > > Not at all. > > > >> I would suggest that this is poor quality practice, and that ALL > >> chpanges 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") > > > > I think that's fair. We already have patches flying by on devel@, we > > could move to a SoB (signed off by), AB (Acked by) model like git > > where at least two people must ok each change before it's approved. > > > > And what if "at least two people" like the change, but other people do not? > Since, I repeat, this stuff becomes de-facto policy -- what > (political/policy) mechanisms are you going to put in place to > disallow "two people" to determine policy between themselves? Well, most people wouldn't simply alter checkpkg (maciej's version) to have it enforce new rules. These would be discussed and then implemented. And, as development is fully open with changes sent to the mailing list, it's easy to monitor (not that I have any qualms about this at all). And, if you want to get right down to it, even in your worst case scenario above where two people collude on policy, that's still better than the current situation where it only takes one. > There will need to be some kind of auto-triggered dispute policy on > this. Otherwise, two board members who collude, can do whatever they > feel like to the code, and block votes on issues that they > personally are against. While I don't see this happening in the way you do, all I can say is that the board is an elected body. It will change over time. Just like any government it will make decisions you don't personally like. Challenge it at the ballot box the next time around. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
