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.
More to the point, no, it doesn't mean that that the package is not used much, it could instead mean that the people using the package (or interested in using the package, if it was already broken when they discovered it) thought that the existence of ci.guix.gnu.org means that contributors doing Guix maintenance already know that the package is broken and assumed that it would be fixed, and that a new bug report would just be annoying the contributors because they already have a bug report: the build failure on ci.guix.gnu.org.
> It can always be resurrected from the git history if someone is > motivated to pick it up. Looking for removed packages from the git > history could become a second instinct if this was made policy. > Looking for removed packages from the git history could become a > second instinct if this was made policy. [trimmed yasnippet stuff]Yes, all this could be done. But how does any of this address my arguments you quoted at all?
Op 29-08-2023 om 16:45 schreef Maxim Cournoyer:
It's frustrating for users when a package is missing, but it's also frustrating/inefficient for maintainers to stumble upon broken packages when checking if an upgrade broke dependent packages (it takes time to build them just to find out they fail, and researching they already did), so a balance is needed.
This part, OTOH, actually has something to do with what you quoted.Again, as I wrote previously, maintainers are users too -- if something is frustrating to users it is frustrating to users because maintainers⊆users. What remains is the quantity of frustration, which is a valid point, but how would you even quantify that? I don't know about you, but I don't know how to do that, so while a valid point, it doesn't seem a useful point to me because it seems impossible to determine whether it is a point for or against.
Also, the amount of frustration would be less than what you appear to believe it to be:
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).
Then, the frustration of researching they already did mostly disappears. (Other sources of inefficiency and frustration remain.)
Also, I believe there shouldn't be a balance, or IOW, the balance should tilt almost completely towards no new broken packages and no removals (*).
I mean, having reliable non-broken packages (and services, installation etc.) is the whole point of a distro, and if that inherently results in frustration for people modifying the distro, IMO that means the frustration should be minimised (see e.g. better tooling suggestions) or computers should stop being used, not that Guix should stop being a distro.
(*) 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.
>> [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.It's something I have encountered and pointed out (less explicitly) in the past in other threads as well.
(**) If you want me to, I could sent you an example of someone writing a single message (and no other messages to Guix) in bad faith by PM.
> [tooling / QA improval suggestions] Agreed. Best regards, Maxime Devos.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature