From: Suhail Singh <suhailsingh247@gmail.com>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: "Suhail Singh" <suhailsingh247@gmail.com>,
"Simon Tournier" <zimon.toutoune@gmail.com>,
"Ludovic Courtès" <ludo@gnu.org>, guix-devel <guix-devel@gnu.org>
Subject: Re: Automatically testing package updates
Date: Thu, 05 Dec 2024 11:10:52 -0500 [thread overview]
Message-ID: <87ldwu860j.fsf@gmail.com> (raw)
In-Reply-To: <87wmge6tad.fsf@elephly.net> (Ricardo Wurmus's message of "Thu, 05 Dec 2024 16:31:06 +0100")
Ricardo Wurmus <rekado@elephly.net> writes:
> It would be preferable to automate trivial updates *completely*, even
> bypassing the need for manual patch generation and submission to the
> bug tracker.
I agree with the goal of automating trivial updates. One way of doing
so is outlined in the proposal I shared here:
<https://yhetil.org/guix/87ed2yufar.fsf@gmail.com/>. Importantly,
automating trivial updates which result in _automated_ patch generation,
is not fundamentally mutually exclusive with "submission to the bug
tracker".
> I'd rather reserve the issue tracker for humans and keep bots in a
> realm that is separate from the user interfaces designed for humans.
I believe it is important to provide _some_ way of distinguishing bot
activities from that of humans. It's not clear to me that keeping said
activities entirely separate from human activities is the best way of
doing so.
I don't necessarily disagree with keeping the two separate. However, it
is still important to provide some transparency on bot activities.
Keeping things on the issue tracker has said transparency as a nice
side-effect. However, it is by no means the only way of doing so.
If we do decide to keep bots in a separate realm as it were, it would be
desirable (and in my opinion, important) if that still allowed for at
least as much transparency that the issue tracker provides for human
activities.
It would help the discussion if we could express the benefits that would
be achieved by not tracking bot activities on the issue tracker.
Especially since there are certain drawbacks (reduction in transparency,
unless addressed by other means) of doing so.
Do you have thoughts on the matter?
--
Suhail
next prev parent reply other threads:[~2024-12-05 16:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-02 13:44 Automatically testing package updates Ludovic Courtès
2024-12-02 14:50 ` Simon Tournier
2024-12-02 19:14 ` Simon Tournier
2024-12-02 19:16 ` Simon Tournier
2024-12-05 7:20 ` Efraim Flashner
2024-12-05 8:06 ` Hilton Chain
2024-12-05 9:23 ` Ricardo Wurmus
2024-12-05 13:29 ` Suhail Singh
2024-12-05 15:31 ` Ricardo Wurmus
2024-12-05 16:10 ` Suhail Singh [this message]
2024-12-05 19:07 ` Attila Lendvai
2024-12-05 19:55 ` Ricardo Wurmus
2024-12-06 5:09 ` Suhail Singh
2024-12-14 23:46 ` Ludovic Courtès
2024-12-06 4:53 ` Suhail Singh
2024-12-05 19:58 ` Ricardo Wurmus
2024-12-03 0:32 ` Vagrant Cascadian
2024-12-14 23:47 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2024-12-03 14:01 Sharlatan Hellseher
2024-12-14 23:51 ` Ludovic Courtès
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=87ldwu860j.fsf@gmail.com \
--to=suhailsingh247@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=rekado@elephly.net \
--cc=zimon.toutoune@gmail.com \
/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).