Hi Maxime, Maxime Devos <maximede...@telenet.be> writes:
>>> The first part looks reasonable to me (though I would decrease 7 days >>> to daily or even hourly, as I don't see a point in the delay), but how >>> does the second part (removing packages) make sense at all? >>> I mean, if you do that: >>> 1. Build failures happen (independent of whether you do that). >>> 2. Hence, by doing that, the distro shrinks over time. >>> 3. Leading to frustrated users(*), because the packages they were >>> using and which were working well were suddenly removed for no good >>> reason (**). >>> 4. Leading to less people fixing build failures (because of the >>> frustration). > >> We could bump the expiry time to 180 days, or even 365 days (a full >> year). If nobody opens an issue for a broken package in that amount of >> time, it's probably not used much if at all and may not be worth the >> maintenance burden. > > Please read the subject line of the original message, subject lines > aren't just fluff. Believe it or not, I actually did! :-) I was replying to the first part of your message, where you mentioned you were against packages removal. My reply was giving support to devising policy that would define when it's acceptable to prune the distribution of broken/unmaintained packages, which is tangentially related to the topic of reporting broken packages. These are just ideas and if we decide to turn some of them into policy we could write it in a way that would favor resolving problems instead of just making them disappear. [...] > If maintainers check that no new build failures are created, then over > time the total amount of old build failures becomes roughly zero > (roughly, because of occasional mistake and new timebombs). You mean that the building vs failing ratio improves, right? I'm all for giving a best effort to keep as many packages as we have the capacity to do, but at some point the Pareto principle kicks in and you realize there's not that much value in spending 3 days trying to fix a hardly maintained leaf package that has been failing to build for a year or two. [...] > (*) Sometimes upstream is really not with the times instead of > slightly out of touch, sometimes the broken package has a good > replacement and often security updates need to be performed before > they existed, but the ‘remove packages’ proposal is not limited to > such exceptions. This is the kind of considerations that we could mention in a package removal policy (basically mention it's a last resort thing). >>> [some other part] >>> Expanding upon this a bit more: >>> * Expecting that people fix build failures of X when updating X >>> seems >>> reasonable to me, and I think this is not in dispute. >>> * Expecting that people using X fix build failures of X or risk >>> the >>> package X being deleted when someone else changed a dependency Y of >>> X seems unreasonable to me. More generally, I am categorically >>> opposed to: >>> ‘If you change something and it breaks something else, you >>> should >>> leave fixing the something else to someone (unless you want to >>> fix it yourself).’ >>> (I can think of some situations where this is a good thing, >>> but not >>> in general and in particular not in this Guix situation.) >>> I mean, I don't know about you, but for me it fails the >>> categorical >>> imperative and the so-called Golden Rule. >> >> I think we can all assume contributors are acting in good faith and >> are ready to fix any problems resulting from their installed changes; >> but they need to be made aware of these failures. [...] > > Again, how does this reply addresses what you quoted? Like, this is > a valuable reply (and I mostly agree with it, but I would qualify > ‘contributors’ as ‘most regular contributors’ (**)) ... but it is not > a good reply to what you quoted. > > * if you left out the quote or separated your reply from the quote > (more explicitly, you could e.g. start with ‘On related matters, > ...’), it would be fine. > > * but if you don't, then you're blatantly ignoring what I wrote, which > is not fine at all. The text of yours I quoted was to provide some context as to what I was answering to; I replied to the essence of your argument I synthesized from it, not point by point as I agreed with it and it wouldn't have added much to do so. > It's something I have encountered and pointed out (less explicitly) in > the past in other threads as well. I think it's a common reaction when faced with a detailed text -- some people may simply ignore it, feeling overwhelmed, or they may synthesize the essence of it to keep it high level and the discussion more fluid. I don't think it should be perceived as mean; a partial reply is still better than none. -- Thanks, Maxim
