www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Full support for Git at Apache, a dangerously indigo plan.
Date Wed, 03 Nov 2010 14:08:03 GMT
Please provide feedback and more tasks.  This is a brainstorm.  Please help out.

If you want to help with a task, go do it.  The velocity of this
project is entirely dependent on volunteers.

Tomorrow I will take all the reasonable tasks we have, and put them
each into a INFRA jira ticket.


Stage -1: Please avoid bike sheds.

  Goal: Indigo is my color today. <http://indigo.bikeshed.com/>  We
will be providing full r/w git support for projects.  It isn't a
trivial project, both for communities and for infrastructure.

  Task: Recruit people to help with the following tasks.



Stage 0: Basic development and design

  Goal: Resolve any remaining questions about design and
implementation of full Git support at Apache.

  Task: Send this email. Status: Done!

  Task: Evaluate Gitolite <https://github.com/sitaramc/gitolite>  We
can definitely at least learn things from Gitolite even if we do not
end up using the code.

  Task: Decide on push transport.  Currently leaning towards offering
only HTTPS based pushing, as then it is very easy to re-use our
existing LDAP infrastructure.  We can do SSH based with a single git
user + ssh public keys, but it is more work.

  Task: Start putting tools, scripts and documentation in SVN.
<https://svn.apache.org/repos/infra/infrastructure/trunk/projects/git/>



Stage 1: Testing Repository

  Goal: Build experience and document how the ASF is hosting
repositories, and ensure correct permissions, hooks, backups,
replication/mirror, etc are all working.

  Task: Find server to do testing repository.  My preference is to use
eris / harmonia as a pair in the long run, but for stage 1 we can just
use a pair of small VMs.

  Task: HTTPS Server setup.  Configure Apache + LDAP +
git-http-backend
<http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html>

  Task: Figure out details of Git Slave.  Just like SVN, we will have
git mirrored in both EU and US.  A push to the EU server should
transparently push to the US server, and replicate back as needed.

  Task: pre-receive hook: Authorization.  Based on groups in LDAP,
restrict write access to members of the correct project. We will not
have path based authorization under, only whole project.

  Task: pre-receive hook: Repository temporarily disabled.  If
/etc/nocommit is present, do not allow any commits.  This allows for
server and repository maintenance.

  Task: pre-receive hook: Do not allow history rewriting / git push --force.

  Task: post-update hook: Logging of commit.  Log both the Apache
committer, and the 'git' committer. Figure out how to make this
information useful.

  Task: post-receive hook: E-Mail notification.  We have a traditional
dependence on 'good' commit emails.  We need a very good mailer, as
SvnMailer handles many cases like large commits, weird charactersets,
etc, that most git based mailers don't even approach.

  Task: post-receive hook: CIA Notification.  <http://cia.vc/>

  Task: post-receive hook: SvnPubSub Notification.  I think we should
add support to SvnPubSub for git repositories. Maybe rename SvnPubSub
-> VcPubSub too.

  Task: post-receive hook: Slave Mirroring.  Every commit will be
mirrored to a second ASF machine, just like we do with Subversion.
This should just be a git push --mirror to a remote repository, but it
needs testing.

  Task: post-receive hook: Github mirroring.  After each push, every
repository will be mirrored to github.

  Task: Find web based view of Git repositories.  Gitweb or cgit or
viewvc.  Evaluate and configure one of them.

  Task: Determine policies for merge commits.  See what Postgres has
done: <http://lwn.net/Articles/409635/>

  Task: Document committer workflow.  Needs a /dev/ page describing
all of the basic workflows that will be used by ASF committers.  This
includes community expectations on how often to push, merge, and
moving patches around.

  Task: Document infrastructure workflows.  How to import a project
from SVN.  How to import an external git repository. How to backup a
repository. How to verify a repository.  How to setup a new TLP.

  Task: Infrastructure Git run book.  Add run book for all services
used in the git project.
<https://svn.apache.org/repos/infra/infrastructure/trunk/docs/services/>

  Task: Consider SVN-Mirroring of projects.  Once the primary VC is in
Git, it is possible to provide a replicated copy in Subversion, so
that existing users and build tools can continue using their checkouts
over SVN.  We need to determine how feasible this is to actually
implement.



Stage 2: "beta" Testing by a project.

  Goal: Test the new service on a volunteer project, ensuring both the
technical and community issues are successfully addressed.

  Task: Testing full history conversion.  We will be preserving 100%
of the history of a project.

  Task: Evaluate after a few months.  Whats working, whats not.
Iterate on problems and documentation.

  Task: Ensure widespread Infrastructure Team knowledge of git.  As
the goal is to have Git be a core service, equivalent to Subversion,
we must have multiple members of the team who are experienced with our
setup and git in general. "Team" includes adding new root@ members, so
step up :-)



Stage 3: Wide availability

  Goal: Projects can choose Subversion or Git as their primary Version
Control, and conversion between each is done via standard INFRA
tickets.

Mime
View raw message