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 <garydgreg...@gmail.com>
Sent: 15 October 2022 12:42
To: dev@xalan.apache.org
Cc: c-us...@xalan.apache.org
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 
<rle...@codelibre.net<mailto:rle...@codelibre.net>> 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: rle...@codelibre.net<mailto:rle...@codelibre.net> 
<rle...@codelibre.net<mailto:rle...@codelibre.net>>
Sent: 22 June 2022 23:21
To: dev@xalan.apache.org<mailto:dev@xalan.apache.org>; 
c-us...@xalan.apache.org<mailto:c-us...@xalan.apache.org>
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:

[cid:image003.png@01D8DA4E.7333F9C0]

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

Reply via email to