Re: Automatically testing package updates

[Suhail Singh <suhailsingh247@gmail.com>]

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