From: Michael Albinus <michael.albinus@gmx.de>
To: Noam Postavsky <npostavs@gmail.com>
Cc: 35362@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 [thread overview]
Message-ID: <87tvep87xg.fsf@gmx.de> (raw)
In-Reply-To: <87d0ldsu6w.fsf@gmail.com> (Noam Postavsky's message of "Mon, 22 Apr 2019 15:42:31 -0400")
Noam Postavsky <npostavs@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.
next prev parent reply other threads:[~2019-04-23 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 14:56 bug#35362: 26.2; [debbugs.el] Automate commit -> debbugs flow (posting patches, closing bugs after pushing) Noam Postavsky
2019-04-21 15:23 ` Noam Postavsky
2019-04-21 15:27 ` Noam Postavsky
2019-04-21 19:58 ` Michael Albinus
2019-04-22 19:42 ` Noam Postavsky
2019-04-23 8:03 ` Michael Albinus [this message]
2019-04-25 2:10 ` Noam Postavsky
2019-04-25 12:16 ` Michael Albinus
2019-04-27 13:44 ` Noam Postavsky
2019-04-28 7:53 ` Michael Albinus
2019-05-06 12:17 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tvep87xg.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=35362@debbugs.gnu.org \
--cc=npostavs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.