[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65391: Acknowledgement (People need to report failing builds even th
From: |
Maxime Devos |
Subject: |
bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) |
Date: |
Wed, 30 Aug 2023 00:44:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
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