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
