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

[Giovanni Biscuolo]

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

signature.asc
Description: PGP signature