W dniu 11.03.2017, sob o godzinie 21∶49 -0500, użytkownik Rich Freeman napisał: > 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.
Actually, what started this is me wondering whether I did the right thing by switching app-arch/xarchiver to the fork. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
