unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Karl Fogel <kfogel@red-bean.com>
To: Lars Magne Ingebrigtsen <larsi@gnus.org>
Cc: emacs-devel@gnu.org
Subject: Re: Seeking a "Patch Champion"
Date: Mon, 25 Apr 2016 13:11:04 -0500	[thread overview]
Message-ID: <8737q9h83r.fsf@red-bean.com> (raw)
In-Reply-To: <m3k2jlej68.fsf@gnus.org> (Lars Magne Ingebrigtsen's message of "Mon, 25 Apr 2016 18:40:15 +0200")

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>I'm afraid I don't think this is likely to help much.  Since it's not
>hooked up to the bug tracker, the list of patches on that site will just
>grow increasingly outdated.  Having somebody herd a patch after it's
>already been applied is a waste of everybody's time.

Just having something that auto-detects all the patches on the mailing list, so there's an easy, "one-stop-shopping" place to find them, could help al ot.  Once the Patch Champion knows that a patch is being handled, or at least is being tracked in Debbugs, they can mark the patch as closed in Patchwork.

Patchwork already natively has the states "Accepted", "Rejected", and "Under Review", and has an "archive" feature to get the patch out of the main list.  We can either use those existing features/states, or perhaps make new states if needed -- see patchwork/fixtures/default_states.xml in the Patchwork source tree for more.

>And I don't think adding yet another formality to the already pretty
>complicated "apply this patch already" "work flow" (for want of a better
>word) is the way to go.

Well, I don't think John's proposal adds any burden to the patch *submitter*.  Rather, he is proposing a role, Patch Champion, along with a tool (Patchwork) that makes that role feasible.

The idea here is to reduce the burden on patch submitters, by having the project -- via the Patch Champion(s) -- keep better track of patches that have been posted on the mailing list.

>But the lost patch situation in Emacs is a genuine problem, and one that
>I think may be disencouraging new contributors.  Here's what I think
>should happen:
>
>1) Whenever somebody posts a patch to emacs-devel, and you don't feel
>like applying it at once, tell them "send this via `M-x
>report-emacs-bug', otherwise it'll never be applied".
>
>2) People interested in herding patches should start using debbugs-gnu.
>I've now added another command to make this easier -- just say `M-x
>debbugs-gnu-patches', and you'll get a nice list of all the bug reports
>that contain patches.  (Or at least the ones that have been marked as
>such, but that's pretty much all of them...)

These two ideas would add burden to the patch submitter, I think, unlike John's proposal.

>And I think that debbugs*.el should be included in Emacs core, so that
>we can get some traction here.  Installing a package is apparently way
>too much work for most people...

No objection there, of course.

(Confidential to John: you might be amused to see http://viewvc.red-bean.com/producingoss?view=revision&revision=2965 :-) The "Patch Champion" role seems to be what I call "Patch Manager" in that section.)

Best regards,
-Karl



  reply	other threads:[~2016-04-25 18:11 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-23 21:22 Seeking a "Patch Champion" John Wiegley
2016-04-23 21:45 ` Dmitry Gutov
2016-04-23 21:54   ` John Wiegley
2016-04-25 19:50     ` Dmitry Gutov
2016-04-25 19:59     ` Dmitry Gutov
2016-04-25 21:29       ` John Wiegley
2016-04-25 21:35         ` Dmitry Gutov
2016-04-26 14:27           ` John Wiegley
2016-04-25 11:29 ` Nicolas Petton
2016-04-25 17:37   ` John Wiegley
2016-04-25 18:48     ` Nicolas Petton
2016-04-25 19:17       ` John Wiegley
2016-04-25 19:28         ` John Wiegley
2016-04-25 16:40 ` Lars Magne Ingebrigtsen
2016-04-25 18:11   ` Karl Fogel [this message]
2016-04-25 18:14     ` Lars Magne Ingebrigtsen
2016-04-25 19:22       ` Karl Fogel
2016-04-25 19:51   ` Dmitry Gutov
2016-04-25 20:27   ` Dmitry Gutov
2016-04-25 20:37     ` Lars Magne Ingebrigtsen
2016-04-25 20:51       ` Dmitry Gutov
2016-04-25 21:14         ` Lars Magne Ingebrigtsen
2016-04-25 21:34   ` John Wiegley
2016-04-25 22:04     ` Lars Magne Ingebrigtsen
2016-04-25 23:44   ` Lars Magne Ingebrigtsen
2016-04-26  6:32 ` Andreas Röhler
2016-04-26 14:30   ` John Wiegley
2016-04-26 15:04     ` Nicolas Petton
2016-04-26 20:24     ` Dmitry Gutov
2016-04-26 21:01       ` John Wiegley
2016-04-27  6:16       ` Eli Zaretskii
2016-04-27 14:40       ` Lars Magne Ingebrigtsen
2016-04-27 15:31         ` Nicolas Petton
2016-04-27 15:49           ` Lars Ingebrigtsen
2016-05-02  7:55         ` Nicolas Petton
2016-05-02 20:55           ` John Wiegley
2016-05-02 21:54             ` Lars Ingebrigtsen
2016-05-03  7:58             ` Michael Albinus
2016-04-28 19:30 ` Philipp Stephani

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=8737q9h83r.fsf@red-bean.com \
    --to=kfogel@red-bean.com \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    /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).