[workflow] Automatically close bug report when a patch is committed

[workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

Hello,

often bug reports related to patches are left open even after the
patch/patchset have been applied, the last example is a batch of Debbugs
manual gardening from Vagrant last Fri and Sat when he closed more than
20 bugs with messages similar to this one:

--8<---------------cut here---------------start------------->8---

 rofi-wayland was added in:

 04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.

 And updated to a newer version in:

 19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 1.7.5+wayland2.

 Marking as done.

--8<---------------cut here---------------end--------------->8---
(https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)

IMO we need a way automatically close this kind of bug reports... or am
I missing something?

Let's avoid manual gardening as much as possible! :-)

The first thing we need is a server side git post-receive hook on
Savannah, I've opened the sr#110928 support request:
https://savannah.nongnu.org/support/index.php?110928

When I asket I though the best way would be to scan for a string like
"Close #<bug-number>" in the commit message (the committer should add
such a string) but probably this can be avoided: the bug can be closed
when a patch is committed to one of the listed official brances (master,
core-updates, etc.)

WDYT?

Ciao, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]


Giovanni Biscuolo <g@xelera.eu> writes:

> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages similar to this one:
>
>
>  rofi-wayland was added in:
>
>  04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.
>
>  And updated to a newer version in:
>
>  19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 1.7.5+wayland2.
>
>  Marking as done.
>
> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)
>
> IMO we need a way automatically close this kind of bug reports... or am
> I missing something?

I think the example you give doesn't relate to what you're looking at
below (a post-receive hook).

There were at least two different issues with patches for adding
rofi-wayland [1] and [2].

1: https://issues.guix.gnu.org/53717
2: https://issues.guix.gnu.org/59241

One improvement I can think of here is that QA should highlight that
some of the changes in each of those patch series can be found in
another patch series.

That would then make it easier to both issues to be closed if that's
appropriate.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

[workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 5163 bytes --]

Hi Christopher,

[note: I'm deleting the "In-Reply-To:" header and changing subject to
try to start a new thread]

Christopher Baines <mail@cbaines.net> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:

[...]

>> 20 bugs with messages similar to this one:
>>
>>
>>  rofi-wayland was added in:
>>
>>  04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.
>>
>>  And updated to a newer version in:
>>
>>  19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 1.7.5+wayland2.
>>
>>  Marking as done.
>>
>> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)
>>
>> IMO we need a way automatically close this kind of bug reports... or am
>> I missing something?
>
> I think the example you give doesn't relate to what you're looking at
> below (a post-receive hook).

Oh I see, thanks!

This is a complex case (see below), at least not one that can be solved
by automatically closing bug reports upon commits :-O

Sorry for the confusion I added by pointing out the wrong example, a
quick look at many bug reports made by Vagrant Cascadian last Fri and
Sat shows that many (all?) of the closed bug reports was some sort of
"duplication" of others.  Vagrant please can you tell us?

Let's call this a "triaging issue" and is a class of "management issue"
that should be discussed in a separate thread (this one), to stay
focused on the subject.

Probably missing to "manually" close bugs after a patch set has been
committed is not /the worst/ management issue currently, but IMO it's
better to just "commit and forget it" :-)

Probably /triaging/ is one of the most critical bug report management
issue, it should be addressed properly:

- by finding or developing triage helping tools to automate what is
  possible
  
- by having more people do the (boring) task of triaging bugs

Probably we should consider adding one more contributor "level": the
triager; the triager is _not_ a reviewer (obviously not a committer),
even if she could /also/ be a reviewer and/or committer.

The point is that triaging is a (boring) activity that Someone™ should
perform, sooner or later (as Vagrant did with the bug reports mentioned
above).

Obviously a contrubutor could (should) also be a self-triager, if she
wants help making the review process more efficient.

> There were at least two different issues with patches for adding
> rofi-wayland [1] and [2].
>
> 1: https://issues.guix.gnu.org/53717

This was to add (version "1.7.3+wayland1") and AFAIU was never committed

> 2: https://issues.guix.gnu.org/59241

This issue have 2 patches:

[PATCH 1/2] gnu: rofi: Update to 1.7.5.

[PATCH 2/2] gnu: Add rofi-wayland.

A (self-)triager should have noted two problems in that patch set
submisison:

1. patch contains two set of unrelated changes (?)

Point 12. of the "check list" in 22.6 Submitting Patches
https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html says:

--8<---------------cut here---------------start------------->8---

Verify that your patch contains only one set of related changes. Bundling unrelated changes together makes reviewing harder and slower.

Examples of unrelated changes include the addition of several packages, or a package update along with fixes to that package.

--8<---------------cut here---------------end--------------->8---

Is the addition of rofi-wayland related to the upgrade of rofi?

...probably yes, but...

2. multiple patches without cover letter

https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1

--8<---------------cut here---------------start------------->8---

When sending a series of patches, it’s best to send a Git “cover letter” first, to give reviewers an overview of the patch series.

--8<---------------cut here---------------end--------------->8---

Missing a cover letter means that triaging is harder.

The issue title is from the first patch (gnu: rofi: Update to 1.7.5.)
and IMO is somewhat confusing because the title is what appears in
search results (Mumi, Debbugs, Emacs Debbugs).

If the contrubutor sent a cover letter with subject "gnu: Update rofi
and Add rofi-wayland (inherinting)", possibly with a little bit of
explanation in the message body, the (now undone) early triaging would
have been easier.

How do we solve such bug management class of problems? WDYT?

> One improvement I can think of here is that QA should highlight that
> some of the changes in each of those patch series can be found in
> another patch series.

...and tag both bugs as related on Debbugs?

This would be very helful for triagers, a very helping tool.

...but we need triagers, IMO

> That would then make it easier to both issues to be closed if that's
> appropriate.

I guess you mean that a (human) triager can find related bugs with the
help of such a tool.

I doubt that related issues should be closed without human intervention,
false positives are very dangerous in this case.

WDYT?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 8270 bytes --]

On 2023-09-07, Giovanni Biscuolo wrote:
> Christopher Baines <mail@cbaines.net> writes:
>
>> Giovanni Biscuolo <g@xelera.eu> writes:
>
> [...]
>
>>> 20 bugs with messages similar to this one:
>>>
>>>
>>>  rofi-wayland was added in:
>>>
>>>  04b5450ad852735dfa50961d3afc789b2e52b407 gnu: Add rofi-wayland.
>>>
>>>  And updated to a newer version in:
>>>
>>>  19c042ddf80533ba7a615b424dedf9647ca65b0f gnu: rofi-wayland: Update to 1.7.5+wayland2.
>>>
>>>  Marking as done.
>>>
>>> (https://yhetil.org/guix/87zg25r0id.fsf@wireframe/)
>>>
>>> IMO we need a way automatically close this kind of bug reports... or am
>>> I missing something?
>>
>> I think the example you give doesn't relate to what you're looking at
>> below (a post-receive hook).
>
> Oh I see, thanks!
>
> This is a complex case (see below), at least not one that can be solved
> by automatically closing bug reports upon commits :-O
>
> Sorry for the confusion I added by pointing out the wrong example, a
> quick look at many bug reports made by Vagrant Cascadian last Fri and
> Sat shows that many (all?) of the closed bug reports was some sort of
> "duplication" of others.  Vagrant please can you tell us?

Yes, I think a fair amount was from "duplicate" patches. From memory, I
would say many, if not most, of the bugs were due to one person
submitting a patch, and someone else independently committing the same
or newer version.

Part of the problem with duplicates may be the difficulty of reviewing a
very long poorly curated list of bugs... before issues.guix.gnu.org was
a thing, it was difficult to actually find prior submissions... and it
is still long enough that it is not easy.


> Probably /triaging/ is one of the most critical bug report management
> issue, it should be addressed properly:
>
> - by finding or developing triage helping tools to automate what is
>   possible
>   
> - by having more people do the (boring) task of triaging bugs
>
> Probably we should consider adding one more contributor "level": the
> triager; the triager is _not_ a reviewer (obviously not a committer),
> even if she could /also/ be a reviewer and/or committer.
>
> The point is that triaging is a (boring) activity that Someone™ should
> perform, sooner or later (as Vagrant did with the bug reports mentioned
> above).

I was definitely in the mood for "let me get some relatively easy, if
boring things done" the other day. :)


> Obviously a contrubutor could (should) also be a self-triager, if she
> wants help making the review process more efficient.

FWIW, I think I used the search:

  https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch

Sorted by date, and searched for the phrase "update" in the subject, as
old bugs proposing to update to a newer version were and are, well,
likely candidates for culling. :)

Other tooling that could further help with the process would be
valuable.


>> There were at least two different issues with patches for adding
>> rofi-wayland [1] and [2].
>>
>> 1: https://issues.guix.gnu.org/53717
>
> This was to add (version "1.7.3+wayland1") and AFAIU was never committed

Right, I marked this (and several others) as done because it was
effectively superseded by newer versions in current guix.

There were sometimes some things that were not merged, and I made
judgement calls on weather they still needed to be, such as a tweak to
the packaging that was maybe only needed to get an older version to
build, but the newer version was building correctly.


>> 2: https://issues.guix.gnu.org/59241
>
> This issue have 2 patches:
>
> [PATCH 1/2] gnu: rofi: Update to 1.7.5.
>
> [PATCH 2/2] gnu: Add rofi-wayland.
>
> A (self-)triager should have noted two problems in that patch set
> submisison:
>
> 1. patch contains two set of unrelated changes (?)
>
> Point 12. of the "check list" in 22.6 Submitting Patches
> https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html says:
>
> --8<---------------cut here---------------start------------->8---
>
> Verify that your patch contains only one set of related changes. Bundling unrelated changes together makes reviewing harder and slower.
>
> Examples of unrelated changes include the addition of several packages, or a package update along with fixes to that package.
>
> --8<---------------cut here---------------end--------------->8---

That is a good reminder, there was at least one bug that seemed like a
collection of "music" packages, and over time more packages were added,
even after the original packages in the bug title were merged.


> Is the addition of rofi-wayland related to the upgrade of rofi?
>
> ...probably yes, but...
>
> 2. multiple patches without cover letter
>
> https://guix.gnu.org/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Multiple-Patches-1
>
> --8<---------------cut here---------------start------------->8---
>
> When sending a series of patches, it’s best to send a Git “cover letter” first, to give reviewers an overview of the patch series.
>
> --8<---------------cut here---------------end--------------->8---
>
> Missing a cover letter means that triaging is harder.

Indeed. Retitling can be used to help after the fact, at least.


> The issue title is from the first patch (gnu: rofi: Update to 1.7.5.)
> and IMO is somewhat confusing because the title is what appears in
> search results (Mumi, Debbugs, Emacs Debbugs).

I retitled several bugs as well, to at least update the current status,
as a few had some patches merged or superseded, but there were
outstanding issues not yet merged.


> If the contrubutor sent a cover letter with subject "gnu: Update rofi
> and Add rofi-wayland (inherinting)", possibly with a little bit of
> explanation in the message body, the (now undone) early triaging would
> have been easier.

Yes, cover letters would help significantly with triaging these more
complicated cases.

That said, sometimes over the course of review, it becomes clear that
additional changes are needed, and it would be helpful to retitle the
bug in these cases.

I saw at least one bug which started out as "Add XYZ" and evolved into
"Update ZXY, ... Add ABC, Add XYZ" and it would not have made sense to
make them separate patch submissions.


> How do we solve such bug management class of problems? WDYT?
>
>> One improvement I can think of here is that QA should highlight that
>> some of the changes in each of those patch series can be found in
>> another patch series.
>
> ...and tag both bugs as related on Debbugs?

Not sure how to mark related, but bugs can be marked as blocking other
bugs... this would make some sense in splitting patch series into
multiple bugs, marking blocking bugs for patches that are dependent on
others. But I suspect that would be painful in practice in many cases.


> This would be very helful for triagers, a very helping tool.
>
> ...but we need triagers, IMO
>
>> That would then make it easier to both issues to be closed if that's
>> appropriate.
>
> I guess you mean that a (human) triager can find related bugs with the
> help of such a tool.
>
> I doubt that related issues should be closed without human intervention,
> false positives are very dangerous in this case.

With old patches, honestly, it might bring attention back to an issue to
close it. When I get a bug closed notification, I definitely check to
make sure the issue is actually fixed, or did not introduce other
surprises...

I am not saying I think we should just blindly close old bugs with
patches, but processes that err slightly on the side of closing old
ones, perhaps with a message "please verify if the issue is actually
closed, and reopen in case we have made a mistake." might be reasonable.

Obviously, if an automated process can automatically rebase and it still
applies, this might be an indication that it still requires human review
and tag it as such... although occasionally a patch might propose adding
something to gnu/packages/abc.scm but actually gets merged into
gnu/packages/xyz.scm, and this might rebase "fine".


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 9880 bytes --]

Hello Vagrant,

sorry for the delay with this reply (maybe meanwhile someone else have
already done all or some of my considerations)

Vagrant Cascadian <vagrant@debian.org> writes:

[...]

>> The point is that triaging is a (boring) activity that Someone™ should
>> perform, sooner or later (as Vagrant did with the bug reports mentioned
>> above).
>
> I was definitely in the mood for "let me get some relatively easy, if
> boring things done" the other day. :)

boring but very much useful: thank you! ...and thanks to all the other
people that sometimes are doing this job!

>> Obviously a contrubutor could (should) also be a self-triager, if she
>> wants help making the review process more efficient.
>
> FWIW, I think I used the search:
>
>   https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch
>
> Sorted by date, and searched for the phrase "update" in the subject, as
> old bugs proposing to update to a newer version were and are, well,
> likely candidates for culling. :)

> Other tooling that could further help with the process would be
> valuable.

A more useful mumi (web or CLI) query to search for duplicates would be:

  is:open tag:patch subject:<package>

With a caveat: searched subject term could not be in the search results,
since it gives bug titles, but in the /thread/ of a found bug, see bug
#65809 for details

WDYT?

[...]

> There were sometimes some things that were not merged, and I made
> judgement calls on weather they still needed to be, such as a tweak to
> the packaging that was maybe only needed to get an older version to
> build, but the newer version was building correctly.

I see and for this reason I feel triaging (for example to merge or close
bugs) cannot be automated, it needs judgement

[...]

>> When sending a series of patches, it’s best to send a Git “cover letter” first, to give reviewers an overview of the patch series.
>>
>> --8<---------------cut here---------------end--------------->8---
>>
>> Missing a cover letter means that triaging is harder.
>
> Indeed. Retitling can be used to help after the fact, at least.

Right: retitling could be one of the (possibly early) triaging actions

>> The issue title is from the first patch (gnu: rofi: Update to 1.7.5.)
>> and IMO is somewhat confusing because the title is what appears in
>> search results (Mumi, Debbugs, Emacs Debbugs).
>
> I retitled several bugs as well, to at least update the current status,
> as a few had some patches merged or superseded, but there were
> outstanding issues not yet merged.

I recently learned not to confuse "subject" with "bug title"... I feel
this is something contributors should always consider

>> If the contrubutor sent a cover letter with subject "gnu: Update rofi
>> and Add rofi-wayland (inherinting)", possibly with a little bit of
>> explanation in the message body, the (now undone) early triaging would
>> have been easier.
>
> Yes, cover letters would help significantly with triaging these more
> complicated cases.
>
> That said, sometimes over the course of review, it becomes clear that
> additional changes are needed, and it would be helpful to retitle the
> bug in these cases.
>
> I saw at least one bug which started out as "Add XYZ" and evolved into
> "Update ZXY, ... Add ABC, Add XYZ" and it would not have made sense to
> make them separate patch submissions.

yes: retitling is an important (re)triaging activity

>> How do we solve such bug management class of problems? WDYT?
>>
>>> One improvement I can think of here is that QA should highlight that
>>> some of the changes in each of those patch series can be found in
>>> another patch series.
>>
>> ...and tag both bugs as related on Debbugs?
>
> Not sure how to mark related,

Uh I see [1]: AFAIU the only available links between bugs are [2]:

1. merge bugnumber bugnumber ...

--8<---------------cut here---------------start------------->8---

Merges two or more bug reports. When reports are merged opening,
closing, marking or unmarking as forwarded and reassigning any of the
bugs to a new package will have an identical effect on all of the merged
reports. [...]

Merger is like equality: it is reflexive, transitive and symmetric.

Merging reports causes a note to appear on each report's logs; on the
WWW pages this includes links to the other bugs.

Merged reports are all expired simultaneously, and only when all of the
reports each separately meet the criteria for expiry.

--8<---------------cut here---------------end--------------->8---

2. block|unblock bugnumber by|with bug [ bug ... ]

--8<---------------cut here---------------start------------->8---

Use to note that one bug blocks another bug from being fixed. The first
listed bug is the one being blocked, and it is followed by the bug or
bugs that are blocking it. Use unblock to unblock a bug.

--8<---------------cut here---------------end--------------->8---

Unfortunately "merge" is not good for two or more bugs containing
"duplicated" patches.

Could "Usertags" pseudo-header be used someway to add "extended" links
with other bug reports?  Something like:

--8<---------------cut here---------------start------------->8---

Usertags: parent_<bugnum>

--8<---------------cut here---------------end--------------->8---

Anyway using this approach makes bug managing (much?) _harder_ because:

1. we have no automatic mechanism to mark the referenced bug
relationship; e.g. if I add to #100 the bug #101 as parent, bug #101
should have #100 as child, and so on for each relationship.

2. managing pseudo-headers cannot be done via server-control commands
[2]

> but bugs can be marked as blocking other bugs... this would make some
> sense in splitting patch series into multiple bugs, marking blocking
> bugs for patches that are dependent on others. But I suspect that
> would be painful in practice in many cases.

In my experience splitting bugs is often useful when managing bug
reports, because you know... ouch; but splitting is also une of the most
painful activity to do, with _every_ bug report tracking system I know
of.

AFAIU splitting bug reports in Debbugs can be done with the clone
command [2]:

--8<---------------cut here---------------start------------->8---

clone bugnumber NewID [ new IDs ... ]

The clone control command allows you to duplicate a bug report. It is useful in the case where a single report actually indicates that multiple distinct bugs have occurred. "New IDs" are negative numbers, separated by spaces, which may be used in subsequent control commands to refer to the newly duplicated bugs. A new report is generated for each new ID.

Example usage:

        clone 12345 -1 -2
        reassign -1 foo
        retitle -1 foo: foo sucks
        reassign -2 bar
        retitle -2 bar: bar sucks when used with foo
        severity -2 wishlist
        clone 123456 -3
        reassign -3 foo
        retitle -3 foo: foo sucks
        merge -1 -3

--8<---------------cut here---------------end--------------->8---

Doable but not much straightforward, it wold be much better if bugs were
splitted my submitter (but in my experience sometimes submitters are
lazy :-) )

[...]

>>> That would then make it easier to both issues to be closed if that's
>>> appropriate.
>>
>> I guess you mean that a (human) triager can find related bugs with the
>> help of such a tool.
>>
>> I doubt that related issues should be closed without human intervention,
>> false positives are very dangerous in this case.
>
> With old patches, honestly, it might bring attention back to an issue to
> close it. When I get a bug closed notification, I definitely check to
> make sure the issue is actually fixed, or did not introduce other
> surprises...

I someway agree with you, but this "let's close old bugs, just reopen it
if needed" should probably be a scheduled _amd_ coordinated effort
between Guix contributors, a sort of meta-hackaton for Guix bugs :-D

> I am not saying I think we should just blindly close old bugs with
> patches, but processes that err slightly on the side of closing old
> ones, perhaps with a message "please verify if the issue is actually
> closed, and reopen in case we have made a mistake." might be
> reasonable.

I agree, it's reasonable IMO.

IMO we should better define what does it mean "old patch" and provide an
easy way to find them; maybe a plain (is:open and tag:patch)

 https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch

is enough, but (is:open and tag:patch,moreinfo) is better:

 https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch%2Cmoreinfo

or even filtered if older than 5m, because "The bug will be closed if
the submitter doesn't provide more information in a reasonable (few
months) timeframe." [3]

We could also add a feature to have "saved searches" in mumi web and CLI
interfaces to help with this task.

Anyway, whatever we decide to do with old bugs, IMO we should improve
Guix bug reporting management by having more people (I'm going to
volunteer, as soon as I get all the right tools and knowledge)
performing triaging activity and people working on bug reports making
better use of the tools and guidelines described in [3]

...maybe we should add some paragraph on this in the Guix manual, also.

WDYT?

[...]


Thanks! Gio'



[1] I was thinking of what can be done in Request-tracker, which I know
better; it allows to track this kind of links: Depends on, Depended on
by, Parents, Children, Refers to, Referred to by

[2] https://debbugs.gnu.org/server-control.html

[3] https://debbugs.gnu.org/Developer.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Simon Tournier]

Hi,

On Mon, 11 Sep 2023 at 09:37, Giovanni Biscuolo <g@xelera.eu> wrote:

> A more useful mumi (web or CLI) query to search for duplicates would be:
>
>   is:open tag:patch subject:<package>

[...]

> is enough, but (is:open and tag:patch,moreinfo) is better:
>
>  https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Apatch%2Cmoreinfo
>
> or even filtered if older than 5m, because "The bug will be closed if
> the submitter doesn't provide more information in a reasonable (few
> months) timeframe." [3]
>
> We could also add a feature to have "saved searches" in mumi web and CLI
> interfaces to help with this task.

Well, the Mumi CLI, “guix shell mumi” and then “mumi search”, should do
act as “saved searches”.  Although it does not work for me.

Note that Debian provides some BTS tools, as pointed here,

        Debbugs CLI client (was Re: Mumi CLI client (was: How can we decrease the cognitive overhead for contributors?)))
        Simon Tournier <zimon.toutoune@gmail.com>
        Tue, 05 Sep 2023 10:58:50 +0200
        id:86msy1uhbp.fsf@gmail.com
        https://yhetil.org/guix/86msy1uhbp.fsf@gmail.com
        https://lists.gnu.org/archive/html/guix-devel/2023-09


Cheers,
simon

Re: [workflow] Triaging issues (was Automatically close bug report when a patch is committed)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

Hi Simon

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

>> is enough, but (is:open and tag:patch,moreinfo) is better:

[...]

>> We could also add a feature to have "saved searches" in mumi web and CLI
>> interfaces to help with this task.
>
> Well, the Mumi CLI, “guix shell mumi” and then “mumi search”, should do
> act as “saved searches”.

I don't understand; I mean for example having a configuration file where
we can save searches, something like:

--8<---------------cut here---------------start------------->8---

 [patches-to-be-checked]
 "is:open and tag:patch,moreinfo"

--8<---------------cut here---------------end--------------->8---

and then "mumi search --saved patches-to-be-checked"

...something like notmuch, I mean.

> Although it does not work for me.

Please help improving mumi with bug reports or patches if you have not
already done

> Note that Debian provides some BTS tools, as pointed here,

Yes I saw your message, useful thanks; we should package it and maybe
add that functions to mumi, one by one

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

> Hello,
>
> often bug reports related to patches are left open even after the
> patch/patchset have been applied, the last example is a batch of Debbugs
> manual gardening from Vagrant last Fri and Sat when he closed more than
> 20 bugs with messages similar to this one:

[...]

> IMO we need a way automatically close this kind of bug reports... or am
> I missing something?
>
> Let's avoid manual gardening as much as possible! :-)

I like the idea!

> The first thing we need is a server side git post-receive hook on
> Savannah, I've opened the sr#110928 support request:
> https://savannah.nongnu.org/support/index.php?110928

It's something that the Savannah folks would need to maintain
themselves, right?

> When I asket I though the best way would be to scan for a string like
> "Close #<bug-number>" in the commit message (the committer should add
> such a string) but probably this can be avoided: the bug can be closed
> when a patch is committed to one of the listed official brances (master,
> core-updates, etc.)

You mean by simply matching the subject?  Maybe that could work.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi,

On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> Let's avoid manual gardening as much as possible! :-)
>
> I like the idea!

I think that automatizing is not trivial.  Sadly.

There are many corner cases:

 1. series as attachement
 2. not all the series is applied
 3. commit message had been tweaked
 4. etc.

The potential issue is the number of false-positive; closing and the
submission is not applied.

Maybe patchwork already running (I think) could help, trying to
regularly rebase the branch dedicated to the submission on the top of
master, then if all is fine, somehow the two heads from the master
branch and the dedicated branch should match, and it would indicate the
patches are included and it is safe to close.  More or less. :-)

That’s said, I always find annoying to loose the track between the Git
history and the discussion that happened in the tracker.  Sometimes,
rational of some details of the implementation had been discussed in the
tracker and it is impossible to find then back.  Therefore, I would be
in favor to add ’Close #1234’ in the commit message, say the first one
from the series tracked by #1234.  Doing so, it would ease automatic
management of guix-patches.  However, it would add again some burden on
committer shoulder.

Similarly, we are already adding in the commit message something like
’Fixes <https://issues.guix.gnu.org/issue/1234>’.  And that could be
used for closing.  Again, the concern is about false-positive; closing
when it should not be.

Well, I think that automatizing is not trivial. :-)


Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>> Let's avoid manual gardening as much as possible! :-)
>>
>> I like the idea!
>
> I think that automatizing is not trivial.  Sadly.
>
> There are many corner cases:
>
>  1. series as attachement
>  2. not all the series is applied
>  3. commit message had been tweaked
>  4. etc.
>
> The potential issue is the number of false-positive; closing and the
> submission is not applied.
>
> Maybe patchwork already running (I think) could help, trying to
> regularly rebase the branch dedicated to the submission on the top of
> master, then if all is fine, somehow the two heads from the master
> branch and the dedicated branch should match, and it would indicate the
> patches are included and it is safe to close.  More or less. :-)

We could use Gerrit's commit hook that adds a unique ID as a git
trailer.  Then it should become possible to

1. Check if all items of a series have appeared in the git history
2. If so, close the associated issue if it was still open

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi,

On Wed, 06 Sep 2023 at 22:01, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> We could use Gerrit's commit hook that adds a unique ID as a git
> trailer.  Then it should become possible to

Do we still already have Gerrit running?

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Wed, 06 Sep 2023 at 22:01, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> We could use Gerrit's commit hook that adds a unique ID as a git
>> trailer.  Then it should become possible to
>
> Do we still already have Gerrit running?

I was not suggesting to host Gerrit, simply to borrow its git commit
hook, which inserts a unique ID in the commit message (as a git
trailer), which can then be used to keep track of a commit even when
it's rebased or amended.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

>> Maybe patchwork already running (I think) could help, trying to
>> regularly rebase the branch dedicated to the submission on the top of
>> master, then if all is fine, somehow the two heads from the master
>> branch and the dedicated branch should match, and it would indicate the
>> patches are included and it is safe to close.  More or less. :-)
>
> We could use Gerrit's commit hook that adds a unique ID as a git
> trailer.

Do you mean "commit-msg" hook as documented here:
https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
?

--8<---------------cut here---------------start------------->8---

The Gerrit Code Review supplied implementation of this hook is a short shell script which automatically inserts a globally unique Change-Id tag in the footer of a commit message. When present, Gerrit uses this tag to track commits across cherry-picks and rebases.

--8<---------------cut here---------------end--------------->8---

> Then it should become possible to
>
> 1. Check if all items of a series have appeared in the git history
> 2. If so, close the associated issue if it was still open

Thinking out loud:

a. each contributed patch will have a unique Change-Id, persistent
across rebases (and git commit --amend), and every new patch version
(produced during patch revision) will have the same Change-Id; this is
valid for all commits in a patch set

b. when all "Change-Id"s of patches contained in a patch set are listed
in the git history (of one of the official branches) the associated
issue can be closed

c. how do we get the issue number of a patch containing "Change-Id"? [1]

Did I miss something?

Thanks, Gio'


[1] right now how do we get the issue number of a committed patch?

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

>> We could use Gerrit's commit hook that adds a unique ID as a git
>> trailer.
>
> Do you mean "commit-msg" hook as documented here:
> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
> ?
>
>
> The Gerrit Code Review supplied implementation of this hook is a short shell script which automatically inserts a globally unique Change-Id tag in the footer of a commit message. When present, Gerrit uses this tag to track commits across cherry-picks and rebases.
>
>> Then it should become possible to
>>
>> 1. Check if all items of a series have appeared in the git history
>> 2. If so, close the associated issue if it was still open
>
> Thinking out loud:
>
> a. each contributed patch will have a unique Change-Id, persistent
> across rebases (and git commit --amend), and every new patch version
> (produced during patch revision) will have the same Change-Id; this is
> valid for all commits in a patch set

Correct.

> b. when all "Change-Id"s of patches contained in a patch set are listed
> in the git history (of one of the official branches) the associated
> issue can be closed

That was my idea.

> c. how do we get the issue number of a patch containing "Change-Id"? [1]

We'd have to search through the currently opened patches issues; I
assume using a tool like the 'mumi' command we already have could do
that.

> [1] right now how do we get the issue number of a committed patch?

There's no direct mapping.  You have to search by subject name.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> c. how do we get the issue number of a patch containing "Change-Id"? [1]
>
> We'd have to search through the currently opened patches issues; I
> assume using a tool like the 'mumi' command we already have could do
> that.

It would be fantastic if we find a way for mumi to index (via xapian)
the "Change-Id", enabling us to provide a query like this: (is:open and
change-id:<ID>).  I don'r know if this is doable by mumi alone or if it
needs Debbugs to be able to manage the new "Change-Id" attribute.

If there is enough consensus I volunteer to collect ideas and send a
feature request to the mumi and/or Debbugs devels (if we need Debbugs
patches I guess it will be a long term goal)

>> [1] right now how do we get the issue number of a committed patch?
>
> There's no direct mapping.  You have to search by subject name.

IMO a link like this is _very_ useful in helping bug tracking management
(and also for historians :-) ) and we should find a way to manage that.

Also for this reason (other that possibly automated bug closing) IMO
committers should add a "Fixes: <namespace>#<bugnum>" signature (or what
is called in Git) to each commit with an associeted bug report.

WDYT?

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
> [...]
>
>>> c. how do we get the issue number of a patch containing "Change-Id"? [1]
>>
>> We'd have to search through the currently opened patches issues; I
>> assume using a tool like the 'mumi' command we already have could do
>> that.
>
> It would be fantastic if we find a way for mumi to index (via xapian)
> the "Change-Id", enabling us to provide a query like this: (is:open and
> change-id:<ID>).  I don'r know if this is doable by mumi alone or if it
> needs Debbugs to be able to manage the new "Change-Id" attribute.
>
> If there is enough consensus I volunteer to collect ideas and send a
> feature request to the mumi and/or Debbugs devels (if we need Debbugs
> patches I guess it will be a long term goal)

I don't think any changes to Debbugs would be necessary.  Mumi is
already able to parse mail headers -- parsing a git trailer should be
just as simple.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> If there is enough consensus I volunteer to collect ideas and send a
>> feature request to the mumi and/or Debbugs devels (if we need Debbugs
>> patches I guess it will be a long term goal)
>
> I don't think any changes to Debbugs would be necessary.  Mumi is
> already able to parse mail headers -- parsing a git trailer should be
> just as simple.

You are right, I'll try to file some feature request for mumi.

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> On Wed, 06 Sep 2023 at 12:14, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>> Let's avoid manual gardening as much as possible! :-)
>>
>> I like the idea!
>
> I think that automatizing is not trivial.  Sadly.

If we "restrict" the automation to "close the bugs that are listed in
the commit message" do you think it's doable?

[...]

> The potential issue is the number of false-positive;

In the context given above, the only way to have a false positive is
that the committer give a wrong bug number, right?

> closing and the submission is not applied.

I don't understand: what do you mean by "submission"?

By design:

--8<---------------cut here---------------start------------->8---

The post-receive hook runs after the entire process is completed and can be used to update other services or notify users.

--8<---------------cut here---------------end--------------->8---
(https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)

In this case the "other service update" is "close bug <number>" and is
guaranteed to be done after the commit is applied.

> Maybe patchwork already running (I think) could help, trying to
> regularly rebase the branch dedicated to the submission on the top of
> master, then if all is fine, somehow the two heads from the master
> branch and the dedicated branch should match, and it would indicate the
> patches are included and it is safe to close.  More or less. :-)

I'm lost :-D

> That’s said, I always find annoying to loose the track between the Git
> history and the discussion that happened in the tracker.  Sometimes,
> rational of some details of the implementation had been discussed in the
> tracker and it is impossible to find then back.  Therefore, I would be
> in favor to add ’Close #1234’ in the commit message, say the first one
> from the series tracked by #1234.  Doing so, it would ease automatic
> management of guix-patches.  However, it would add again some burden on
> committer shoulder.

I completely agree that (often, seldom?) we miss traceability if we do
not link a commit with a bug report (when present) and vice versa (when
a bug report is resolved by a series of commit)

> Similarly, we are already adding in the commit message something like
> ’Fixes <https://issues.guix.gnu.org/issue/1234>’.

Is this an informal convention or is this documented somewhere?

> And that could be used for closing.

Yes, we can use al list of keywords for closing (Closes, Close, Fix,
Fixes, etc.), but for the bug report I'd use only a number, the URL
really does not matter

> Again, the concern is about false-positive; closing when it should not
> be.

Modulo a programming error in the script, the only way would be to write
the wrong bug number after the "keyword" and IMO this is similar write
the wrong bug number in the "To:" field when closing a bug via email.

> Well, I think that automatizing is not trivial. :-)

Not trivial but automatable, IMO :-D

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Gio',

On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo <g@xelera.eu> wrote:
>
> close the bugs that are listed in
> the commit message

Perhaps you'd like to see Debian's hook [1] for the Salsa web forge
(which is controversially based on Gitlab).

The regex does not work properly for more than two bugs, however, so
here is my proposed fix. [2] The merge request was closed
automatically when I began contributing to Guix.

Kind regards
Felix

[1] https://salsa.debian.org/salsa/salsa-webhook/-/blob/997412ad4b1d89fd3227d5409471bdf71abcf863/helpers/bugs.rb#L19
[2] https://salsa.debian.org/salsa/salsa-webhook/-/merge_requests/22

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

