Re: Unreleased fixes in master

[Ethan A M. <sf...@us...>]

On Thursday, February 21, 2019 9:52:17 AM PST Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > That's a tough call.  I see somewhere on the order of 20-30 commits over
> > a period of 8 months that are related to that change, touching core files
> > as well as individual terminal drivers.  That is far more extensive than
> > I ever used to consider for back-porting from the development version to
> > the stable source.
> 
> Hmmm. I guess this was done long-enough ago that I assumed the latest
> release would include it, especially since it fixes a real problem.

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.


> By the way, how are you keeping track of what's in the release and what isn't? 

Changes to the stable branch are tracked in ChangeLog and in NEWS.
I use the bullet-point summary in NEWS to prepare release notes.

In the development branch, the top section of NEWS is a bullet-point list of
what went into 5.3 but not 5.2.

I haven't been updating ChangeLog for the development branch because
people told me that the "git way" was to use commit messages instead.
I have been doing that, but see below.


> I can ask git about the difference in branches (git log
> 5.2.6..master), but they're very diverged, and that command isn't
> entirely helpful.

Tracking changes via commit messages is one of the things I like least
about git.  I am seriously considering to switch back to a model where
changes are fully described in a separate ChangeLog and all git commits
simply say "see ChangeLog".  That would require some automated way to
insert the appropriate git hash indices into the text of the ChangeLog.
I have tried a couple of git add-ons that looked like they might help, 
but so far with no success.

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. 

	Ethan