[haiku-development] Re: Commit access for Rene Gollent
- From: Stephan Assmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 24 Feb 2008 15:09:34 +0100
On 2008-02-24 at 15:00:05 [+0100], Niels Reedijk <niels.reedijk@xxxxxxxxx>
wrote:
> 2008/2/24, Ingo Weinhold <ingo_weinhold@xxxxxx>:
> > We already discussed formalizing the criteria for getting repository write
> > access a bit a while ago on the admin list. IIRC we were mainly
> > concentrating
> > on size/number of committed/accepted patches and period of commitment.
> > I.e.
> > small/infrequent patches over several months or heavy/frequent patches
> > over a
> > short period would make someone a suitable candidate. There would be no
> > automatism, though. A candidate can propose himself, but a developer with
> > write access would have to start a vote (just as Stippi did) -- it will
> > usually be one who accepted patches.
>
> Ah good. Has anyone stepped up yet to set these in stone on the website?
The dissolve of the admin team is waiting on the progress of the transition
team. At least this is what has been happening so far. Maybe we should
re-evaluate if we should just go ahead with the changes to the development
team.
> > > Also, I guess it might be wise to appoint two or three 'admins'.
> > > Responsibilities:
> > > - Organize new members for vote
> >
> > Unless we have like 5 candidates a day, there's not that much to
> > organize, I
> > guess. :-)
> >
> >
> > > - Grant proper permissions (website, berlios, trac) in case someone is
> > > accepted
> > I suppose usually the developer initiating the vote could do that.
>
> Could be, but I think it would be ... unwise to grant all developers
> admin rights in Berlios, Drupal and Trac. I would trust any one of the
> developers, but in order to minimize the risk of human error, keeping
> privileges contained would be wise. It would also minimize the
> security risks. Especially admin privileges on Trac are dangerous in
> the sense that they expose sensetive data. I would imagine something
> like that also being the case for Drupal (but I could be wrong).
>
> Or maybe I'm overly cautious.
I see your point. By far not all of the developers do have admin rights on
Berlios, though. Until now, it was never a problem to get someone with the
necessary rights to implement a decision by the team.
> > > - Clean up stray permissions of people who are leaving.
> > We also discussed this, and I believe there was a tendency towards not
> > removing members unless there's a good reason to. Again one of the
> > developers
> > would just initiate a vote.
>
> How would this voting process go? Would it be transparant (on this
> list), or will there be a private list/mail going out to all?
I don't know. Maybe we should indeed have a separate non-public list for
developers with commit rights only. On this public list, it is probably
unlikely that anyone will voice objections even though they may have them. Or
as in the above case, propose someone for removal from the commiters list.
> > I think as long as Haiku is a relative small project (speaking of the
> > number
> > of developers) we can keep those processes rather simple. When the
> > project
> > has grown much bigger we can probably move to a FreeBSD like
> > organization,
> > i.e. electing a small admin group once a year or so.
>
> Well, I would still opt for selecting a small admin group, because of
> the security reasons outlined above. I don't think these would have to
> be elected, just two or three people who are active on these list and
> that automagically take care of these initiations.
We specifically wanted to try without admin group and see how that goes.
Best regards,
-Stephan
Other related posts:
