unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).