www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Full support for Git at Apache, a dangerously indigo plan.
Date Wed, 03 Nov 2010 22:47:17 GMT
A few such tools already exist, because that's what the Linux guys use also. 

Another point: we have to be carefull with 
git merge --squash          and
git rebase -i

if we apply patches from external. Because this will cause loosing some IP information. Not
sure if there is a way to omit this somehow, at least we need to make people sensitive for
this area.

LieGrue,
strub


Not sure, but is there a way to 

--- On Wed, 11/3/10, Brett Porter <brett@apache.org> wrote:

> From: Brett Porter <brett@apache.org>
> Subject: Re: Full support for Git at Apache, a dangerously indigo plan.
> To: infrastructure-dev@apache.org
> Date: Wednesday, November 3, 2010, 9:51 PM
> Probably a trivial thing, but how
> important are aggregated statistical info about where
> individual committers do their work, the "1,000,000 commits"
> type of tracking, svnsearch.org, etc. for us or PR? Do we
> need to do the svn commit mirroring to keep that, or perhaps
> have something else optionally available?
> 
> On 03/11/2010, at 10:08 AM, Paul Querna wrote:
> 
> > 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.
> 
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> 
> 


      

Mime
View raw message