Re: Tracking forks of dead upstreams

[Sean Whitton <spwhitton@spwhitton.name>]

Hello,

On Wed, Sep 14, 2016 at 01:30:18PM +0000, Bernhard Schmidt wrote:
> 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.

I think you're right, because you've described this software as being in
maintenance-mode.  Option 3 would be best if there were going to be
significant changes, but it sounds like it is not worth investing time
in convincing the GitHub guy to do that.

You could note in README.Debian that the Debian package is indebted to
the GitHub guy for improvements.

-- 
Sean Whitton