On 23/04/2017 18:26, Cantor, Scott wrote:
On 4/22/17, 2:59 PM, "Roger Leigh" <rle...@codelibre.net> wrote:

There are two choices for merging it:
- to the 3.1 branch
- to the trunk, for releasing as 3.2

Or a third branch, but I think you already did that via git anyway and that's 
simpler in practice so we can dismiss that one.

I can certainly rebase the cmake-3.1 branch onto trunk if that would make sense. However, looking at the differences between the 3.1 branch and the trunk, it looks like the trunk might need a fair amount of 3.1 work applying. Is it a bit out of date?

I'm getting a few conflicts in EXTRA_DIST in a few Makefile.ams. Nothing major, but it's highlighting that there's stuff missing on the trunk.

Since the proposed changes don't touch any of the existing build
systems, merging onto the 3.1 branch would be safe, but since it's a
fairly large change it would be understandable to leave this for a new
minor release.  Is there any particular preference?

I think there's a relevant parallel discussion about the project's next step. 
Right now there are some apparent regressions on the branch I introduced trying 
to fix security issues in code I didn't understand. And there are some 
outstanding security issues on both branches because of that DOMHelper code 
that's making in-memory object layout assumptions with improper casts. That has 
got to be fixed.

Meanwhile, Red Hat has refused to ship existing security fixes in their copy of 
3.1, which is leaving my customers screwed, and that's becoming intolerable.

My only practical solution to fix that is to get my software rebased onto a new 
version, 3.2, which I can ship in a non-conflicting package. So I'm inclined to 
do the very ugly work of figuring out what's missing from the trunk and 
reviewing all the additional work there that was done before the project went 
into moribundity, and try and get a 3.2 out the door this summer.

So given that, I suspect the thing to do is to put it on trunk, but I'd like a 
bit of time to review current trunk before we do that merge so I'm not dealing 
with both at once if that's ok.

OK.  If there's anything I can do to help out here, I can certainly try.


To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Reply via email to