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