Re: [gentoo-dev] How to deal with package forks?

[Rich Freeman]

On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric <kentnl@g.o> wrote:
> On Thu, 09 Mar 2017 16:34:20 +0100
> Michał Górny <mgorny@g.o> wrote:
>
>> 1. classic forks -- package B is forked out of A, and the development of
>> both continue independently (eudev/systemd, ffmpeg/libav);
>>
>> 2. large patch sets / continuously rebased forks -- where the particular
>> set of changes is usually applied to mainline or regularly rebased
>> against mainline but without full separation (kernel patchsets, bitcoin
>> patches);
>>
>> 3. abandoned package forks -- package A stops being maintained upstream,
>> someone forks it and starts working on top of that (xarchiver).
>
> I think any formal guideline needs to be clear that these statements are with regards
> to *mutually exclusive* forks, where dual-installation is not viable and/or auto-linking
> magic would do bad things if they were co-installed.
>
> Partly because not all forks are done by 3rd parties. Some projects "Self fork".
>
> But here, the distinction between "fork" and "major version" blurs, because often
> the reason for a "self fork" is to explicitly allow cohabitation with the "old fork",
> in a manner very akin to "new major version in new slot".
>
> So with that said, in all of those cases, if the "new" fork and the "old" fork don't
> directly compete at a physical level, even though they share logical ancestry, they can be considered
> new independent software.
>

So, I have to ask.  All this theorizing is interesting and I think it
can make for guidelines, but do we really have any cases where it
isn't working out under maintainer discretion, other than the one case
that started this discussion?

My sense is that everybody has already figured out the best way to
handle these kinds of patches and is already using discretion to sort
out these cases.  I don't think we need a generic policy over a
dispute about how bitcoin is packaged.

-- 
Rich