Seeking a "Patch Champion"

Seeking a "Patch Champion"

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]

Greetings Emacsers!

It has been brought to my attention, a few times now, that many of the patches
submitted to our project -- through the mailing list, and issue reports --
tend to wither and die before getting a chance to be reviewed and merged.

Largely this is because we have so many of them: 435 this year, so far. And no
one (besides myself, who has been fully derelict in this duty) is currently
dedicated to ensuring that each of these patches receives due attention.
Unless someone with commit access has a particular interest in attending to a
patch right away, it generally fades into history.

I would like to change this state of affairs by asking for a core of
volunteers who are willing to champion patches, and ensure that they go
through a process of review before being either rejected or applied.

To assist this effort, I've connected our mailing lists with a service running
on my own VPS (for now) called "Patchwork"[1]:

    http://patchwork.newartisans.com/

Every patch sent -- either on emacs-devel or bug-gnu-emacs -- is captured by
this server and assigned a ticket number. Note: these are not *issue tickets*,
but *patch tickets*, one for each patch, even if multiple patches are
submitted for a single bug[2]. Also, any discussion related to a particular
patch is captured, and preserved along with that patch ticket.

Although Patchwork offers a Web interface, there is also a command-line client
for listing patches, changing their state, delegating them to others, and even
applying them directly into Git. You only need git clone the Patchwork
sources, and use their "pwclient" Python script.[3]

The hope is that this tool will allow our patch champions to more easily tame
the set of outstanding patches, and move them from state to state until they
are either accepted or rejected.

I've pre-seeded the Patchwork server with all the patches from 2016 to date.
If there are more patches from earlier that you'd like to see in the system,
just resend the related e-mail to: patchwork@newartisans.com.

Footnotes: 
[1]  Patchwork relies entirely on free and libre software, notably:
       Patchwork     GPL
       Django        BSD
       Python        Python (GPL compatible)
       MySQL         GPL
       MySQL-python  LGPL
       uwsgi         GPL
       nginx         "2-clause BSD-like"

    Javascript used:
       bootstrap     MIT
       selectize     Apache
       jQuery        MIT

[2]  Related patches may be grouped together into "bundles".

[3]  After setting ~/.pwclientrc to:

    [options]
    default=emacs-devel
    
    [emacs-devel]
    url=http://patchwork.newartisans.com/xmlrpc/
    
    [emacs-bugs]
    url=http://patchwork.newartisans.com/xmlrpc/

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

Hey John,

On 04/24/2016 12:22 AM, John Wiegley wrote:

> Largely this is because we have so many of them: 435 this year, so far. And no
> one (besides myself, who has been fully derelict in this duty) is currently
> dedicated to ensuring that each of these patches receives due attention.
> Unless someone with commit access has a particular interest in attending to a
> patch right away, it generally fades into history.
>
> I would like to change this state of affairs by asking for a core of
> volunteers who are willing to champion patches, and ensure that they go
> through a process of review before being either rejected or applied.
>
> To assist this effort, I've connected our mailing lists with a service running
> on my own VPS (for now) called "Patchwork"[1]:
>
>     http://patchwork.newartisans.com/

This is great. I will try it sometime.

There's one problem in the current list: it doesn't seem to take into 
account the status of the related bugs. Here are a few entries from bugs 
that have already been closed:

http://patchwork.newartisans.com/patch/538/
http://patchwork.newartisans.com/patch/565/
http://patchwork.newartisans.com/patch/553/

Shouldn't they have a different status, at least?

> Every patch sent -- either on emacs-devel or bug-gnu-emacs -- is captured by
> this server and assigned a ticket number. Note: these are not *issue tickets*,
> but *patch tickets*, one for each patch, even if multiple patches are
> submitted for a single bug[2].

Could they be grouped somehow? Most of the time, the next patch 
submitted to a bug report supersedes the previous one.

Best regards,
Dmitry.

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> There's one problem in the current list: it doesn't seem to take into
> account the status of the related bugs. Here are a few entries from bugs
> that have already been closed:

At the present time, I have no way of automating the connection between the
debbugs tracker and the patchwork server. It *could* be done, using the
pwclient utility on the debbugs server to close related issues, but I'm afraid
it's not a switch I can turn on today. :(

>> Every patch sent -- either on emacs-devel or bug-gnu-emacs -- is captured
>> by this server and assigned a ticket number. Note: these are not *issue
>> tickets*, but *patch tickets*, one for each patch, even if multiple patches
>> are submitted for a single bug[2].

