bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 6144 bytes --]

>> 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.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]