www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <bri...@infinity.nu>
Subject Re: Status of Version Control at the ASF
Date Mon, 27 Apr 2009 16:57:22 GMT


Paul Querna wrote:
> Culture: While we have over 70 TLPs, we have some shared values,
> including that there are no single dictators in a community.  Through
> the Incubator, we also bring in large chunks of new code, sometimes
> into exist projects.  Code can and does move between TLPs.
>
>
> Legal:  We require all significant contributions to be covered by an
> iCLA or a cCLA.  We trust committers when they commit code that they
> have the rights to commit that code.
>
>
> Tech: With an infrastructure hat on, we want systems that preserve
> data at all costs.  We want systems with long term maintainability and
> supportive communities with volunteers who can help maintain it
>
>
> What we have today:  Using Subversion we have a master server, and a
> (transparent) slave system, distributed between the US and Europe.  We
> also have read-only git-svn mirrors for many TLPs with updates
> triggered by commit emails.
>
>
> Going forward:
> 1) I believe we should keep a single canonical subversion system as
> our version control for all TLPs.
>    - The Subversion community has significant overlap with Apache, and
> has been very supportive of us.  As a (centralized) version control
> system, they will not be going away anytime soon, and are still
> improving with every version.
>   
I don't see how we can just shut out all other possibilities just 
because Subversion is in place today. A more appropriate discussion is 
what are the core values of Apache that must be protected regardless of 
the system (which stared to cover above in the legal section). I see 
something more basic like:

1)All "Apache" releases must from from a sanctioned official repository.
2)We require all significant contributions to be covered by an iCLA or a 
cCLA.
3)Access to the sanctioned repository is controlled by the PMC of a 
project by the process of voting in a new committer.

Those statements are true of the current system, and should be the basis 
for evaluating any new proposed system. If it meets the core values of 
Apache and protects the legal status, it should be considered.
>   - We have a stable working infrastructure for backups,  notification
> of changes, and a cultural model that is well understood and supported
> by Subversion.
>   - I believe there is significant value in all TLPs using the same
> version control system, from the ability to audit where code came
> from, to Incubating new projects, to infrastructure's ability to
> support it
>
>   
I can understand the desire to have a single stable infrastructure that 
is supportable, but that assumes that the ASF must run everything 
themselves. I don't necessarily think this should be a requirement. More 
and more organizations, open and closed are moving to service based 
structures for everything. There's no good reason put forth yet why ASF 
should be different. Again, it's about the legal protection of the code 
by the Apache organization and as long as that is met, then the most 
cost effective, reliable solutions should be used. (why may or may not 
mean doing it ourselves, but it's a case by case decision imo).
> 2) I believe we should continue adding and improving read-only
> mirroring for other SCMs.
>   - I am experimenting with adding Mercurial mirrors.  Hopefully have
> something we can show off in a few weeks.
>
> 3) I believe we should encourage the improvement of dSCMs tools for
> cross SCM work (git-svn, hgsubversion)
>   
This only makes sense if you are completely locked on svn. Otherwise 
you're trying to shove a square peg into a round hole. If you want to do 
any amount of significant work in an alternate system, there's no way 
that's always going to be able to be pushed back into svn...particularly 
if it involves renaming and moving files. Not to mention you completely 
loose any support that a native system could provide over and above svn.

>   - Need to hear more about 'git-svn issues'  and better understand
> how to integrate these work flows.
>   - I have filled a few upstream hgsubversion bugs so far, but it is
> close to usable.
>   - The tools are improving; Most can support commiting change sets
> directly into a master Subversion repository, we should encourage and
> develop workflows for committers around this.
>   

Mime
View raw message