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 [1]),
> 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 [2].
>
> 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
>
>
> [1] https://github.com/openssl/openssl/pull/9333
> [2] https://github.com/openssl/openssl/pull/9333#issuecomment-536105158
>

Reply via email to