Hi,

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi Gio',
>
> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo <g@xelera.eu> wrote:
>>
>> close the bugs that are listed in
>> the commit message
>
> Perhaps you'd like to see Debian's hook [1] for the Salsa web forge
> (which is controversially based on Gitlab).
>
> The regex does not work properly for more than two bugs, however, so
> here is my proposed fix. [2] The merge request was closed
> automatically when I began contributing to Guix.

Did you see my message about integrating a commit-hook similar to what
Gerrit uses?  It produces unique ID such as:

--8<---------------cut here---------------start------------->8---
Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
--8<---------------cut here---------------end--------------->8---

at the bottom (it's a git trailer) of a commit message.  Being unique,
these could be used to match if a patch on the tracker has been merged
in the master branch.

Attached is what the hook looks like.  The random 'Change-Id' is
generated via

--8<---------------cut here---------------start------------->8---
random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
  git hash-object --stdin)
--8<---------------cut here---------------end--------------->8---


[-- Attachment #2: commit-msg --]
[-- Type: application/octet-stream, Size: 2272 bytes --]

#!/bin/sh
# From Gerrit Code Review 3.6.1
#
# Part of Gerrit Code Review (https://www.gerritcodereview.com/)
#
# Copyright (C) 2009 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

set -u

# avoid [[ which is not POSIX sh.
if test "$#" != 1 ; then
  echo "$0 requires an argument."
  exit 1
fi

if test ! -f "$1" ; then
  echo "file does not exist: $1"
  exit 1
fi

# Do not create a change id if requested
if test "false" = "$(git config --bool --get gerrit.createChangeId)" ; then
  exit 0
fi

if git rev-parse --verify HEAD >/dev/null 2>&1; then
  refhash="$(git rev-parse HEAD)"
else
  refhash="$(git hash-object -t tree /dev/null)"
fi

random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } | git hash-object --stdin)
dest="$1.tmp.${random}"

trap 'rm -f "${dest}"' EXIT

if ! git stripspace --strip-comments < "$1" > "${dest}" ; then
   echo "cannot strip comments from $1"
   exit 1
fi

if test ! -s "${dest}" ; then
  echo "file is empty: $1"
  exit 1
fi

reviewurl="$(git config --get gerrit.reviewUrl)"
if test -n "${reviewurl}" ; then
  if ! git interpret-trailers --parse < "$1" | grep -q '^Link:.*/id/I[0-9a-f]\{40\}$' ; then
    if ! git interpret-trailers \
          --trailer "Link: ${reviewurl%/}/id/I${random}" < "$1" > "${dest}" ; then
      echo "cannot insert link footer in $1"
      exit 1
    fi
  fi
else
  # Avoid the --in-place option which only appeared in Git 2.8
  # Avoid the --if-exists option which only appeared in Git 2.15
  if ! git -c trailer.ifexists=doNothing interpret-trailers \
        --trailer "Change-Id: I${random}" < "$1" > "${dest}" ; then
    echo "cannot insert change-id line in $1"
    exit 1
  fi
fi

if ! mv "${dest}" "$1" ; then
  echo "cannot mv ${dest} to $1"
  exit 1
fi

[-- Attachment #3: Type: text/plain, Size: 19 bytes --]


-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

On 2023-09-07, Maxim Cournoyer wrote:
> Felix Lechner <felix.lechner@lease-up.com> writes:
>> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo <g@xelera.eu> wrote:
>>>
>>> close the bugs that are listed in
>>> the commit message
...
> Did you see my message about integrating a commit-hook similar to what
> Gerrit uses?  It produces unique ID such as:
>
> --8<---------------cut here---------------start------------->8---
> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
> --8<---------------cut here---------------end--------------->8---
>
> at the bottom (it's a git trailer) of a commit message.  Being unique,
> these could be used to match if a patch on the tracker has been merged
> in the master branch.
>
> Attached is what the hook looks like.  The random 'Change-Id' is
> generated via
>
> --8<---------------cut here---------------start------------->8---
> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
>   git hash-object --stdin)
> --8<---------------cut here---------------end--------------->8---

That seems like it would only work if the patch was identical, as
opposed to a slightly rebased patch on top of newer patches on master?

How can you correlate Change-Id to a patch in the tracker?

Would it break git commit signatures?


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> writes:

[...]

>> Did you see my message about integrating a commit-hook similar to what
>> Gerrit uses?  It produces unique ID such as:
>>
>> --8<---------------cut here---------------start------------->8---
>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
>> --8<---------------cut here---------------end--------------->8---
>>
>> at the bottom (it's a git trailer) of a commit message.  Being unique,
>> these could be used to match if a patch on the tracker has been merged
>> in the master branch.
>>
>> Attached is what the hook looks like.  The random 'Change-Id' is
>> generated via
>>
>> --8<---------------cut here---------------start------------->8---
>> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
>>   git hash-object --stdin)
>> --8<---------------cut here---------------end--------------->8---
>
> That seems like it would only work if the patch was identical, as
> opposed to a slightly rebased patch on top of newer patches on master?
>
> How can you correlate Change-Id to a patch in the tracker?

The Change-Id stays the same unless you manually edit it out of your
commit message when amending / rebasing, so the commit hash may change
while the Change-Id stays the same.  So you can rebase your feature
branch on master and share a v2, whose existing commits will have the
same Change-Ids (newly added commits would get their own Change-Id
trailer).

> Would it break git commit signatures?

It doesn't impact git commit signatures.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi Maxim,

On Sat, 09 Sep 2023 at 19:50, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>>> --8<---------------cut here---------------start------------->8---
>>> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
>>>   git hash-object --stdin)
>>> --8<---------------cut here---------------end--------------->8---
>>
>> That seems like it would only work if the patch was identical, as
>> opposed to a slightly rebased patch on top of newer patches on master?
>>
>> How can you correlate Change-Id to a patch in the tracker?
>
> The Change-Id stays the same unless you manually edit it out of your
> commit message when amending / rebasing, so the commit hash may change
> while the Change-Id stays the same.  So you can rebase your feature
> branch on master and share a v2, whose existing commits will have the
> same Change-Ids (newly added commits would get their own Change-Id
> trailer).

I am sorry if I am slow but I do not understand.

--8<---------------cut here---------------start------------->8---
$ git var GIT_COMMITTER_IDENT
Simon Tournier <zimon.toutoune@gmail.com> 1694428674 +0200
$ git var GIT_COMMITTER_IDENT
Simon Tournier <zimon.toutoune@gmail.com> 1694428800 +0200
--8<---------------cut here---------------end--------------->8---

Therefore this Change-Id can be different for the same series, depending
when I am locally committing.  No?

And sorry if I am slow but I am also missing your answer about “How can
you correlate Change-Id to a patch in the tracker?”.  How is this
Change-Id correlated to the Debbugs number?


Let take an example. :-) Assume Change-Id was used for your submission
bug#65280 about Qt.  It reads many patches and we have:

        02/59
        1717c8a233b7fda3a10aabc061168c71317f883e
        AuthorDate: Fri Aug 11 15:26:14 2023 -0400

        59/59
        0a77b869322274030c4c0e8315ddea802da44c92
        AuthorDate: Tue Aug 15 16:20:10 2023 -0400

From my understanding,

 1. GIT_COMMITTER_IDENT depends on time so these two commits would have
a different Change-Id, no?

 2. How is Change-Id linked to #65280?

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> On Sat, 09 Sep 2023 at 19:50, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>>> --8<---------------cut here---------------start------------->8---
>>>> random=$({ git var GIT_COMMITTER_IDENT ; echo "$refhash" ; cat "$1"; } |
>>>>   git hash-object --stdin)
>>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> That seems like it would only work if the patch was identical, as
>>> opposed to a slightly rebased patch on top of newer patches on master?
>>>
>>> How can you correlate Change-Id to a patch in the tracker?
>>
>> The Change-Id stays the same unless you manually edit it out of your
>> commit message when amending / rebasing, so the commit hash may change
>> while the Change-Id stays the same.  So you can rebase your feature
>> branch on master and share a v2, whose existing commits will have the
>> same Change-Ids (newly added commits would get their own Change-Id
>> trailer).
>
> I am sorry if I am slow but I do not understand.
>
> $ git var GIT_COMMITTER_IDENT
> Simon Tournier <zimon.toutoune@gmail.com> 1694428674 +0200
> $ git var GIT_COMMITTER_IDENT
> Simon Tournier <zimon.toutoune@gmail.com> 1694428800 +0200
>
> Therefore this Change-Id can be different for the same series, depending
> when I am locally committing.  No?
>
> And sorry if I am slow but I am also missing your answer about “How can
> you correlate Change-Id to a patch in the tracker?”.  How is this
> Change-Id correlated to the Debbugs number?

The commit hook job is simple: generate a unique ID.  The magic is that
it only adds it *once* to a commit message; if it finds the 'Change-Id:'
line already present in it, it won't refresh its value or add a new one.
So it's immutable once added, preserved in the Git commit message
itself.

> Let take an example. :-) Assume Change-Id was used for your submission
> bug#65280 about Qt.  It reads many patches and we have:
>
>         02/59
>         1717c8a233b7fda3a10aabc061168c71317f883e
>         AuthorDate: Fri Aug 11 15:26:14 2023 -0400
>
>         59/59
>         0a77b869322274030c4c0e8315ddea802da44c92
>         AuthorDate: Tue Aug 15 16:20:10 2023 -0400
>
> From my understanding,
>
>  1. GIT_COMMITTER_IDENT depends on time so these two commits would have
> a different Change-Id, no?

Correct.  The commit hook adds a unique ID *per* commit.

>  2. How is Change-Id linked to #65280?

Each patch submission ("issue") can have one or multiple commits.  We'd
know for sure the series was merged (and thus can be closed) when the
set of 'Change-Id's its commits contains have all appeared in the master
branch.  The mapping of Debbugs ID <-> set(change-ids) would need to be
established by an external tool such as Mumi (which I think is in a good
position to do so).

I hope that helps!

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi Maxim,

Thanks for the explanations.

On Mon, 11 Sept 2023 at 15:47, Maxim Cournoyer
<maxim.cournoyer@gmail.com> wrote:

> >  2. How is Change-Id linked to #65280?
>
> Each patch submission ("issue") can have one or multiple commits.  We'd
> know for sure the series was merged (and thus can be closed) when the
> set of 'Change-Id's its commits contains have all appeared in the master
> branch.  The mapping of Debbugs ID <-> set(change-ids) would need to be
> established by an external tool such as Mumi (which I think is in a good
> position to do so).

I think it is not straightforward to maintain such mapping.  Because
Mumi needs to implement a way to extract patches; and there is many
corner-cases.

For instance, I am already using a pre-commit hook, how would it work
in this case?

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Maxim,
>
> Thanks for the explanations.
>
> On Mon, 11 Sept 2023 at 15:47, Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
>
>> >  2. How is Change-Id linked to #65280?
>>
>> Each patch submission ("issue") can have one or multiple commits.  We'd
>> know for sure the series was merged (and thus can be closed) when the
>> set of 'Change-Id's its commits contains have all appeared in the master
>> branch.  The mapping of Debbugs ID <-> set(change-ids) would need to be
>> established by an external tool such as Mumi (which I think is in a good
>> position to do so).
>
> I think it is not straightforward to maintain such mapping.  Because
> Mumi needs to implement a way to extract patches; and there is many
> corner-cases.

It wouldn't need to cover *all* cover cases to be useful; even if it
only worked for 'git send-email' series, it'd still be useful.

> For instance, I am already using a pre-commit hook, how would it work
> in this case?

I didn't think about this case, but if it's common, we could have our
own default pre-commit hook include an escape hatch (e.g., run all
scripts under ~/.config/git/hooks/pre-commit.d) and document that, so
that users could still plug their very own pre-commit hooks.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

On 2023-09-09, Maxim Cournoyer wrote:
> Vagrant Cascadian <vagrant@debian.org> writes:
>>> Did you see my message about integrating a commit-hook similar to what
>>> Gerrit uses?  It produces unique ID such as:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
>>> --8<---------------cut here---------------end--------------->8---
...
>> That seems like it would only work if the patch was identical, as
>> opposed to a slightly rebased patch on top of newer patches on master?
>>
>> How can you correlate Change-Id to a patch in the tracker?
>
> The Change-Id stays the same unless you manually edit it out of your
> commit message when amending / rebasing, so the commit hash may change
> while the Change-Id stays the same.  So you can rebase your feature
> branch on master and share a v2, whose existing commits will have the
> same Change-Ids (newly added commits would get their own Change-Id
> trailer).

Ok, that makes some sense.

Although the majority of bugs in the cleanup work I did were actually
filed by someone else entirely... so the Change-Id will not help with
those. Not a reason not to implement it, but not consistent with some of
the triggers of this thread. :)

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi,

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2023-09-09, Maxim Cournoyer wrote:
>> Vagrant Cascadian <vagrant@debian.org> writes:
>>>> Did you see my message about integrating a commit-hook similar to what
>>>> Gerrit uses?  It produces unique ID such as:
>>>>
>>>> --8<---------------cut here---------------start------------->8---
>>>> Change-Id: I9b86781869d80eda347659f0c009b8dfe09bdfd0
>>>> --8<---------------cut here---------------end--------------->8---
> ...
>>> That seems like it would only work if the patch was identical, as
>>> opposed to a slightly rebased patch on top of newer patches on master?
>>>
>>> How can you correlate Change-Id to a patch in the tracker?
>>
>> The Change-Id stays the same unless you manually edit it out of your
>> commit message when amending / rebasing, so the commit hash may change
>> while the Change-Id stays the same.  So you can rebase your feature
>> branch on master and share a v2, whose existing commits will have the
>> same Change-Ids (newly added commits would get their own Change-Id
>> trailer).
>
> Ok, that makes some sense.
>
> Although the majority of bugs in the cleanup work I did were actually
> filed by someone else entirely... so the Change-Id will not help with
> those. Not a reason not to implement it, but not consistent with some of
> the triggers of this thread. :)

I doubt the Change-Id idea would help much closing *bugs* on the
bug-guix tracker, but I'd expect it to be useful to close already merged
(but forgotten on the guix-patches tracker) *patches*.

The Change-Ids would be added automatically without the user having to
install anything, so from the time it's deployed we'd have a means to
identify which patch series were all merged.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]

On 2023-09-13, Maxim Cournoyer wrote:
> Vagrant Cascadian <vagrant@debian.org> writes:
>> On 2023-09-09, Maxim Cournoyer wrote:
>>> The Change-Id stays the same unless you manually edit it out of your
>>> commit message when amending / rebasing, so the commit hash may change
>>> while the Change-Id stays the same.  So you can rebase your feature
>>> branch on master and share a v2, whose existing commits will have the
>>> same Change-Ids (newly added commits would get their own Change-Id
>>> trailer).
>>
>> Ok, that makes some sense.
>>
>> Although the majority of bugs in the cleanup work I did were actually
>> filed by someone else entirely... so the Change-Id will not help with
>> those. Not a reason not to implement it, but not consistent with some of
>> the triggers of this thread. :)
>
> I doubt the Change-Id idea would help much closing *bugs* on the
> bug-guix tracker, but I'd expect it to be useful to close already merged
> (but forgotten on the guix-patches tracker) *patches*.

Well, all of the "bugs" I was referring to were submitted patches
tracked at debbugs.gnu.org via the issues.guix.gnu.org
frontend... weather they were submitted via guix-patches@ or bug-guix@
or NNN@debbugs.gnu.org... :)

They are all "bugs" to me, though "issues" seems a bit more neutral in
tone and I like it better, but new packages or package updates are just
generally wishlist bugs/issues and not inherrently something broken,
though they may sometimes fix things or be related to fixes...


> The Change-Ids would be added automatically without the user having to
> install anything, so from the time it's deployed we'd have a means to
> identify which patch series were all merged.

Well, they would still have to install the commit hook, or did I miss
something?


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hello,

Le 14 septembre 2023 12:30:41 GMT-04:00, Vagrant Cascadian <vagrant@debian.org> a écrit :

[…]

>> I doubt the Change-Id idea would help much closing *bugs* on the
>> bug-guix tracker, but I'd expect it to be useful to close already merged
>> (but forgotten on the guix-patches tracker) *patches*.
>
>Well, all of the "bugs" I was referring to were submitted patches
>tracked at debbugs.gnu.org via the issues.guix.gnu.org
>frontend... weather they were submitted via guix-patches@ or bug-guix@
>or NNN@debbugs.gnu.org... :)
>
>They are all "bugs" to me, though "issues" seems a bit more neutral in
>tone and I like it better, but new packages or package updates are just
>generally wishlist bugs/issues and not inherrently something broken,
>though they may sometimes fix things or be related to fixes...

Let's call these patch series to avoid confusion :-)

>
>> The Change-Ids would be added automatically without the user having to
>> install anything, so from the time it's deployed we'd have a means to
>> identify which patch series were all merged.
>
>Well, they would still have to install the commit hook, or did I miss
>something?

Yes! Hooks can be configured upon building the Guix checkout, the same way its now done for our pre-push hook :-)

Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Hi Felix,

Felix Lechner <felix.lechner@lease-up.com> writes:

> Hi Gio',
>
> On Thu, Sep 7, 2023 at 4:08 AM Giovanni Biscuolo <g@xelera.eu> wrote:
>>
>> close the bugs that are listed in
>> the commit message
>
> Perhaps you'd like to see Debian's hook [1] for the Salsa web forge
> (which is controversially based on Gitlab).

[...]

Thank you for the reference, it'll be an useful example.

A ruby interpreter dependency in this case probably is too much, but we
can always rewrite that :-)

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]

Hi Maxim and Ludovic,

I'm including you, Ludovic, becaus in the past you requested a similar
git hook installation for Guix and maybe you have more info

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Giovanni Biscuolo <g@xelera.eu> writes:

[...]

OK, I really found the wrong examples as Christopher pointed out, but my
proposal still holds valid :-D

>> IMO we need a way automatically close this kind of bug reports... or am
>> I missing something?
>>
>> Let's avoid manual gardening as much as possible! :-)
>
> I like the idea!

Fine, let's try to do it!

>> The first thing we need is a server side git post-receive hook on
>> Savannah, I've opened the sr#110928 support request:
>> https://savannah.nongnu.org/support/index.php?110928
>
> It's something that the Savannah folks would need to maintain
> themselves, right?

Forgot to mention that I'm pretty sure a post-receive server side hook
is already running (and maintained) for our guix.git repo on Savannah,
it's the one that sends notifications to guix-commits mailing list
https://lists.gnu.org/mailman/listinfo/guix-commits

Maybe that server side hook is common to all Savannah hosted projects,
but in this case it sould be configurable per-project since the "From:"
and "To:" email headers must be project related.

...or that post-receive hook has been installed the Savannah admin of
the Guix project?

I don't know what is the policy for "custom" server side web hooks: for
sure Someone™ with ssh access to /srv/git/guix.git/hooks/ should
/install/ such a script.

I've not found any reference to "per project" git hooks in the Savannah
documentation
(https://duckduckgo.com/?q=git+hook+site%3Ahttps%3A%2F%2Fsavannah.gnu.org%2Fmaintenance%2FFrontPage%2F&ia=web)

I have found many support request mentioning git hooks:
https://savannah.gnu.org/search/?words1=git+hook&type_of_search=support&Search=Search&exact=1#options

In particular, this support threads:

- sr #110614: auctex-diffs emails should be in the same format as emacs-diffs
https://savannah.nongnu.org/support/?func=detailitem&item_id=110614

- sr #110594: git push returns "hints" about ignored hooks
https://savannah.nongnu.org/support/?func=detailitem&item_id=110594

- sr #110482: Install irker hooks in poke.git
https://savannah.nongnu.org/support/?func=detailitem&item_id=110482

- sr #109104: Add Git 'update' hook for Guix repositories
https://savannah.nongnu.org/support/?func=detailitem&item_id=109104

Makes me believe that server-side hooks are something that must be
installed per-project by Savannah sysadmins

>> When I asket I though the best way would be to scan for a string like
>> "Close #<bug-number>" in the commit message (the committer should add
>> such a string) but probably this can be avoided: the bug can be closed
>> when a patch is committed to one of the listed official brances (master,
>> core-updates, etc.)
>
> You mean by simply matching the subject?  Maybe that could work.

Thinking twice maybe it's better to add a "Close: #<bug>" to the commit
message.

Now... let's find (or develop) such a post-receive hook!

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]

Hi,

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

>>> The first thing we need is a server side git post-receive hook on
>>> Savannah, I've opened the sr#110928 support request:
>>> https://savannah.nongnu.org/support/index.php?110928
>>
>> It's something that the Savannah folks would need to maintain
>> themselves, right?
>
> Forgot to mention that I'm pretty sure a post-receive server side hook
> is already running (and maintained) for our guix.git repo on Savannah,
> it's the one that sends notifications to guix-commits mailing list
> https://lists.gnu.org/mailman/listinfo/guix-commits

Regarding server side git hooks, I forgot to mention that on 2023-08-31
a new commit-hook is available on Savannah (installation must be
requested per-project):

git post-receive UDP syndication
https://savannah.gnu.org/news/?id=10508

--8<---------------cut here---------------start------------->8---

A new commit-hook is available to install for git repositories that will send a single Datagram via UDP after each successful commit.  This can be useful for continuous integration (CI) schemes and elsewise when a push driven model is prefered to (e.g) regularly repolling upstream when changes may or may not have occured. 

To request installation please open a ticket with the Savannah Administration project:

[...]

The (sh, GPLv3+) post-receive script source, detail on how the Datagram is structured, and example "receiver" scripts (in perl) can be found here:

  https://git.sr.ht/~mplscorwin/git-udp-syndicate

--8<---------------cut here---------------end--------------->8---

Maybe this hook is useful for comminication with the QA service(s).

Maybe this hook could be adapted to close bugs instead of send an UDP
datagram.

Happy hacking! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]


Giovanni Biscuolo <g@xelera.eu> writes:

> [[PGP Signed Part:Signature made by expired key D37D0EA7CECC3912 Giovanni Biscuolo (Xelera) <g@xelera.eu>]]
> Hi,
>
> Giovanni Biscuolo <g@xelera.eu> writes:
>
> [...]
>
>>>> The first thing we need is a server side git post-receive hook on
>>>> Savannah, I've opened the sr#110928 support request:
>>>> https://savannah.nongnu.org/support/index.php?110928
>>>
>>> It's something that the Savannah folks would need to maintain
>>> themselves, right?
>>
>> Forgot to mention that I'm pretty sure a post-receive server side hook
>> is already running (and maintained) for our guix.git repo on Savannah,
>> it's the one that sends notifications to guix-commits mailing list
>> https://lists.gnu.org/mailman/listinfo/guix-commits
>
> Regarding server side git hooks, I forgot to mention that on 2023-08-31
> a new commit-hook is available on Savannah (installation must be
> requested per-project):
>
> git post-receive UDP syndication
> https://savannah.gnu.org/news/?id=10508
>
>
> A new commit-hook is available to install for git repositories that will send a single Datagram via UDP after each successful commit.  This can be useful for continuous integration (CI) schemes and elsewise when a push driven model is prefered to (e.g) regularly repolling upstream when changes may or may not have occured. 
>
> To request installation please open a ticket with the Savannah Administration project:
>
> [...]
>
> The (sh, GPLv3+) post-receive script source, detail on how the Datagram is structured, and example "receiver" scripts (in perl) can be found here:
>
>   https://git.sr.ht/~mplscorwin/git-udp-syndicate
>
> Maybe this hook is useful for comminication with the QA service(s).

Not QA directly, but the Guix Data Service would benefit from supporting
this, as that could supplement or replace listening for emails to
determine when new revisions have been pushed.

I've added an entry to the TODO list in the README.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]

On 2023-09-07, Giovanni Biscuolo wrote:
> Hi Maxim and Ludovic,
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>> Giovanni Biscuolo <g@xelera.eu> writes:
..
>>> When I asket I though the best way would be to scan for a string like
>>> "Close #<bug-number>" in the commit message (the committer should add
>>> such a string) but probably this can be avoided: the bug can be closed
>>> when a patch is committed to one of the listed official brances (master,
>>> core-updates, etc.)
>>
>> You mean by simply matching the subject?  Maybe that could work.
>
> Thinking twice maybe it's better to add a "Close: #<bug>" to the commit
> message.

Sooooo... I maintain the guix package in Debian, and want to make sure
that whatever bug-closing indicator guix upstream uses, does not end up
triggering when I push new upstream versions to salsa.debian.org ... and
start incorrectly marking incorrect bug numbers on bugs.debian.org that
were meant for debbugs.gnu.org.

Currently that is:

  https://salsa.debian.org/salsa/salsa-webhook/-/blob/997412ad4b1d89fd3227d5409471bdf71abcf863/helpers/bugs.rb#L19

  SCAN_BUGS = /Closes:\s+(?:Bug)?#(?:(\d{4,8})\b)(?:,?\s*(?:Bug)?#(?:(\d{4,8})\b))*/i

"Close: #<bug>" is a bit nervously close; I could see a stray typo of an
extra "s" triggering the occasional very annoying problem.

I am much more comfortable with the "Fixes" convention of:

  Fixes: https://issues.guix.gnu.org/NNN


So, while I cannot insist here... I can plead a bit... and a namespaced
URL is kind of better in some ways anyways. :)


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Vagrant!

On Thu, Sep 7, 2023 at 9:13 AM Vagrant Cascadian <vagrant@debian.org> wrote:
>
> Sooooo... I maintain the guix package in Debian, and want to make sure
> that whatever bug-closing indicator guix upstream uses, does not end up
> triggering when I push new upstream versions to salsa.debian.org ... and
> start incorrectly marking incorrect bug numbers on bugs.debian.org that
> were meant for debbugs.gnu.org.

Good catch! Surely, many downstream maintainers face that issue.

It's been a while since I hacked on Salsa. Regardless of the outcome
here, can you disable the standard webhook and add your own?

Kind regards
Felix

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
> I am much more comfortable with the "Fixes" convention of:
> 
>   Fixes: https://issues.guix.gnu.org/NNN
I like the idea, but we should also consider the bugs.gnu.org address
here as well as the convention of putting it into angular brackets.  In
fact, I might even prefer it if the convention was
  Fixes: Bug description <link>
where bug description is a (possibly empty) name for the bug such as
"Emacs hangs when I press a key" or something.


As for when to send it, remember that we already send a bunch of mails
to guix-commits@gnu.org as our commit hook?  I think it shouldn't be
too hard to search for the fixes line and send it to debbugs control.

WDYT?

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

Hi!

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>> I am much more comfortable with the "Fixes" convention of:
>> 
>>   Fixes: https://issues.guix.gnu.org/NNN

OK, I understand Vagrant's concerns: we need a _namespaced_ URI, but
there is no need that URI is the URL of **one** of our current web
interfaces, why not the other one? ;-)

IMO this is an implementation detail we can easily fix once we find a
consensus on introducing this requirement in the Guix guidelines on
committing.

> I like the idea, but we should also consider the bugs.gnu.org address
> here as well as the convention of putting it into angular brackets.  In
> fact, I might even prefer it if the convention was
>   Fixes: Bug description <link>
> where bug description is a (possibly empty) name for the bug such as
> "Emacs hangs when I press a key" or something.

I agree that an (optional) bug description might be useful (could also
be automatically added by some cool etc/committer.scm funcion?)

I propose:

 Fixes: [optional bug description] <namespace:#bug-number>

where namespace is the package name, in our case "guix"; fo example:

 Fixes: Emacs hangs when I press a key <guix:#123456789>

WDYT?

> As for when to send it, remember that we already send a bunch of mails
> to guix-commits@gnu.org as our commit hook?  I think it shouldn't be
> too hard to search for the fixes line and send it to debbugs control.

Do you please know whare to get that scripts, just to have a quick look
and understand how we could eventually add a function for automatic bug
closing?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

> Hi!
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
>> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>>> I am much more comfortable with the "Fixes" convention of:
>>> 
>>>   Fixes: https://issues.guix.gnu.org/NNN
>
> OK, I understand Vagrant's concerns: we need a _namespaced_ URI, but
> there is no need that URI is the URL of **one** of our current web
> interfaces, why not the other one? ;-)

> IMO this is an implementation detail we can easily fix once we find a
> consensus on introducing this requirement in the Guix guidelines on
> committing.

Agreed.  I think a simple git trailer such as:

--8<---------------cut here---------------start------------->8---
Fixes: bug#65738 (java-ts-mode tests)
--8<---------------cut here---------------end--------------->8---

Would be nice, where bug#NNNNN is already known and shown as a URL in
Emacs when the bug-reference minor mode is enabled (it's the case
working with Magit), so bugs can be consulted easily without any context
switching.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Am Montag, dem 11.09.2023 um 10:09 +0200 schrieb Giovanni Biscuolo:
> Hi!
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
> > Cascadian:
> > > I am much more comfortable with the "Fixes" convention of:
> > > 
> > >   Fixes: https://issues.guix.gnu.org/NNN
> 
> OK, I understand Vagrant's concerns: we need a _namespaced_ URI, but
> there is no need that URI is the URL of **one** of our current web
> interfaces, why not the other one? ;-)
Well, I like cool URLs, but maybe that's a nice benefit here.

> 
> I propose:
> 
>  Fixes: [optional bug description] <namespace:#bug-number>
> 
> where namespace is the package name, in our case "guix"; fo example:
> 
>  Fixes: Emacs hangs when I press a key <guix:#123456789>
Maybe make that bug-guix so that it matches with the mailing list name,
though we also need a wording for when a patch is not a bug, e.g. a
simple package upgrade.

WDYT about the following
  Applies: [patch] <namespace:#bug-number>
  Closes: [patch] <namespace:#bug-number>
  Resolves: [patch] <namespace:#bug-number>
  Done: [patch] <namespace:#bug-number>

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

> Maybe make that bug-guix so that it matches with the mailing list name,
> though we also need a wording for when a patch is not a bug, e.g. a
> simple package upgrade.
>
> WDYT about the following
>   Applies: [patch] <namespace:#bug-number>
>   Closes: [patch] <namespace:#bug-number>
>   Resolves: [patch] <namespace:#bug-number>
>   Done: [patch] <namespace:#bug-number>

I don't follow; why do we need 'Applies' ?  Why do we need a
'namespace'.  Are these things the user would need to manually know and
enter themselves in their commit messages?

If so, that's adding rather than reducing friction, and I'm not sure
it'd gain much traction.  The way I see it, it needs to happen
automatically.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer:
> Hi,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> [...]
> 
> > Maybe make that bug-guix so that it matches with the mailing list
> > name,
> > though we also need a wording for when a patch is not a bug, e.g. a
> > simple package upgrade.
> > 
> > WDYT about the following
> >   Applies: [patch] <namespace:#bug-number>
> >   Closes: [patch] <namespace:#bug-number>
> >   Resolves: [patch] <namespace:#bug-number>
> >   Done: [patch] <namespace:#bug-number>
> 
> I don't follow; why do we need 'Applies' ?  Why do we need a
> 'namespace'.  Are these things the user would need to manually know
> and enter themselves in their commit messages?
I'm just asking which wording you prefer.  For the tracker, they'd mean
the same as "Fixes", but fixes imho sounds like a bug, which "Update
Emacs to 29.2" isn't.  Thus, something with a more neutral meaning like
"Resolves" might apply better here.

> If so, that's adding rather than reducing friction, and I'm not sure
> it'd gain much traction.  The way I see it, it needs to happen
> automatically.
I mean, the way I imagine is that you type this as part of your message
and then debbugs would do the work of closing the bug.  In short, "git
push" saves you the work of writing a mail because there's a hook for
it.

As for the namespace: you would have to type it on your own – hence why
I prefer the URL approach as that can more easily be copied.  I think
we had a discussion that we don't want to involuntarily trigger stuff
elsewhere, hence why we're marking our own bugs as our own.

Cheers

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 11.09.2023 um 14:36 -0400 schrieb Maxim Cournoyer:
>> Hi,
>>
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>>
>> [...]
>>
>> > Maybe make that bug-guix so that it matches with the mailing list
>> > name,
>> > though we also need a wording for when a patch is not a bug, e.g. a
>> > simple package upgrade.
>> >
>> > WDYT about the following
>> >   Applies: [patch] <namespace:#bug-number>
>> >   Closes: [patch] <namespace:#bug-number>
>> >   Resolves: [patch] <namespace:#bug-number>
>> >   Done: [patch] <namespace:#bug-number>
>>
>> I don't follow; why do we need 'Applies' ?  Why do we need a
>> 'namespace'.  Are these things the user would need to manually know
>> and enter themselves in their commit messages?
> I'm just asking which wording you prefer.  For the tracker, they'd mean
> the same as "Fixes", but fixes imho sounds like a bug, which "Update
> Emacs to 29.2" isn't.  Thus, something with a more neutral meaning like
> "Resolves" might apply better here.

If we choose this simple scheme where the top commit of a series can be
annotated with Debbugs control commands, I'd opt for:

--8<---------------cut here---------------start------------->8---
Applies: #bug-number
--8<---------------cut here---------------end--------------->8---

I'm not sure what [patch] or namespace add (is it for a fancy URL?), so
I'd drop them.

>> If so, that's adding rather than reducing friction, and I'm not sure
>> it'd gain much traction.  The way I see it, it needs to happen
>> automatically.
> I mean, the way I imagine is that you type this as part of your message
> and then debbugs would do the work of closing the bug.  In short, "git
> push" saves you the work of writing a mail because there's a hook for
> it.

Perhaps both approach could be combined.  I still see value in a general
scheme to automate closing applied series that linger on in Debbugs.

[0]  https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00138.html

Change-Ids would also add the benefit that any commit found in Git could
easily be traced back to their submission on the guix-patches or guix
trackers or vice-versa (git log --grep='Change-Id=XXXX'), as noted by
Giovanni.

The process could go like this:

1. commits of a series pushed to master
2. Savannah sends datagram to a remote machine to trigger the
post-commit job, with the newly pushed commits 'Change-Id' values (a
list of them).
3. The remote machine runs something like 'mumi close-issues [change-id-1
change-id-2 ...]'

