unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Maxim Cournoyer <maxim.cournoyer@gmail.com>,
	Maxime Devos <maximedevos@telenet.be>
Cc: 65391@debbugs.gnu.org, "Bruno Victal" <mirai@makinata.eu>,
	Csepp <raingloom@riseup.net>, 宋文武 <iyzsong@envs.net>,
	"Andy Tai" <atai@atai.org>
Subject: bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)
Date: Thu, 07 Sep 2023 13:32:20 +0200	[thread overview]
Message-ID: <87tts6kym3.fsf@gmail.com> (raw)
In-Reply-To: <87h6ohc3gk.fsf@gmail.com>

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.

The question is the way to detect them.  QA can do whatever we want but
until people are helping Chris because, IMHO, Chris is already enough
busy to keep stuff running, we probably need to keep our process simple
enough in order to stay actionable and avoid some vacuum of “coulda,
shoulda or woulda”.  For what my opinion is worth on that. :-)

Cheers,
simon




  parent reply	other threads:[~2023-09-07 15:20 UTC|newest]

Thread overview: 33+ 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
     [not found] ` <871qfpxp76.fsf@envs.net>
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  4:30   ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Bruno Victal
2023-08-27 16:24 ` bug#65391: People need to report failing builds even 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 [this message]
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
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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tts6kym3.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).