Hey Scott,
I think personally that we retire the code base and you fork it for your own
use. Unless others want to step in and assist I think it’s clear it’s not
getting much attention other than from you - and there are extra overheads on
you if you have to do a level of management of the code within the ASF.
I’ve clearly not had time to do anything at all for ages :(.
So as the only person maintaining - I’d say go the path that is easiest for
you.
My 2c
Cheers,
Berin
> On 21 Feb 2024, at 02:35, Cantor, Scott <[email protected]> wrote:
>
> 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
>
>