In case it couldn't close an issue, it could send a notification to the
submitter: "hey, I've seen some commits of series NNNN landing to
master, but not all of the commits appears to have been pushed, please
check"

What mumi does internally would be something like:

a) Check in its database to establish the Change-Id <-> Issue # relation,
if any.

b) For each issue, if issue #'s known Change-Ids are all covered by the
change-ids in the arguments, close it

This is a bit more complex (UDP datagram, mumi database) but it does
useful work for us committers (instead of simply changing the way we
currently do the work).

When not provided any change-id argument, 'mumi close-issues' could run
the process on its complete list of issues.

Since it'd be transparent and requires nothing from a committer, it'd
provide value without having to document yet more processes.

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 10861 bytes --]

Hi Maxim and Liliana,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

>>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

>>> > WDYT about the following
>>> >   Applies: [patch] <namespace:#bug-number>
>>> >   Closes: [patch] <namespace:#bug-number>
>>> >   Resolves: [patch] <namespace:#bug-number>
>>> >   Done: [patch] <namespace:#bug-number>

[...]

>> I'm just asking which wording you prefer.  For the tracker, they'd mean
>> the same as "Fixes", but fixes imho sounds like a bug,

But we actually have to close/fix/resolve/mark-as-done a bug
(report), no?  :-D

>> which "Update Emacs to 29.2" isn't.  Thus, something with a more
>> neutral meaning like "Resolves" might apply better here.

IMO this is just an implementation "detail", although an important one.

Keywords are _just_ labels, the semantics is defined elsewhere (even
when it's "implicit") and the semantics establish the behaviour we
intend to implement via our algorithm we use to (re)program the git hook
in order to automatically close a bug report when the committer pushes
all needed patches in a bug of class "PATCH" or find it's appropriate to
mark it as done when committing another class of bug (sorry for being so
convoluted :-O )

Anyway, I agree with Liliana that having more keyworks will help humans
better capture (and remember) the implied semantics (that we should
definitely document, anyway); for this reason my proposal is to accept
all this _lowercased_ keywords (all followed by a ":" with NO spaces in
between): fix, fixes, close, closes, resolve, resolves, do, done.

This means that a committer can write for example "RESOLVES:" and the
meaning is the same as "do:" or "Fixes:".

IMO the "superficial" semantic of the keyword apply/applies is ambiguos:
does this mean:

1. the commit is part of a series of patches tracked in #bug-num thus
the rest of the series is still to be worked upon (please don't close
the bug report)

or

2. the commit is the last one of all the patches tracked in #bug-num
thus no other patch is left to be committed (please close the bug
report)

WDYT?

> If we choose this simple scheme where the top commit of a series can be
> annotated with Debbugs control commands, I'd opt for:
>
> --8<---------------cut here---------------start------------->8---
> Applies: #bug-number
> --8<---------------cut here---------------end--------------->8---

Uh I think I get it: you mean we could use a keyword in the commit
message to allow the committer to effectively link a commit to a
#bug-number, right?

This is something we sould consider, but it's another topic: how to
effectively link commits to #bug-num (I guess we already talked about
this in some other thread)

> I'm not sure what [patch] or namespace add (is it for a fancy URL?), so
> I'd drop them.

I'll try to recap, sorry for the repetitions!

Namespace has been assumed as part of the proposed URI to try address
Vagrant's concerns [1]:

--8<---------------cut here---------------start------------->8---

   Sooooo... I maintain the guix package in Debian, and want to make sure
   that whatever bug-closing indicator guix upstream uses, does not end up
   triggering when I push new upstream versions to salsa.debian.org ... and
   start incorrectly marking incorrect bug numbers on bugs.debian.org that
   were meant for debbugs.gnu.org.

--8<---------------cut here---------------end--------------->8---

Here we have a use case in which a Guix committer is also committer of
other projects using a similar git hook, with (a subset of) the _very
same_ keywords we choose for our hook.

That's why I proposed [2] a namespaced URI, possibly not including the
URL:

--8<---------------cut here---------------start------------->8---

Fixes: [optional bug description] <namespace:#bug-number>

--8<---------------cut here---------------end--------------->8---
(here, URI is <namespace>:#<bug-number>)

...but then you, Maxim, suggested [3] this form:

--8<---------------cut here---------------start------------->8---
Fixes: bug#65738 (java-ts-mode tests)
--8<---------------cut here---------------end--------------->8---
(here, URI is bug#<bug-number)

That is nice since it is shown as a URL in Emacs with the minor mode
bug-reference-mode enabled, so bugs can be consulted easily (by Emacs
users); this is documented in Emacs manual "29.7 Bug Reference" [4].

I (still?!?) ignored that Emacs feature, wow! :-D (Note to self: improve
your emacs-foo)

Given all this, I propose this generalized form:

--8<---------------cut here---------------start------------->8---

<keyword>: bug#<bug-num>@<namespace> (<bug title>)

--8<---------------cut here---------------end--------------->8---

I'm an Emacs user also and when I enable bug-reference-mode in this
message buffer I still see the "bug#<num>" part of the string:

bug#65738@guix

is shown as an URL (pointing nowhere since I still did not configure my
Emacs properly)

Maxim: do you think my proposal could work also for Emacs
bug-reference-mode "machinery"?

And everyone: do you think that the above proposal for an "Emacs
compatible" namestaced URI could be fine for all considered usercases?

>>> If so, that's adding rather than reducing friction, and I'm not sure
>>> it'd gain much traction.  The way I see it, it needs to happen
>>> automatically.
>> I mean, the way I imagine is that you type this as part of your message
>> and then debbugs would do the work of closing the bug.  In short, "git
>> push" saves you the work of writing a mail because there's a hook for
>> it.

I guess all of us are looking for this very same thing: a server side
web hook that automatically closes bugs (via email) when committers
pushing "instructs" it to do so.

The automatic email message will be sent to our "bug control and
manipulation server" [5], with this header:

--8<---------------cut here---------------start------------->8---

From: GNU Guix git hook <noreply@gnu.org>
Reply-To: <Committer> <<committer-email>>
To: control@debbugs.gnu.org

--8<---------------cut here---------------end--------------->8---

and this body:

--8<---------------cut here---------------start------------->8---

package guix
close <bug-number> [<commit-hash>]
quit

--8<---------------cut here---------------end--------------->8---

The "Reply-To:" (I still have to test it) will receive a notification
from the control server with the results of the commands, including
errors if any.

Then, the documentation for the close command [5] states:

--8<---------------cut here---------------start------------->8---

A notification is sent to the user who reported the bug, but (in
contrast to mailing bugnumber-done) the text of the mail which caused
the bug to be closed is not included in that notification.

If you supply a fixed-version, the bug tracking system will note that
the bug was fixed in that version of the package.

--8<---------------cut here---------------end--------------->8---

Last but not least, the very fact that "GNU Guix git hook" have closed
the bug report is tracked and showed in the bug report history, as any
other action made via email using the Debbugs control server.

WDYT?

> Perhaps both approach could be combined.  I still see value in a general
> scheme to automate closing applied series that linger on in Debbugs.
>
> [0]
> https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00138.html

Yes I agree, they are two complementary approaches: I think there are
usecases (many? few?) in which committer pushing to the repo are
actually solving an issue in some but report, even if this is not
tracked as a patch bug report.

[...]

> The process could go like this:
>
> 1. commits of a series pushed to master
> 2. Savannah sends datagram to a remote machine to trigger the
> post-commit job, with the newly pushed commits 'Change-Id' values (a
> list of them).
> 3. The remote machine runs something like 'mumi close-issues [change-id-1
> change-id-2 ...]'

I think that extending the already existing post-receive hook is better
since it does not depend on the availability of a remote service
receiving a **UDP** datagram.

For sure, we need an enhanced version of mumi CLI (capable of indexing
Change-Id) on the server running the post-receive hook to achieve this.

> In case it couldn't close an issue, it could send a notification to the
> submitter: "hey, I've seen some commits of series NNNN landing to
> master, but not all of the commits appears to have been pushed, please
> check"

Interesting!  This could also be done by a server post-receive hook, in
contrast to a remote service listening for UDP datagrams.

> What mumi does internally would be something like:
>
> a) Check in its database to establish the Change-Id <-> Issue # relation,
> if any.
>
> b) For each issue, if issue #'s known Change-Ids are all covered by the
> change-ids in the arguments, close it

I think that b) is better suited for a git post-receive hook and not for
mumi triggered by a third service; as said above for sure such a script
needs mumi (CLI) to query the mumi (server) database.

> This is a bit more complex (UDP datagram, mumi database) but it does
> useful work for us committers (instead of simply changing the way we
> currently do the work).

I agree: an automatic bug closing "machinery" when patches are pushed to
master (and any other official branch?) is the best approach

> When not provided any change-id argument, 'mumi close-issues' could run
> the process on its complete list of issues.

Do you mean the list of issues provided by "Close/Fix/Resolve:
#bug-number"?

If I don't miss something, again this is someting that should be
provided by a git post-receive hook and not by an enhanced version on
mumi

> Since it'd be transparent and requires nothing from a committer, it'd
> provide value without having to document yet more processes.

No, but we should however document the design of this new kind of
machinery, so we can always check that the implementation respects the
design and eventually redesign and refactor if needed.

WDYT?

Thanks, Gio'



[1] id:87y1hikln6.fsf@wireframe https://yhetil.org/guix/87y1hikln6.fsf@wireframe

[2] id:87pm2pces0.fsf@xelera.eu https://yhetil.org/guix/87pm2pces0.fsf@xelera.eu

[3] id:875y4gzu85.fsf@gmail.com https://yhetil.org/guix/875y4gzu85.fsf@gmail.com

[4] https://www.gnu.org/software/emacs/manual/html_node/emacs/Bug-Reference.html
please also consider that bug-reference-bug-regexp can be customized ;-)

[5] https://debbugs.gnu.org/server-control.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Giovanni,

Giovanni Biscuolo <g@xelera.eu> writes:

[...]

>>>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
>>>> > WDYT about the following
>>>> >   Applies: [patch] <namespace:#bug-number>
>>>> >   Closes: [patch] <namespace:#bug-number>
>>>> >   Resolves: [patch] <namespace:#bug-number>
>>>> >   Done: [patch] <namespace:#bug-number>

[...]

> Anyway, I agree with Liliana that having more keyworks will help humans
> better capture (and remember) the implied semantics (that we should
> definitely document, anyway); for this reason my proposal is to accept
> all this _lowercased_ keywords (all followed by a ":" with NO spaces in
> between): fix, fixes, close, closes, resolve, resolves, do, done.

OK, I now get the point; we're not discussing synonyms but various
actions both 'Closes and 'Fixes' would be implement via the
NNNNN-done@debbugs.gnu.org special email sent to the control server, but
they convey a different idea to us humans.  I agree.

[...]

>> If we choose this simple scheme where the top commit of a series can be
>> annotated with Debbugs control commands, I'd opt for:
>>
>> --8<---------------cut here---------------start------------->8---
>> Applies: #bug-number
>> --8<---------------cut here---------------end--------------->8---
>
> Uh I think I get it: you mean we could use a keyword in the commit
> message to allow the committer to effectively link a commit to a
> #bug-number, right?

Yes!  I think my thought train went that way while Liliana and yours
were more focused on a post push action to close *fixed* issues, right?
What I described here was a general process by which we could close
*patches* series that were forgotten in an 'open' state.

> This is something we sould consider, but it's another topic: how to
> effectively link commits to #bug-num (I guess we already talked about
> this in some other thread)
>
>> I'm not sure what [patch] or namespace add (is it for a fancy URL?), so
>> I'd drop them.
>
> I'll try to recap, sorry for the repetitions!
>
> Namespace has been assumed as part of the proposed URI to try address
> Vagrant's concerns [1]:
>
>
>    Sooooo... I maintain the guix package in Debian, and want to make sure
>    that whatever bug-closing indicator guix upstream uses, does not end up
>    triggering when I push new upstream versions to salsa.debian.org ... and
>    start incorrectly marking incorrect bug numbers on bugs.debian.org that
>    were meant for debbugs.gnu.org.

I don't understand how this risk could be triggered; we're strictly
talking about commits made in the Guix repository, not in one of
Debian's?  Why/how would a Guix commit message trigger a Debian Debbugs
server action?  Maybe if Vagrant put something like:

Fixes: <debbugs.debian.org/NNNNN> that could cause problems?  But then
the URL is different, so we could filter out these, so I don't see the
problem, if we use URLs.  And if we accept just 'Fixes: #NNNNN', it
should be documented that these are strictly intended to refer to Guix
issues, not that of other projects.  I don't think we'll be able to make
this error proof, so we should instead aim to make it convenient for the
main use cases, which is to refer to Guix issues.  Does that make sense?

> Fixes: [optional bug description] <namespace:#bug-number>
>
> (here, URI is <namespace>:#<bug-number>)
>
> ...but then you, Maxim, suggested [3] this form:
>
> Fixes: bug#65738 (java-ts-mode tests)

Note that we can stick with the <issues.guix.gnu.org/NNNNNN> URL and
achieve the same result with some extra config (see: bug#65883).

>>>> If so, that's adding rather than reducing friction, and I'm not sure
>>>> it'd gain much traction.  The way I see it, it needs to happen
>>>> automatically.
>>> I mean, the way I imagine is that you type this as part of your message
>>> and then debbugs would do the work of closing the bug.  In short, "git
>>> push" saves you the work of writing a mail because there's a hook for
>>> it.
>
> I guess all of us are looking for this very same thing: a server side
> web hook that automatically closes bugs (via email) when committers
> pushing "instructs" it to do so.
>
> The automatic email message will be sent to our "bug control and
> manipulation server" [5], with this header:
>
>
> From: GNU Guix git hook <noreply@gnu.org>
> Reply-To: <Committer> <<committer-email>>
> To: control@debbugs.gnu.org
>
>
> and this body:
>
>
> package guix
> close <bug-number> [<commit-hash>]
> quit
>
>
> The "Reply-To:" (I still have to test it) will receive a notification
> from the control server with the results of the commands, including
> errors if any.
>
> Then, the documentation for the close command [5] states:

Note that 'close' is deprecated in favor of 'done', which does send a
reply.

> A notification is sent to the user who reported the bug, but (in
> contrast to mailing bugnumber-done) the text of the mail which caused
> the bug to be closed is not included in that notification.
>
> If you supply a fixed-version, the bug tracking system will note that
> the bug was fixed in that version of the package.
>
> Last but not least, the very fact that "GNU Guix git hook" have closed
> the bug report is tracked and showed in the bug report history, as any
> other action made via email using the Debbugs control server.
>
> WDYT?

Yes, these last bits are what an implementation would have to do,
whether it's a simple hook working from Git trailers or the more complex
idea I had working from mumi and mapping commit sets (via Change-Ids) to
Debbugs guix-patches issues.

> [...]
>
>> The process (*for closing lingering *guix-patches* issues) could go
>> like this:
>>
>> 1. commits of a series pushed to master
>> 2. Savannah sends datagram to a remote machine to trigger the
>> post-commit job, with the newly pushed commits 'Change-Id' values (a
>> list of them).
>> 3. The remote machine runs something like 'mumi close-issues [change-id-1
>> change-id-2 ...]'
>
> I think that extending the already existing post-receive hook is better
> since it does not depend on the availability of a remote service
> receiving a **UDP** datagram.
>
> For sure, we need an enhanced version of mumi CLI (capable of indexing
> Change-Id) on the server running the post-receive hook to achieve this.


>> In case it couldn't close an issue, it could send a notification to the
>> submitter: "hey, I've seen some commits of series NNNN landing to
>> master, but not all of the commits appears to have been pushed, please
>> check"
>
> Interesting!  This could also be done by a server post-receive hook, in
> contrast to a remote service listening for UDP datagrams.

The reason in my scheme why the more capable mumi CLI would be needed is
because closed series would be inferred from commits Change-IDs rather
than explicitly declared.

>> What mumi does internally would be something like:
>>
>> a) Check in its database to establish the Change-Id <-> Issue # relation,
>> if any.
>>
>> b) For each issue, if issue #'s known Change-Ids are all covered by the
>> change-ids in the arguments, close it
>
> I think that b) is better suited for a git post-receive hook and not for
> mumi triggered by a third service; as said above for sure such a script
> needs mumi (CLI) to query the mumi (server) database.

To clarify, the above should be a sequential process; with the Change-Id
scheme, you don't have a direct mapping between a series and the Debbugs
issue -- it needs to be figured out by checking in the Mumi database.

>> This is a bit more complex (UDP datagram, mumi database) but it does
>> useful work for us committers (instead of simply changing the way we
>> currently do the work).
>
> I agree: an automatic bug closing "machinery" when patches are pushed to
> master (and any other official branch?) is the best approach
>
>> When not provided any change-id argument, 'mumi close-issues' could run
>> the process on its complete list of issues.
>
> Do you mean the list of issues provided by "Close/Fix/Resolve:
> #bug-number"?
>
> If I don't miss something, again this is someting that should be
> provided by a git post-receive hook and not by an enhanced version on
> mumi

It could process the 'Fixes: #NNNNN' and other git trailers we choose to
use as well, but what I had on mind was processing the *guix-patches*
outstanding Debbugs issues based on the presence of unique Change-Ids in
them.  It complements the other proposal as it could be useful for when
a committer didn't specify the needed trailers and forgot to close the
issue in *guix-patches*, for example.

