Tracking forks of dead upstreams
Hi,
TL;DR:
What to do when a project with a dead upstream is "forked" and
development continues under the same name
Long story:
gnarwl, a GPLv2 LDAP-based email autoresponder developed by Patrick
Ahlbrecht, has recently been orphaned in Debian. Since a legacy mail
system of my employer still uses it (and will use it for at least a
couple of years) and we are running a local package to fix #703369
anyway I decided to adopt it.
Upstream has not seen a release since 2009 and it is listed as legacy
project on the authors webpage http://www.onyxbits.de/.
In 2012 someone on Github imported the last released version and added
LDAPS support (https://github.com/fln/gnarwl). I have also pushed the
fix for #703369 there. Together with an RPM spec file fix these are the
only diffs from the latest upstream so far. This is the only fork of
gnarwl I'm aware of, searching around did not find anything useful and
the usual distros don't carry notable additional patches either. I asked
around on the postfix mailinglist and did not get an answer. Other than
a note in the README about this being a fork of the original gnarwl it
still uses the same name, and all documentation still points to the
original author.
The software works well enough and I don't think anyone would use it for
new installations anyway, but there are a few rough edges in the
buildsystem (i.e. CFLAGS and DESTDIR support) that all distributions are
touching one way or another. It would be great to have this fixed in a
way every distro could simply take it.
I wrote the original author and asked him whether he would consider to
officially endorse the Github repo as "successor" to avoid
fragmentation. This would allow "fln" (not sure whether he would be even
interested in it) to collect patches and eventually tag a new version
the distributions could switch to.
Patrick very quickly replied and declined with (IMHO very reasonable)
arguments
* people still associate gnarwl with his name and would expect him
to fix issues in gnarwl
- therefor can't endorse some other repo he does not have control
over
* is completely out of the loop and does not operate a mailserver
anymore, so unable to judge or test patches
- therefor cannot run a repo and accept patches himself
(I have abbreviated it, hopefully not in the wrong way).
How would you generally deal with a situation like this?
* switch homepage to github, convince github owner to tag new upstream
release and update package to new release
+ properly documented where development (if any) could happen
- completely disregards original author wish, essentially a hijack
* keep original release and track (selected) commits as patches
+ respects original author on the paper, although it is still a
different software than he originally shipped
- a lot of patches, could be a mess in active forks
? switch Homepage field?
* convince github owner to rename fork and officially carry the
"upstream" burden for a ageing software
+ no conflict with original author
- depending on how the packaging is done (additional package with
new binaries, proper transitional package) it could fragment the
already tiny userbase even more
For gnarwl I'm currently leaning to the second option based on the
expected patch load, but I'm interested in your general opinion.
Regards,
Bernhard
Reply to: