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: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35362 <at> debbugs.gnu.org
Subject: bug#35362: 26.2; [debbugs.el] Automate commit -> debbugs flow (posting patches, closing bugs after pushing)
Date: Tue, 23 Apr 2019 10:03:39 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

Hi Noam,

>> All your defcustoms miss a :version tag. I guess, "27.1" is proper.
>
> Oh, hmm.  Shouldn't the version correspond to the debbugs.el package
> version, since it's not tied to the Emacs version as such?

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.

>> 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.

>>> +(defun debbugs-gnu--git-insert (&rest args)
>>> +  "Insert output of running git with ARGS.
>>> +Throws error if git returns non-zero.  Uses `debbugs-gnu-git-program'."
>>> +  (unless (eql 0 (apply #'process-file
>>> +                        debbugs-gnu-git-program nil '(t t) nil
>>> +                        args))
>>> +    (error "git %s failed: %s" (car args) (buffer-string))))
>>
>> 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.

> 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?

> For example, suppose you are reading the message of ``Bug#1234:

All other examples in this manual use 12345. Do we want to follow?

> Invoke the command @code{debbugs-gnu-pick-commits} and press

Should we give this command a key binding?

> @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.

> @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.

> 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.

Best regards, Michael.

Previous Next

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