[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [REQUEST] Public temporary & rewindable branches for GSoC features
From: |
Stefano Lattarini |
Subject: |
Re: [REQUEST] Public temporary & rewindable branches for GSoC features |
Date: |
Wed, 15 Jun 2011 09:35:09 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; ) |
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