You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@community.apache.org by Roger Leigh <rl...@codelibre.net> on 2018/02/24 12:53:22 UTC
Status of the Xalan-C project (is it abandoned?)
Hi folks,
I'm not sure if this is the most appropriate list, but I'm not sure
exactly how to proceed, so if it's wrong please redirect me to where I
should go.
I'm a user of Apache Xerces-C++ and Xalan-C++. Both of these projects
haven't seen much maintenance for the last few years, and I was having
severe problems building them on modern platforms because of the
outdated and broken build systems these projects used. It wasn't
possible to build either on Windows without extensive patching of the
Visual Studio Project/Solution files, and similar for brokenness in the
GNU Autoconf/Automake builds, which imposed a significant maintenance
burden upon myself and other users of these projects.
To fix this, I joined the Apache project and contributed a CMake build
plus fixes to the Autoconf/Automake build to the Apache Xerces-C++
project on behalf of my employer. There was quite a bit of interest in
this from other users suffering from the same problems, and the active
developer on the project was welcoming of the patches. This was
eventually released as Xerces-C++ 3.2.0 last year, with a 3.2.1 due
imminently with some bugfixes for this work.
Unfortunately, I have not have the same success with the Xalan-C
project. Over the last two years, I have opened several tickets with
tested patches, made several posts to the mailing lists regarding the
same, and received zero responses.
Tickets:
https://issues.apache.org/jira/browse/XALANC-773
https://issues.apache.org/jira/browse/XALANC-766
https://issues.apache.org/jira/browse/XALANC-767
https://issues.apache.org/jira/browse/XALANC-776
Posts:
https://marc.info/?l=xalan-dev&m=149748238016328&w=2
https://marc.info/?l=xalan-dev&m=150228668631916&w=2
https://marc.info/?l=xalan-dev&m=150618078013560&w=2
It's a bit of a black hole. Looking at the SVN repository:
Last release was 1.11: on Oct 31 2012 (5 years, 4 months)
Last development commit: Sep 25 2013 (4 years, 5 months)
There is zero visible activity there for a long, long time.
There have been a small number of messages from the maintainer to the
mailing list, but no actual work appears to be taking place, and without
any replies to my tickets or posts, I'm a bit stuck. I do need to get
the longstanding portability bugs fixed so that I can continue to use it
on contemporary systems without it requiring man weeks of effort
maintaining out of tree patches which require redoing from scratch for
every new version of Visual Studio. Even with hand-patching I'm still
seeing subtle misbehaviour at link time and runtime on various
platforms; what's there simply isn't fit for purpose and the current
situation is not tenable for us as end users.
Is there any process within the Apache project for handling dead
projects (assuming this is the case). I don't want to take over the
project, I just want to submit a bunch of fixes so that we can make a
new point release which actually works without extensive patching. I've
been waiting over two years for a single reply to any of my attempts at
contact, and my patience has its limits, which is why I'm writing here
to see if there's any way to make some actionable progress.
Many thanks,
Roger Leigh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Status of the Xalan-C project (is it abandoned?)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Roger,
On Sat, Feb 24, 2018 at 1:53 PM, Roger Leigh <rl...@codelibre.net> wrote:
> ...I'm not sure if this is the most appropriate list, but I'm not sure exactly
> how to proceed, so if it's wrong please redirect me to where I should go...
We can handle this here - I understand your confusion.
> ...I'm a user of Apache Xerces-C++ and Xalan-C++. Both of these projects
> haven't seen much maintenance for the last few years...
Indeed. They are managed by the Xalan PMC, you can see both of them
mentioned in that PMC's reports at
https://whimsy.apache.org/board/minutes/Xalan.html
Those reports have several mentions like "we would still appreciate
more active persons to build Xalan-C tests" so it looks like you would
be welcome to help.
I have forwarded your query to the Xalan PMC, asking them to reply
here. Let's see if it helps.
FWIW http://attic.apache.org/ is where dead projects go, but it looks
like those are not in this case.
-Bertrand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Status of the Xalan-C project (is it abandoned?)
Posted by Paul Hammant <pa...@hammant.org>.
>
> If I fork it, I'll have to change the library name, and that will make me
> incompatible with the rest of the world--all downstream consumers including
> my own.
^ Is an assumption.
You could start with the fork on GitHub 'as is' and make one tiny addition
to the resulting linkable object. Specifically add a "-gh" to the resulting
binary name. Engage the ASF (you kind of are already) as you go. Keep
going with that until someone has a better idea, which may include
breathing life into Xalan-C at the ASF again (or not) and consuming the
changes back. Maybe get all the contribs to the forked one to be
copyright-granted to you, so that you may later easily copyright grant (and
CLA) them to Apache. Copyright grant isn't a exclusivity statement, by the
way. There was some kerfuffle on copyrights when *Apache Geronimo *was
created in 2003 and contributors had to rake over the history of certain
source files in order to claim "I authored this originally and later gave a
copyright grant to a legal entity, and now want to do the same to the ASF
for the same source from back then".
Not forks as such necessarily, but *libc* hs plenty of
maintained-divergence alternates - http://www.etalabs.net/compare_libcs.html
Note, I'm not an officer of the ASF it has to be said so I'm only saying
what I'd do if I personally cared enough about a library and couldn't wait
for meetings and decisions to happen.
-ph
Re: Status of the Xalan-C project (is it abandoned?)
Posted by Roger Leigh <rl...@codelibre.net>.
On 24/02/18 13:09, Paul Hammant wrote:
> GitHub heralded one fantastic thing that didn't exist before - easy forking
> or a repo. That is more likely to force an 'upstream' dev team to be more
> benevolent to directions of others. Perhaps because of the possibility of
> mind-share shifting to the fork and away from the upstream/origin. That
> divergence from the origin happens isn't a problem necessarily. I've been
> doing open source for 18 years now, and the only thorny thing that remains
> is trademarks (were the forker wanting to release a binary) and a lesser
> honor system: "hey stop using the name of my OSS tool/lib because you're
> just confusing people". Node.js and Io.js is a notable case
> <https://www.theregister.co.uk/2015/09/09/node_js_v400_reunites_with_io_js/>
> .
>
> If you have your patches, then just apply them to a fork on GitHub. You
> don't have to become maintainer - make that clear in the readme
> <https://svn.apache.org/repos/asf/xerces/c/trunk/README> (oooh maybe
> http://makeareadme.com/ applies). Start something there and see if there
> are others that want to help. One of them might become maintainer :)
It's not quite that simple when you're dealing with versioned shared
libraries, and you yourself are making versioned shared libraries for
others to use. We need to be compatible with the wider ecosystem using
these libraries.
If I fork it, I'll have to change the library name, and that will make
me incompatible with the rest of the world--all downstream consumers
including my own. And the fixes won't propagate through all the various
OS distributions without a very large effort. I could fork it, but it's
an option of last resort since it's easy to do, but a logistical
nightmare to deal with the fallout. I don't want to maintain a whole
forked project, I want to submit a handful of essential bugfixes and
make a new point release which benefits everyone.
I've already applied a number of these patches to various Linux
distributions, FreeBSD ports, Mac homebrew formula etc. We need a new
upstream release containing these fixes, not a hard fork.
Thanks,
Roger
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org
Re: Status of the Xalan-C project (is it abandoned?)
Posted by Paul Hammant <pa...@hammant.org>.
GitHub heralded one fantastic thing that didn't exist before - easy forking
or a repo. That is more likely to force an 'upstream' dev team to be more
benevolent to directions of others. Perhaps because of the possibility of
mind-share shifting to the fork and away from the upstream/origin. That
divergence from the origin happens isn't a problem necessarily. I've been
doing open source for 18 years now, and the only thorny thing that remains
is trademarks (were the forker wanting to release a binary) and a lesser
honor system: "hey stop using the name of my OSS tool/lib because you're
just confusing people". Node.js and Io.js is a notable case
<https://www.theregister.co.uk/2015/09/09/node_js_v400_reunites_with_io_js/>
.
If you have your patches, then just apply them to a fork on GitHub. You
don't have to become maintainer - make that clear in the readme
<https://svn.apache.org/repos/asf/xerces/c/trunk/README> (oooh maybe
http://makeareadme.com/ applies). Start something there and see if there
are others that want to help. One of them might become maintainer :)