> Could they be grouped somehow? Most of the time, the next patch submitted to
> a bug report supersedes the previous one.

I haven't seen any way to do that yet, and it might not be true that there is
always exactly one patch per bug that is the correct one. For now, determining
this will be a job of the patch worker.

Btw, glibc apparently uses Patchwork as well. They've even documented their
workflow with it:

    https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/24/2016 12:54 AM, John Wiegley wrote:

> At the present time, I have no way of automating the connection between the
> debbugs tracker and the patchwork server. It *could* be done, using the
> pwclient utility on the debbugs server to close related issues, but I'm afraid
> it's not a switch I can turn on today. :(

I think it should help a lot. But there's no big hurry.

>> Could they be grouped somehow? Most of the time, the next patch submitted to
>> a bug report supersedes the previous one.
>
> I haven't seen any way to do that yet, and it might not be true that there is
> always exactly one patch per bug that is the correct one. For now, determining
> this will be a job of the patch worker.

What I had in mind is more advanced systems like Gerrit where patch 
submitters work with patchsets directly and can indicate whether a new 
one replaces the old one (that happens somewhat automatically because of 
the workflow: you post the new patch as the successor of the old one 
because you want to preserve continuity and see the previous comments in 
one history with the comments to the current iteration).

Maybe the simplicity of Patchwork will turn out all right. We'll have to 
see.

> Btw, glibc apparently uses Patchwork as well. They've even documented their
> workflow with it:
>
>     https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

Looks fine, but it also shows the simplicity of what's provided: it's a 
repository of patches where we double-check that no patch has gone 
without a second look. And that's it.

We can't comment on them there (i.e. review), or apply with a click of a 
button.

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/24/2016 12:54 AM, John Wiegley wrote:

>     https://sourceware.org/glibc/wiki/Patch%20Review%20Workflow

This page lists a Committed state, separate from Accepted. I don't see 
it in our instance. Should it be added?

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> This page lists a Committed state, separate from Accepted. I don't see it in
> our instance. Should it be added?

Added!

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/26/2016 12:29 AM, John Wiegley wrote:
>>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> This page lists a Committed state, separate from Accepted. I don't see it in
>> our instance. Should it be added?
>
> Added!

Thanks. Should we mark them "archived" as well?

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> Thanks. Should we mark them "archived" as well?

I guess you don't have to, since they won't show up in the default "needs
work" query.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

> Greetings Emacsers!

Hi John,

> I would like to change this state of affairs by asking for a core of
> volunteers who are willing to champion patches, and ensure that they go
> through a process of review before being either rejected or applied.
>
> To assist this effort, I've connected our mailing lists with a service running
> on my own VPS (for now) called "Patchwork"[1]:
>
>     http://patchwork.newartisans.com/


You got a volunteer, assuming that I'm not the only looking at them (it
would be too much work).

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> You got a volunteer, assuming that I'm not the only looking at them (it
> would be too much work).

I think initially it would be you, me, Dmitry and Eli. And of course, others
may join us.

First thing to do is to clear out the patches that have already been either
committed, or rejected, based on what's been said on the MLs.  That should
narrow down the list pretty significantly.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

> First thing to do is to clear out the patches that have already been either
> committed, or rejected, based on what's been said on the MLs.  That should
> narrow down the list pretty significantly.

Is there a way in patchwork to mark them as done?

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> Is there a way in patchwork to mark them as done?

You would change the state to Accepted, and once it's in Git, change it to
Archived.

I'm still trying to figure out why superusers cannot change tickets that are
not delegated to them (meaning no one can re-delegate a ticket that isn't
assigned to someone; you end up needing to do that through the Administrative
interface). Also, I need to create an account for you and Dmitry.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> John Wiegley <jwiegley@gmail.com> writes:

> I'm still trying to figure out why superusers cannot change tickets that are
> not delegated to them (meaning no one can re-delegate a ticket that isn't
> assigned to someone; you end up needing to do that through the
> Administrative interface).

Yay, this is fixed: You and Dmitry (and Eli) should now be able to re-delegate
and modify any of the patches in either project.

I have to keep -bugs and -devel separate, only because Patchwork pays
attention to the List-id in order to segregate patches, so different List-ids
need to be assigned to different Patchwork projects.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> Largely this is because we have so many of them: 435 this year, so far. And no
> one (besides myself, who has been fully derelict in this duty) is currently
> dedicated to ensuring that each of these patches receives due attention.
> Unless someone with commit access has a particular interest in attending to a
> patch right away, it generally fades into history.

Well, that's what happens to patches on emacs-devel.  The ones submitted
to the bug tracker never fade away.

> I would like to change this state of affairs by asking for a core of
> volunteers who are willing to champion patches, and ensure that they go
> through a process of review before being either rejected or applied.
>
> To assist this effort, I've connected our mailing lists with a service running
> on my own VPS (for now) called "Patchwork"[1]:
>
>     http://patchwork.newartisans.com/

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.

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.

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

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Karl Fogel]

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

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

Karl Fogel <kfogel@red-bean.com> writes:

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

The first one is an added burden to the submitter, but the second one
isn't something the submitter has to deal with at all -- it's for the
cat herders.  I mean, patch managers...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>Karl Fogel <kfogel@red-bean.com> writes:
>>>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.
>
>The first one is an added burden to the submitter, but the second one
>isn't something the submitter has to deal with at all -- it's for the
>cat herders.  I mean, patch managers...

Ah, good point, agreed.

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/25/2016 07:40 PM, Lars Magne Ingebrigtsen wrote:

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

If a potential reviewer can't spend the effort to install a package from 
ELPA, they're probably not going to give us a lot of help anyway.

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/25/2016 07:40 PM, Lars Magne Ingebrigtsen wrote:

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

I'm inclined to agree.

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

I don't know if it is: I've just went through the lists, and didn't find 
a single patch within my area of interest that had "fallen through the 
cracks". So I basically had to go and sort all of them into Accepted, 
RFC and Rejected. And several belonging to the issues where the 
discussions hadn't come to the conclusion yet (those I've left untouched).

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

This seems to work well enough. Until we have evidence to the contrary, 
the ability to show bugs with patches in debbugs should be sufficient, I 
think.

Or maybe Patchwork will help other contributors better, I don't know.

If we had switched to a better bug tracker, on the other hand... :)

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> If we had switched to a better bug tracker, on the other hand... :)

One with a better integration with the vc system would be nice, yes.
And a better web interface.  :-)  But I find working with debbugs on a
day to day basis easier than other bug trackers I have to interact with,
because the other bug trackers don't integrate with Emacs.

I mean, you can even use debbugs offline.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/25/2016 11:37 PM, Lars Magne Ingebrigtsen wrote:

>> If we had switched to a better bug tracker, on the other hand... :)
>
> One with a better integration with the vc system would be nice, yes.
> And a better web interface.  :-)

+1 on both.

> But I find working with debbugs on a
> day to day basis easier than other bug trackers I have to interact with,
> because the other bug trackers don't integrate with Emacs.

Not really true. There is e.g. http://www.jemarch.net/hacks/bugz-mode, 
for Bugzilla. I don't know how it compares to the Debbugs package, but 
the description seems reasonable.

I'm sure there are some integrations with other trackers as well. I've 
even seen a package that bridges Org and JIRA (not that I would advocate 
using it ;-)) a couple of weeks ago.

> I mean, you can even use debbugs offline.  :-)

Ehh, not the kind of feature I'd dream of, personally, but I'm sure it 
doesn't hurt. :)

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> There is e.g. http://www.jemarch.net/hacks/bugz-mode,
> for Bugzilla. I don't know how it compares to the Debbugs package, but
> the description seems reasonable.

Ah, nice.  From the description is seems ideal.  I'll try using that at
work...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Well, that's what happens to patches on emacs-devel.

Right now the Patchwork is tracking both -devel and -bugs. If tracking -bugs
is not useful, we can stop doing that.

> The ones submitted to the bug tracker never fade away.

No, but they fade into time, becoming irrelevant against the current version
of the code. I've had several people approach me directly and say that they
won't contribute to Emacs anymore, because their patches were left to rot in
debbugs.

The idea behind Patchwork is that it separates contributed code from (a)
discussions on emacs-devel and (b) problem reports in the bug tracker. A patch
has a great chance of saving us some work, because it's code we don't have to
write. I was hoping that Patchwork would call out these code contributions,
and shorten the time to acceptance.

