On Wed, Sep 14, 2016 at 01:30:18PM +0000, Bernhard Schmidt wrote:
> What to do when a project with a dead upstream is "forked" and
> development continues under the same name
> 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
The solution I've seen other projects use that were in a similar
situation is to refer to the new project's home on the old homepage.
This is very easy.
If he isn't maintaining it himself anymore, and someone else has taken
over maintainership, then he should seriously consider doing this,
unless there is a real objection (for example, the new maintainer is not
doing a good job or is taking it into a completely different direction
than the original maintainer wanted).
> 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
I've done this with the "crawl" package. It was originally Linley
Henzell's version of Dungeon Crawl, but when he stopped maintaining it
and the Stone Soup team forked it, I just switched my package over to
the fork.
> * 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?
I'd advise against doing this, unless the patches are merely bugfixes.
Once you start adding features not in the original, then you're just
following the fork. In the latter case, it's better to be explicit about
it.
> * 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
I don't think that is helpful in this case.
> For gnarwl I'm currently leaning to the second option based on the
> expected patch load, but I'm interested in your general opinion.
You should try to have the two upstreams agree on having the
maintainership passing from one person to the other, if possible. In any
case, ensure the new maintainer does his part properly (indeed, proper
tags, version numbers, tarballs, et cetera), and make it clear that the
package was originally written by the first maintainer, but that it has
been taken over by the second one, so that both get proper attribution,
and that end-users know what version of the software they are running.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@debian.org>
Attachment:
signature.asc
Description: Digital signature