www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Blog post on Gerrit (GIT review tool)
Date Tue, 15 Feb 2011 15:47:04 GMT
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



Mime
View raw message