> From: Bill Blough <de...@blough.us> > On Wed, Jun 22, 2022 at 11:21:11PM +0100, rle...@codelibre.net wrote: > > > > I don't personally think there is sufficient community involvement or > > developer involvement to realistically support Xalan-C as an active > > project in any sense. There is no one working on it. And while I'm > > sure there are some users, there's next to no active engagement of users as > > a community.
> However, there are still users, and sometimes things break as systems get > upgraded. So I guess a question is, do we feel it's worth it to support these > users by way of small maintenance efforts on an as-needed basis, even > though we know that usage is trending down over time, and that there will > never be another major release? > > Or, perhaps a bigger question is, will there be enough devs to continue the > project, even for just the small maintenance efforts? This is certainly the kind of question I'd like us to consider. One part of that is determining the ongoing maintenance efforts required to make a point release for any bugfixes, and/or for reviewing and merging any provided changes. If you go to https://github.com/apache/xalan-c and look at the CI status for the latest merged change, you'll see it's got a red "X" next to it. If you look at that in more detail, you'll see that both the Travis builds and the AppVeyor builds are both failing. Travis: https://github.com/apache/xalan-c/runs/4304118187, looks like two failing MacOS X builds. Likely issues on the Travis side rather than on our part AppVeyor: https://ci.appveyor.com/project/ApacheSoftwareFoundation/xalan-c/builds/4164 2715, some odd link error If we're going to be making any further changes, even just merging pull requests, we need a working CI setup. Unfortunately, maintaining such a setup is a significant commitment. The Travis (Linux, MacOS X) setup needs migrating over to use GitHub actions after the Travis company went off the rails; not sure what the Apache project arrangements are for doing that. The AppVeyor setup needs updating to use a more recent base image with up-to-date dependencies provisioned with vcpkg. And once working, they both need ongoing maintenance effort to keep them current and working. None of this is especially difficult. But it is very time-consuming. If you look at the setup for Xerces-C++, you'll see a working and more comprehensive Travis setup (https://github.com/apache/xerces-c/runs/5526468479) and a mostly working AppVeyor setup (https://ci.appveyor.com/project/ApacheSoftwareFoundation/xerces-c-gfvct/bui lds/42880201)--two failing Cygwin variants (I think the image needs updating). Ours is only testing one Windows variant, and doesn't even attempt MinGW or Cygwin. We could just remove all CI testing and merge changes as-is. However, I wouldn't be too happy in removing that quality bar, I do feel it's a bare minimum for guaranteeing that the code quality and portability are acceptable. The other side of things is determining if we have the necessary expertise to review patches. https://github.com/apache/xalan-c/pull/39 needs review, and it looks simple, but I don't have the existing expertise (or the time to dig into it in detail to get that expertise) to properly review and test this change. This change has been open for seven months. > Forgive me if I'm reading too much into your message, but I'm wondering if > you bringing this up is due to wanting to step away from the project? > If that's the case, then ultimately we need to determine if there will continue > to be enough people to conduct votes. If not, then there will be little choice > in the matter. I haven't actually used Xerces-C++ since making the 1.12 release, so my current involvement and expected future involvement are currently zero, I'm sorry to say.. While I would certainly like to be able to offer my time, unfortunately I haven't had enough of it for some time now, and I don't expect that to change. I would like to step away, and this is certainly part of the reason for bringing this up: I wouldn't want to leave the project leaving things hanging and its status uncertain. > Personally, I'd like to see Xalan stay around, if for no other reason than to > continue support for those existing legacy users. Though I realize that's an > easy thing for me to say, as I haven't been very active in the past couple of > years (in any of the FLOSS projects I'm involved with, not just Xalan > specifically). If we do have it moved to the Attic, it could be reactivated again in the future if some future developers wish to resurrect it. If there are remaining legacy users, it would be useful to hear from them. At some level, if those remaining users need support, then I think they would need to commit to supporting the project more directly themselves, and picking up some of the maintenance and support burden. At least from the open source side of things, I haven't seen any evidence of any users these last few years. When I got it fixed up and working in Debian, FreeBSD, homebrew and vcpkg, there were no reverse dependencies upon Xalan-C++. Most of these systems either had dropped Xalan-C++ packaging due to it being broken for years, or it never having been added in the first place. Now, this is limited to packaged open-source software provided through distribution package managers. But it's indicative of the overall usage being close to zero, I'm afraid to say. Kind regards, Roger --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
