Costin Manolache wrote: > > > well, no -- that's not overriding the veto, because the changes > > aren't getting checked into the branch where they were vetoed. > > vetos are mostly (possibly completely, need to think about that) > > per-branch, not per-codebase. > > True. > > But the point is that the revolution makes it impossible to veto a > certain feature or architecture or piece of code from becoming part > of the product and release.
no, not if the revolutionary code is never accepted back into the main branch. if it isn't merged back in, it *isn't* part of the product and release; it remains a branch, or maybe gets forked into a completely separate product. vetoed never makes it into a release. at least it had better not. it might end up in a branch or fork where it hasn't been vetoed, but that would be a different product with its own release. > And it removes the potential for abuse of the veto. well, lessens it. > If we accept the idea that the majority of committers control the > release process and name - including the codebase that is going to > be released - that will imply that nobody can block the majority > by using vetoes. no again. vetoed code never makes it into a release. what you are describing is a pathological situation. solutions to it include the majority 'routing around' by forking a revolutionary branch and taking the name with it, and executive decision by some authority (for which there are currently no guidelines). > ( or control the direction of the project by > vetoing everything but his own view ). again, pathological. if things get to this point, the pmc/chair should take corrective/punitive action. commit access is a privilege, not a right; such behaviour as you describe is an abuse of that privilege.
