www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Next steps with git (Was: Added a simple tutorial on Git cloning)
Date Sun, 04 Jan 2009 12:04:23 GMT

On Wed, Dec 31, 2008 at 6:08 PM, Grzegorz Kossakowski
<gkossakowski@apache.org> wrote:
> My idea of informing committers@ was to make people aware of our effort and to
> gather some feedback bigger set of people.
> I didn't have any official announcements in mind but I may be wrong on the purpose
> of committers@ list.

I think a better approach for now would be to use community@ and the
dev@ lists people are subscribed on  to spread news about the git
mirrors. It would be nice to have more people trying them out but for
now we should still warn them that the mirrors may well need to be
regenerated (and histories broken) before they become a part of the
official ASF infra.

For example I've been thinking of changing the svn.eu.apache.org in
the commit logs to svn.apache.org.

> Jukka Zitting pisze:
>> a) Set up the mirrors on Apache hardware. We could for example request
>> a Solaris zone like git.zones.apache.org for this. It would be good to
>> have at least two or three administrators to avoid making me a
>> bottleneck.
> Yep, good idea but I wonder how much of resources we are going to need. Can you show
us some
> statistics of your server? At least consumed bandwidth and disk space occupied Git mirrors.
> What about a load that Git is putting on server? I guess it's not that much?

The current set of mirrors takes about 4GB of disk space, and I'm
currently serving about 5GB of git data over the net per month (up
from 2GB four months ago). The CPU load is negligible, the average
load of the server is just 2% of a single CPU.

> When it comes to administration you can count on me even if I don't qualify as a very
> Linux/Solaris administrator. Anyway, I can resolve most of problems with Git itself.
> Also, I can allot my time over weekends mostly.

Cool, thanks. The most common administration tasks would likely be
setting up new git mirrors or changing the configuration of existing
ones (for example due to a project graduating from the incubator).

>> b) Clean up and document the mirror maintenance scripts (currently at
>> [1]) and move them to an appropriate location under
>> repos/asf/infrastructure. It should be possible for a new
>> administrator to get up to speed with just some pointers to
>> documentation.
> Agreed. BTW. How email-update.sh is triggered?

I have a dedicated email address git@jukka.zitting.name invokes
email-update.sh whenever a new commit message is received.

I've been thinking of modifying the script so that it automatically
detects which mirror needs to be updated based on the svn paths in the
message and the git-svn settings in each mirror. This way project
admins could just subscribe the address to their commit mailing lists
to enable automatic git updates without me having to manually update
the script.

>> c) Improve and extend the documentation we now have in the wiki and
>> move it to an appropriate location under www.apache.org/dev.
> Don't you think that it's too early to move our documentation to official Apache website?
I think
> this would make an impression that Git has received an official "blessing" from Apache
which didn't
> happen, right?

Once we do move the mirrors to Apache infra then I think it makes
sense to also start posting the documentation under /dev/. Same goes
for the INFRA Jira.

It's not something that I think we should do today, but I wouldn't be
surprised if we were ready to take that step sometime during this

> If we are going to allow exchanging Git trees (repositories) instead of plain patches
> then we should establish a policy that non-committers are considered as a leaf developers.
> This implies that contributor can send a pull request for a tree that contains shes own
patches or
> patches coming from committers but not from other contributors. Basically, contributors
should be
> allowed to merge from committers only.

I'm not sure if we can or should enforce such rules. In the end it's
up to the committer that commits a change to be reasonably certain
about the origin and legal status of the code he or she is committing.

> The good thing about GitHub is that it does not provide any communication means.
> I think that as long as communication happens on Apache mailing list and the final
> result is being committed into svn we shouldn't worry to much about GitHub and
> similar sites.

But GitHub does provide such communication means. There are commit
feeds and comments, pull requests, wikis, etc.

Given that we can't prevent people from using those mechanisms, how do
we make sure that the key principles of Apache-style development are
still followed? Also, how do we decide whether a potential new
development pattern enabled by Git tools is beneficial or not?


Jukka Zitting

View raw message