From: "宋文武 via Bug reports for GNU Guix" <bug-guix@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: Andy Tai <atai@atai.org>, Bruno Victal <mirai@makinata.eu>,
Csepp <raingloom@riseup.net>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>,
65391@debbugs.gnu.org
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 18:29:00 +0800 [thread overview]
Message-ID: <87edjkvn6b.fsf@envs.net> (raw)
In-Reply-To: <6a62aced-9138-0496-fb01-d5d8e89ba8d6@telenet.be> (Maxime Devos's message of "Tue, 29 Aug 2023 16:03:22 +0200")
Maxime Devos <maximedevos@telenet.be> writes:
>> Maybe we can automatically report the failures as bugs, say every 7
>> days, and remove a package if it still fail to build in 90 days?
>
> 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?
>
Oh, to be more clear I didn't mean automatically remove a package, but
notify guix-devel to consider removing one if its "fail to build" issue
had existed for a long time and no one care.
> [...]
>
> Instead, what about:
>
>> Maybe we can automatically report the failures as bugs, say every
>> hour, and revert the commit(s) causing the new build failures if they
>> haven't been fixed in a week.
Yes, automatically report bugs would be helpful. And I'll leave the
reverting rights to committers, which usually need some research and
maybe risky.
> [...]
> 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 agree. Well sometimes if breaks are overlooked by me, then it's very
welcome for other to give me a hand.
Thanks.
next prev parent reply other threads:[~2023-08-30 10:30 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-19 23:53 bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Maxime Devos
2023-08-22 23:45 ` Csepp
2023-08-24 9:57 ` Simon Tournier
2023-08-24 17:23 ` Csepp
2023-08-24 14:52 ` Maxime Devos
2023-08-24 17:27 ` Csepp
2023-08-29 22:52 ` Maxime Devos
2023-08-30 2:36 ` Maxim Cournoyer
2023-08-24 15:02 ` Maxime Devos
2023-08-24 17:38 ` Csepp
2023-08-27 1:13 ` 宋文武
2023-08-27 3:38 ` Maxim Cournoyer
2023-08-27 8:16 ` bug#65391: [Cuirass] feature requests for dashboard 宋文武 via Bug reports for GNU Guix
2023-08-27 3:39 ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Maxim Cournoyer
2023-08-27 4:30 ` Bruno Victal
2023-08-27 15:07 ` Giovanni Biscuolo
2023-08-27 16:24 ` bug#65391: People need to report failing builds even Andy Tai
2023-08-27 21:26 ` Andy Tai
[not found] ` <handler.65391.B.169248925726403.ack@debbugs.gnu.org>
2023-08-29 14:03 ` bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Maxime Devos
2023-08-29 14:45 ` Maxim Cournoyer
2023-08-29 22:44 ` Maxime Devos
2023-08-30 2:28 ` Maxim Cournoyer
2023-08-30 10:39 ` Dr. Arne Babenhauserheide
2023-08-30 19:12 ` Maxim Cournoyer
2023-09-07 11:53 ` Simon Tournier
2023-09-11 8:30 ` Dr. Arne Babenhauserheide
2023-09-11 14:00 ` Simon Tournier
2023-09-11 23:12 ` Dr. Arne Babenhauserheide
2023-09-12 0:39 ` Simon Tournier
2023-08-30 11:50 ` Maxime Devos
2023-09-07 11:32 ` Simon Tournier
2023-09-11 7:28 ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Csepp
2023-09-11 7:58 ` Simon Tournier
2023-09-11 21:52 ` Csepp
2023-09-12 18:43 ` bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Maxime Devos
2023-08-30 10:29 ` 宋文武 via Bug reports for GNU Guix [this message]
2024-02-14 9:13 ` bug#65391: Close Andreas Enge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edjkvn6b.fsf@envs.net \
--to=bug-guix@gnu.org \
--cc=65391@debbugs.gnu.org \
--cc=atai@atai.org \
--cc=iyzsong@envs.net \
--cc=maxim.cournoyer@gmail.com \
--cc=maximedevos@telenet.be \
--cc=mirai@makinata.eu \
--cc=raingloom@riseup.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.