I'm going to top-post. I agree that this is a good idea, but I want to define it expansively as a positive.
(1) The current authz that defines all of the AOO committers must be preserved. This is used to generate foundation information like: http://people.apache.org/committers-by-project.html#openoffice (2) Let's focus only on adding one new authz list for the code tree. Call it openoffice-coders and populate it with those who HAVE any commit activity in the current code tree. With ta coders authz everyone knows who is on the list by checking: http://people.apache.org/committers-by-project.html#openoffice-coders People can then really know who to bug to get their patch committed. (3) Andrea as PMC Chair or any Apache Member has karma to add or remove people on the coders authz. We can debate the rules, but those don't effect the structure implied. Let's look for Consensus on the structure first. Once that is out of the way we can easily describe how this new structure is a significant improvement and that it is a win all around without a real downside. (Some will spin a downside and parrying that is a different discussion.) Regards, Dave On Apr 3, 2013, at 1:30 PM, Rob Weir wrote: > On Wed, Apr 3, 2013 at 1:45 PM, Andrea Pescetti <pesce...@apache.org> wrote: > >> Jürgen Schmidt wrote: [...] >> >>> On 3 April 2013 14:39, Rob Weir<robw...@apache.org> wrote: >>>>> >>>>>> one change to our current process that will, I think, greatly increase >>>>>> >>>>>> security. This would be to restrict SVN authorization for the code >>>>>> >>>>> >> I don't think this would greatly increase security, since the current >> review model would still be the better defense. But surely this doesn't >> decrease security and doesn't impact on people who are not using it. >> >> > Good to think in layers of security. An account that is not authorized is > an account we don't need to worry about at all. > > Note: we have people currently authorized for our source code, who have > *never* checked in code and who have *never* posted on the mailing list. I > have a heard time believing that they are following best practices to avoid > losing control of their Apache login credentials. > > >> >> I see also no problem if we handle it more careful and give svn access >>> to the code on demand only. Nobody should take it personal >>> >> >> Before we manage again to make simple discussions complex, let's see: >> - All committers have the right to have write access to the source code >> > > > Yes, though the "right" is a de jure right, not exactly equivalent to the > technical authorization. But one should lead to the other on demand. > > > >> - By default 3 subtrees (trunk, tags, branches) are read-only >> - Any committer can receive write access to the 3 subtrees immediately, by >> sending an e-mail here >> >> This could be fine for me, provided that: >> >> 1) We have the right way to manage this (another LDAP group does not look >> like the right solution: people who don't want to understand correctly will >> invent that this is a multi-level hierarchy while it would simply be a >> permission that we enable on demand) >> >> 2) Enabling write access is extremely simple, especially if this is >> something that I must take care of! Something like the current " >> modify_unix_group.pl" scripts currently used for the committers group. >> >> > I'd do it like this: > > 0) Call it "active" and "dormant" statuses. This doesn't change status as > a committer, just status of SVN authorization. > > 1) By default the active list includes only those who have made commits to > those trees in the last 12 months (or some other suitable time period). > "Ever" would be a fine time period as well. > > 2) Everyone else has authorization for /site, /ooo-site and /devtools > > 3) Any committer can be added to the active list on demand. > > 4) New committers are explained this when they are voted in and asked if > they want to be on the active list for Subversion. > > Regards, > > -Rob > > Regards, >> Andrea. >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
