Danny Angus wrote:
Dany: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.
I hate to say this but I total disagree concerning the PMC. I really think that there is a *major* fobia concerning project to PMC interaction. Projects like James and Avalon and I'm sure other should be making PMC members work their buts off for and on behalf of the projects they are representing. IOf they don't have the bandwith then the need to expand capacity - look at Jakarta today - it does not have the bandwith to handle everything - which means that there is a potential that they are not representing you. Due to that flack on the reorg list concerning licensing I'm currently working with the PMC to come up with a license solution with will take a lot of icky stuff out of the code that I have committed (icky from a legal point of view). The actions of the PMC have a potential to make the work I'm doing much easier - engage more comitters in content I'm directly involved within. I've been stuffing around with getting solutiuon "by myself" for 9 months - then I went to thr PMC - winthin 48 hours we have a couple of people who have the necessary contacts to make things happen jumped up and voluteer to help. The board jumped in with opinions wich provide me sufficient guidance so that I know what to do to conform with the "Apache Way".
Working with your PMC is a positive thing.
Making your PMC work for you is even better.
:-D
Cheers, Steve.
All of the above helps to reduce the possibility of code yo-yo-ing between two competing designs.
d.
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
