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: 3835 bytes --]



Op 07-09-2023 om 13:32 schreef Simon Tournier:
> Hi,
> 
> On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> 
>> 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.
> 
> There is nothing worse as an user to have this experience:
> 
>      guix search foobar
> 
> oh cool, foobar is there, let try it,
> 
>      guix shell foobar
> 
>      … wait …
>      … stuff are building …
>      … laptop is burning …
>      … wait …
>      Bang!
> 
> Keeping broken packages is just annoyances.  Contributor are annoyed
> because as said by the paragraph above.  And user are annoyed as
> described just above.
 >
> I am in favor to set a policy for removing then.

You don't need to keep broken packages, they can be fixed instead. 
Although given later e-mails, I suppose that this hypothetical policy 
for removing them would contain things about fixing them instead.

It's this focus on 'broken -> delete' that bothers me, why is the first 
reaction ‘delete them’, not ‘fix them’?

> Op 11-09-2023 om 16:00 schreef Simon Tournier:
>> If you care about one package that is marked to be removed soon, then
>> you fix it or raise your concern.  Else it means no one care and so what
>> is the point to keep broken packages that no one uses?

It doesn't mean that.  As I wrote previously:

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

---

 > The more important question is (serious question and *not* for
 > assigning blame, but to see whether we can improve processes): with
 > the time we already spent in this discussion, we could have fixed a
 > lot of packages.  Why did we not do that?

Speaking only for myself:

   * (because I chose to mostly not work on Guix anymore for reasons that
     aren't relevant to this discussion)

    * if I were to fix broken packages, I would like others to avoid
      creating new breakage (and if breakage occurs, then fix it it
      early).  (Otherwise, not much point to it ...)

      Hence, there needs be some discussion to ensure that other people
      don't do that new breakage in the future.

    * hearing ‘delete it’ as first reaction to ‘broken package’ is rather
      demoralising to people fixing packages.  It's so ... defeatist.
      Sure people with this reaction add a few qualifiers to when it is
      to _not_ be removed, but it sounds rather hollow.

Instead of having a ‘removal policy’ that lays down exceptions that 
indicate when the package should instead be kept, I would rather have a 
‘fixing policy’ that has exceptions indicating when the package may 
instead be removed.

In a sense, those are technically equivalent, but the different framing 
makes a difference in motivation.

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