If debbugs can be modified to just show unapplied patches, maybe this is all
we need. Part of the job of a patch champion would then be to create new
tickets on behalf of submitters who send their code to emacs-devel.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> If debbugs can be modified to just show unapplied patches, maybe this is all
> we need.

If you want a web interface for that, that's

https://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;tag=patch

The Patchworks web interface is nicer, though.

And if you want an Emacs interface, there's `M-x debbugs-gnu-patches',
which I think has a nicer interface.  :-)

> Part of the job of a patch champion would then be to create new
> tickets on behalf of submitters who send their code to emacs-devel.

Sure.  Or you could just forward them to debbugs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> (Or at least the ones that have been marked as such, but that's pretty
> much all of them...)

That is not true.  I thought little elves were tagging bug reports
containing patches, but that doesn't seem to happen as often as I
assume.  As an experiment, I went through the newest 80 open bug reports
that were not tagged as "patch" and looked whether they, indeed, didn't
have any (seemingly workable) patches.  And 8 of them did, as far as I
could judge (very quickly).

Would a command like `M-x debbugs-gnu-mark-as-patch' help?  It could
look for something like a bug number on the current line and then mark
the report as having a patch, and should work in all Emacs mail readers?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Andreas Röhler]

On 23.04.2016 23:22, John Wiegley wrote:
> Greetings Emacsers!
>
> It has been brought to my attention, a few times now, that many of the patches
> submitted to our project -- through the mailing list, and issue reports --
> tend to wither and die before getting a chance to be reviewed and merged.
>

[ ... ]

Hi John,

while backing the effort, being concerned, that way new overhead is created.

Why not keeping all patches at the bug-tracker?

Either a patch relates to a bug - attach it there. In case of not - open 
a new ticket.

A patch-champion keeping an eye at this process and taking action if 
needed will be useful still.

Cheers,

Andreas

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Andreas Röhler <andreas.roehler@online.de> writes:

> Why not keeping all patches at the bug-tracker?
>
> Either a patch relates to a bug - attach it there. In case of not - open a
> new ticket.

I'm ready to go with whatever solution our champions prefer to use. If
debbugs-as-a-patch-tracker works better for Eli, Dmitry and Nicolas, we'll use
debbugs and disable the Patchwork server. Or if Patchwork aids their workflow,
I'll keep it running for however long they want to use it.

It's really up to them. This is about making it easier and more enjoyable to
keep the patches flowing, since nothing is more frustrating than doing the
work of submitting a patch, and then seeing nothing come of it. I'm glad to
hear from Dmitry that this has been happening less of late.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Andreas Röhler <andreas.roehler@online.de> writes:
>
>> Why not keeping all patches at the bug-tracker?
>>
>> Either a patch relates to a bug - attach it there. In case of not - open a
>> new ticket.
>
> I'm ready to go with whatever solution our champions prefer to use. If
> debbugs-as-a-patch-tracker works better for Eli, Dmitry and Nicolas, we'll use
> debbugs and disable the Patchwork server. Or if Patchwork aids their workflow,
> I'll keep it running for however long they want to use it.

Both solutions would work for me.  Whatever solution we choose, it'd be
nice to document it somewhere.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Seeking a "Patch Champion"

[Dmitry Gutov]

On 04/26/2016 05:30 PM, John Wiegley wrote:

> I'm ready to go with whatever solution our champions prefer to use. If
> debbugs-as-a-patch-tracker works better for Eli, Dmitry and Nicolas, we'll use
> debbugs and disable the Patchwork server. Or if Patchwork aids their workflow,
> I'll keep it running for however long they want to use it.

Between Scylla and Charybdis, eh? :)

> I'm glad to
> hear from Dmitry that this has been happening less of late.

I may simply have a narrow-ish area of interest, though. The kind of 
patches that might fall through the crash are likely targeting an area 
without an active maintainer.

An active patch herder might manage those in Patchwork, but as long as 
they are submitted to the bug tracker, they won't be lost (even if no 
one is actively reviewing them).

Though of course it would be much better if the bug tracker assigned a 
tag "patch" to such bug reports automatically.

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> Between Scylla and Charybdis, eh? :)

Well, historically those who two very compelling options, whose actual state
was horrific and led to painful death. So I'm hoping that one of them is NOT
of that sort. :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 26 Apr 2016 23:24:20 +0300
> 
> I may simply have a narrow-ish area of interest, though. The kind of 
> patches that might fall through the crash are likely targeting an area 
> without an active maintainer.
> 
> An active patch herder might manage those in Patchwork, but as long as 
> they are submitted to the bug tracker, they won't be lost (even if no 
> one is actively reviewing them).

I think a more useful approach is to try to handle any patch which you
understand well enough to feel it's about right.  (The cracks between
the areas of our interest are too wide to only handle those within the
areas.)  That still would leave a lot of doubt about whether a patch
could do any harm in some other place or use case; I wonder if we
could come up with some procedure to minimize that chance.

Re: Seeking a "Patch Champion"

[Lars Magne Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Though of course it would be much better if the bug tracker assigned a
> tag "patch" to such bug reports automatically.

It would be.  It seems like there's already some automatic (?) tag
assignments based on the subject header?  Could that be extended to
examining the email bodies for patches?  That doesn't seem like it
should be a very difficult thing to do...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Though of course it would be much better if the bug tracker assigned a
>> tag "patch" to such bug reports automatically.
>
> It would be.  It seems like there's already some automatic (?) tag
> assignments based on the subject header?  Could that be extended to
> examining the email bodies for patches?  That doesn't seem like it
> should be a very difficult thing to do...

Could that work for patches inlined, or only the ones attached to an
email?

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Seeking a "Patch Champion"

[Lars Ingebrigtsen]

Nicolas Petton <nicolas@petton.fr> writes:

> Could that work for patches inlined, or only the ones attached to an
> email?

Finding a regexp to recognise patches shouldn't be that difficult...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> Though of course it would be much better if the bug tracker assigned a
>> tag "patch" to such bug reports automatically.
>
> It would be.  It seems like there's already some automatic (?) tag
> assignments based on the subject header?  Could that be extended to
> examining the email bodies for patches?  That doesn't seem like it
> should be a very difficult thing to do...

I think I would like that more than using patchwork, as it would let me
use Emacs instead of going to a website, and it would be more convenient
(and easier for everybody, I think )to have everything in debbugs.

Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Seeking a "Patch Champion"

[John Wiegley]

>>>>> Nicolas Petton <nicolas@petton.fr> writes:

> I think I would like that more than using patchwork, as it would let me use
> Emacs instead of going to a website, and it would be more convenient (and
> easier for everybody, I think )to have everything in debbugs.

I also agree that a single database is preferable.

Lars, can you extend debbugs to scan for patches that aren't mentioned by
having [PATCH] in the subject line, both for attachments and for inline
patches?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Seeking a "Patch Champion"

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

> Lars, can you extend debbugs to scan for patches that aren't mentioned by
> having [PATCH] in the subject line, both for attachments and for inline
> patches?

I have no power over debbugs.  :-)  I think Glenn is the one that does
most of the work on the machine?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Seeking a "Patch Champion"

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

> Lars, can you extend debbugs to scan for patches that aren't mentioned by
> having [PATCH] in the subject line, both for attachments and for inline
> patches?

M-x debbugs-gnu-search <RET> [RX] ^@@ <RET> package <RET> emacs <RET> <RET>

This returns you all Emacs bugs which have message containing a patch
line starting with "@@". Unfortunately, it returns *all* bugs, even the
closed and/or archived ones (2789 as of today). This is unfortune. You
could filter out the closed bugs by typing "x" (351 bugs are left), but
this is bad wrt performance and load on the debbugs server.

The debbugs interface offers also the attribute "status" with the value
"open", which should discriminate the results to still active bugs. That
doesn't seem to work. Will investigate what's up.

If the interactive command shown above looks useful, I could provide a
function doing the same.

Best regards, Michael.

Re: Seeking a "Patch Champion"

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

John Wiegley <jwiegley@gmail.com> schrieb am Sa., 23. Apr. 2016 um
23:22 Uhr:

> To assist this effort, I've connected our mailing lists with a service
> running
> on my own VPS (for now) called "Patchwork"[1]:
>
>     http://patchwork.newartisans.com/
>
> Every patch sent -- either on emacs-devel or bug-gnu-emacs -- is captured
> by
> this server and assigned a ticket number.
>

Great, thanks! One question though: Is the patch list expected to be
complete? For example, I can't seem to find my patches in the interface.
See, for example, the patch attached to
https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-04/msg00706.html:
I've searched both patch sets for the bug number, yet I can't find the
patch.

[-- Attachment #2: Type: text/html, Size: 1197 bytes --]