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
