You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Thomas Koch <th...@koch.ro> on 2010/12/04 22:11:41 UTC
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 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
RE: GIT requirements was: Git Tasks
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----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