El mié, 13-02-2008 a las 18:28 -0500, Noel J. Bergman escribió:
> J Aaron Farr wrote:
> > J Aaron Farr wrote:
> >>> git could be an issue.
> > > Can you explain what the issue is with Git?
> > Leo already gave a decent explanation.
> > Basically, it comes down to two aspects:
> > 1) infrastructure support
> > 2) cultural bias
>
> Only the first one is marginally correct, IMO.
>
> Santiago wrote:
> > > 1. You have to use subversion.
> > Why? Has been a vote done? where? I vote +1 for git if a vote is still open.
>
> No, there was no vote and is not vote, nor is there any choice.
> Subversion is one of the few things that the Board has mandated,
> imposed on all projects. Period. Pretty much end of discussion.
>
> No project was allowed to stay with CVS. No project will be allowed to
> use another source control system unless it is adopted at the ASF
> level. Source code is a critical, shared, public resource maintained
> by the Foundation, not something whose storage is managed on a project
> by project basis. The Infrastructure Team maintains and protects that
> shared resource on behalf of the Foundation.
>
If I remember correctly, the policy was not to impose subversion, but to
mandate end of life for CVS. If I remember correctly, this was due to
security concerns, CVS requiring user accounts in the machine where the
repository is stored while subversion does not. Also functionality. Also
that having a lengthy transition was stressing infrastructure. I have
been looking into mail archives but have not found a pointer yet.
Funny enough, all people using distributed SCM quoted ease and
simplification of administration as one of the core advantages, be it
git, bazaar, mercurial or darcs.
If I read correctly your last two sentences, I see that
- you are no longer considering the Foundation as an umbrella for the
projects, but as an entity with a life that, I see from your reaction,
needs to protect itself from the (some?) projects
- The infrastructure team is a Police body ("to serve and protect")
Information can be copied and still stays the same, trying to restrict
it to a server is really futile and wasting. The only thing that
actually would need a "custody" would be a PGP-signed text document with
SHA1 of the release source and date. And I don't think it would be
signed by the infrastructure team, but by the three +1 voters of the
release in the PMC. And this "custody" can easily be achieved by
publishing in a multiply archived email list.
I don't think centralization has ever been part of "the Apache way".
Regards
Santiago
> --- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
