www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Next steps with git (Was: Added a simple tutorial on Git cloning)
Date Wed, 31 Dec 2008 16:08:15 GMT
Jukka Zitting pisze:
> Hi,
> On Tue, Dec 30, 2008 at 10:25 PM, Grzegorz Kossakowski
> <gkossakowski@apache.org> wrote:
>> Since we have something working and we have gained enough experience to sort out
most of the
>> problems that may arise maybe we should let others know about our experiments? I
have in mind
>> sending an e-mail to committers@ list informing about Git activity at Apache.
> I guess we're still some way from informing committers@, but you're
> right in that it's now time to move forward with this setup.

My idea of informing committers@ was to make people aware of our effort and to gather some
bigger set of people.

I didn't have any official announcements in mind but I may be wrong on the purpose of committers@

> Here's what I think we should do:
> 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?

When it comes to administration you can count on me even if I don't qualify as a very skilled
Linux/Solaris administrator. Anyway, I can resolve most of problems with Git itself.

Also, I can allot my time over weekends mostly.

> 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?

> 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
happen, right?

> d) Start using the INFRA project in Jira for git tasks like setting up
> a new mirror.

The same as above.

> There's also the open issue of how to best handle contributions made
> via git. Should we always insist on patches or would a pull request be
> OK? It would be good to have some documented best practice for such
> cases.

I think pull requests should be allowed. On the other hand this will force committers willing
merge contributions to use Git. Not sure how people will react on such situation.

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
patches coming from committers but not from other contributors. Basically, contributors should
allowed to merge from committers only.

This way committers willing to handle pull request have an easy job when it comes to verification
all changes are covered by ICLA.

This also addresses the concern (message id: 393918.154.qm@web54406.mail.yahoo.com and the
rest of
the thread) that Joe has raised at members@ mailing list about addressing authorship in a
reliable way.

> Another issue to think about is our approach to people publishing
> their clones on places like github. On one hand it's good when people
> do that as making your working copy public is one area where git
> really helps collaboration. On the other hand we'll want to make sure
> that development efforts won't splinter to other forums.

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

Best regards,
Grzegorz Kossakowski

View raw message