On Sat, Mar 11, 2017 at 8:48 PM, Kent Fredric <[email protected]> wrote: > On Thu, 09 Mar 2017 16:34:20 +0100 > Michał Górny <[email protected]> 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
