Re: native-git-svn: A Summer of Code 2010 proposal

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 21, 2010, 11:47 UTC
Message-ID: <alpine.DEB.1.00.1003211236050.7596@pacific.mpi-cbg.de>
In-Reply-To: <20100321110807.GA24016@progeny.tock>

Hi,

On Sun, 21 Mar 2010, Jonathan Nieder wrote:

Show 20 quoted lines

> Johannes Schindelin wrote:
> > On Sat, 20 Mar 2010, Jonathan Nieder wrote:
> >> Ramkumar Ramachandra wrote:
> 
> >>> == Timeline ==
> >>
> >> The one thing I worry about is that you are proposing to wait a while 
> >> before submitting your changes upstream.  I would suggest pushing 
> >> whatever pieces work to contrib/ early on to get more feedback from 
> >> reviewers and testers.  (I am saying this selfishly, as a potential 
> >> tester.)
> >
> > I would rather have frequent updates about the progress on the mailing 
> > list, and a long-running branch in which the code is developed, only 
> > rebasing to Junio's next/pu when absolutely necessary.
> 
> You are usually right about this kind of thing, so I will not disagree
> too strongly.
> 
> But I will say: I think this was a mistake in the git sequencer project.

The mistakes in the sequencer project were more than this. Not only was the development of the branch almost invisible, when it was done, it was basically with a comment "here it is, take it or leave it", and good suggestions as to improve the code went unheeded.

That's why I suggested frequent progress reports on the mailing list. Of course, these reports should only be commented upon by people who are fully informed about the project, they should not be invitations to everybody and her dog to distract the student by putting in unreasonable or uninformed wishes.

> Now it is hard enough to merge current master into the sequencer 
> branch...

The problem is not the merging. The problem is that the code is not in a form I (or certain others) want to see in git.git.

Show 5 quoted lines

> > After all, it would be additional work to put it first into contrib/ 
> > and then to integrate it fully into git.git.
> 
> I am not sure I understand this point.  Are you saying the change in 
> filenames would be problematic?

I say that distracting the student from the real task is problematic. The real task does not involve putting the code into contrib/ first, and then move it into the final location.

Personally, I would have little problems just adding the remote and checking out the branch, just to test the thing after I got a promising progress report. And I think those who are truly interested in git-remote-svn will have little problems, either. The important part would be the visible progress (i.e. mails by the student to this list).

Ciao, Dscho