Re: [PATCHES] Two small improvements to HACKING

[Stefano Lattarini]

On Thursday 19 August 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Thu, Aug 19, 2010 at 12:09:15AM CEST:
> >   HACKING: improve description of git "bugfix branches".
> >   HACKING: acknowledge Perl 4 as utterly obsolete.
> 
> Nits below.
> 
> > Subject: [PATCH 1/2] HACKING: improve description of git "bugfix
> > branches".
> > 
> > * HACKING (Working with git): Extend and make less terse the
> > description of git "bugfix branches".
> 
> grammar: ... and make the description of ... less terse.
*blush*
> or just: Extend.
Yes, better.
 
> > --- a/HACKING
> > +++ b/HACKING
> > @@ -139,9 +139,11 @@
> > 
> >    # if all seems ok, then actually push:
> >    git push origin maint branch-1.11 master
> > 
> > -* For bug fixes of long-standing bugs, it may be useful to commit them to
> > -  a new branch based off of the commit that introduced the bug, and merge
> > -  this bugfix branch into active branches that descend from the buggy 
> > commit.
> > +* When fixing a bug (especially a long-standing one), it may be useful
> > +  to commit the fix to a new temporary branch based off the commit that
> > +  introduced the bug.  Then this "bugfix branch" can be merged into all
> > +  the active branches descending from the buggy commit.  This offers a
> > +  simple way to fix the bug consistently and effectively.
> 
> Are you aware that merging fix-foo in maint, branch-1.11, and
> master is equivalent to merging fix-foo in maint, then merging
> maint in branch-1.11 and master (under the assumption that prior
> to the fix, maint was an ancestor of branch-1.11 and master)?
Yes.
> If no, this paragraph should be rewritten, if yes, then how come you
> didn't just merge maint into branch-1.11 and master?  ;-)
I was just describing the most genral scenario, that should work also
in more unusual branching situations.  Also, I said....
 > This offers a simple way to fix the bug consistently and effectively.
... which doesn't mean it's the only way ;-)
Moreover, an avarage git user with pushing right should know what you
explained above, i.e. that...
  > merging fix-foo in maint, branch-1.11, and
  > master is equivalent to merging fix-foo in maint, then merging
  > maint in branch-1.11 and master (under the assumption that prior
  > to the fix, maint was an ancestor of branch-1.11 and master)?
... while the usefulness of the bug-fixing-through-branching policy you
are using for automake might not be obvious (it wasn't for me until your
explanation in a previous mail).

In light of these considerations, is my wording acceptable?

> > Subject: [PATCH 2/2] HACKING: acknowledge Perl 4 as utterly
> > obsolete.
> > 
> > * HACKING (Editing automake.in and aclocal.in): Don't tell that
> > Perl 5 is OK now: that's obvious!   In fact, I'd be surprised to
> > see anyone still using Perl 4...
> 
> Let's keep our log entries concise, and no need to get excited in
> them. configure already requires 5.6, so this would have been
> sufficient, no?
> 
> HACKING: Perl 4 is obsolete.
> * HACKING (Editing automake.in and aclocal.in): Remove note about
> Perl 5.
OK, done.

Regards,
  Stefano

P.S. When you said ...
> If no, this paragraph should be rewritten, if yes, then how come you
> didn't just merge maint into branch-1.11 and master?  ;-)
... were you asking why I didn't do that in my last push?  Well,
because I find an explicit merge of the bug-fixing branch in all the
affected branches clearer: it's like saying "Hey, I'm doing this
merge to fix a bug!", while this is unclear in a merge of e.g. maint.