Santiago Gala wrote:
I'd say that if a project wants to have a distributed scm and makes a reasonable case of the reasons, they would ask for it to infrastructure. If infrastructure denies it and the project does not accept the reasoning or how it is exposed, we have a conflict. If there is a conflict the Board *has* to consider the issue. I'm not sure on how it is worded in the bylines.
Well, yes, board is the appeal of last resort. But just like the board rarely touches the third rail of making development decisions for a project, they rarely make architectural decisions overriding infrastructure. The right way is for infra to determine they won't do it unless ___ happens, and appeal to the board to make ___ happen on behalf of the requester.
While we typically value consensus a lot, we typically don't take bureaucratic answers as absolutes. Or at least that is how I remember the ASF used to be. :P
You can't have a less absolute bureaucratic result than bringing an issue to the board ;-)
The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community.
But there's a deep question of if this goes against the principals of the meritocracy of peers that has worked so well for the ASF. We don't and wouldn't entertain such roles as code wrangler, project lead, etc. It's just not our ethos/social schema. Bill --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