>> Since it'd be transparent and requires nothing from a committer, it'd
>> provide value without having to document yet more processes.
>
> No, but we should however document the design of this new kind of
> machinery, so we can always check that the implementation respects the
> design and eventually redesign and refactor if needed.

Yes, it should be summarily described at least in the documentation,
with pointers to the source.

Oof, that's getting long.

To recap:

We have two propositions in there:

1. A simple one that is declarative: new git trailers added to commit
messages would convey actions to be done by the server-side hook.

2. A more complex one that would allow us to close *some* (not all) of
the *guix-patches* issues automatically, relying on Change-Ids (and
Mumi's ability to parse them) to infer which patch series saw all their
commits merged already.

I think both have value to be pursued, but 1. could be implemented first
since it is simpler.

Thanks,

Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 10203 bytes --]

Hi Maxim and Vagrant,

I'm sorry for some of the inconprehensions.

Finally I think we got a useful design overall for the _two_ user cases
and the related pieces of metadata and algorithms, now it's time for
_two_ implementations proposals, that also means _code_...

If nihil obstat, I'm going to open 2 bug reports (severity: wishlist)
and will take ownership... but only to coordinate the work, since I miss
some competence /and/ some authorization (for example to get and/or
install the server side git hook)

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> Anyway, I agree with Liliana that having more keyworks will help humans
>> better capture (and remember) the implied semantics (that we should
>> definitely document, anyway); for this reason my proposal is to accept
>> all this _lowercased_ keywords (all followed by a ":" with NO spaces in
>> between): fix, fixes, close, closes, resolve, resolves, do, done.
>
> OK, I now get the point; we're not discussing synonyms but various
> actions

Yes :-D

[...]

>>> If we choose this simple scheme where the top commit of a series can be
>>> annotated with Debbugs control commands, I'd opt for:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> Applies: #bug-number
>>> --8<---------------cut here---------------end--------------->8---
>>
>> Uh I think I get it: you mean we could use a keyword in the commit
>> message to allow the committer to effectively link a commit to a
>> #bug-number, right?
>
> Yes!

OK! :-)  Let's see how this relates to the 2 use cases we are talking
about:

1. Use "Fixes:" (et al) in commit msg to tell "the hook" to close the
bug.

This "action" implies that the commit we are pushing upstream "Applies:"
to that bug report; it has no added value.

2. Use 'Change-Id'...

This also implies that the commit we are pushing upstream "Applies:" to
that bug report related to that [PATCH]; no added value also.

So, when and only when we will implement a 'Change-Id' requirement
adding an 'Applies' metadata is not useful for linking [PATCH]es to a
bug report.

Did I miss something?

> I think my thought train went that way while Liliana and yours
> were more focused on a post push action to close *fixed* issues,
> right?

Yes, it's a (super?) /brainstorming/ :-)

> What I described here was a general process by which we could close
> *patches* series that were forgotten in an 'open' state.

Yes: until we miss the 'Change-Id' metadata, we cannot do [1] nothing
for forgotten patches series.

[...]

>> Namespace has been assumed as part of the proposed URI to try address
>> Vagrant's concerns [1]:
>>
>>
>>    Sooooo... I maintain the guix package in Debian, and want to make sure
>>    that whatever bug-closing indicator guix upstream uses, does not end up
>>    triggering when I push new upstream versions to salsa.debian.org ... and
>>    start incorrectly marking incorrect bug numbers on bugs.debian.org that
>>    were meant for debbugs.gnu.org.
>
> I don't understand how this risk could be triggered; we're strictly
> talking about commits made in the Guix repository, not in one of
> Debian's?  Why/how would a Guix commit message trigger a Debian Debbugs
> server action?  Maybe if Vagrant put something like:
>
> Fixes: <debbugs.debian.org/NNNNN> that could cause problems?  But then
> the URL is different, so we could filter out these, so I don't see the
> problem, if we use URLs.

Yes we are saying the same thing! :-)

Sorry I've made confusion but Vagrant's concern was expressed _before_
someone proposed (maybe Liliana) to use namespaced URIs.

Vagrant please: do you confirm that using URLs "Fixes:
<issues.guix.gnu.org/NNNNNN>" is OK for your usecase?

[...]

>> Fixes: [optional bug description] <namespace:#bug-number>
>>
>> (here, URI is <namespace>:#<bug-number>)
>>
>> ...but then you, Maxim, suggested [3] this form:
>>
>> Fixes: bug#65738 (java-ts-mode tests)
>
> Note that we can stick with the <issues.guix.gnu.org/NNNNNN> URL and
> achieve the same result

Thinking twice about this point, now I see that using the URL is
**much** better than <guix:NNNNNN>, simply because URLs can be
copy/pasted in a browser for users not using the bug-reference Emacs
feature or any other similar feature in their preferred IDE, if
available.

> with some extra config (see: bug#65883).

Fantastic!

[...]

>> The automatic email message will be sent to our "bug control and
>> manipulation server" [5], with this header:
>>
>>
>> From: GNU Guix git hook <noreply@gnu.org>
>> Reply-To: <Committer> <<committer-email>>
>> To: control@debbugs.gnu.org
>>
>>
>> and this body:
>>
>>
>> package guix
>> close <bug-number> [<commit-hash>]
>> quit
>>
>>
>> The "Reply-To:" (I still have to test it) will receive a notification
>> from the control server with the results of the commands, including
>> errors if any.
>>
>> Then, the documentation for the close command [5] states:
>
> Note that 'close' is deprecated in favor of 'done', which does send a
> reply.

Sorry I'm not finding 'done' (and the deprecation note) here:
https://debbugs.gnu.org/server-control.html

Maybe do you mean that we should not use the control server but send a
message to <bug-number>-done@debbugs.gnu.org?

Like:

--8<---------------cut here---------------start------------->8---

From: guix-commits
To: <bug-number>-done@debbugs.gnu.org

Version: <commit-hash>

This is an automated email from the git hooks/post-receive script.

This bug report has been closed on behalf of <Committer>
<<committer-email>> since he added an appropriate pseudo-footer in the
commit message of <commit-hash> (see <http link to documentation>).

For details on the commit content, please see: <http link to commit>.

--8<---------------cut here---------------end--------------->8---

OK: this goes in the upcoming [PATCH] and related patch revision
process... :-D

[...]

>> Interesting!  This could also be done by a server post-receive hook, in
>> contrast to a remote service listening for UDP datagrams.
>
> The reason in my scheme why the more capable mumi CLI would be needed is
> because closed series would be inferred from commits Change-IDs rather
> than explicitly declared.

Yes I agree: a more capable mumi CLI is also needed in my scheme :-)

The "only" difference in my scheme is that we don't need an external
server listening for a UPD datagram, IMO a more capable version of our
current git hooks/post-receive script is better.

>>> What mumi does internally would be something like:
>>>
>>> a) Check in its database to establish the Change-Id <-> Issue # relation,
>>> if any.
>>>
>>> b) For each issue, if issue #'s known Change-Ids are all covered by the
>>> change-ids in the arguments, close it
>>
>> I think that b) is better suited for a git post-receive hook and not for
>> mumi triggered by a third service; as said above for sure such a script
>> needs mumi (CLI) to query the mumi (server) database.
>
> To clarify, the above should be a sequential process;

It was clear to me, thanks!

> with the Change-Id scheme, you don't have a direct mapping between a
> series and the Debbugs issue -- it needs to be figured out by checking
> in the Mumi database.

Yes, to be precise it needs to be figured out by a tool that is indexing
'Change-Id' via Xapian.

The preferred tool to be extended by the Guix project contributors is
mumi, obviously

... but a similar feature could also be provided by an enhanced version
of (the unofficial) guix-patches public-inbox, that uses Xapian queries
for searches [2], it "just" lacks indexing messages by 'Change-Id' (is
there a public-inbox CLI for searching and scripting purposes?!?)

[...]

> It could process the 'Fixes: #NNNNN' and other git trailers we choose to
> use as well, but what I had on mind was processing the *guix-patches*
> outstanding Debbugs issues based on the presence of unique Change-Ids in
> them.  It complements the other proposal as it could be useful for when
> a committer didn't specify the needed trailers and forgot to close the
> issue in *guix-patches*, for example.

Yes I think I get it :-)

To be cristal clear: I think that "the other proposal" (that is use
"Fixes:" and alike in commit msg to close the provided bug num) will be
**superseeded** when all the tools to manage (first of all: CLI query
tool) the 'Change-Id' preudo-header/footer :-D

>>> Since it'd be transparent and requires nothing from a committer, it'd
>>> provide value without having to document yet more processes.
>>
>> No, but we should however document the design of this new kind of
>> machinery, so we can always check that the implementation respects the
>> design and eventually redesign and refactor if needed.
>
> Yes, it should be summarily described at least in the documentation,
> with pointers to the source.
>
> Oof, that's getting long.

Wow! \O/

> To recap:
>
> We have two propositions in there:
>
> 1. A simple one that is declarative: new git trailers added to commit
> messages would convey actions to be done by the server-side hook.
>
> 2. A more complex one that would allow us to close *some* (not all) of
> the *guix-patches* issues automatically, relying on Change-Ids (and
> Mumi's ability to parse them) to infer which patch series saw all their
> commits merged already.
>
> I think both have value to be pursued, but 1. could be implemented first
> since it is simpler.

I think that finally we have a clear big picture.  Thanks!

As stated at the beginning of this message, I'm going to open bug
reports :D


Happy hacking! Gio'


[1] whatever "do" does mean: it could range from a "simple" search with
mumi (or something similar) by a human "bug reports gardener" to a full
fledged server side git hook to notify involved parties and/or
automatically close the related bug report.

[2] https://yhetil.org/guix-patches/_/text/help/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Am Donnerstag, dem 14.09.2023 um 11:42 +0200 schrieb Giovanni Biscuolo:
> OK! :-)  Let's see how this relates to the 2 use cases we are talking
> about:
> 
> 1. Use "Fixes:" (et al) in commit msg to tell "the hook" to close the
> bug.
> 
> This "action" implies that the commit we are pushing upstream
> "Applies:" to that bug report; it has no added value.
> 
> 2. Use 'Change-Id'...
> 
> This also implies that the commit we are pushing upstream "Applies:"
> to that bug report related to that [PATCH]; no added value also.
> 
> So, when and only when we will implement a 'Change-Id' requirement
> adding an 'Applies' metadata is not useful for linking [PATCH]es to a
> bug report.
> 
> Did I miss something?
On "Fixes:" vs. "Applies:" etc: the point of having more keywords is
that "Fixes:" implies a bug, whereas more general wording is preferable
when pushing a patch that simply updates a package.  I just wrote some
example wordings and wanted all of us to agree on the one that makes
"the most sense"; alas it got misinterpreted.

> 
> > Maybe if Vagrant put something like:
> > 
> > Fixes: <debbugs.debian.org/NNNNN> that could cause problems?  But
> > then the URL is different, so we could filter out these, so I don't
> > see the problem, if we use URLs.
> 
> Yes we are saying the same thing! :-)
> 
> Sorry I've made confusion but Vagrant's concern was expressed
> _before_ someone proposed (maybe Liliana) to use namespaced URIs.
> 
> Vagrant please: do you confirm that using URLs "Fixes:
> <issues.guix.gnu.org/NNNNNN>" is OK for your usecase?
I actually prefer cool URLs myself, my format was 
"Fixes: [optional description] <URL>"

> > 
> To be cristal clear: I think that "the other proposal" (that is use
> "Fixes:" and alike in commit msg to close the provided bug num) will
> be **superseeded** when all the tools to manage (first of all: CLI
> query tool) the 'Change-Id' preudo-header/footer :-D
Well I still very much prefer human readable footers, but I'm perhaps a
little lonely in this debate.

Cheers
> > > 

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Hi Maxim,

Am Montag, dem 11.09.2023 um 16:41 -0400 schrieb Maxim Cournoyer:
> [...]
> Perhaps both approach[es] could be combined.  I still see value in a
> general scheme to automate closing applied series that linger on in
> Debbugs.
> 
> [0] 
> https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00138.html
> 
> Change-Ids would also add the benefit that any commit found in Git
> could easily be traced back to their submission on the guix-patches
> or guix trackers or vice-versa (git log --grep='Change-Id=XXXX'), as
> noted by Giovanni.
The thing is, we're discussing the same basic workflow (which you lay
out below), just different kinds of metadata that we'd have to attach
to our commits.  IIUC ChangeIds need to actually be carried around by
the committers as they e.g. rewrite patches (rebasing, squashing, what
have you), and they're basically opaque hashes so I don't see the
benefit to the reader.  (I think you might be arguing that the benefit
is uniqueness, but I'm not sure if I ought to buy that.)

Meanwhile "Fixes: [whatever notation]" also needs to carried around,
sure, but at the same time provides semantics by pointing to a (known)
bug report.  Now again, I personally prefer cool URLs here, but that's
a bike we can shed however we want.

> The process could go like this:
> 
> 1. commits of a series pushed to master
> 2. Savannah sends datagram to a remote machine to trigger the
> post-commit job, with the newly pushed commits 'Change-Id' values (a
> list of them).
> 3. The remote machine runs something like 'mumi close-issues [change-
> id-1 change-id-2 ...]'
Yeah, I think we basically agree on the 1 and 2 here, but I don't think
we have to really implement 3.  IMHO we could do something simpler for
all parties by just carrying the bug number around (in whichever form),
which we do for some of our pre-ChangeLog explanations already.
 
> In case it couldn't close an issue, it could send a notification to
> the submitter: "hey, I've seen some commits of series NNNN landing to
> master, but not all of the commits appears to have been pushed,
> please check"
I'm not sure how common this case is, but if it's needed we could add
"Part-of: [same stuff as for fixes]" which once parsed by Debbugs/Mumi
would send that notification.


Cheers

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]

Hi Liliana and Maxim,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

> The thing is, we're discussing the same basic workflow

No, we are discussing two (complementary) workflows:

1. the one I suggested to add a "footer-metadata-field" named
Fix/Fixes/Close/Closes/whatever that will allow people pushing to the
Guix official repo to _add_ the information that the (already installed,
to be enhanced) server side git post-receive hook should also close one
or more bug reports; that "metadata-footer" should be "manually" added
to the commit message before pushing, the commit must be _amended_ (git
commit --amend).

2. the one suggested by Maxim (bringed by Gerrit) to _automatically_ add
a "footer-metadata-field" named 'Change-Id' that will allow "a
machinery" (IMO it should be the currently installed hook, enhanced) to
_automaticcally_ close bug reports when all 'Change-Id's contained in a
bug report have been pushed to the official Guix repo.

This is my understanding of what we are discussing here: did I miss
something?

> (which you lay out below), just different kinds of metadata that we'd
> have to attach to our commits.

Thay are different because they serve different needs.

> IIUC ChangeIds need to actually be carried around by the committers as
> they e.g. rewrite patches (rebasing, squashing, what have you)

Since 'Change-Id' is automaticcaly generated by a _local_ git hook upon
committing and left unchanged if already present, the only precaution
the committer should apply is to preserve it when rebasing in case the
person needs to send a new version of the patch. 

> and they're basically opaque hashes so I don't see the benefit to the
> reader.

The benefit are not for the reader but for "the machinery" to be able to
compute when a patch set is completely pushed to the Guix official repo,
this also means that the related bug repo (related to the patch set) can
be happily automatically closed.  No?

> (I think you might be arguing that the benefit is uniqueness, but I'm
> not sure if I ought to buy that.)

The benefit is that 'Change-Id' is autogererated as unique, kept between
rebases (with some pracaution by the _local_ committer) thus is useful
to compute the completion of each patch contained in a bug repo (of
class [PATCH]).

Obviously all of this should be clearly documented, so everyone will
understand how it works.

[...]

>> In case it couldn't close an issue, it could send a notification to
>> the submitter: "hey, I've seen some commits of series NNNN landing to
>> master, but not all of the commits appears to have been pushed,
>> please check"
> I'm not sure how common this case is

Don't know the cardinality, but I guess is a /very/ useful usecase for
people who have committ access to the official Guix repo... at least for
Maxim :-)

Anyway, I think the main use case for this _second_ way of automatically
closing related bugs (the one based upon 'Change-Id') when all [PATCH]es
are pushed is very useful for all people with commit access to the Guix
repo, a sort of "push and (almost) forget".

[...]

