www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav..." <ga...@16degrees.com.au>
Subject RE: GIT requirements was: Git Tasks
Date Sat, 04 Dec 2010 21:27:34 GMT


> -----Original Message-----
> From: Thomas Koch [mailto:thomas@koch.ro]
> Sent: Sunday, 5 December 2010 7:12 AM
> To: infrastructure-dev@apache.org
> Cc: Sander Temme; Paul Querna
> Subject: GIT requirements was: Git Tasks
> 
> Sander Temme:
> > We are not talking about individual tools yet.  This is not the time
> to
> > push one tool over another: we're still figuring out what the needs
> and
> > requirements are specific to our foundation mandate, infrastructure
> > requirements and the capability of our staff to support what we end
> up
> > with.
> Hi Sander,
> 
> I'm a bit confused. The tasks that Paul Querna added to jira[1] are
> already
> quite technically detailed and won't all make sense if we should end up
> e.g.
> with Gerrit. But you say, that the exact requirements are not yet
> finally
> figured out. Others already want to make a test installation of
> gitolite.
> 
> I believe that it wouldn't be good to start talking about tasks if the
> requirements aren't at least drafted and different solutions have been
> discussed.
> 
> I haven't found any place where the requirements are collected 

Have you looked at:

https://svn.apache.org/repos/infra/infrastructure/trunk/projects/git/THE-PLA
N-SO-FAR

Gav...

> so I
> took the
> freedom to just dump a set of requirements and wishes I could think of.
> Maybe
> you'd like to start with this list and augment or shorten it? Otherwise
> I'm
> not sure, what the next steps towards GIT are supposed to be and
> whether there
> is any way how I could help. - New year is coming and there may be some
> free
> hours around these days...
> 
> [1] https://issues.apache.org/jira/browse/INFRA/component/12312655
> 
> So here goes my initial, totaly subjective and gerrit-biased
> requirements
> list:
> 
> Requirements for GIT at the ASF
> ===============================
> 
> Performance
> -----------
> 
> * The system should support 40 commits per hour.
> 
> Lars Eilebrecht@ApacheCon Europe 2009, "Behind the Scenes of The Apache
> Software Foundation": 300 SVN Revisions per day. Let's say all
> revisions are
> made during eight working hours a day: 320/8 = 40
> 
> * Read-Only mirrors for the GIT repositories must be possible.
> 
> Availability
> ------------
> 
> * High availability is not necessary. A hot backup should be available
> so that
>   an administrator could switch to the backup during working hours.
> 
> * All informations of the systems must be backed up and may _not_ be
> lost.
> 
> Authorization
> -------------
> 
> * Authorization can be granted on a project or repository level.
> 
> * Permissions (can) include:
>   - direct commit to GIT
>   - force commit (non fast-forward commits, should not be used at all)
>   - vote on patches
>   - commit patches (only commits patches that have enough votes)
>   - flag patches as verified
>   - create branches
>   - delete branches
>   - delete repositories
>   - create repositories
> 
> * User Credentials are read from LDAP.
> 
> * Project Chairs are indentified from LDAP and have all permissions on
> a
>   project.
> 
> * Contributors are identified from LDAP and have these permissions:
>   - vote on patches
>   - commit patches (only commits patches that have enough votes)
>   - flag patches as verified
>   - create branches
>   - delete branches
> 
> * Everybody can create an account to upload patches and comment on
> patches.
> 
> Legal
> -----
> 
> * Patches can only be commited to GIT if they've been cryptographically
> signed
>   by a contributor whose CLA is on file.
> 
> Workflow
> --------
> 
> * Comments can be attached to patches, maybe on a per codeline base.
> 
> * A new version of a patch can be submitted while keeping the
> connection to
>   old versions of that patch.
> 
> * Repositories can be organized to show their affiliation to projects,
> maybe
>   as first and second (sub-projects) level repositories.
> 
> Communication
> -------------
> 
> * Everybody can subscribe to be notified by mail of these events:
>   - upload of a new patch
>   - comments / votes on my/all patches
>   - commit of a patch
>   - direct commits to the repository
>   - ...?
> 
> * All activity in a repository / project can also be forwarded to IRC /
> CIA /
>   Jabber(?).
> 
> Web-Frontend
> ------------
> 
> * The GIT repository can be explored as provided by e.g. git-web
> 
> * Patches can be reviewed / commented / voted on in a web frontend.
> 
> * It should be possible to load balance the web-frontend over multiple
> servers
>   in the same data center, better over continents.
> 
> Continuous-Integration
> ----------------------
> 
> * Continuos Integration systems are either notified of new patches or
> can get
>   a list of patches that have not yet been seen by them.
> 
> * The Continuous Integration system can post its result as a comment to
> a
> patch.
> 
> Protocols
> ---------
> 
> * The GIT repository can be checked out by http://, git:// and ssh://
> 
> * Commits or patches can be uploaded via ssh://
> 
> 
> Best regards,
> 
> Thomas Koch, http://www.koch.ro



Mime
View raw message