Re: Re: Keeping CVS? was - Re: [PEAR-DEV] CVS 2 SVN (Re: [PEAR-DEV] candidatesfor PEAR Group: why should we vote for you? Tell us your plans and
yourhistory)
| From: | till | Date: | Thu, 25 Jun 2009 14:58:25 +0000 |
| Subject: | Re: Re: Keeping CVS? was - Re: [PEAR-DEV] CVS 2 SVN (Re: [PEAR-DEV] candidatesfor PEAR Group: why should we vote for you? Tell us your plans and yourhistory) |
||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-52211@lists.php.net to get a copy of this message | ||
On Thu, Jun 25, 2009 at 9:05 AM, Alexey Borzov<borz_off@cs.msu.su> wrote:
> Hi Travis,
>
> Travis Swicegood wrote:
>>>
>>> I immediately see at least three problems with having "pear" and
>>> "pear2"
>>> accounts anywhere, including GitHub:
>>> 2) It will introduce unnecessary security problems.
>>
>> Unless you are willing to back this statement up with examples of stated
>> "security problems", I would like to ask you to refrain from spreading FUD.
>
> I thinks it is pretty obvious: if N people have password for an account then
> the chance that this password is compromised is N times bigger.
>
> Also please remember that most PEAR officials are elected, thus it will be
> harder to revoke access of former officials and less transparent.
>
> Both of these will, of course, be a non-issue if "pear" and "pear2" are not
> accounts but groups and / or roles. I am not aware whether GitHub supports
> those, though.
>
If people are not supposed to share accounts then this boils down to two things.
1) PEAR/PHP doing their own git, svn and whatever (enough) people
request. And generally, not allowing people to host code in PEAR on an
external VCS (only).
2) If we allow an external VCS, then the issue is that people need to
be added to them in order to do QA and make sure the package is
maintained. That is in order to comply with the TOS of most of those
services ("accounts cannot be shared"). The people on the QA team
probably have accounts on SF, Google Code and Github anyway and each
of those could be added. The only issue then is to stay on top of
changes, e.g. someone from the QA team drops off, they need to be
removed from the repositories, etc.. Which comes down to more
management.
Till