Developers that are not involved in a specific part of the codebase should abstain from vetoing components that other developers work on.
For example, say that I have worked for weeks on IMAP, and someone that has never committed anything to it vetos one of my commits...
That person has no real moral "right" to do it, unless its global involvement and partecipation in the project is so big that he can rightly claim to have high stakes in it.
Some think this has to be made a rule, some don't.
The bottom line is: respect the work of others and don't block them if you are not helping them.
And I agree with what Danny says below :-)
Danny Angus wrote:
p.s. I don't know anything about the context of this dicussion :-) Cheers, Steve.Well done then for hitting the nail on the head! As far as I can ascertain the rules mean this; That although the policy is "comit then review", and review is subject to lazy concensus (ie abstention is tacit aceptance) changes affecting architecure, existing functionality or design policy which are likely to provoke comment are best discussed beforehand and concensus reached, with or without a formal vote on the issue. If the community is working well discussions will be taking place anyway. This is one very good reason to keep technical discussions on the list, not behind the scenes, even where the perticipants feel that it would be of no value to have them in public, perhaps because they are esoteric, of marginal relevance to the overall picture, or just plain dull. As far as a veto, I agree with Steves analysis that vetos have to be justified, and that the only way to remove a veto is by reaching concensus with the vetoer. In the case where concensus can't be reached, the PMC are there to help resolve issues, but I couldn't imagine resorting to this drastic step would do much more than harm the community, whatever the outcome. All of the above helps to reduce the possibility of code yo-yo-ing between two competing designs.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
