On Tue, 2008-03-18 at 09:57 +0100, Kinkie wrote: > The idea is nice, but a bit dangerous IMO, as it lends itself to > abuse. I second that we can try it out, and see how it works out.
I think it will work out well. And in any case there is a second level human filter to make the actual commit. > The point I don't understand then, is "what is -core?". I had been > told that it is about project governance, but this is not really > governance. So either -core is being overloaded with a second task, or > it is not "just" about governance. Today core is pretty much equal to committers, with some minor exceptions. Yes, the role of core is governance and management of the project. This among other things involves keeping an eye on what is being merged and vetoing things which doesn't make sense even if there is two other developers who is very excited about it.. For bundlebuggy it's not a hard distinction. The separation of meaningful and abuse veto votes is best dealt with at a human level by social interaction. Hence "mainly reserved for squid-core". It's not meaningful to define yet another strict group for this purpose. The developer community around Squid is so small and with a pretty low churn rate, so the rules needs to be as simple and open as possible. For our project the less administration we need of bundlebuggy and the more meaningful information it picks up the better. Each time bundlebuggy misses a meaningful vote for whatever reason is a major obstacle for the project. But it's only a minor annoyance (moscito level) if someone on squid-dev tries to abuse the bundlebuggy system. The main problem in such case is on squid-dev and the social interaction needed to get that person to behave, not the traces left in bundlebuggy. Regards Henrik