GNU bug report logs - #35362
26.2; [debbugs.el] Automate commit -> debbugs flow (posting patches, closing bugs after pushing)

Previous Next

Full log

View this message in rfc822 format

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 35362 <at> debbugs.gnu.org
Subject: bug#35362: 26.2; [debbugs.el] Automate commit -> debbugs flow (posting patches, closing bugs after pushing)
Date: Wed, 24 Apr 2019 22:10:52 -0400

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:

> I usually take the Emacs version for the :version attribute. Debbug's
> own version would be better tagged with :package-version; I haven't used
> this attribute, 'tho.

Alright.

>>> debbugs-gnu.el supports both gnus and rmail. Do we miss something for
>>> rmail then?
>>>
>>> (I'm not an rmail user, but Eli is.)
>>
>> Possibly yes, I haven't used rmail so I'm not sure how to test that out.
>
> Me neither. Let's keep it as it is, waiting for protest ... or patches.

Right, maybe later.

>>> Why not `vc-git--call'?
>>
>> I thought relying on a function marked as internal would not be a good
>> idea for an ELPA package which should potentially work across multiple
>> versions of Emacs.  Otherwise vc-git--call should work fine too.
>
> Right. However, this function is stable for years. And its
> implementation looks more robust than your version.

Yes, that's true.  Okay, switched to using it.

>> Once you have committed a patch fixing a bug you usually want to post
>> it to the bug thread for review and testing.  And when the patch is
>> deemed satisfactory and pushed to the official repository, the bug
>> should be marked closed.
>
> Well, this is about local commits, which haven't been pushed yet. Or
> maybe pushed already, but in a branch. Could you pls say?

ok

>> For example, suppose you are reading the message of ``Bug#1234:
>
> All other examples in this manual use 12345. Do we want to follow?

Ah, I suppose we may as well stay consistent.

>> Invoke the command @code{debbugs-gnu-pick-commits} and press
>
> Should we give this command a key binding?

Maybe, but then the question is what map to bind it in.  Is it okay to
start adding things into vc-git-log-view-mode-map?

>> @kbd{RET} to accept the default bug number (which will be 1234 since
>
> This should be @kbd{@key{RET}}, like at other places in this manual.

ok.

>> @vindex debbugs-gnu-read-commit-range-hook
>> The query for commit (or commit range) to use is controlled by
>> @code{debbugs-gnu-read-commit-range-hook}.  Initially it has an entry
>> which operates in @samp{*vc-change-log*} buffers: the default will be
>> the commit under point, or the commit range contained in the region if
>> it is active.
>
> I don't understand (yet), how the description of this variable helps. Is
> the user expected to change the value herself, somehow? Otherwise, we
> might to keep this description out.

The idea is you can add entries that can work with other packages, e.g.,
magit.

>> Additionally, if the remote url matches an entry in
>> @code{debbugs-gnu-git-remote-info-alist}, then its @code{commit-url}
>> subitem is appended to the commit description.  By default this
>> variable is configured for the GNU Emacs and GNU ELPA repositories.
>
> Maybe you add a short sentence, that it is expected that people adapt
> this user option if they run an own Emacs fork, located somewhere else,
> or if they host a repository for own packages.

Ok.  I didn't mention an Emacs fork as an expected variation, as that
would mean a different debbugs server too, which I really just wouldn't
expect to happen.

[0001-Automate-commit-debbugs-workflow-Bug-35362.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.