On 2023-09-13, Maxim Cournoyer wrote: > Vagrant Cascadian <vagr...@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 n...@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
signature.asc
Description: PGP signature