Re: Unreleased fixes in master

[sfeam <me...@uw...>]

On Thursday, 21 February 2019 23:48:53 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > That's not the development model we have been using.
> >
> > Trivial bug-fixes are applied for both the stable and development branches
> > immediately as they are found.
> >
> > Non-trivial changes, even bug fixes, are applied only to the
> > development branch. Often people using the development branch then
> > report related issues that require additional fixes or re-thinking of
> > the original fix. After sufficient testing in the development version
> > the original fix and any follow-ups developed during testing may or
> > may not be back-ported to the stable branch. This particular change
> > was non-trivial to begin with and engendered many follow-up fixes.
> 
> OK. Is your thinking to include this in a 5.4 release at some point in
> the future?

Sure.  
The development model is that at some point a branch-5-4-stable
is created from the development branch (_not_ from branch-5-2-stable).
It will obviously contain everything that has gone into the development
branch prior to that point.
- The old stable branch becomes a dead end.
- The new stable branch is used to prepare release packages.
- Development continues in the main branch.


[snip]
> i.e. there were 224 commits that appear in both master..5.2.6 AND in
> 5.2.6..master. Taking a random one. Look at this:
> 
>   gitk 1f7160945 fb107d74e
> 
> These are clearly the same commit, so ideally it should appear on
> neither "git log master..5.2.6" nor "git log 5.2.6..master", but it
> appears on both. Those commits aren't in a merge, and their immediate
> parents aren't the same. How did we get here? Did we cherry-pick it?

Yes.  Patch applied and tested in the development branch, later cherry-picked
for the stable branch.

> > The thing is, you can't go back to edit old commit messages like you
> > can edit a ChangeLog. That means you cannot fix typos, cannot clarify
> > or expand bad descriptions, cannot update or redact Email addresses,
> > cannot forward-link to eventual reversion or to subsequent related
> > patches etc.
> >
> > My #1 suggestion for improving git would be to move all the commit
> > messages to a parallel data structure so that they can be edited
> > without invalidating the orginal commit hash.
> 
> Are you really proposing to have a hand-curated NEWS file AND a
> hand-curated ChangeLog AND version control?

I would much rather that git maintained the ChangeLog automatically,
but so far as I have been able to learn it cannot be persuaded to do that.
The NEWS file is a bullet-point summary where each bullet point may
summarize many commits.  How would you get that other than manual
curation?  It might be more conventional to call it ReleaseNotes rather than NEWS.

	still willing to learn

		Ethan