Re: automake branch management

[Ralf Wildenhues]

Hello Jan, all,

[ This discussion started off-list (see below for discussion of that
  topic, too  ;-).  I'm quoting generously so that all context should
  be available ]

* Jan Engelhardt wrote on Fri, Nov 28, 2008 at 12:19:45PM CET:
> On Friday 2008-11-28 06:28, Ralf Wildenhues wrote:
> >
> >First off, why not discuss this on address@hidden
> 
> Well seems to me more like a personal development idiom.

Well, that may be, but even so, it generally really helps to keep _all_
discussion related to package development on-list (unless of course
there is a reason for privacy), for several reasons:

- one can search for it later and hope to actually find it.  I've had
  this problem myself several times, after deleting off-list discussion
  that, at the time, looked like a finished topic to me.
- it improves transparency of the project; lack of transparency may
  deter potential contributors, and makes it harder for future
  maintainers to learn about the motives behind some non-obvious
  decisions made earlier.  I have been thankful for Automake mailing
  list archives from 2001 before, and have more than once wished I had
  archives from discussions in the 90s.
- other list participants may have good ideas that one doesn't know
  about, doesn't have, and won't ever learn in an off-list discussion.
- last but not least, curious developers may find the answer to
  questions such as yours in the archives, and won't have to ask me
  personally, should they have that same question.  ;-)

Now to the meat:

> >* Jan Engelhardt wrote on Thu, Nov 27, 2008 at 11:32:50PM CET:
> >> 
> >> I see that cherry-picking is used rather excessively in the automake git 
> >> repository. Is there anything that speaks against just merging "stable" 
> >> (whatever currently runs, atm this is origin/branch-1-10) regularly into 
> >> "master"?
> >
> >Well, when I started it, it seemed to me the easier way.  Merging is
> >problematic because not all changes from branch-1-10 belong in master.
> >For example the release changes.  I don't see how to avoid that.
> 
> I usually do the release changes (version bump) when it is about
> to be released.
> 
> When you graph git://dev.medozas.de/pam_mount with `gitk --all` for example,
> you may find that practice between 0.40--0.43 or 0.45--0.47.

Yes, I see that.  Maybe it is useful to try out such a changed setup
when starting branch-1-11.  Right now it seems problematic because
master and branch-1-10 have quite a few independent (and mostly
mechanical) changes which will cause merge conflicts, and I'm not really
motivated to fix them.

Hmm, trying out a 'git merge -s ours branch-1-10' mostly does the right
thing: namely a zero content change, which causes any further merges to
only consider newer history on the branch.  Still, doing that makes
history claim to have another 140some changes incorporated which aren't
in fact there.

Another thing that bothers me when merging from stable to master is that
I'm not used to developing fixes on the stable branch.

But given the chance for corruption with cherry-pick which I experienced
in practice with 1.10.2, I'm willing to try out and change the strategy,
but probably not before 1.11.  So I think I will continue branch-1-10 as
done now, and try to switch one branch-1-11 branches.

Cheers, and thanks for the suggestion,
Ralf