CHANGELOG: unintended consequences

[Siirola, John D]

All,

 

We have hit an unintended consequence with our new policy of updating the CHANGELOG.txt with each PR.  As expected, that has led to merge conflicts.  What was not expected is that that causes PR tests (notably AppVeyor) to fail.  This makes processing PRs harder as many indicate “red x’s” that are completely bogus.  It also suppresses things like coverage reporting.  This is especially troublesome, as Appveyor tends to lag hours behind the PR, giving ample opportunity for merge conflicts to crop up.

 

I would like to solicit opinions on an alternative approach:

 

We still request changelog input as part of the PR.  Instead of directly editing the CHANGELOG.txt file, we create a development_changelog directory where each PR can create its own file (nominally the PR or issue number “.txt”).  As each PR touches its own file, there will not be any merge conflicts.  When we release, tabulating the changelog is a simple matter of `cat development_changelog/* >> new_changelog.txt; git rm development_changelog/*` and then pasting that file at the top of the CHANGELOG.txt.

 

Thoughts?

 

john

[Qi Chen]

That seems like a reasonable workaround to me. I did notice the merge conflicts cropping up.

--
You received this message because you are subscribed to the Google Groups "Pyomo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-develope...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Laird, Carl Damon]

John, I think what you propose could work fine.

 

I wonder if we could use something like this: https://github.com/cfpb/github-changelog

(I don’t think we should use titles, but we could have a section in the PR that we parse out. Maybe “changelog=’asdfasdf’”?)

--

[Laird, Carl Damon]

This seems to have more moving parts than I thought. I think John’s solution is easier.

[William Hart]

I agree that there isn't a simple solution for these conflicts.  What about recording the PRs on the github website?

--

[Laird, Carl Damon]

Can you expand on what you mean?

 

From: <pyomo-de...@googlegroups.com> on behalf of William Hart <whar...@gmail.com>

Reply-To: "pyomo-de...@googlegroups.com" <pyomo-de...@googlegroups.com>
Date: Saturday, May 19, 2018 at 12:36 AM
To: "pyomo-de...@googlegroups.com" <pyomo-de...@googlegroups.com>

[William Hart]

I just meant that committing to the CHANGELOG is a convenience.  We could just as easily recored approved PRs on a wikipage or within a github issue associated with the "next" release.

[Siirola, John D]

Actually, that’s an even better idea.  It also helps with the chicken-and-egg issue of not knowing the PR # until after you create it.  There would be an administrative question of who updates the wiki (the proposer, or person that merges the PR).

 

john

[Gabe Hackebeil]

Without completely understanding the AppVeyor issue, can I just suggest that when creating a PR we just delay modifying the changelog until after final approval. Then do a quick commit and merge without waiting on tests to run again. Wouldn’t that prevent any kind of merge conflicts on other branches?

Gabe

[William Hart]

Yes, that would.  But then our PR history wouldn't archive the final test results.

[Gabriel Hackebeil]

Wouldn’t the merge commit that subsequently triggers tests on master be the archive?

Gabe

[William Hart]

But it's not associates with the PR itself.