Ciao, Gio'.

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi Maxim,
>
> Am Montag, dem 11.09.2023 um 16:41 -0400 schrieb Maxim Cournoyer:
>> [...]
>> Perhaps both approach[es] could be combined.  I still see value in a
>> general scheme to automate closing applied series that linger on in
>> Debbugs.
>> 
>> [0] 
>> https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00138.html
>> 
>> Change-Ids would also add the benefit that any commit found in Git
>> could easily be traced back to their submission on the guix-patches
>> or guix trackers or vice-versa (git log --grep='Change-Id=XXXX'), as
>> noted by Giovanni.
> The thing is, we're discussing the same basic workflow (which you lay
> out below), just different kinds of metadata that we'd have to attach
> to our commits.  IIUC ChangeIds need to actually be carried around by
> the committers as they e.g. rewrite patches (rebasing, squashing, what
> have you), and they're basically opaque hashes so I don't see the
> benefit to the reader.  (I think you might be arguing that the benefit
> is uniqueness, but I'm not sure if I ought to buy that.)

Correct; the Change-Ids must be preserved when rebasing ((*if* they were
already published -- otherwise it doesn't matter)), and for the human
reader they're mostly noise.  Since it can be automated though, from the
day it's added all the commits would have one and they would become a
valuable unique key to cross-reference between what's in master and what
was reviewed in guix-patches, for example.

> Meanwhile "Fixes: [whatever notation]" also needs to carried around,
> sure, but at the same time provides semantics by pointing to a (known)
> bug report.  Now again, I personally prefer cool URLs here, but that's
> a bike we can shed however we want.

That's nice, and as I wrote in my previous reply to Giovanni, I think
both schemes have their place.

>> The process could go like this:
>> 
>> 1. commits of a series pushed to master
>> 2. Savannah sends datagram to a remote machine to trigger the
>> post-commit job, with the newly pushed commits 'Change-Id' values (a
>> list of them).
>> 3. The remote machine runs something like 'mumi close-issues [change-
>> id-1 change-id-2 ...]'
> Yeah, I think we basically agree on the 1 and 2 here, but I don't think
> we have to really implement 3.  IMHO we could do something simpler for
> all parties by just carrying the bug number around (in whichever form),
> which we do for some of our pre-ChangeLog explanations already.

For just closing cross-referenced bugs, I agree.  For closing forgotten,
already merged issues on guix-patches we'd need the Change-Id and a tool
able to map Change-Ids -> issue number (mumi is in the best place to do
so).

It's been a hard discussion to follow, but I think we're coming to some
understanding that we are discussing two different schemes that could be
both implemented to provide different benefits, right?

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Am Mittwoch, dem 13.09.2023 um 11:27 -0400 schrieb Maxim Cournoyer:
> For just closing cross-referenced bugs, I agree.  For closing
> forgotten, already merged issues on guix-patches we'd need the
> Change-Id and a tool able to map Change-Ids -> issue number (mumi is
> in the best place to do so).
> 
> It's been a hard discussion to follow, but I think we're coming to
> some understanding that we are discussing two different schemes that
> could be both implemented to provide different benefits, right?
I do wonder how the ChangeId would work in practice.  Since it's not
really assigned by the committer, it would have to be generated "on the
fly" and attached to the mail in between, which could result in all
kinds of nasty behaviour like unstable Ids or duplicated ones.  Also,
if we can automate this for ChangeIds, we could also automate this for
patch-sets – the last patch in the series just gets the Closes: tag
added by mumi.  

Furthermore, I'm not convinced that it would ease the issue of
forgotten bugs as you can't really apply them to the past.  So the
practical use is limited to the case where you intentionally cherry-
pick this or that commit from a series.  How we want to deal with that
case could be a discussion in its own right, and maybe ChangeIds really
trump the explicit tags proposed by Giovanni or myself here.  Whether
that justifies the cognitive overhead of juggling them around on every
submission remains to be shown or disproven.

Beyond the scope of the discussion so far, it also doesn't help us with
duplicate or superseded patches (e.g. two series on the mailing list
propose a similar change, because one of them has already been
forgotten).  Again, the explicit close tags would allow this case to be
handled in an interpretable fashion.  In both cases, we do however also
introduce the potential for incorrect tagging, which then needs to be
resolved manually (more or less a non-issue, as it's the status quo).

Cheers

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi,

On Wed, 13 Sep 2023 at 21:14, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

> I do wonder how the ChangeId would work in practice.  Since it's not
> really assigned by the committer, it would have to be generated "on the
> fly" and attached to the mail in between, which could result in all
> kinds of nasty behaviour like unstable Ids or duplicated ones.  Also,
> if we can automate this for ChangeIds, we could also automate this for
> patch-sets – the last patch in the series just gets the Closes: tag
> added by mumi.

I think it would work using some pre-commit hook.  When one commits
their change, this commit is run and it can pre-fill the commit
message.  Well, that’s how I have understood the thread.


> Furthermore, I'm not convinced that it would ease the issue of
> forgotten bugs as you can't really apply them to the past.  So the
> practical use is limited to the case where you intentionally cherry-
> pick this or that commit from a series.  How we want to deal with that
> case could be a discussion in its own right, and maybe ChangeIds really
> trump the explicit tags proposed by Giovanni or myself here.  Whether
> that justifies the cognitive overhead of juggling them around on every
> submission remains to be shown or disproven.

I agree.  I am not convinced by the benefits and I already see some
troubles.

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Maxim Cournoyer]

Hi,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi,
>
> On Wed, 13 Sep 2023 at 21:14, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:
>
>> I do wonder how the ChangeId would work in practice.  Since it's not
>> really assigned by the committer, it would have to be generated "on the
>> fly" and attached to the mail in between, which could result in all
>> kinds of nasty behaviour like unstable Ids or duplicated ones.  Also,
>> if we can automate this for ChangeIds, we could also automate this for
>> patch-sets – the last patch in the series just gets the Closes: tag
>> added by mumi.
>
> I think it would work using some pre-commit hook.  When one commits
> their change, this commit is run and it can pre-fill the commit
> message.  Well, that’s how I have understood the thread.

Yes; exactly like how it's done in Gerrit, if you've ever used that
(we'd reuse their hook).  It'd be enabled out-of-the-box so it'd be
transparent to users.

>> Furthermore, I'm not convinced that it would ease the issue of
>> forgotten bugs as you can't really apply them to the past.  So the
>> practical use is limited to the case where you intentionally cherry-
>> pick this or that commit from a series.  How we want to deal with that
>> case could be a discussion in its own right, and maybe ChangeIds really
>> trump the explicit tags proposed by Giovanni or myself here.  Whether
>> that justifies the cognitive overhead of juggling them around on every
>> submission remains to be shown or disproven.

I like the 'Closes: ' trailer idea; it's simple.  However, it'd need to
be something added locally, either the user typing it out (unlikely for
most contributors) or via some mumi wizardry (it's unlikely that all
users will use mumi), which means its usage (and value) would depend on
how motivated individuals are to learn these new tricks.

On the other hands, having Change-Ids added by a pre-commit hook
automatically would means the user doesn't need to do anything special
other than using git, and we could still infer useful information at any
time (in a server hook, or as a batch process).

For this reason, I think we could have both (why not?  Change-Ids by
themselves provide some value already -- traceability between our git
history and guix-patches).

-- 
Thanks,
Maxim

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

> I like the 'Closes: ' trailer idea; it's simple.  However, it'd need to
> be something added locally, either the user typing it out (unlikely for
> most contributors) or via some mumi wizardry (it's unlikely that all
> users will use mumi), which means its usage (and value) would depend on
> how motivated individuals are to learn these new tricks.

I agree: the ratio, or better usecase, of my /trivial/ (in design, not
in implementation) initial proposal [1] was to try to help committers
closing bugs "in one go" by adding proper information to the commit
message, e.g. "Closes: #NNNNN"

It was _not_ intended for contributors, also because they could _not_
know that **specific** patch in a patch series will really close a
**whole** bug report: that's only a judgement of the committer.

Also, my ratio was influenced by my misunderstanding of a series of bug
closing actions performed by Vagrant (see [1] for details): the problem
in the majority (all?) of those cases was **not** that the committer
simply forgot to close the related bug report /but/ that bug reports
containing (different) patches for the _same_ package were not linked
each other: the solution to this class of problems in obviously not
"Automatically close bug report when a patch is committed", it's
something else [2]

> On the other hands, having Change-Ids added by a pre-commit hook
> automatically would means the user doesn't need to do anything special
> other than using git, and we could still infer useful information at any
> time (in a server hook, or as a batch process).
>
> For this reason, I think we could have both (why not?  Change-Ids by
> themselves provide some value already -- traceability between our git
> history and guix-patches).

I agree: just having 'Change-Ids' alone already provide some added
value, even if we still miss the tooling (server side git hook, batch
processing

Thanks!  Gio'


[1] id:8734zrn1sc.fsf@xelera.eu https://yhetil.org/guix/8734zrn1sc.fsf@xelera.eu/

[2] id:87msxyfhmv.fsf@xelera.eu https://yhetil.org/guix/87msxyfhmv.fsf@xelera.eu

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

On 2023-09-14, Giovanni Biscuolo wrote:
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>> I like the 'Closes: ' trailer idea; it's simple.  However, it'd need to
>> be something added locally, either the user typing it out (unlikely for
>> most contributors) or via some mumi wizardry (it's unlikely that all
>> users will use mumi), which means its usage (and value) would depend on
>> how motivated individuals are to learn these new tricks.
>
> I agree: the ratio, or better usecase, of my /trivial/ (in design, not
> in implementation) initial proposal [1] was to try to help committers
> closing bugs "in one go" by adding proper information to the commit
> message, e.g. "Closes: #NNNNN"

To be really, really clear, I am honestly pretty much fine with anything
except:

  Closes:.*#NNNNN

or

  Closes:.*NNNNN

These are already widely used in Debian, and their use was well
established before guix or even nix were even an inkling of an idea
wriggling around in any human brains.

Staying away from anything that uses any permutation of "close" would be
most appreciated. :)

(There may be some slightly more complicated variants; I think someone
posted a link to the regexp used earlier in the thread)

Since I push the entire relevent portions of upstream guix git history
when pushing changes for guix packaging in Debian, it would be a
significant bother for me if guix started using the same syntax, or
similar enough that a trivial typo might lead to something acting on the
wrong issue tracker...

This is why I think it is important for projects to have some sort of
namespacing for this sort of thing; I am not really opinionated on the
exact details, other than it not conflicting with Debian's terribly
generic entirely un-namespaced historical "Closes:" syntax. :)

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> writes:

[...]

> This is why I think it is important for projects to have some sort of
> namespacing for this sort of thing; I am not really opinionated on the
> exact details, other than it not conflicting with Debian's terribly
> generic entirely un-namespaced historical "Closes:" syntax. :)

Noted and agreed!  At this point of discussion I also think there is
consensus (by the persons involved in this thread until now) to use a
namespaced URI (a full URL) for that upcoming feature (one of the two
discussed in the thread).

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

>>  maybe ChangeIds really trump the explicit tags proposed by Giovanni
>> or myself here.  Whether that justifies the cognitive overhead of
>> juggling them around on every submission remains to be shown or
>> disproven.
>
> I agree.  I am not convinced by the benefits and I already see some
> troubles.

Please can you expand what troubles do you see in automatically adding
'Change-Id:' using a hook-commit-msg like
https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
?

Thanks, Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi,

On Thu, 14 Sep 2023 at 12:27, Giovanni Biscuolo <g@xelera.eu> wrote:

> Please can you expand what troubles do you see in automatically adding
> 'Change-Id:' using a hook-commit-msg like
> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
> ?

1. The hook must be installed.
2. The hook must not be in conflict with user configuration.
3. The generated Change-Id string can be mangled by some user unexpected
   action.
4. etc.

Many things can rail out on user side.  For an example, base-commit is
almost appearing systematically in submitted patches almost 3 years
later.  The patches of some submissions are badly formatted.  Etc.

Whatever the implementation, I am not convinced that the effort is worth
the benefits.  And I am not convinced it will help in closing the
submissions when the patches have already been applied.

That’s said, I am not against the proposal.  I just have mixed feelings
and before deploying I strongly suggest to review if the proposal covers
the intent.

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3628 bytes --]

Hello Simon,

thank you for havig listed possible troubles.

Before commenting, just let me repeat that we are _copying_ the
'Change-Id' idea (and related possible implementation issues) from
Gerrit:

https://gerrit-review.googlesource.com/Documentation/user-changeid.html

This means that Somewhere™ in our documentation we should start
explaining that:

--8<---------------cut here---------------start------------->8---

Our code review system needs to identify commits that belong to the same
review.  For instance, when a proposed patch needs to be modified to
address the comments of code reviewers, a second version of that patch
can be sent to guix-patches@gnu.org.  Our code review system allows
attaching those 2 commits to the same change, and relies upon a
Change-Id line at the bottom of a commit message to do so.  With this
Change-Id, our code review system can automatically associate a new
version of a patch back to its original review, even across cherry-picks
and rebases.

--8<---------------cut here---------------end--------------->8---

In other words, 'Change-Id' is /just/ metadata automatically added to
help in code review **tracking**, specificcally helping "across
cherry-picks and rebases" [1]

Sorry if I'm repeating things probably already understood!

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

>> Please can you expand what troubles do you see in automatically adding
>> 'Change-Id:' using a hook-commit-msg like
>> https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html
>> ?
>
> 1. The hook must be installed.

AFAIU a hook is already installed when configuring for contribution.

If this is stil not properly documented it will be fixed.

> 2. The hook must not be in conflict with user configuration.

I guess you mean not in conflict with other locally installed git hooks:
since AFAIU we **already** have a locally installed git hook, this is
already a requirement and this is something the user (contributor)
should be aware of.

If this is stil not properly documented it will be fixed.

> 3. The generated Change-Id string can be mangled by some user unexpected
>    action.

Contributors and committers should not delete or change and already
existing 'Change-Id', this will be documented.

> Many things can rail out on user side.  For an example, base-commit is
> almost appearing systematically in submitted patches almost 3 years
> later.

I don't understand how this could impact the addition of the
patch-tracking metadata named 'Change-Id'

> The patches of some submissions are badly formatted.  Etc.

I don't understand what is the problem of having a 'Change-Id' (in
commit messages) in badly formatted patch submissions.

> Whatever the implementation, I am not convinced that the effort is worth
> the benefits.

OK, I'm sorry

> And I am not convinced it will help in closing the submissions when
> the patches have already been applied.

OK, I'm sorry

> That’s said, I am not against the proposal.  I just have mixed feelings
> and before deploying I strongly suggest to review if the proposal covers
> the intent.

OK, thank you for your suggestion.

Happy hacking! Gio'


[1] AFAIU 'Change-Id' can even track different versions of patches (that
by design are from commits in the same branch, properly rebased as
needed) sent by mistake via **different bug reports**, this also means
that different bug reports containing the same 'Change-Id' are _surely_
linked togheter.

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Simon Tournier]

Hi Giovanni,

Before commenting, let me repeat. ;-)

        That’s said, I am not against the proposal.  I just have mixed
        feelings and before deploying I strongly suggest to review if
        the proposal covers the intent.


On Fri, 15 Sep 2023 at 09:16, Giovanni Biscuolo <g@xelera.eu> wrote:

> Before commenting, just let me repeat that we are _copying_ the
> 'Change-Id' idea (and related possible implementation issues) from
> Gerrit:
>
> https://gerrit-review.googlesource.com/Documentation/user-changeid.html
>
> This means that Somewhere™ in our documentation we should start
> explaining that:
>
> --8<---------------cut here---------------start------------->8---
>
> Our code review system needs to identify commits that belong to the same
> review.  For instance, when a proposed patch needs to be modified to
> address the comments of code reviewers, a second version of that patch
> can be sent to guix-patches@gnu.org.  Our code review system allows
> attaching those 2 commits to the same change, and relies upon a
> Change-Id line at the bottom of a commit message to do so.  With this
> Change-Id, our code review system can automatically associate a new
> version of a patch back to its original review, even across cherry-picks
> and rebases.
>
> --8<---------------cut here---------------end--------------->8---
>
> In other words, 'Change-Id' is /just/ metadata automatically added to
> help in code review **tracking**, specificcally helping "across
> cherry-picks and rebases" [1]
>
> Sorry if I'm repeating things probably already understood!

All this does not address my concern. :-)


>> 1. The hook must be installed.

[...]

> If this is stil not properly documented it will be fixed.

Maybe… and it will be another item in the already very long list of
steps to complete before contributing.  This is one of my concern: add
yet another thing to an already complicated process for contributing.


>> 2. The hook must not be in conflict with user configuration.
>
> I guess you mean not in conflict with other locally installed git hooks:
> since AFAIU we **already** have a locally installed git hook, this is
> already a requirement and this is something the user (contributor)
> should be aware of.

AFAIK, we have a pre-push hook.  This hook is only useful for the small
set of people who push the code.  And we can assume that this set of
people is skilled and are able to invest if something is unexpected.
Being Guix committer implies such commitment, IMHO.

Here, we are speaking for a Git hook applied to all.  That’s a different
situation, IMHO.

As an user and simple contributor, if I already have a global pre-commit
hook and then when I want to contribute to Guix, I potentially hit some
unexpected behaviour or even conflict, then as an user, either a. I give
up, drop and move my interest to something else than Guix, either b. I
spend some time for fixing this annoyance and that is pure friction (no
value for me and no value for the project).

> If this is stil not properly documented it will be fixed.

Yes, yet another thing to an already complicated process for
contributing.


>> 3. The generated Change-Id string can be mangled by some user unexpected
>>    action.
>
> Contributors and committers should not delete or change and already
> existing 'Change-Id', this will be documented.

Yes, yet another thing to an already complicated process for
contributing.


