This is a common refrain in the FOSS world: People get used to free software,
free maintenance, don't get involved, and complain when things change.
This sounds to me like a call of action for you to survey the other free
software you use and get involved; that or buy software ;-)
Gary
On 2022/10/19 07:13:24 Scott Furry wrote:
> I'm only an occasional user of Xerces-C/Xalan-C libraries but retirement
> seems wrong to me. Understandable. Lamentable. Still wrong.
>
> Reading the suggestion of placing Xalan-C into 'the attic', I dove
> online to plan a migration strategy should it become necessary. I was
> not pleased with what I found:
> - Saxon has a `community edition` but is only interested in selling
> licenses.
> - Folks over at libxml2/libxslt go to great lengths to stipulate that
> Gnome is not required - but library has its 'C' quirks. C++ wrappers of
> various type and quality abound.
>
> The previous move by Oracle to 'abandoned' the Netbeans IDE to the
> Apache Foundation was not pleasant for me. After seven release
> iterations the IDE still doesn't have a decent C/C++ setup comparable to
> the Netbeans 8.2 plugin. Everyone in the Apache Netbeans project seems
> focused on Java. I have an overall negative impression of Apache
> projects as a result.
>
> I can appreciate that few have the time and resources to commit to
> maintain code. We've gone from "The Cathedral and The Bazaar" to silos
> ("Big Box Stores") of companies - Ubuntu, Gnome, Red Hat, et al. The
> notion of the dedicated developer toiling away doing incredible work in
> obscurity is becoming quaint. XKCD pretty much nailed it with the
> 'Dependency' comic (https://xkcd.com/2347/).
>
> Given the long history of the Xerces-C/Xalan-C, as well as few decent
> compatible replacements, I would hope the code could be maintained in
> the future.
>
> /rant
> Scott
>
>
> On 2022-10-17 11:43, Roger Leigh wrote:
> >
> > Hi Gary,
> >
> > Thanks to you and everyone else for responding. It looks like the
> > final tally is 3 (a) and 1 (b). I hope this meets the required quorum.
> >
> > So assuming this is OK with everyone, would it be OK for you as the
> > PMC chairman to handle the moving of the Xalan-C project to the
> > Attic? Would it also be possible to remove me from the PMC (or does
> > the PMC get dissolved entirely)?
> >
> > Do we want to recommend that organisations such as the various
> > distributors of Xalan-C retire it at this time as well? Or just
> > notify them of the move to the Attic and let them exercise their own
> > judgement on the risks?
> >
> > Kind regards,
> >
> > Roger
> >
> > *From:* Gary Gregory <[email protected]>
> > *Sent:* 15 October 2022 12:42
> > *To:* [email protected]
> > *Cc:* [email protected]
> > *Subject:* Re: [VOTE] Moving Xalan-C to the Attic
> >
> > Retirement of Xalan-C seems ok to me if only due to my lack of
> > involvement with it; I've only helped on the Java side IIRC. So that
> > would be (a) for me.
> >
> > Gary
> >
> > On Fri, Oct 7, 2022, 08:19 Roger Leigh <[email protected]> wrote:
> >
> > Dear all,
> >
> > It’s been over three months since my original email on this
> > subject. There is a related discussion about this on the
> > Xerces-C++ mailing list just now, and it would be useful to reach
> > a conclusion on this for Xalan-C as well.
> >
> > I've updated the git statistics I did earlier in the year, which
> > can be viewed or downloaded here: xerces-xalan-git-monthly.xlsx
> > icon xerces-xalan-git-monthly.xlsx
> >
> > <https://codelibreconsulting.sharepoint.com/:x:/s/Opensourcesoftware/EabAzxgzU3pCjUSKSVvWjZgBlUGZUb91q2PVMkGk1oaIHw?e=MVBvPA>.
> > There are no changes—there has not been a single commit to the
> > source repository since 2021. There has not been any change to the
> > maintenance status of the project since my last email: there are
> > no active maintainers, no one has shown any interest in doing any
> > maintenance, and none of the previous maintainers who are still
> > present actually use Xalan any longer—so there is little prospect
> > of previously active maintainers returning. I myself will be
> > leaving the project once this question is answered irrespective of
> > the outcome—I no longer use Xalan-C, I have no time to commit to
> > it for future work and releases, I just want to see it retired
> > gracefully so that we don’t leave anyone with the mistaken
> > impression that this is a project which is active and well
> > supported when it is most certainly not. This is not a library
> > which new projects should be considering to use.
> >
> > This is the commit history since 01 Oct 2012:
> >
> > $ git shortlog -s --oneline --all --since "01 OCT 2012"
> >
> > 1 Benjamin Beasley
> >
> > 1 Bill Blough
> >
> > 1 Biswapriyo Nath
> >
> > 1 Kvarec Lezki
> >
> > 182 Roger Leigh
> >
> > 29 Steven J. Hathaway
> >
> > I would like for the PMC to vote on the future of the project. Do we
> >
> > 1. Retire the project to the Attic
> > 2. Keep the project going
> >
> > I’m not sure if I’m formally a PMC member or not, but
> > realistically I’m the only one who has done any work on the
> > project for the past 8 years. So if I can vote on this I’ll vote
> > for (a).
> >
> > Kind regards,
> >
> > Roger
> >
> > *From:* [email protected] <[email protected]>
> > *Sent:* 22 June 2022 23:21
> > *To:* [email protected]; [email protected]
> > *Subject:* Future of xalan-c
> >
> > Dear all,
> >
> > I wanted to write this email to sound out where the project is,
> > where it is going, and whether or not it has a future. If it does
> > not have a future, is it time to wrap up the project and move it
> > to the Attic?
> >
> > To start with, a bit of context. This is a summary of the
> > project’s commit activity over the previous 22 years:
> >
> > Back in July 2020, just a little under two years ago, I released
> > Xalan-C 1.12. This was the first release since Xalan-C 1.11 in
> > October 2012, and it incorporated a number of patches which had
> > been accumulated over the course of years by several downstream
> > distributors.
> >
> > https://apache.github.io/xalan-c/releases.html#major-changes shows
> > the major changes in this release. On the above graph, this
> > release is comprised of the commits from 2019 to 2020. I was the
> > /sole/ committer for this release.
> >
> > The previous 1.11 release was made in October 2012 with Steven J.
> > Hathaway being the principal contributor.
> >
> > The previous 1.10 release was made in October 2005 with David N
> > Berton and Dmitry Hayes being the principal contributors.
> >
> > The previous 1.9 release was made in December 2004 with June Ng,
> > Matthew Hoyt, David N Berton and Dmitry Hayes being the principal
> > contributors.
> >
> > The previous 1.8 release was made in April 2004 with Matthew Hoyt,
> > David N Berton and Dmitry Hayes being the principal contributors.
> >
> > The main points I’d like to make here are the following:
> >
> > * Active development of Xalan-C effectively finished with the
> > /1.10/ release in 2005. The vast majority of work since then
> > has been little more than essential bugfixing and portability
> > work to support new platforms and toolchains.
> > * 1.11 was a bugfix release. It was primarily comprised of
> > essential bugfixes, and fixes for building with different
> > toolchains on different platforms and some documentation
> > work. There was one code improvement of note: “Add number and
> > nodeset types as top-level stylesheet parameters”
> > * 1.12 was a bugfix release. It was primarily comprised of
> > essential bugfixes, and fixes for building on different
> > platforms, with the CMake support generalising that to build
> > on current platforms, plus the documentation switch to
> > Markdown. There were zero new features or improvements
> > outside essential bugfixing.
> > * There is essentially ~zero developer mailing list activity
> > * There is essentially ~zero user mailing list activity
> > * Community involvement on GitHub is present but at very low and
> > sporadic levels. We have three PRs from contributors other
> > than myself
> > (https://github.com/apache/xalan-c/pulls?q=is%3Apr+is%3Aclosed).
> > One was a triviality, two were portability fixes just altering
> > platform-specific ifdefs. There is one open PR
> > (https://github.com/apache/xalan-c/pulls?q=is%3Aopen+is%3Apr).
> > This looks simple but I’m not sure of the impact in case of
> > unexpected subtleties.
> >
> > I became involved in the project for pragmatic reasons—I worked on
> > a project using XSLT and picked up Xalan-C as a dependency. I
> > wrote and contributed the CMake support and worked on the 1.12
> > release for that reason. But I don’t know the underlying
> > codebase, and I can’t do any real feature development or deep
> > bugfixing. I don’t have the expertise with XSLT, or the time to
> > do this. And since I no longer work on any projects using
> > Xalan-C, I’m no longer realistically able to do any further
> > maintenance work either. If I hadn’t done the most recent work
> > and made the 1.12 release, it’s most likely that the incorporation
> > of community patchsets and making a point release would not have
> > happened. No one aside from me has worked on Xalan-C since Steven
> > J Hathaway’s last work in 2012.
> >
> > 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.
> >
> > I’ve made a good effort to keep the project going for the near- to
> > medium-term. The CMake build made it possible to build on all
> > contemporary platforms. The documentation switch to Markdown made
> > it possible to build without obsolete and unavailable Java
> > libraries. The bugfixes we included in 1.12 fixed a number of
> > critical issues. So 1.12 should serve as a usable release for the
> > foreseeable future even in the absence of further development.
> >
> > However, I don’t see a future for anything beyond 1.12 unless
> > there is a dramatic change. XSLT usage is declining, and Xalan-C
> > doesn’t support XSLT 2.0 and beyond. Rather than letting the
> > current situation linger on indefinitely, I wanted to suggest we
> > take stock of where we are, and if there is consensus to do so, I
> > think it would be advisable to draw a line at this point and end
> > the project gracefully.
> >
> > Kind regards,
> >
> > Roger
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
