I didn't get any feedback on this amongst the PMC, but after discussing things with my project team, I'm going to float what is essentially my proposal for the future of the Santuario C++ branch.
As the sole maintainer left, you can think of this as an ultimatum I guess, but it's not really meant that way, it's simply where I'm at with this. Bottom line, I can't maintain the code any longer in its current form, because I can't devote time to issues that don't affect my project. Xerces is in a similar state right now, but I'm parking that for the time being, it's not relevant to this. I don't think it's responsible for us to be hosting this code in the current form when I simply can't support it, so I'm left with 2 choices, with a third being "somebody else offers to own it", so I'm putting that aside. Option 1: We retire this codebase. If that's the decision, I will fork it for use in Shibboleth, and likely will engage in a heavy round of code deletion, getting rid of a number of the features and parts of the code I can't maintain and don't use. Because it seems to me bad optics to claim I can't work on the code and then turn around and do all that work, I'm offering: Option 2: I do the excising work I would do personally but here at Apache and we continue to host the code. The new version would be labeled 3.0.0 and would lack a number of current features: - no XKMS code - no Windows or NSS crypto provide support (the interface would remain, just the implementations would be removed) - no XPath/XSLT support and the option to build with Xalan would be removed - the code would default to disallowing various remote lookup scenarios (e.g., the RetrievalMethod issue), and I would make some adjustments to make it easier to override some of that behavior, as a courtesy That's not exhaustive, I may find some other bits to chop out, but suffice to say, it would be unsuitable for generic use any more, as that's not my use case and I can't support that any longer. There is no option 3 where this continues to be a general-purpose library maintained by me. Somebody else would have to step up, and I would continue to assist if that happens, for now at least. I have no particular preference here. I'm willing to do the work here if that's what people want, but I'm also happy to simply park this code and fork it, I just don't want the blowback of doing that without a public discussion and the PMC deciding to take that step. I am not in a big rush to do any work, but I think it's best if we move expediently on the decision at least so people know what's happening. Thanks, -- Scott
