From: Suhail Singh <suhailsingh247@gmail.com>
To: Attila Lendvai <attila@lendvai.name>
Cc: "Suhail Singh" <suhailsingh247@gmail.com>,
"Ricardo Wurmus" <rekado@elephly.net>,
"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 23:53:29 -0500 [thread overview]
Message-ID: <877c8dfm46.fsf@gmail.com> (raw)
In-Reply-To: <UyK5AUS0t_4hOooVgcfRLtxe_ItA9r4YDwjKXY4QFZ9YYmj6WUNGTiBVu7Vw5nPba2nfOlTi4YYHW8SqLPjFqCL_Bgnh-2G1cFrhocLbmBo=@lendvai.name> (Attila Lendvai's message of "Thu, 05 Dec 2024 19:07:22 +0000")
Attila Lendvai <attila@lendvai.name> writes:
> what other data would you miss that is not available in the git log?
No data that is currently being automatically generated. Then again,
none of the patches at present are. One can argue (and perhaps that's
what you are) that, even in the future, whatever automated-comments may
be left (e.g. guix lint/style stats, integration test-suite status) on
issues created for automated-patches could instead also be noted in the
automated-commits. That's certainly possible.
Another thing to note is that when there's an integration-test-suite,
patch-generation may not automatically lead to patch-merge, and even in
the case that they do there may be a delay between patch-generation and
patch-merge. Those situations are elegantly handled by having a
patch-generation and patch-merge bot interacting on a debbugs
issue-tracker.
> - it's a lot of wasted effort; the admin overhead of a simple package
> update is several times of the effort that goes into creating the
> patch. it gives the impression that the project organization
> doesn't value the time of its participants.
Sure, however, this doesn't apply in the case when patches are
automatically handled.
> - when i search for something, it's lost in the noise of boring and
> obsolete stuff in the issue tracker (package updates being one
> source). if a bot joins the "effort", i'm afraid it'll become that
> much worse.
Being "lost in the noise" can be addressed by ensuring there's a
straightforward way to exclude all bot-generated-patches from search
results.
Guix already makes good use of debbugs usertags. It would be
straightforward for all automatically generated patches to have a
pre-defined usertag denoting the fact that they've been automatically
generated. The mumi interface at issues.gnu.guix.org could also have
the default configuration which ignores all issues with said usertag.
Conclusion: The reasons presented so far seem to fundamentally be about
retaining the ability to discern automatically-generated-patches from
human-generated-patches. This is possible while still tracking such
patches via the issue tracker.
--
Suhail
next prev parent reply other threads:[~2024-12-06 5:35 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
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 [this message]
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=877c8dfm46.fsf@gmail.com \
--to=suhailsingh247@gmail.com \
--cc=attila@lendvai.name \
--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).