Merge early is pretty much my default position ... and that applies to this
context in my view.
On Sat, 28 Sep. 2019, 7:44 am Dr. Matthias St. Pierre, <
> 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?
>  https://github.com/openssl/openssl/pull/9333
>  https://github.com/openssl/openssl/pull/9333#issuecomment-536105158