www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: [scm] Version control tools for contributors
Date Fri, 25 Apr 2008 10:03:15 GMT
El mié, 23-04-2008 a las 15:02 -0500, Jesse McConnell escribió:
> I won't address the individual points, just generally explain what I mean
> since I think its pretty basic.
> 
> It breaks down to how the tools are going to be used.  Obviously, if the
> changesets being consumed by a project are small and often then its really
> not that big a deal either way.  Processing large patches or changesets are
> always a big deal and the intent behind many GSoC projects are nontrivial,
> sizable chunks of code.  How the student (or anyone) is presented with the

Precisely because of the fact that the final contribution is a sizable
chunk of code, it might make sense (or not, depending if the chunk is a
refactoring or a new block of functionality) to have it as a number of
changesets.

As an example, I recently did a trivial but big refactoring using
git(-svn). I did it and maintained it using git as almost 40 different
commits, which *should* have the following properties:
- each one kept the build going (in fact in the process I found a number
of errors and had to bisect back to diagnose)
- each one renamed a variable/method or similar "unit"
- each one built on the previous ones.

Then the moment to commit arrived, I asked what was people preferring.
There would have been no problem to me committing 40 revisions to svn or
just the final, aggregated one. People preferred one revision, but my
guess is that it happened because we don't have enough patch culture. 40
revisions made the code:
- testable individually for each small change
- the purpose of a 20 lines patch is obviously easier to review and vet
that the purpose of a 1300 lines patch

You can see several versions the patches at Jira:
https://issues.apache.org/jira/browse/SHINDIG-194

(for-humans -> won't apply to svn, but are smaller and easier to read
due to move/copy detection; for-robots -> aimed to svn; squashed means
all commits in one patch)

I guess that, it the case arrives that both mentor and student are
proficient in dSCM tools, being able to bring back to the project a set
of readable commits instead of a big patch could easily improve the
results, but also the possibility of reusing parts of the contribution
(bug fixes or small commits that can be cherry-picked, etc.)


> environment on which they work is an important factor to consider.  It
> doesn't matter if the conduit for these things making it back into the
> project are patches attached to jiras or distributed scm's the onus is on
> whoever is reviewing them to do the right thing.  People can be careless
> with either system.
> 
> If apache is going to go through the process of setting up an infrastructure
> to promote non-merit based scm backed contribution then I think it makes
> sense to
> 
> a) sandbox that contribution
> b) make review of contributions as simple and as safe as possible
> 

I think that keeping the contribution as sets of patches allows easier
review. But, again, this assumes a certain level of knowledge about the
tool on student and mentor.

> As for killer use cases, I think it has been this list that has had a number
> of mails back and forth talking about broader use of different types of
> scm's and how that would work at apache.  I was just saying that I don't see
> this as the 'everyone should do it this way' place to use distributed scms
> which is what the a thru d of this mail was discussing...
> 

+1

> I have nothing against distributed scm, they are awesome, I am just saying
> that that being the way all gsoc contributions should be processed seems
> dangerous to me which was the purpose of this thread (at least I thought so)
> 

+1 (I actually read your email a criticism, I notice now that you meant
*non mandatory* and I fully agree)

> cheers!
> jesse
> 

Regards
Santiago

> On Wed, Apr 23, 2008 at 2:27 PM, Santiago Gala <sgala@apache.org> wrote:
> 
> > El mar, 22-04-2008 a las 15:36 -0500, Jesse McConnell escribió:
> > (...)
> > > > d) Distributed SCM. Contributors could use tools like git-svn (or even
> > > > svn vendor branches with some manual overhead) to manage their own
> > > > source repositories where they could manage their work and push things
> > > > back to the Apache projects in more meaningful chunks.
> > > >
> > >
> > > problem I see here is in consuming the results of the GSoC work into the
> > > project.  This would almost encourage the short term developer to tweak
> >
> > I don't understand what do you mean. I have been using git-svn for a
> > couple of projects (basically the global apache site and shindig) and it
> > is trivial to produce and consume
> >
> > > api's or code that maybe they shouldn't really be touching (if I just
> > tweak
> > > this one thing it makes life so much easier) and increases the potential
> > for
> >
> > huh? Why is a tool encouraging "tweaking api's (sic) or code"? Why
> > wouldn't they "tweak apis or code" if they use emacs, for instance? I
> > junt don't follow.
> >
> > > potentially dangerous changes to slip in via a careless review.  Sure
> > that
> >
> > careless review? Who is doing the careless review? Once a git
> > repository, that has the (updated) svn trunk + the coder branches out of
> > svn is judged ready, the work can be either committed as a whole chunk
> > or in a set of revisions. git offers excellent support for inspecting
> > differences, can merge very well and has the ability to redo the history
> > of commits until they can be committed to the "master" subversion
> > repository.
> >
> > > should be caught by whatever kind of mentor they have, but I wonder if
> > this
> > > is the 'killer use case' that people are looking for to get distributed
> > > scm's into broader use at apache.
> > >
> >
> > Nobody that I know is looking for a "killer use case". As far as I can
> > tell we are trying to use tools (traditional and new tools) in useful
> > ways, and get more/better work done, with whatever tools. Obviously I
> > would not recommend to use git-svn/git for a GSoC project unless both
> > the mentor and the student have some experience, I would use something
> > simpler like mercurial or even bazaar if they have experience in those,
> > etc.
> >
> > Regards
> > Santiago
> >
> > > cheers,
> > >
> > > jesse
> >
> > --
> > Santiago Gala
> > http://memojo.com/~sgala/blog/ <http://memojo.com/%7Esgala/blog/>
> >
> >
> 
> 
> -- 
> jesse mcconnell
> jesse.mcconnell@gmail.com
-- 
Santiago Gala
http://memojo.com/~sgala/blog/


Mime
View raw message