You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@hadoop.apache.org by Thomas Koch <th...@koch.ro> on 2011/02/10 10:44:54 UTC
Blog post on Gerrit (GIT review tool)
http://alblue.bandlem.com/2011/02/someday.html
Very nice writeup of the advantages of Gerrit and integration with Jenkins.
Gerrit is a code review plattform on top of GIT developed by Google for the
Android project and in use at the Eclipse Foundation.
How do you think in general about GIT for the ASF? It puzzles me, that there
doesn't seem to be much of an interest to get official GIT repositories
despite the pain of working with Subversion. The discussion on infra@a.o is
stale for more then 2 months now.
Best regards,
Thomas Koch, http://www.koch.ro
Re: Blog post on Gerrit (GIT review tool)
Posted by Mark Struberg <st...@yahoo.de>.
+1 I think gerrit would be a great addition in terms of being a channel for random contributors. We of course might have to tweak something for our Jira integration. But since each contribution has its unique sha-1, this shouldn't be too problematic.
LieGrue,
strub
--- On Thu, 2/10/11, Jukka Zitting <ju...@gmail.com> wrote:
> From: Jukka Zitting <ju...@gmail.com>
> Subject: Re: Blog post on Gerrit (GIT review tool)
> To: infrastructure-dev@apache.org
> Date: Thursday, February 10, 2011, 9:55 AM
> Hi,
>
> [replying only on infra-dev@]
>
> On Thu, Feb 10, 2011 at 10:44 AM, Thomas Koch <th...@koch.ro>
> wrote:
> > How do you think in general about GIT for the ASF? It
> puzzles me, that there
> > doesn't seem to be much of an interest to get official
> GIT repositories
> > despite the pain of working with Subversion. The
> discussion on infra@a.o is
> > stale for more then 2 months now.
>
> Sorry about that. I've been busy writing a book and it
> seems like the
> read-write git effort started at ApacheCon has not picked
> up speed.
> I'm on target to finish writing the book at the end of this
> month, and
> I'm dying to get back to more actively drive the Git
> efforts here. :-)
>
> I noticed your earlier Gerrit work and would like to see
> some of that
> being channeled back to our infra. I already have an
> earlier
> experimental Gerrit setup at http://git.apache.org/gerrit/ (see [1]),
> but so far it never went anywhere due to lack of time.
> Would you be
> interested in becoming a co-admin of that setup?
>
> [1] http://markmail.org/message/24zkrctjzqf6t3ar
>
> BR,
>
> Jukka Zitting
>
Re: Blog post on Gerrit (GIT review tool)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
[replying only on infra-dev@]
On Thu, Feb 10, 2011 at 10:44 AM, Thomas Koch <th...@koch.ro> wrote:
> How do you think in general about GIT for the ASF? It puzzles me, that there
> doesn't seem to be much of an interest to get official GIT repositories
> despite the pain of working with Subversion. The discussion on infra@a.o is
> stale for more then 2 months now.
Sorry about that. I've been busy writing a book and it seems like the
read-write git effort started at ApacheCon has not picked up speed.
I'm on target to finish writing the book at the end of this month, and
I'm dying to get back to more actively drive the Git efforts here. :-)
I noticed your earlier Gerrit work and would like to see some of that
being channeled back to our infra. I already have an earlier
experimental Gerrit setup at http://git.apache.org/gerrit/ (see [1]),
but so far it never went anywhere due to lack of time. Would you be
interested in becoming a co-admin of that setup?
[1] http://markmail.org/message/24zkrctjzqf6t3ar
BR,
Jukka Zitting
Re: Blog post on Gerrit (GIT review tool)
Posted by Thomas Koch <th...@koch.ro>.
Owen O'Malley:
> On Feb 10, 2011, at 11:20 PM, Thomas Koch wrote:
> > And it's not much IMHO what needs to be learned. It's a well
> > packaged, proven
> > system with a big, active and maybe even helpful community.
> > And I also offered my help to set it up. I can also help in
> > maintenance, if
> > you really need it. I also already did set up a test instance (on
> > request of
> > Owen O'Malley) without any trouble.
>
> I tried to figure out what I was supposed to do, but the documentation
> that I found was mostly deeply tied to android's process. I ran out of
> time trying to figure it out and meant to reach out to you to get
> help, but it slipped off my plate.
>
> Is there a page that runs through the flow of how to upload a patch,
> have someone review it, and get it committed?
>
> -- Owen
What timezone are you in? I'm in CET (UTC+1). If you're in America, we could
schedule an IRC meeting in one of the next days and I'll talk you through. I'd
be available all the next days unless wednesday.
I even thought it would be very helpful to do a screencast of Gerrits
workflow, but I've not yet done anything like that.
Thomas Koch, http://www.koch.ro
Re: Blog post on Gerrit (GIT review tool)
Posted by Tony Stevenson <pc...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/02/2011 07:20, Thomas Koch wrote:
> Paul Davis:
>>> OTOH I don't think git can be used "much the same" as svn. I would
>>> recommend any people that has not used git deeply to avoid comparing it
>>> with subversion until they have used it deeply during, say, one year. By
>>> using I
>>
>>> mean at least:
>> I was worried someone would take that comment wrong. I should've been
>> more clear.
>>
>> I meant to point out that it would be the same or similar from the
>> point of view of the infrastructure team. As in, it'd be hosted by
>> httpd, use mod_ldap for authentication, some various pieces of code to
>> plug in ldap groups for authorization, etc. It'd be based on services
>> for which there is already experience running.
>>
>> This is opposed to something like Gerrit that would require multiple
>> people on the infrastructure team to learn and care for a new service
>> as well as require changes to processes like getting CLA's and such
>> forth.
>>
>> HTH,
>> Paul Davis
> So just because some people on infra should be avoided the burden to learn
> something new, some thousand developers should suffer from a suboptimal
> system?
> And it's not much IMHO what needs to be learned. It's a well packaged, proven
> system with a big, active and maybe even helpful community.
> And I also offered my help to set it up. I can also help in maintenance, if
> you really need it. I also already did set up a test instance (on request of
> Owen O'Malley) without any trouble.
>
> It would just help to have just a little bit of communication going on. I've
> asked for a list of requirements on 2010/12/04 and even started a draft list
> to help out. However there wasn't any reaction to that.
>
Get more people interested, get them to take part on infra-dev@.
> Please note that the list of _TASKS_ on jira is not a list of requirements.
> Requirements come before you make tasks.
Not especially. However, infra have a standing list of requirements for
any service. This list of tasks you see was agreed, verbally, at the git
get-together in Atlanta.
> I know it's much more fun to sit down and hack on something. Communication is
> the hard part.
Then communicate less aggressively and avoid getting peoples
irritability levels higher.
>
> So you just formulated the first requirement: The infrastructure team
> shouldn't be required to learn anything new. Now questions could be:
>
> - Who is the infrastructure team? I don't know.
To keep it simple, we are infrastructure@, or in some cases limited to
root@
> - Do they agree with this requirement?
What requirement? You mean your childish statement? "The infrastructure
team shouldn't be required to learn anything new." Well, I for one do
not agree.
If we "dont learn it" it wont be made available. As we will ultimately
be the ones too support it.
> - Could somebody else join the infrastructure team who would like to work with
> something new?
Sure, rock on up on the ML, take part, earn your merit like everyone
else, like all our projects. We dont just hand out shell accounts like
sweets/candy.
> - Could the GIT installation be administrated by another, dedicated GIT team?
Put simply, no. We do not divide the team up like that, it simply does
not scale. However, whilst we have people who have stronger skills in
some areas, no one person or group of people is responsible for a given
toolset.
You may think that the infra team are impossible to please, hard to
break into, hard to get information from. This is not because we want
to be awkward little bastards, but because we have a responsibility to
maintain very high standards of service, unfortunately this can mean
people think we are a hard bunch of people to speak too. This is not
true, you just have to approach us in the right way.
Being aggressive in your tone, and accusing of not giving you all the
latest toys on a whim is one way to piss us off. We have to balance
requests like this against the risk, the time to test, deploy, maintain,
secure and keep up against whimsical requests. We often do this by
asking folks to help with the service, this often serves as a good
indicator as too how much something is really wanted.
- --
Cheers,
Tony
- ------------------------
tony@pc-tony.com
pctony@apache.org
tony@caret.cam.ac.uk
http://blog.pc-tony.com
GPG - 1024D/51047D66
- ------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VMbkACgkQyceSTlEEfWaFAQCgjETiAn95fktQYn8DaKEvWQJf
WyQAn0lZygkpES+NhClERJj/oPtRkKEe
=2SpR
-----END PGP SIGNATURE-----
Re: Blog post on Gerrit (GIT review tool)
Posted by Santiago Gala <sa...@gmail.com>.
FYI, the (incubating) wave in a box project used to use
http://codereview.waveprotocol.org/ for code review (not sure if a gerrit
instance, reviewboard, rietveld or a similar tool). They used mercurial as
SCM and are in the process to migrate to the ASF infrastructure. People
familiar with their former environment might give more information if asked
at wave-dev@incubator.
Regards
Santiago
On Fri, Feb 11, 2011 at 5:53 PM, Owen O'Malley <om...@apache.org> wrote:
>
> On Feb 10, 2011, at 11:20 PM, Thomas Koch wrote:
>
> And it's not much IMHO what needs to be learned. It's a well packaged,
>> proven
>> system with a big, active and maybe even helpful community.
>> And I also offered my help to set it up. I can also help in maintenance,
>> if
>> you really need it. I also already did set up a test instance (on request
>> of
>> Owen O'Malley) without any trouble.
>>
>
> I tried to figure out what I was supposed to do, but the documentation that
> I found was mostly deeply tied to android's process. I ran out of time
> trying to figure it out and meant to reach out to you to get help, but it
> slipped off my plate.
>
> Is there a page that runs through the flow of how to upload a patch, have
> someone review it, and get it committed?
>
> -- Owen
>
>
Re: Blog post on Gerrit (GIT review tool)
Posted by Owen O'Malley <om...@apache.org>.
On Feb 10, 2011, at 11:20 PM, Thomas Koch wrote:
> And it's not much IMHO what needs to be learned. It's a well
> packaged, proven
> system with a big, active and maybe even helpful community.
> And I also offered my help to set it up. I can also help in
> maintenance, if
> you really need it. I also already did set up a test instance (on
> request of
> Owen O'Malley) without any trouble.
I tried to figure out what I was supposed to do, but the documentation
that I found was mostly deeply tied to android's process. I ran out of
time trying to figure it out and meant to reach out to you to get
help, but it slipped off my plate.
Is there a page that runs through the flow of how to upload a patch,
have someone review it, and get it committed?
-- Owen
Re: Blog post on Gerrit (GIT review tool)
Posted by Tony Stevenson <pc...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/02/2011 12:24, Santiago Gala wrote:
> On Fri, Feb 11, 2011 at 1:10 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> Not as an ASF project. As an ASF project is one year old.
>
Right, stop the bitching already.
It is a large project, we (TheASF) made a big song and dance about it in
Oakland. It stores all the code that the makes TheASF.
Moving on though. The attitudes around here need to smarten up and quick.
Clearly you guys are free to progress with this as you wish, and you can
present your results to infra{-dev}@ as you see fit. So long as you
realise it may not be chosen, or indeed it may. If it is we will expect
a detailed runbook, and details. As well as the code added to SVN, and
licensed accordingly.
So if you want to try different options. Have at it. Just keep this ML
in the loop.
- --
Cheers,
Tony
- ------------------------
tony@pc-tony.com
pctony@apache.org
tony@caret.cam.ac.uk
http://blog.pc-tony.com
GPG - 1024D/51047D66
- ------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1VLoMACgkQyceSTlEEfWYdgwCggf3MS0Crn1GVr0zEzv1qjpEi
85EAni05oqX+HwMOb62XS11vTRMR/LvV
=JiSu
-----END PGP SIGNATURE-----
Re: Blog post on Gerrit (GIT review tool)
Posted by Santiago Gala <sa...@gmail.com>.
On Fri, Feb 11, 2011 at 1:10 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> Santiago Gala wrote on Fri, Feb 11, 2011 at 12:01:10 +0100:
> > On Fri, Feb 11, 2011 at 10:48 AM, Gav... <ga...@16degrees.com.au> wrote:
> >
> > > Whatever gave you the idea that
> > > berating a flagship Apache product at Apache was a good thing to do?
> > >
> >
> > I didn't know Subversion was a *flagship* Apache project. It just
> graduated
> > from incubation a few months ago.
> >
>
> It's 10 years old, not one year old.
>
Not as an ASF project. As an ASF project is one year old.
Re: Blog post on Gerrit (GIT review tool)
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Santiago Gala wrote on Fri, Feb 11, 2011 at 12:01:10 +0100:
> On Fri, Feb 11, 2011 at 10:48 AM, Gav... <ga...@16degrees.com.au> wrote:
>
> > Whatever gave you the idea that
> > berating a flagship Apache product at Apache was a good thing to do?
> >
>
> I didn't know Subversion was a *flagship* Apache project. It just graduated
> from incubation a few months ago.
>
It's 10 years old, not one year old.
Re: Blog post on Gerrit (GIT review tool)
Posted by Santiago Gala <sa...@gmail.com>.
On Fri, Feb 11, 2011 at 10:48 AM, Gav... <ga...@16degrees.com.au> wrote:
> Whatever gave you the idea that
> berating a flagship Apache product at Apache was a good thing to do?
>
I didn't know Subversion was a *flagship* Apache project. It just graduated
from incubation a few months ago.
Regards
Santiago
Re: Blog post on Gerrit (GIT review tool)
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello Jukka,
I have just read the blog post of Alblue
http://alblue.bandlem.com/2011/02/someday.html which was mentioned
by Thomas at the beginning of the thread and I found it quite
convincing. Especially with the part about the use of jenkins to
validate the branches/patches.
Reading this gives me a feeling that it could help various contributors
in the community to prepare patches and give a chance
to the committers to have a process to work on the patches/bug reports.
I am sensitive too to the rationale exposed by Thomas to use a proven
system rather than try to develop one's own.
That said if we can get both the system of Paul and gerrit working it
would be great.
That will give me [ and maybe a lot of other committers at Apache ] a
chance to get exposed to git. I have only used git once a few seconds
for now.
Regards,
Antoine
On 2/11/2011 5:06 AM, Jukka Zitting wrote:
> Hi,
>
> Timeout! There have been communication breaks, which is now causing
> some tension. How about if we started fresh with what we have now and
> forget who said or didn't say what before? We have a number of people
> who are interested and even passionate about this, which is a great
> thing! Now we just need to channel that energy productively.
>
> The system Paul has been setting up seems to be pretty good already
> and looks like the best path forward for now. Gerrit adds a few extra
> features that would be quite useful at least to some projects. As Paul
> said, there's no reason why we couldn't (and good reasons why we
> should!) develop these approaches in parallel, and perhaps we could
> even find a way to make them work together.
>
> BR,
>
> Jukka Zitting
Re: Blog post on Gerrit (GIT review tool)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
Timeout! There have been communication breaks, which is now causing
some tension. How about if we started fresh with what we have now and
forget who said or didn't say what before? We have a number of people
who are interested and even passionate about this, which is a great
thing! Now we just need to channel that energy productively.
The system Paul has been setting up seems to be pretty good already
and looks like the best path forward for now. Gerrit adds a few extra
features that would be quite useful at least to some projects. As Paul
said, there's no reason why we couldn't (and good reasons why we
should!) develop these approaches in parallel, and perhaps we could
even find a way to make them work together.
BR,
Jukka Zitting
RE: Blog post on Gerrit (GIT review tool)
Posted by "Gav..." <ga...@16degrees.com.au>.
> -----Original Message-----
> From: Thomas Koch [mailto:thomas@koch.ro]
> Sent: Friday, 11 February 2011 5:20 PM
> To: Paul Davis
> Cc: infrastructure-dev@apache.org
> Subject: Re: Blog post on Gerrit (GIT review tool)
>
> Paul Davis:
> > > OTOH I don't think git can be used "much the same" as svn. I would
> > > recommend any people that has not used git deeply to avoid
> comparing it
> > > with subversion until they have used it deeply during, say, one
> year. By
> > > using I
> >
> > > mean at least:
> > I was worried someone would take that comment wrong. I should've been
> > more clear.
> >
> > I meant to point out that it would be the same or similar from the
> > point of view of the infrastructure team. As in, it'd be hosted by
> > httpd, use mod_ldap for authentication, some various pieces of code
> to
> > plug in ldap groups for authorization, etc. It'd be based on services
> > for which there is already experience running.
> >
> > This is opposed to something like Gerrit that would require multiple
> > people on the infrastructure team to learn and care for a new service
> > as well as require changes to processes like getting CLA's and such
> > forth.
> >
> > HTH,
> > Paul Davis
> So just because some people on infra should be avoided the burden to
> learn
> something new, some thousand developers should suffer from a suboptimal
> system?
You really are not winning any friends whatsoever with your bias towards
Git and your disdain of Apache Subversion. Whatever gave you the idea that
berating a flagship Apache product at Apache was a good thing to do?
The ASF has long been based around Subversion, calling it suboptimal and
trying to shove Git in the face of everyone that has used it for years
really
is the wrong way to gain favour here.
'Infra' is not averse to learning new things, there are many many new things
that can and are learned, Git and Gerrit and just a part of that.
> And it's not much IMHO what needs to be learned. It's a well packaged,
> proven
> system with a big, active and maybe even helpful community.
That and a thousand other products.
> And I also offered my help to set it up. I can also help in
> maintenance, if
> you really need it. I also already did set up a test instance (on
> request of
> Owen O'Malley) without any trouble.
I'm sure you did, we have see it.
>
> It would just help to have just a little bit of communication going on.
You need to stop with the negative tones you have towards Subversion and the
Apache way of things. You need to stop saying Gerrit is everything don't
even
bother looking elsewhere.
We will and have looked at Gerrit. We will continue to evaluate it, we will
also look at other options that will (shock to you Im sure) not involve
Gerrit.
We will make the choices that best fit the Apache Software Foundation. If
that
in the end includes Gerrit, then fine, we are all happy. If that does not
include
Gerrit then you must accept that and move on, because we are not all about
you.
> I've
> asked for a list of requirements on 2010/12/04 and even started a draft
> list
> to help out. However there wasn't any reaction to that.
These things take time.
>
> Please note that the list of _TASKS_ on jira is not a list of
> requirements.
> Requirements come before you make tasks.
Then you must ask the specific questions that you need answers to. The ASF
has
its own conditions on which commits are made etc, those tasks in Jira have
conditions in mind.
>
> I know it's much more fun to sit down and hack on something.
> Communication is
> the hard part.
I agree, so far you have not impressed me at all with your communication.
>
> So you just formulated the first requirement: The infrastructure team
> shouldn't be required to learn anything new. Now questions could be:
>
> - Who is the infrastructure team? I don't know.
The infrastructure team is a team of highly skilled and dedicated volunteers
and 2 paid staff than run the hardware and software for the entire
foundation,
keeping things running smoothly for nearly 3000 committers, nearly 400
members,
and many millions of contributors and end users.
> - Do they agree with this requirement?
Some of the infrastructure team agree that a Git read/write repo is worth
looking
at on a test basis for evaluation. There is no promise at this stage that it
will
succeed or remain beyond the evaluation. Though it is certainly possible.
> - Could somebody else join the infrastructure team who would like to
> work with
> something new?
Absolutely, though usually, like everything else in life, you can just wave
a badge
and get in 5 minutes. Trust and respect has to be earned, that does not mean
giving
a list of achievements.
> - Could the GIT installation be administrated by another, dedicated GIT
> team?
I would say not. Dedicated teams have been tried in the past and failed. We
have one
infrastructure team, not several splinter groups.
Now, you may find my email here negative, I am just being as blunt as you
are in your
emails and pointing out that talking in this manner is not going to get
anyone
anywhere.
The move towards providing more Git based services is going to take time, it
may or may
not involve Gerrit, please be aware of that fact in your efforts to offer
help. Also be
aware that there are few other volunteers that currently have time to work
on the Git
effort, so be patient. You must also work with our Jira system and file
issues as you
see them, despite your hate for the product that we must use on a daily
basis.
Now, if you have ideas, or very specific questions, please go ahead and ask,
be patient
for an answer and be polite without any bias. We like people that just get
things done
without fuss and without trouble, if we spot trouble makers we tend to steer
clear.
Gav...
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro
Re: Blog post on Gerrit (GIT review tool)
Posted by Thomas Koch <th...@koch.ro>.
Paul Davis:
> > OTOH I don't think git can be used "much the same" as svn. I would
> > recommend any people that has not used git deeply to avoid comparing it
> > with subversion until they have used it deeply during, say, one year. By
> > using I
>
> > mean at least:
> I was worried someone would take that comment wrong. I should've been
> more clear.
>
> I meant to point out that it would be the same or similar from the
> point of view of the infrastructure team. As in, it'd be hosted by
> httpd, use mod_ldap for authentication, some various pieces of code to
> plug in ldap groups for authorization, etc. It'd be based on services
> for which there is already experience running.
>
> This is opposed to something like Gerrit that would require multiple
> people on the infrastructure team to learn and care for a new service
> as well as require changes to processes like getting CLA's and such
> forth.
>
> HTH,
> Paul Davis
So just because some people on infra should be avoided the burden to learn
something new, some thousand developers should suffer from a suboptimal
system?
And it's not much IMHO what needs to be learned. It's a well packaged, proven
system with a big, active and maybe even helpful community.
And I also offered my help to set it up. I can also help in maintenance, if
you really need it. I also already did set up a test instance (on request of
Owen O'Malley) without any trouble.
It would just help to have just a little bit of communication going on. I've
asked for a list of requirements on 2010/12/04 and even started a draft list
to help out. However there wasn't any reaction to that.
Please note that the list of _TASKS_ on jira is not a list of requirements.
Requirements come before you make tasks.
I know it's much more fun to sit down and hack on something. Communication is
the hard part.
So you just formulated the first requirement: The infrastructure team
shouldn't be required to learn anything new. Now questions could be:
- Who is the infrastructure team? I don't know.
- Do they agree with this requirement?
- Could somebody else join the infrastructure team who would like to work with
something new?
- Could the GIT installation be administrated by another, dedicated GIT team?
Best regards,
Thomas Koch, http://www.koch.ro
Re: Blog post on Gerrit (GIT review tool)
Posted by Santiago Gala <sa...@gmail.com>.
On Tue, Feb 15, 2011 at 4:47 PM, Steve Loughran <st...@apache.org> wrote:
> On 10/02/11 20:42, Santiago Gala wrote:
>
> My opinion is the gerrit is one of the best ways to get low entry barriers
>> and open collaboration, around a repository. I have had a number of
>> commits
>> into cyanogenmod, all via gerrit. I signed up a CLA via web, keep my own
>> repository and use "repo upload" for automatic push to gerrit.
>>
>
> I've not used gerrit; no experience.
>
>
>
> OTOH I don't think git can be used "much the same" as svn. I would
>> recommend
>> any people that has not used git deeply to avoid comparing it with
>> subversion until they have used it deeply during, say, one year. By using
>> I
>> mean at least:
>> - one small standalone project, with several ongoing branches and changes
>> getting applied in subsets of those, during a significant time.
>> - one long lived branch of a small size collective project, where the main
>> developer takes some of our patches and we take patches from him and from
>> other developers, some of which can later be merged into the main line (
>> for
>> instance I am stariing to work like this with bottle.py again for this
>> year's course: https://github.com/sgala/bottle/network )
>> - "casual" contributions to a big project, such as my small patches and
>> translations for cyanogenmod ( see for example
>> http://review.cyanogenmod.com/#dashboard,225 )
>>
>
> I've been using it on some multi machine stuff, but even there, I'm still
> learning, and as we move to some team stuff at work it's going to be hard
> keeping a bunch of prima donna's under control "It's in MY repository" they
> will say when I corner them and ask why their code bears no resemblance to
> what pretends to be a normative specification.
>
> I imagine Hudson/Jenkins will need to be ruthless here and
>
> -require everyone to push their changes, even personal ones, to a remote
> repository that is open to others for reading. Yes, that means no rebasing,
> but tough.
>
rebasing could be allowed if the "personal" branched are socially taken as a
showcase. The contract would be that when someone is interested in a commit
from a personal branch, she would ask the owner to push it to an integration
branch, rebasing if needed, and everybody takes ot from there.
> -have hudson/jenkins set up to build and test the branches of these
> personal repos, as well as the shared ones.
> -worry a lot about how to merge things. Let people push their branches up
> but have an Integration branch that people are expected to follow and merge
> with.
>
>
An interesting query, that I'm doing more and more as I try to learn what
goes where in the set of android repositories and branches, is something
like:
git log --stat -p ^local-branch remote-branch
i.e., a log of the commits from "remote-branch" that I don't have in my
local branch. Frequently there are also non-empty "git log --stat -p
^remote-branch local-branch", and zipping together both branches is what
integration is about.
quite often, even when comparing different branches of kernels from
different (android) devices, the logs of diverging history are quite small,
~10-20 commits.
The same kind of queries can give ideas such as:
what is there in a branch that is not in last release? what commits am I
missing from the stable branch?...
> I'm not sure which are the current infrastructure requirements, but I
>> think
>> that no svn-like git workflow will be a significant advantage about plain
>> old svn.
>>
>
> I think it does some things that are good, some things that are danger
>
> -good: everyone gets SCM. It doesn't have that "committer",
> "non-committer" split any more, as everyone is equal.
>
>
One side effect is that patches come with proper metadata: who, when, log
messages, ..., as they are commits from a remote repository.
> -good: ease of switching branches and working offline encourages people to
> have a separate branch for every issue, and integration branches that merge
> things.
>
>
something I do frequently in git is: cherry pick a small number of commits
from my "dirty" wotking branch, sometimes splitting some, sometimes joining
them, into a coherent, purposeful set of patches. Issue a pull request or
merge directly this small set somewhere, and cleanup my work branch to
contain the rest of my work-queue.
The main difference I see re: svn or cvs is that commits are easy to do and
redo, so I'm not lazy when it comes to committing small sets of changes, or
to get things perfect at first try.
> -danger: ease of diverging your code from the rest of the teams.
>
>
This danger exists, but is similar to the danger of keeing big modified
working copies in centralised SCM, be it because you are offline or because
you don't feel sure this is the right thing to do.
> I can't say what makes a good workflow here, I'm just starting out to lay
> one down. I know what doesn't work, but not what does.
>
>
Agreed.
> Now, in the Hadoop group there are some interesting issues coming up
>
> -Y! want to merge their changes (on Github?) into hadoop-core,
> hadoop-hdfs, hadoop-mapred. Now, if the apache projects were also in git, I
> think this would be easier to do. But I worry about moving big projects to
> Git right now, not without more experience of using it in Apache.
>
>
I'd do a git-svn repository from the official tree and then try to rebase
their changes on top of it, and commit those to svn using git-svn once the
history looks right. A git repository can contain any number of roots, so
the same repository can hold the git-svn branches and Y! ones together,
making it relatively simple to do diffs or to cherry-pick commits.
> -some of the undermaintained contributions are going to be put in the
> attic, but some ought to go into incubation, such as MRUnit, a unit testing
> tool. It would be an interesting experiment to host that project's code in
> Git, to see how well it works, to see what the ASF+git collaboration
> processes should become.
>
> -steve
>
>
>
Re: Blog post on Gerrit (GIT review tool)
Posted by Steve Loughran <st...@apache.org>.
On 10/02/11 20:42, Santiago Gala wrote:
> My opinion is the gerrit is one of the best ways to get low entry barriers
> and open collaboration, around a repository. I have had a number of commits
> into cyanogenmod, all via gerrit. I signed up a CLA via web, keep my own
> repository and use "repo upload" for automatic push to gerrit.
I've not used gerrit; no experience.
> OTOH I don't think git can be used "much the same" as svn. I would recommend
> any people that has not used git deeply to avoid comparing it with
> subversion until they have used it deeply during, say, one year. By using I
> mean at least:
> - one small standalone project, with several ongoing branches and changes
> getting applied in subsets of those, during a significant time.
> - one long lived branch of a small size collective project, where the main
> developer takes some of our patches and we take patches from him and from
> other developers, some of which can later be merged into the main line ( for
> instance I am stariing to work like this with bottle.py again for this
> year's course: https://github.com/sgala/bottle/network )
> - "casual" contributions to a big project, such as my small patches and
> translations for cyanogenmod ( see for example
> http://review.cyanogenmod.com/#dashboard,225 )
I've been using it on some multi machine stuff, but even there, I'm
still learning, and as we move to some team stuff at work it's going to
be hard keeping a bunch of prima donna's under control "It's in MY
repository" they will say when I corner them and ask why their code
bears no resemblance to what pretends to be a normative specification.
I imagine Hudson/Jenkins will need to be ruthless here and
-require everyone to push their changes, even personal ones, to a
remote repository that is open to others for reading. Yes, that means no
rebasing, but tough.
-have hudson/jenkins set up to build and test the branches of these
personal repos, as well as the shared ones.
-worry a lot about how to merge things. Let people push their branches
up but have an Integration branch that people are expected to follow and
merge with.
> I'm not sure which are the current infrastructure requirements, but I think
> that no svn-like git workflow will be a significant advantage about plain
> old svn.
I think it does some things that are good, some things that are danger
-good: everyone gets SCM. It doesn't have that "committer",
"non-committer" split any more, as everyone is equal.
-good: ease of switching branches and working offline encourages
people to have a separate branch for every issue, and integration
branches that merge things.
-danger: ease of diverging your code from the rest of the teams.
I can't say what makes a good workflow here, I'm just starting out to
lay one down. I know what doesn't work, but not what does.
Now, in the Hadoop group there are some interesting issues coming up
-Y! want to merge their changes (on Github?) into hadoop-core,
hadoop-hdfs, hadoop-mapred. Now, if the apache projects were also in
git, I think this would be easier to do. But I worry about moving big
projects to Git right now, not without more experience of using it in
Apache.
-some of the undermaintained contributions are going to be put in the
attic, but some ought to go into incubation, such as MRUnit, a unit
testing tool. It would be an interesting experiment to host that
project's code in Git, to see how well it works, to see what the ASF+git
collaboration processes should become.
-steve
Re: Blog post on Gerrit (GIT review tool)
Posted by Paul Davis <pa...@gmail.com>.
> OTOH I don't think git can be used "much the same" as svn. I would recommend
> any people that has not used git deeply to avoid comparing it with
> subversion until they have used it deeply during, say, one year. By using I
> mean at least:
I was worried someone would take that comment wrong. I should've been
more clear.
I meant to point out that it would be the same or similar from the
point of view of the infrastructure team. As in, it'd be hosted by
httpd, use mod_ldap for authentication, some various pieces of code to
plug in ldap groups for authorization, etc. It'd be based on services
for which there is already experience running.
This is opposed to something like Gerrit that would require multiple
people on the infrastructure team to learn and care for a new service
as well as require changes to processes like getting CLA's and such
forth.
HTH,
Paul Davis
Re: Blog post on Gerrit (GIT review tool)
Posted by Santiago Gala <sa...@gmail.com>.
On Thu, Feb 10, 2011 at 8:19 PM, Paul Davis <pa...@gmail.com>wrote:
> On Thu, Feb 10, 2011 at 11:39 AM, Thomas Koch <th...@koch.ro> wrote:
> > Paul Davis:
> >> On Thu, Feb 10, 2011 at 4:44 AM, Thomas Koch <th...@koch.ro> wrote:
> >> > http://alblue.bandlem.com/2011/02/someday.html
> >> >
> >> > Very nice writeup of the advantages of Gerrit and integration with
> >> > Jenkins.
> >> >
> >> > Gerrit is a code review plattform on top of GIT developed by Google
> for
> >> > the Android project and in use at the Eclipse Foundation.
> >> >
> >> > How do you think in general about GIT for the ASF? It puzzles me, that
> >> > there doesn't seem to be much of an interest to get official GIT
> >> > repositories despite the pain of working with Subversion. The
> discussion
> >> > on infra@a.o is stale for more then 2 months now.
> >> >
> >> > Best regards,
> >> >
> >> > Thomas Koch, http://www.koch.ro
> >>
> >> I've been working on various scripts and configurations to get a more
> >> traditional setup over the last couple months. There current bits are
> >> at [1]. So far I have most of the major requirements [2] handled and
> >> working. The last bit of code that I need to write is the logging of
> >> commits so that we have a history of who pushed what.
> >>
> >> After that my next steps are to start documenting the code and
> >> configuration and then write up documentation on committer and
> >> non-committer workflows.
> >>
> >> If anyone feels like hacking or writing feel free to ping me in
> >> #asfinfra on freenode or just start committing to that repository (any
> >> committer has write access for the time being).
> >>
> >> [1] http://git-wip-us.apache.org/git?p=asfgit-admin.git;a=summary
> >> [2]
> >>
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQu
> >>
> ery=project+%3D+INFRA+AND+component+%3D+Git+AND+status+%3D+Open+ORDER+BY+pr
> >> iority+DESC&mode=hide
> > Hi Paul,
> >
> > I feel bad, very bad. That being said, I try to be as objective and
> friendly
> > as possible.
> >
> > On 2010/11/25 you wrote[1] , that you'd like to start hacking on GIT and
> test
> > it out on couchdb. Three days later I responded[2] to you and on the
> list,
> > that I'd strongly propose to evaluate Gerrit before any time is wasted
> hacking
> > together some home grown scripts. I also offered my help.
> >
> > Nevertheless you did not care to answer me or give any further hint that
> you'd
> > indeed start hacking.
> >
> > The only indication that you indeed might have worked on something were
> your
> > comments in the jira issues. It was my failure that I did not watch them.
> > However you also did not care to assigne any of these issues to you.
> >
> > Could we please try to start over again and make a concept in an open
> process?
> > I believe you're wasting your time. Even worse we might end up with your
> hand-
> > wired GIT setup while IMHO an almost perfect solution is turn-key ready.
> >
> > I hope you can understand my dissapointment and won't take this personal.
> >
> > [1] "Re: Git Tasks" on infra@a.o
> > [2] Gerrit over gitolite? was: Git Tasks
> >
> > Best regards,
> >
> > Thomas Koch, http://www.koch.ro
> >
>
> Don't be sad. Its just code.
>
> Apologies for not responding about trying out Gerrit but to be honest
> I don't really have much desire to administer or use it. If it becomes
> the one and only way to use Git at Apache then I'd probably put up
> with it much the same as I put up with Jira. Although, I would
> encourage others to set it up and evaluate it. There's no reason that
> we can't investigate multiple methods for using Git and see which
> solution looks like it'll be the best in terms of infrastructure
> support, user satisfaction, and compatibility with established
> processes (or worth changing existing processes).
>
> My opinion is that the most likely solution to using Git at ASF will
> treat it much the same as SVN. To that end I've been working on
> putting together the required code and configuration to make it
> possible to evaluate such a solution. At the beginning of my work I
> evaluated Gitosis and Gitolite but neither was close enough to
> fulfilling the requirements laid out by infra for a viable solution,
> hence the code I've been hacking on.
>
My opinion is the gerrit is one of the best ways to get low entry barriers
and open collaboration, around a repository. I have had a number of commits
into cyanogenmod, all via gerrit. I signed up a CLA via web, keep my own
repository and use "repo upload" for automatic push to gerrit.
OTOH I don't think git can be used "much the same" as svn. I would recommend
any people that has not used git deeply to avoid comparing it with
subversion until they have used it deeply during, say, one year. By using I
mean at least:
- one small standalone project, with several ongoing branches and changes
getting applied in subsets of those, during a significant time.
- one long lived branch of a small size collective project, where the main
developer takes some of our patches and we take patches from him and from
other developers, some of which can later be merged into the main line ( for
instance I am stariing to work like this with bottle.py again for this
year's course: https://github.com/sgala/bottle/network )
- "casual" contributions to a big project, such as my small patches and
translations for cyanogenmod ( see for example
http://review.cyanogenmod.com/#dashboard,225 )
I'm not sure which are the current infrastructure requirements, but I think
that no svn-like git workflow will be a significant advantage about plain
old svn.
git is very disruptive for the old hierarchical SCM, and I think that theASF
is actually loosing steam in this process...
Regards
Santiago
> If it turns out that the final solution for Git at ASF doesn't use
> anything I've worked on, I've still won, because we'll be able to use
> Git at ASF. I'm not taking anything personally, but I can't fathom
> why you're disappointed. If you think that my solution is terrible and
> there's a much better one out there, I very much encourage you to
> convince everyone of that.
>
> HTH,
> Paul Davis
>
Re: Blog post on Gerrit (GIT review tool)
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Feb 10, 2011 at 11:39 AM, Thomas Koch <th...@koch.ro> wrote:
> Paul Davis:
>> On Thu, Feb 10, 2011 at 4:44 AM, Thomas Koch <th...@koch.ro> wrote:
>> > http://alblue.bandlem.com/2011/02/someday.html
>> >
>> > Very nice writeup of the advantages of Gerrit and integration with
>> > Jenkins.
>> >
>> > Gerrit is a code review plattform on top of GIT developed by Google for
>> > the Android project and in use at the Eclipse Foundation.
>> >
>> > How do you think in general about GIT for the ASF? It puzzles me, that
>> > there doesn't seem to be much of an interest to get official GIT
>> > repositories despite the pain of working with Subversion. The discussion
>> > on infra@a.o is stale for more then 2 months now.
>> >
>> > Best regards,
>> >
>> > Thomas Koch, http://www.koch.ro
>>
>> I've been working on various scripts and configurations to get a more
>> traditional setup over the last couple months. There current bits are
>> at [1]. So far I have most of the major requirements [2] handled and
>> working. The last bit of code that I need to write is the logging of
>> commits so that we have a history of who pushed what.
>>
>> After that my next steps are to start documenting the code and
>> configuration and then write up documentation on committer and
>> non-committer workflows.
>>
>> If anyone feels like hacking or writing feel free to ping me in
>> #asfinfra on freenode or just start committing to that repository (any
>> committer has write access for the time being).
>>
>> [1] http://git-wip-us.apache.org/git?p=asfgit-admin.git;a=summary
>> [2]
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQu
>> ery=project+%3D+INFRA+AND+component+%3D+Git+AND+status+%3D+Open+ORDER+BY+pr
>> iority+DESC&mode=hide
> Hi Paul,
>
> I feel bad, very bad. That being said, I try to be as objective and friendly
> as possible.
>
> On 2010/11/25 you wrote[1] , that you'd like to start hacking on GIT and test
> it out on couchdb. Three days later I responded[2] to you and on the list,
> that I'd strongly propose to evaluate Gerrit before any time is wasted hacking
> together some home grown scripts. I also offered my help.
>
> Nevertheless you did not care to answer me or give any further hint that you'd
> indeed start hacking.
>
> The only indication that you indeed might have worked on something were your
> comments in the jira issues. It was my failure that I did not watch them.
> However you also did not care to assigne any of these issues to you.
>
> Could we please try to start over again and make a concept in an open process?
> I believe you're wasting your time. Even worse we might end up with your hand-
> wired GIT setup while IMHO an almost perfect solution is turn-key ready.
>
> I hope you can understand my dissapointment and won't take this personal.
>
> [1] "Re: Git Tasks" on infra@a.o
> [2] Gerrit over gitolite? was: Git Tasks
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro
>
Don't be sad. Its just code.
Apologies for not responding about trying out Gerrit but to be honest
I don't really have much desire to administer or use it. If it becomes
the one and only way to use Git at Apache then I'd probably put up
with it much the same as I put up with Jira. Although, I would
encourage others to set it up and evaluate it. There's no reason that
we can't investigate multiple methods for using Git and see which
solution looks like it'll be the best in terms of infrastructure
support, user satisfaction, and compatibility with established
processes (or worth changing existing processes).
My opinion is that the most likely solution to using Git at ASF will
treat it much the same as SVN. To that end I've been working on
putting together the required code and configuration to make it
possible to evaluate such a solution. At the beginning of my work I
evaluated Gitosis and Gitolite but neither was close enough to
fulfilling the requirements laid out by infra for a viable solution,
hence the code I've been hacking on.
If it turns out that the final solution for Git at ASF doesn't use
anything I've worked on, I've still won, because we'll be able to use
Git at ASF. I'm not taking anything personally, but I can't fathom
why you're disappointed. If you think that my solution is terrible and
there's a much better one out there, I very much encourage you to
convince everyone of that.
HTH,
Paul Davis
Re: Blog post on Gerrit (GIT review tool)
Posted by Thomas Koch <th...@koch.ro>.
Paul Davis:
> On Thu, Feb 10, 2011 at 4:44 AM, Thomas Koch <th...@koch.ro> wrote:
> > http://alblue.bandlem.com/2011/02/someday.html
> >
> > Very nice writeup of the advantages of Gerrit and integration with
> > Jenkins.
> >
> > Gerrit is a code review plattform on top of GIT developed by Google for
> > the Android project and in use at the Eclipse Foundation.
> >
> > How do you think in general about GIT for the ASF? It puzzles me, that
> > there doesn't seem to be much of an interest to get official GIT
> > repositories despite the pain of working with Subversion. The discussion
> > on infra@a.o is stale for more then 2 months now.
> >
> > Best regards,
> >
> > Thomas Koch, http://www.koch.ro
>
> I've been working on various scripts and configurations to get a more
> traditional setup over the last couple months. There current bits are
> at [1]. So far I have most of the major requirements [2] handled and
> working. The last bit of code that I need to write is the logging of
> commits so that we have a history of who pushed what.
>
> After that my next steps are to start documenting the code and
> configuration and then write up documentation on committer and
> non-committer workflows.
>
> If anyone feels like hacking or writing feel free to ping me in
> #asfinfra on freenode or just start committing to that repository (any
> committer has write access for the time being).
>
> [1] http://git-wip-us.apache.org/git?p=asfgit-admin.git;a=summary
> [2]
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQu
> ery=project+%3D+INFRA+AND+component+%3D+Git+AND+status+%3D+Open+ORDER+BY+pr
> iority+DESC&mode=hide
Hi Paul,
I feel bad, very bad. That being said, I try to be as objective and friendly
as possible.
On 2010/11/25 you wrote[1] , that you'd like to start hacking on GIT and test
it out on couchdb. Three days later I responded[2] to you and on the list,
that I'd strongly propose to evaluate Gerrit before any time is wasted hacking
together some home grown scripts. I also offered my help.
Nevertheless you did not care to answer me or give any further hint that you'd
indeed start hacking.
The only indication that you indeed might have worked on something were your
comments in the jira issues. It was my failure that I did not watch them.
However you also did not care to assigne any of these issues to you.
Could we please try to start over again and make a concept in an open process?
I believe you're wasting your time. Even worse we might end up with your hand-
wired GIT setup while IMHO an almost perfect solution is turn-key ready.
I hope you can understand my dissapointment and won't take this personal.
[1] "Re: Git Tasks" on infra@a.o
[2] Gerrit over gitolite? was: Git Tasks
Best regards,
Thomas Koch, http://www.koch.ro
Re: Blog post on Gerrit (GIT review tool)
Posted by Paul Davis <pa...@gmail.com>.
On Thu, Feb 10, 2011 at 4:44 AM, Thomas Koch <th...@koch.ro> wrote:
> http://alblue.bandlem.com/2011/02/someday.html
>
> Very nice writeup of the advantages of Gerrit and integration with Jenkins.
>
> Gerrit is a code review plattform on top of GIT developed by Google for the
> Android project and in use at the Eclipse Foundation.
>
> How do you think in general about GIT for the ASF? It puzzles me, that there
> doesn't seem to be much of an interest to get official GIT repositories
> despite the pain of working with Subversion. The discussion on infra@a.o is
> stale for more then 2 months now.
>
> Best regards,
>
> Thomas Koch, http://www.koch.ro
>
I've been working on various scripts and configurations to get a more
traditional setup over the last couple months. There current bits are
at [1]. So far I have most of the major requirements [2] handled and
working. The last bit of code that I need to write is the logging of
commits so that we have a history of who pushed what.
After that my next steps are to start documenting the code and
configuration and then write up documentation on committer and
non-committer workflows.
If anyone feels like hacking or writing feel free to ping me in
#asfinfra on freenode or just start committing to that repository (any
committer has write access for the time being).
[1] http://git-wip-us.apache.org/git?p=asfgit-admin.git;a=summary
[2] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+INFRA+AND+component+%3D+Git+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide