Merge early is pretty much my default position ... and that applies to this context in my view.
Tim. On Sat, 28 Sep. 2019, 7:44 am Dr. Matthias St. Pierre, < matthias.st.pie...@ncp-e.com> wrote: > Hi, > > some of you might have loosely followed pull request #9333 (see ), > where I am reorganizing the header files in a more consistent manner. > > Since I intend to do the reorganization both to master and the 1.1.1 > stable branch (in order to facilitate conflict-free cherry-picking to > the 1.1.1 LTS branch), I decided to automate the changes. This decision > turned out to be very convenient, because the heavy rearchitecturing on > master frequently conflicted with my changes. Instead of resolving > conflicts, I could just rerun the script after rebasing. > > When this pull request finally gets merged, it might happen that you > in turn encounter more merge conflicts as usual, in particular if you > are one of the 'replumbers' involved in the FIPS rearchitecturing. > It might also happen if you are working on some long running pull > request like the CMP integration. > > To check the impact of my changes on your work, I did some rebasing > experiments, and as a result I wrote down some guidance about possible > rebasing strategies in . > > The reason I write this mail is because I'd like to hear your opinion > about how to proceed with this pull request. There are two possibilities: > > Variant I): > Merge early in to get the reorganization integrated as soon > as possible and not wait until shortly before the next release. > > Variant II): > Wait a little bit more until the heavy rearchitecturing > has settled down a little bit. > > What is your opinion? What are your preferences? > > > Regards, > > Matthias > > >  https://github.com/openssl/openssl/pull/9333 >  https://github.com/openssl/openssl/pull/9333#issuecomment-536105158 >