>> Many things can rail out on user side.  For an example, base-commit is
>> almost appearing systematically in submitted patches almost 3 years
>> later.
>
> I don't understand how this could impact the addition of the
> patch-tracking metadata named 'Change-Id'
>
>> The patches of some submissions are badly formatted.  Etc.
>
> I don't understand what is the problem of having a 'Change-Id' (in
> commit messages) in badly formatted patch submissions.

In these both example, I just pointed that we already have some
potential frictions.  And here, another one is added.

What I know from my experience at work and from the small experience
backed by my reading of help-guix or some bug reports is that:
robustness is hard in an environment you do not control.  More action we
add in that uncontrolled environment and weaker the robustness becomes;
and weak robustness means friction.


Again, I am not saying the proposal is not worth – I am following the
discussion with interest. :-) I am just trying to ask if this proposal
will really fix an concrete annoyance compared to the relative
complexity it adds, and if it is the right balance between the part and
the counter-part.

Cheers,
simon

The already complicated (complex?) process for contributing.

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]

Hi Simon,

maybe we are drifting... again? ;-)

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

>> If this is stil not properly documented it will be fixed.
>
> Maybe… and it will be another item in the already very long list of
> steps to complete before contributing.  This is one of my concern: add
> yet another thing to an already complicated process for contributing.

[...]

> Yes, yet another thing to an already complicated process for
> contributing.

[...]

> Yes, yet another thing to an already complicated process for
> contributing.

[...]

While I agree that if some-"thing" (or the lack of, OK?) is
/complicating/ the contributing process, that "thing" should be
addressed, I disagree that _adding_ the **requirement** for contributors
to properly configure git to use git hooks provided by Guix and
understand the purpose of and pay attention to the 'Change-Id' field is
another "thing" that adds /complication/.

Talking in general: if you mean that contributing to Guix is /complex/ I
agree, but /complex/ does not imply /complication/; also, /complexity/
is common to every DCVS based project with significant dimensions that I
know of.

So yes, contributing /in general/ is a complex process and I guess we
all would like it to be less complicated as possible; proposals in this
thread are trying to go in this direction: adding a little help in
«integrating a proposed change» with no complications (useless by
design) for _all_ involved parties.

Looking at other project development processes, take as an example
**one** of the activities in the Linux kernel development process:
«posting patches» [1].

You also need to know:

- «Submitting patches: the essential guide to getting your code into the
  kernel» [2]

- «Linux Kernel patch submission checklist» [3]

- «Linux kernel coding style» [4]

- «Email clients info for Linux» [5]...  just to mention one of the
cited MUAs, it states: «Gmail (Web GUI). Does not work for sending
patches..».  Probably Guix should copy/paste that.

Is it /complex/ or /complicated/?

To begin with, it's quite a lot of documentation, quite challenging to
study /just/ to be able to send a useful patch to the Linux kernel... or
/just/ to understand how and _why_ the process is designed that way.

I hear you Someone™ reader: I cannot summarise, sorry! :-D ...anyway
it's a very interesting reading, I'd suggest it. (I did not read all.)

To have an overall picture of the /complexity/ of the whole development
process of the Linux kernel, take a look at «the index» [6]. :-O

Could it be simpified without making it /complicated/ for Someone™?
...maybe.

Is Guix development process comparable to the Linux kernel one? ...who
knows :-D


Thanks! Gio'


[1] https://docs.kernel.org/process/5.Posting.html

[2] https://www.kernel.org/doc/html/latest/process/submitting-patches.html

[3] https://www.kernel.org/doc/html/latest/process/submit-checklist.html

[4] https://www.kernel.org/doc/html/latest/process/coding-style.html

[5] https://docs.kernel.org/process/email-clients.html
"Run away from it.": ROTFL!

[6] https://docs.kernel.org/process/index.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: The already complicated (complex?) process for contributing.

[Simon Tournier]

Hi Giovanni,

On Fri, 15 Sep 2023 at 16:37, Giovanni Biscuolo <g@xelera.eu> wrote:

> maybe we are drifting... again? ;-)

Yes we are. :-)

> Is it /complex/ or /complicated/?

Change-Id is not really complex – especially if the complexity is hidden
behind some pre-commit hook – and it is not complex compared to setup
git-send-email for example.

IMHO, it is complicated because it adds yet another point of potential
friction.  Well, let focus the discussion on practical implementation
details instead of some abstract considerations.  It is only once all is
implemented that this discussion about “complicated” enters, IMHO.

On a side note, documentation is very fine but I do not read (or
study!?) the documentation of my oven, instead I am just cooking stuff
for fun.  Other said, the first principle is the principle of the least
astonishment (POLA).  If a project needs really lengthy documentation
for just contributing, either it is a more-than-thousand contributors
project as the Linux kernel, either something is wrong.  Maybe both. ;-)

Cheers,
simon

Re: The already complicated (complex?) process for contributing.

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]

Hi Simon,

since I already replied you offline please forgive me for any
repetitions, but later I realized a better comment to your metaphore
(see below) could be useful to other people.

Simon Tournier <zimon.toutoune@gmail.com> writes:

[...]

> On a side note, documentation is very fine but I do not read (or
> study!?) the documentation of my oven, instead I am just cooking stuff
> for fun.

On a side note, I like your metaphores!

OK but in my view the GNU Guix project is not a personal kitchen but an
international food company [1], with a complex /distributed/ production
process involving tools (ovens, etc.) and recipes (code) ranging from
trivial to very complex; not to forget **legal requirements**, a
challenging supply chain management and a very _peculiar_ process called
"change integration management" from "customers" proposals.  Am I
exaggerating?

Now, given the above context is a valid analogy, is it a fair
expectation you can contribute to the company [1] with the food you cook
just for fun with your oven?

The food GNU Guix company [1] supplies is boostrappable and reproducible
binary code, largerly "baked" using third-party recipes, with a
progressively shrinking binary seed: yeah! :-D

Well, to be honest the food analogy does not fit very well: Guix
supplies /peculiar/ tools that users can use for a variety of
activities, ranging from cooking just for fun to complex infrastructures
management... and to effectively use /that/ tools users should better
study its documentation (ungrateful job the documentation writer!) ;-)

[...]

> If a project needs really lengthy documentation for just contributing,
> either it is a more-than-thousand contributors project, as the Linux
> kernel

I disagree this is a valid metric to measure the complexity of the
process called "change integration management", it could even be _one_
customer asking to change the recipe for his preferred cake.

> either something is wrong.  Maybe both. ;-)

...or maybe it's not "just" a project but a whole food compay [1].

Oh, oh, oh: wait!  Are we going into /that/ famous essay [2] and its
sequel [3] ?!? (very interesting readings!)

...OK, I surrender, unconditionally! :-D

Happy cooking! :-) Gio'


[1] with a very peculiar vision, mission and business model; but please
concede the analogy

[2] "On Management and the Maginot Line"
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s12.html

[3] "Project Structures and Ownership"
http://catb.org/~esr/writings/homesteading/homesteading/ar01s16.html



P.S.: on a side note, I think that part (all?) of the problems discussed
in [2] and [3] are rooted in the anthropological set of questions known
as «Phenomenon of Bullshit Jobs»
https://davidgraeber.org/articles/on-the-phenomenon-of-bullshit-jobs-a-work-rant/

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: The already complicated (complex?) process for contributing.

[Simon Tournier]

Hi Giovanni,

On Sat, 16 Sep 2023 at 09:33, Giovanni Biscuolo <g@xelera.eu> wrote:

> since I already replied you offline please forgive me for any
> repetitions, but later I realized a better comment to your metaphore
> (see below) could be useful to other people.

Since your offlist comment is more or less about the same idea, let me
paste my answer. :-)

First, Guix is done by volunteers and is not an “industrial food
company”. :-) Being done by volunteers does not mean low-quality – Guix
is probably better than many products done by professionals ;-).
Instead, done by volunteers implies other mechanisms than the ones used
in “industrial food company”.

Second, I think we all agree with: we all have or had to read some
documentation and have to make some trial/error loop before being able
to run Guix.

That's also all my point, IMHO. :-)

As you said elsewhere, complex does not mean complicated.  Simple is not
necessary easy.  Etc.  Somehow, Rich Hikey says the obvious in their
talk [1] and that’s why the talk speaks to many people, I guess.  Rich
Hikey makes clear what we already know and had never said explicitly.
It is important to remember the message behind, IMHO.

From my point of view, if the Guix community wants to Guix being
successful, then we have to work on two directions:

 1. Spread the word.
 2. Keep easy what should be easy.

About #1, it means talks, skill sharing, blog posts, tutorials,
documentation, etc.  and being pedagogical by showing what Guix is able
to offer.

About #2, it is where Guix is still a bit weak and we need to work on
that part.  Although, it is regularly improving.

Back to the initial discussion of this thread, which is a tiny stuff in
that picture :-) Your answer "it will be documented" focus on #1.
That's fine and yes having a good documentation is more than important.

My concern is to just say: please do not forget #2.

Thanks for the discussion.  And thanks for pushing ideas and for
pushing how to make them concrete.

My final word, the culinary proverb: talk does not cook the rice. :-)  I
am going to try to cook some rice. ;-)

Cheers,
simon

Re: [workflow] Automatically close bug report when a patch is committed

[Andreas Enge]

Hello,

Am Wed, Sep 13, 2023 at 09:14:52PM +0200 schrieb Liliana Marie Prikler:
> I do wonder how the ChangeId would work in practice.  Since it's not
> really assigned by the committer, it would have to be generated "on the
> fly" and attached to the mail in between, which could result in all
> kinds of nasty behaviour like unstable Ids or duplicated ones.

this one would be easy to solve: it could just be the hash of something.
For instance, it could actually be the commit "number" itself of the
commit when it is first created.

Andreas

Re: [workflow] Automatically close bug report when a patch is committed

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]

Hi Liliana

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Mittwoch, dem 13.09.2023 um 11:27 -0400 schrieb Maxim Cournoyer:

[...]

> I do wonder how the ChangeId would work in practice.

It's a «tag to track commits across cherry-picks and rebases.»

It is used by Gerrit to identify commits that belong to the same review:
https://gerrit-review.googlesource.com/Documentation/user-changeid.html

We could use it for the same purpose and instead of building a web
application for code review, "simply" count that all 'Change-Id's in a
patchset have been pushed to the Guix official repo to declare the
related bug report closed.

> Since it's not really assigned by the committer, it would have to be
> generated "on the fly" and attached to the mail in between

Not to the mail, to the commit msg! [1]

> which could result in all kinds of nasty behaviour like unstable Ids
> or duplicated ones.

No, modulo hook script bugs obviously.

> Also, if we can automate this for ChangeIds, we could also automate
> this for patch-sets – the last patch in the series just gets the
> Closes: tag added by mumi.  

The idea is that, but we don't need to add "Closes" to the commit msg
(via post-receive hook), we "just" need the hook to send an email to
NNNN-done on behalf of the committer (the committer, not the
contributor).

> Furthermore, I'm not convinced that it would ease the issue of
> forgotten bugs as you can't really apply them to the past.

No, this 'Change-Id' is not intended for past bug reports since we
**must not** rewrite past commits _because_ commit messages are
/embedded/ in commit objects.

...but for this purpose we could use git-notes, **if** wanted:
https://git-scm.com/docs/git-notes :-D

> So the practical use is limited to the case where you intentionally
> cherry- pick this or that commit from a series.

No: the practical use is that for each guix-patch bug report we can
count how many [PATCH]es are left to be committed and act accordigly,
for example notify all involved parties (contributor, committer,
'X-Debbugs-CC's) that N/M patches from the series are still to be merged
upstream... or close the bug report if zero patches are left.

> How we want to deal with that case could be a discussion in its own
> right, and maybe ChangeIds really trump the explicit tags proposed by
> Giovanni or myself here.  Whether that justifies the cognitive
> overhead of juggling them around on every submission remains to be
> shown or disproven.

There will be no additional cognitive overhead for contributors since
'Change-Id' will be automatically managed, they can simply ignore it.

> Beyond the scope of the discussion so far, it also doesn't help us with
> duplicate or superseded patches (e.g. two series on the mailing list
> propose a similar change, because one of them has already been
> forgotten).

No, IMO there is **no** solution to this problems other than "triaging"
(id:87msxyfhmv.fsf@xelera.eu
https://yhetil.org/guix/87msxyfhmv.fsf@xelera.eu/)

> Again, the explicit close tags would allow this case to be
> handled in an interpretable fashion.  In both cases, we do however also
> introduce the potential for incorrect tagging, which then needs to be
> resolved manually (more or less a non-issue, as it's the status quo).

There is no potential of incorret tagging when using a hook-commit-msg
[1] to add 'Change-Id'.

For the other method discussed here, there is no way to avoid users
mistyping 'Closes:' pseuto-headers in their commit messages: if mistuped
they will be ignored :-(


Cheeers, Gio'


[1] https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On 2023-09-10, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant Cascadian:
>> I am much more comfortable with the "Fixes" convention of:
>> 
>>   Fixes: https://issues.guix.gnu.org/NNN
> I like the idea, but we should also consider the bugs.gnu.org address
> here as well as the convention of putting it into angular brackets.  In
> fact, I might even prefer it if the convention was
>   Fixes: Bug description <link>
> where bug description is a (possibly empty) name for the bug such as
> "Emacs hangs when I press a key" or something.
>
>
> As for when to send it, remember that we already send a bunch of mails
> to guix-commits@gnu.org as our commit hook?  I think it shouldn't be
> too hard to search for the fixes line and send it to debbugs control.

Well, the complication gets to be ... which branch did it land in? in
master, it's fairly obvious... you can just mark it as
done/closed/etc. I guess with other branches it makes sense to mark it
with the "pending" or maybe some more specific usertag
"pending-in-BRANCH"?

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [workflow] Automatically close bug report when a patch is committed

[Liliana Marie Prikler]

Am Donnerstag, dem 14.09.2023 um 15:51 -0700 schrieb Vagrant Cascadian:
> On 2023-09-10, Liliana Marie Prikler wrote:
> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
> > Cascadian:
> > > I am much more comfortable with the "Fixes" convention of:
> > > 
> > >   Fixes: https://issues.guix.gnu.org/NNN
> > I like the idea, but we should also consider the bugs.gnu.org
> > address
> > here as well as the convention of putting it into angular
> > brackets.  In
> > fact, I might even prefer it if the convention was
> >   Fixes: Bug description <link>
> > where bug description is a (possibly empty) name for the bug such
> > as "Emacs hangs when I press a key" or something.
> > 
> > 
> > As for when to send it, remember that we already send a bunch of
> > mails to guix-commits@gnu.org as our commit hook?  I think it
> > shouldn't be too hard to search for the fixes line and send it to
> > debbugs control.
> 
> Well, the complication gets to be ... which branch did it land in? in
> master, it's fairly obvious... you can just mark it as
> done/closed/etc. I guess with other branches it makes sense to mark
> it with the "pending" or maybe some more specific usertag
> "pending-in-BRANCH"?
I don't think such a distinction is needed in most cases.  In fact, if
it's about regular bugs, then a graft should likely hit master in case
that an actual update is needed on another branch.  Other than that,
it'd be silly to mark bugs specifically for e.g. "emacs-team" as still
pending on the account of them not having hit master yet.

Cheers

Re: [workflow] Automatically close bug report when a patch is committed

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

On 2023-09-15, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 14.09.2023 um 15:51 -0700 schrieb Vagrant Cascadian:
>> On 2023-09-10, Liliana Marie Prikler wrote:
>> > Am Donnerstag, dem 07.09.2023 um 09:12 -0700 schrieb Vagrant
>> > Cascadian:
>> > > I am much more comfortable with the "Fixes" convention of:
>> > > 
>> > >   Fixes: https://issues.guix.gnu.org/NNN
>> > I like the idea, but we should also consider the bugs.gnu.org
>> > address
>> > here as well as the convention of putting it into angular
>> > brackets.  In
>> > fact, I might even prefer it if the convention was
>> >   Fixes: Bug description <link>
>> > where bug description is a (possibly empty) name for the bug such
>> > as "Emacs hangs when I press a key" or something.
>> > 
>> > 
>> > As for when to send it, remember that we already send a bunch of
>> > mails to guix-commits@gnu.org as our commit hook?  I think it
>> > shouldn't be too hard to search for the fixes line and send it to
>> > debbugs control.
>> 
>> Well, the complication gets to be ... which branch did it land in? in
>> master, it's fairly obvious... you can just mark it as
>> done/closed/etc. I guess with other branches it makes sense to mark
>> it with the "pending" or maybe some more specific usertag
>> "pending-in-BRANCH"?
> I don't think such a distinction is needed in most cases.  In fact, if
> it's about regular bugs, then a graft should likely hit master in case
> that an actual update is needed on another branch.  Other than that,
> it'd be silly to mark bugs specifically for e.g. "emacs-team" as still
> pending on the account of them not having hit master yet.

I guess I do not consider anything done until it lands in the master
branch, but obviously if it is committed in some branch, it is nice to
flag that somehow. "pending" seems appropriate up until it lands in
master.

Maybe marking by team or branch or whatnot is overkill, sure. Though it
would allow you could see at a glance which branch to look in without
diving into the whole history of the issue...

Of course, I will not make terrible loud noises if folks decide
otherwise. :)

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]