process - release patches about triplea HOT 4 CLOSED

#41 is an interesting example:

• #41 was created some time ago
• recently for a release that commit was added to the release branch (but under a different SHA).

Now with the release branch merged in, we have this PR still open.

We now have a big problem, the PR for #41 is still open, and nothing tells the submitter that it is stale, nor reviewers. This can result in a needless review, is an extra PR that is open, and adds yet more overhead for the contributor w.r.t to branch maintenance.

from triplea.

Two things:
About the release process:
Assuming that we want the bug fix or whatever to go into the release branch (we normally do not), then I prefer option 2 (submit a single PR to the release branch) when the release does not include anything that makes it different from the master branch. If the release branch does have some special commit or something, which the master branch does not have and does not want, then I think I probably prefer option 1.

Secondly, at my work place, we use Gerrit for code reviews. When we commit a branch, and that branch becomes out of date, gerrit holds up a big sign that says this branch is now out of date, and you must rebase the branch before you can merge it. I like this a lot and am very surprised that github doesn't do this.
Can we get anything like this in place for github PR's / code review's?

from triplea.

Even if the commit, the change into both branches is the same, you could have a merge conflict opportunity since master may have diverged.

If you are pushing stuff to a release, I would suggest chances are good the release branch is not a good release. Maybe one small fix, but more than that, and the release IMO should just be scrapped. For example, in the last 8 commits to master, half of them are release branch merge commits. Merge commits are a bit scary since anything can change in them, yet it is assumed that usually nothing has changed. In this release, since the release branch and master kept pace, if we just recut the release branch, we would have saved a half dozen needless release branch merge commits.

So part of this branch model which may not be understood, is that when you start finding problems in a release, you tend to be quick to throw away that release, and then focus on getting the tip of master to be stable and test that so you can cut a new release branch right away.

It's also better if we can tag a location on master and then cut a release branch, rather than tagging a location on a branch. If we tag locations on branches, our tags could maybe get kinda weird.

w.r.t out of data branches. Git does tell you when a branch needs to be updated and when it cannot be merged automatically. In the case I pointed out, the out of date PR had a different SHA from anything on master, so GIT could not know this was out of data until after the merge.

So let me summarize, part of the idea is that every time you get a pull request into a release branch,we collectively think really hard each time about aborting that release branch and focusing on stabilizing the head of master. For example, today, we actually worked pretty hard to get release and master to be current - we could have done so just as easily by deleting the current release branch and recreating it. Plus then our tag would be on the correct branch too.

Okay, so some discussion has been had. But it still remains that we've some problems with a merge workflow, and I think the double commit work flow is more robust, but there is not agreement yet. I think one thing not quite clearly communicated is that the extra overhead of a double commit is intended to be a red flag. If any significant amount of that overhead is incurred, generally we should try to not struggle through it but instead consider re-cutting the release.

from triplea.

Closing, unresolved.

At question is whether release fixes are to be fixed in just a release branch and also master, or just release branch and the release branches are then merged back into master.

from triplea.