Re: [REQUEST] Public temporary & rewindable branches for GSoC features

[Stefano Lattarini]

On Tuesday 14 June 2011, Ralf Wildenhues wrote:
> Hi Stefano,
> 
> * Stefano Lattarini wrote on Tue, Jun 14, 2011 at 05:55:02PM CEST:
> > Would be ok with you if in the future I create some temporary branches
> > *in the automake official repository* that I can rebase, edit, and delete
> > at will?
> 
> I don't mind, as long as they are marked/documented as such (and your
> naming strategy would seem to indicate that clearly enough), but I have
> a couple of (non rhetorical) questions:
> 
> > I think that keeping future unfinished or experimental work open and public
> > could help speeding up the project advancement,
> 
> Why do you think this would be the case?
>
Well, I can say that having a branch published is a good incentive to
keep it active and keep thinking about it, also (or even especially!)
if it has no clear direction or definite purpose yet.  At least, this
is true *for what concerns me*, and is quite well confirmed by my past
experiences with, e.g., the yacc-work and java-work branches.  I'm
well ready to concede that this might not hold for other people, but
I'm pretty confident it holds for me (which is what we're concerned
about ATM).

> > and IMHO it would be more
> > expedient than having to keep track of 3 o 4 versions of the same patch
> > series only through the mailing list archives.
> 
> Why does work for *you* get less when you publish branches (as opposed
> to not)?
>
The work for me is more or less unchanged (but I have the "motivational"
advantages I've spoken of above).  However, you then ask ...

> Is this aimed to increase visibility of your changes?  Or help the reviewer?
> 
Both these reasons.  One of the main points of having public experimental
branches is to attract more criticism and comments early, without burdening
a "casual" reaviwer with more work (cloning a remote branch is surely faster
and easier that having to apply a series of, say, four patches -- not very
much, but enough).

> As reviewer I'm usually more concerned with why something was done, and
> maybe how the patch evolved.
>
Absolutely, I'm by no means proposing of doing without the by-email patch
posting and reviews; that would be absurd.  But the experimental branches
can be a useful addition/complement to this IMHO.  And before an
experimental branch is promoted to stable, it should again go through
the usual "patch series thread -> review -> amend -> push" process.

> But things like rationale can typically only be found in the mails
> describing a change, rather than the change itself.
>
IMHO these things should go also into the ChangeLog and git commit
message; i.e., if a rationale for a change isn't either obvious or
explained in the ChangeLog, then there's a serious problem.

Hope that clarifies your doubts.

Thanks,
  Stefano