On Wed, Apr 3, 2013 at 11:30 PM, Louis Suárez-Potts <lui...@gmail.com>wrote:
> Thanks, Rob, et al., > > On 13-04-03, at 22:22 , Peter Junge <peter.ju...@gmx.org> wrote: > > >>>> > >>>> One way of implementing this would be to look at all commits for the > >>> past 6 > >>>> months (or 1 year?) and remove authorization on /trunk, /tag and > >>> /branches > >>>> for those who have not made commits. But preserve authorization for > the > >>>> website directories. > >>>> > >>>> Thoughts? > >>>> > >>>> -Rob > >>>> > > > > In OOo we used SSH2. We also limited actual inclusion to code that had > been reviewed by a small coterie of project managers. This last part—that > that group of elites was another way of saying, "Sun" or, later, "Oracle," > led to displeasure. But not exactly because of the hierarchical system but > because it was perceived that that system allowed Sun to control things > while claiming open source openness. > > Whatever the merits of the critiques, having multiple layers of review and > using SSH2 (which I rather like, as I don't like passwords at all, having > read far too much Schneier) is one step. I'd also concur with the idea of > scrubbing the lists of nonactive committers. That set would include me. I > have not made any commits to the code (or anything) in the last year, at > least. > > I generally agree, but it will be important that we describe this in an accurate way. A "committer" is someone who contributes to the project and has demonstrated merit and then has been voted in as a committer by the PMC. Some will be coders. But many will be contributing in other ways. All committers get an Apache ID and password. These give automatic access to things like: a personal home directory on people.apache.org, the ability to send email from an apache.org email address, etc. There are other things that committers are entitled to, but which a separate request must be made, like a blog editor account or being a list moderator. What we're suggesting is that write access to the source code be one of those things that a committer must request separately. It would not be automatically enabled. So we're not talking about "inactive committers", since they may be active in the project in ways other than coding. I'd just describe it by saying we have committers that are involved in all areas of the project and each committer has the permissions they need to do the tasks they want to do. But we avoid giving automatic SVN permissions to everyone. This is not for hierarchical, or burocratic reasons, but purely for security reasons. We take security very importantly, as befits a product installed and used by many millions of users. -Rob The point here is not to diminish any kind of democratic spirit or > innovation but rather to ensure that the code we call ours (AOO) is really > just ours and not a trap for the unwary—malware. The problem with traps > like that is that rumour of their existence is almost as bad as their > presence. I've had more than one discussion with government officials who > said they could not use OO because they could not absolutely guarantee the > license or sanctity of the code. I was able to convince them of both, but > the point is that this sort of anxiety, fuelled by vicious minds, can only > be dismissed with facts. And if you have doubts, just look to see how > BlackDuck earns its profits. Enterprise adoption of open source is not seen > as risk free. > > BTW, in OOo, Web directories were treated a little differently, than code > but I argued for even stronger differentiation. > > -louis > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
