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 Sun, 04 Jan 2009 13:32:29 GMT
Jukka Zitting pisze:
> Hi,
> 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.

Sure. On the other hand, since our focus is to push changes back to svn as soon as it makes
sense I
don't think that regenerated repositories would be more than a little inconvenience.

I've been migrating my local branches from my own copy of Cocoon repository to the one generated
you and it wasn't that hard to migrate them. Tools like git format-patch and git am and sed
me to do the whole task within twenty minutes including rewriting Author field that was broken
in my
repository for my patches.

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

Is there any reason for doing that? I thought that both svn.eu.a.o and svn.a.o are considered
official even if, technically, the first one is a mirror.

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

Ah, so not that much. Since the whole svn repository is something like 27GB I guess we won't
that much. The same goes for average load which might be high only on initial cloning but
after that
there won't be any load for obvious reasons (Git is DVCS).

> 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).

Ok, this is doable for me.

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

Ok, but I was asking more about how you do it in terms of setting up appropriate Linux tools.
I have
no experience with processing e-mails at Linux.

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

I could have a look into it as soon as you answer my previous question.

> 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
> year.

It looks like I misunderstood your intentions previously. I thought you would like to ask
infra just
for a zone so we can try to setup everything in usual Apache infrastructure environment but
keep it highly experimental.

If we are going to stay closer to infra team with our effort and at the same time make it
experimental then I guess it would be helpful that infra folks speak up now. I would like
to know
what kind of requirements we would have to fulfill in order to become a part of infra team
to some
limited extent.

To make it more clear: I would like to know what do we have to do in order to be ready to
migrate to
Apache's hardware.

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

I was talking about guidelines only. Obviously, it's very easy to commit a patch contributed
someone who *only* claims that is an author of that patch and there is no automated way to
check if
it's true. We should establish a good practice just to protect committers from making mistakes

The rest stays the same as it was with plain svn.

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

You are right. I had in mind a mailing lists which is my main mean of communication but obviously
not the only one.

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

I think that the only difference between commenting on patches at GitHub and commenting on
at JIRA is that we administrate JIRA and have some helper stuff set up like notification e-mails.

Not that much of a difference IMHO. Moreover, there are already services like FishEye actively
across Apache we are not controlled by Apache.

I fail to understand your last question. Why do we need to decide? I guess that if most committers
(or better PMC members) feel something works better for them then they should use it. Do you
anything specific in mind?

Best regards,
Grzegorz Kossakowski

View raw message