> > We change the GitHub setup such that pull requests to stable > > branches need to be based onto the new-style branches, but keep the > > old-style stable branches in sync with the new-style branches for a > > little while. > > Er... how do you change that Github setup? I thought it simply > showed a list of all available branches regardless. So if we got a > duplicate set, it's going to show both, isn't it? Considering that > the github repo is a --mirror of the git.openssl.org repo, I'm not > sure how the old branch refs would be filtered out...
You are right, I thought it was possible using protected branches, but that doesn't seem to be the case. > > It seems to me like this discussion is splitting into two: > > 1) Start with new names for 3.0 and on (I can only see positive > responses so far, even with Matt's hesitance) > 2) Rename of the old names. > > As far as I can see, those two don't have to be in absolute sync, even > though that would be desirable. In other words, we can figure out the > details of 2 even after we've started 1. Agreed. The best thing would be to publicly announce the branch renaming in a blog post with a sufficient notice time (3-6 months) and with detailed instructions how to rename the local branches and how to reset the upstream branches (using `git branch --set-upstream-to=...`). Just as we did for the grand code reformatting. We might even provide a smart helper script for users to do the local conversion. Matthias