How to M-x debbugs-gnu with new guix-patches

How to M-x debbugs-gnu with new guix-patches

[Christopher Allan Webber]

So!  We have a new debbugs tracking of guix-patches.  Great!  Those who
are emacs users in the know probably like to use the M-x debbugs-gnu
interface.  Here's what you need to do:

Add this to your .emacs:
  (add-to-list 'debbugs-gnu-all-packages "guix-patches")

Now open up debbugs-gnu:
  C-u M-x debbugs-gnu <RET> <RET> guix-patches <RET> n y

And now you have a nice emacs interface!

I found this documentation on debbugs useful:
  https://www.debian.org/Bugs/Reporting

And also, maybe you want to tag bugs or etc.  Use the 'C' key from the
emacs interface!

Happy bug triaging!

Re: How to M-x debbugs-gnu with new guix-patches

[Catonano]

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

2017-02-12 15:21 GMT+01:00 Christopher Allan Webber <cwebber@dustycloud.org>
:

> So!  We have a new debbugs tracking of guix-patches.  Great!  Those who
> are emacs users in the know probably like to use the M-x debbugs-gnu
> interface.  Here's what you need to do:
>
> Add this to your .emacs:
>   (add-to-list 'debbugs-gnu-all-packages "guix-patches")
>
> Now open up debbugs-gnu:
>   C-u M-x debbugs-gnu <RET> <RET> guix-patches <RET> n y
>
> And now you have a nice emacs interface!
>
> I found this documentation on debbugs useful:
>   https://www.debian.org/Bugs/Reporting
>
> And also, maybe you want to tag bugs or etc.  Use the 'C' key from the
> emacs interface!
>
> Happy bug triaging!
>

Say you want to test one patch that has been submitted to patches-guix

How do you do that ?
How do you extract the patch from within the Emacs Debbugs buffer ?

I see there's a menu that pops up with the mouse-3 button with a "save
as..." issue.

Do you just save it somewhere and then you continue from there ?

Further, there are 2 issues in that menu that make me curious

"View interactively..." that asks me to indicate a Viewer. Which viewer ?
What is this about ?

"Take action on part..." that asks me to indicate an Action. Again, what is
this about ?

Thanks

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

Re: How to M-x debbugs-gnu with new guix-patches

[Pjotr Prins]

I submitted my first patch on debbugs. It is a fairly trivial one for
speedtest-cli which I need because I move around so much ;)

More importantly I wrote some documentation:

  https://github.com/pjotrp/guix-notes/blob/master/HACKING.org#making-a-patch-and-submit-to-the-guix-project

Comments welcome (as usual).

Pj.

Re: How to M-x debbugs-gnu with new guix-patches

[Christopher Allan Webber]

Pjotr Prins writes:

> I submitted my first patch on debbugs. It is a fairly trivial one for
> speedtest-cli which I need because I move around so much ;)
>
> More importantly I wrote some documentation:
>
>   https://github.com/pjotrp/guix-notes/blob/master/HACKING.org#making-a-patch-and-submit-to-the-guix-project
>
> Comments welcome (as usual).
>
> Pj.

This is really nice!  Maybe we should link to it from or put it on the
Guix website somewhere?

gnu-patches back log

[Pjotr Prins]

Now we have debbugs we can see there is a building back-log:

  https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;max-bugs=100;base-order=1;bug-rev=1

A patch like this one

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725

has been two weeks without comment. I think we should not leave patches without
feedback longer than one week - even 3 days, to be honest. It is the surest way
to kill enthusiasm.

To move forward with Guix and to recognise the effort new submitters
put in I would like to ask *all* reviewers to pick an outstanding
patch on a regular basis. If reviewers split the work it should be doable.

Would it be an idea to send out weekly E-mails with patches that had
no attention to a select list of reviewers? Or maybe to the ML as a
whole? Basically it would read:

Summary

    Status
        31 Outstanding
        18 Resolved
    Severity
        49 Normal bugs
    Classification
        22 Patch Available
        9 Unclassified

Patches older than 1 week:

gnu: mumble: Build with 'murmur' server component.  Modified 13 days ago;
gnu: Add blists.                                    Modified 13 days ago;
gnu: Add lush2.                                     Modified 13 days ago;
etc.

Pj.

Re: gnu-patches back log

[Hartmut Goebel]

Am 28.02.2017 um 07:25 schrieb Pjotr Prins:
> Would it be an idea to send out weekly E-mails with patches that had
> no attention to a select list of reviewers? Or maybe to the ML as a
> whole? Basically it would read:

This might be a good idea.

Please mind adding links to that mail so one can easily access the
patches and the "reports". This would make occasional reviewers live
much easier.



-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: gnu-patches back log

[Pjotr Prins]

On Tue, Feb 28, 2017 at 12:14:52PM +0100, Hartmut Goebel wrote:
> Am 28.02.2017 um 07:25 schrieb Pjotr Prins:
> > Would it be an idea to send out weekly E-mails with patches that had
> > no attention to a select list of reviewers? Or maybe to the ML as a
> > whole? Basically it would read:
> 
> This might be a good idea.
> 
> Please mind adding links to that mail so one can easily access the
> patches and the "reports". This would make occasional reviewers live
> much easier.

Also, not all reviewers have push rights. Maybe we can add tags for
'PLEASE REVIEW', 'IN REVIEW', 'HELP WANTED', 'LGTM' and 'PLEASE PUSH'.
Without capitals ;)

That way the masters can quickly scan for pathes that need attention.

Pj.

Re: gnu-patches back log

[Leo Famulari]

On Tue, Feb 28, 2017 at 06:25:31AM +0000, Pjotr Prins wrote:
> Now we have debbugs we can see there is a building back-log:
> 
>   https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;max-bugs=100;base-order=1;bug-rev=1
> 
> A patch like this one
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725
> 
> has been two weeks without comment. I think we should not leave patches without
> feedback longer than one week - even 3 days, to be honest. It is the surest way
> to kill enthusiasm.
> 
> To move forward with Guix and to recognise the effort new submitters
> put in I would like to ask *all* reviewers to pick an outstanding
> patch on a regular basis. If reviewers split the work it should be doable.

We all know that patch review is important. But it's also real work, and
just as hard as writing patches in many cases. I think we all do it when
we find the motivation. 

> Would it be an idea to send out weekly E-mails with patches that had
> no attention to a select list of reviewers? Or maybe to the ML as a
> whole? Basically it would read:

As long as the list of reviewers volunteered for that.

We already get the messages with the patches. I wonder if adding yet
another message to our mail boxes is going to help. At least for me, the
issue is finding the energy to review things, not tools for finding old
patches.

If we are interested in handling submissions more quickly, we could
arrange for package-related changes to be linted and built before they
get sent to the list subscribers. Spending time on a patch series before
learning that the submitter did not even test it reduces my motivation
to review.

Re: gnu-patches back log

[Pjotr Prins]

On Wed, Mar 01, 2017 at 01:16:25AM -0500, Leo Famulari wrote:
> > Would it be an idea to send out weekly E-mails with patches that had
> > no attention to a select list of reviewers? Or maybe to the ML as a
> > whole? Basically it would read:
> 
> As long as the list of reviewers volunteered for that.
> 
> We already get the messages with the patches. I wonder if adding yet
> another message to our mail boxes is going to help. At least for me, the
> issue is finding the energy to review things, not tools for finding old
> patches.

With the 'Journal of Open Source Software' we created such a reminder
and it worked well. The back log of pending pre-reviews disappeared :).

> If we are interested in handling submissions more quickly, we could
> arrange for package-related changes to be linted and built before they
> get sent to the list subscribers. Spending time on a patch series before
> learning that the submitter did not even test it reduces my motivation
> to review.

Automation solves something but not all.

Debbugs is a good step because it displays our shortcomings
immediately. I know Ludo is away now, which explains some back log,
but it should not depend on 1 or 2 people to move forward. The back
log does not look long now - but at this rate I predict it will grow.

Now, the questions are: (1) how to we get master reviewers to push
more patches, (2) how do we get normal contributors to contribute more
reviews - anyone can review a few patches a week - and (3) how do we
get more 'newbie' reviewers (like me) to do more. I am happy to add
LGTM. A normal reviewer can add PLEASE PUSH. And all Ricardo has to do
is push.

Scaling up has to come from more people doing less, rather than less
people doing more. My answer is to lighten the load and 'ask' people
to look at patches. Most people respond to queries.

I would like to ask the Guix mailing list members whether it is
*acceptable* that a good looking patch has not been touched for two
weeks. Like this one

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725

Looks to me like it could go right in, even if it has no tests. And I
bet it was linted. 

I.e., LGTM, and apologies for the submitter. It is just embarrassing
and as a project we can do better *together*. If two weeks is
acceptable, will 4 weeks be acceptable? Where do we draw the line?

Pj.

-- 

Re: gnu-patches back log

[Andy Wingo]

On Wed 01 Mar 2017 09:17, Pjotr Prins <pjotr.public12@thebird.nl> writes:

> I would like to ask the Guix mailing list members whether it is
> *acceptable* that a good looking patch has not been touched for two
> weeks. Like this one
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725

FWIW -- I accept this situation.  I have limited bandwidth and can't do
everything and am not always in a very Guixy place.  If I felt that I
could not accept this, my life would be much worse -- stress, burnout,
etc.

Hopefully the patch situation will improve over time as more people
become committers, and we improve our processes (for example the tags
from your great suggestions).

Andy

Re: gnu-patches back log

[Pjotr Prins]

On Wed, Mar 01, 2017 at 11:42:29AM +0100, Andy Wingo wrote:
> On Wed 01 Mar 2017 09:17, Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > I would like to ask the Guix mailing list members whether it is
> > *acceptable* that a good looking patch has not been touched for two
> > weeks. Like this one
> >
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725
> 
> FWIW -- I accept this situation.  I have limited bandwidth and can't do
> everything and am not always in a very Guixy place.  If I felt that I
> could not accept this, my life would be much worse -- stress, burnout,
> etc.

Last thing we want! And I do appreciate such concerns of every
individual. We do, however, have some 30 people who can push to
savannah:

  https://savannah.gnu.org/project/memberlist.php?group=guix

and we have another even larger group of people without push rights
who do not mind commenting on peers. Even today we should be able to
distribute the load better. 

I am not asking you in particular, but everyone in general, if you
feel like coaching one submission per week. That would take a load
of work away from Ricardo and Ludo and improve speed dramatically.

This is the first thing I am trying :). The main difference with the
existing approach is that I want to have more engagement from fresh
contributors who can also peer review. Review is an excellent way of
learning. How exactly we are going to do this is not clear yet. But
that is what I am thinking. 

Meanwhile I want to know what limits people actually have. I think 2
weeks is not acceptable (but that should be obvious).

Pj.

-- 

Re: gnu-patches back log

[Thomas Danckaert]

From: Pjotr Prins <pjotr.public12@thebird.nl>
Subject: Re: gnu-patches back log
Date: Wed, 1 Mar 2017 11:17:15 +0000

> This is the first thing I am trying :). The main difference with the
> existing approach is that I want to have more engagement from fresh
> contributors who can also peer review. Review is an excellent way of
> learning. How exactly we are going to do this is not clear yet. But
> that is what I am thinking.

Speaking for myself as a new/beginning contributor: there is a finite 
amount of time I can (want to) spend on Guix, and a large number of 
things I want to fix/improve/experiment for myself.  I now try to 
review some patches occasionally, but of course that takes away from 
the time I have to work on the issues I care most about myself.  (And 
for other contributors: time that cannot be spent on the many other 
important things that need to be done.)

I understand that in the long term, time spent supporting new 
contributors (i.e. helping the community grow) will probably benefit 
Guix (and therefore also me) more than trying to do everything 
myself, but it takes some effort to adopt this mindset.

> Meanwhile I want to know what limits people actually have. I think 2
> weeks is not acceptable (but that should be obvious).

Of course this is personal, but for me it is acceptable. I assume 
that, when a patch is good, it will eventually make it in, and accept 
that, sometimes, I have to be patient (of course faster is always 
better).  I see a lot of dedication and effort from everybody here, 
and accept that a patch I submit might not be on the top of anyone's 
priority list.

So, I hear your call to slightly reconsider priorities for my 
Guix-time, and try to spend more time mentoring (and will try to do 
that, as far as I can :) ), but also think contributors should assume 
everybody here is doing their best, and have some patience.

Thomas

Re: gnu-patches back log

[Pjotr Prins]

On Wed, Mar 01, 2017 at 01:48:55PM +0100, Thomas Danckaert wrote:
> > This is the first thing I am trying :). The main difference with the
> > existing approach is that I want to have more engagement from fresh
> > contributors who can also peer review. Review is an excellent way of
> > learning. How exactly we are going to do this is not clear yet. But
> > that is what I am thinking.
> 
> Speaking for myself as a new/beginning contributor: there is a finite amount
> of time I can (want to) spend on Guix, and a large number of things I want
> to fix/improve/experiment for myself.  I now try to review some patches
> occasionally, but of course that takes away from the time I have to work on
> the issues I care most about myself.  (And for other contributors: time that
> cannot be spent on the many other important things that need to be done.)
> 
> I understand that in the long term, time spent supporting new contributors
> (i.e. helping the community grow) will probably benefit Guix (and therefore
> also me) more than trying to do everything myself, but it takes some effort
> to adopt this mindset.
> 
> > Meanwhile I want to know what limits people actually have. I think 2
> > weeks is not acceptable (but that should be obvious).
> 
> Of course this is personal, but for me it is acceptable. I assume that, when
> a patch is good, it will eventually make it in, and accept that, sometimes,
> I have to be patient (of course faster is always better).  I see a lot of
> dedication and effort from everybody here, and accept that a patch I submit
> might not be on the top of anyone's priority list.
> 
> So, I hear your call to slightly reconsider priorities for my Guix-time, and
> try to spend more time mentoring (and will try to do that, as far as I can
> :) ), but also think contributors should assume everybody here is doing
> their best, and have some patience.

Thanks Thomas. Exactly what I am asking. One thing to consider is that
review also allows one to learn about how to do things. To write
scientific papers I learnt the most from reviewing others people's
papers. The mind shift I am asking for is that we stop seeing review
as something that can only be handled by experts.

Some write that the review process is hard - but from what I saw on
the ML it the comments can be split into a number of recurring
sub-types. Like:

- wrong indentation (lint should see that)
- naming conventions
- solution conventions (i.e., standard ways of doing things)
- problems around licensing and included code
- missing tests
- incompleteness
- splitting of packages
- versions (git checkout or old release)

etc. I think it is possible to create a check list with examples that
newcomers can use (and even old hands). During review you can simply
point to the relevant section. 

Maybe we can start a review checklist on the wiki and every time
someone does review, instead of writing it in a message, update the
wiki and point to that section.

That way review could end up being a bunch of URL's. 

Also the person writing a package can point to URL's instead of
explaining everything.

Again, this may appear like extra work, but in the end it could save
us time.

How about that?

Pj.
-- 

Re: gnu-patches back log

[Leo Famulari]

On Wed, Mar 01, 2017 at 11:17:15AM +0000, Pjotr Prins wrote:
> I am not asking you in particular, but everyone in general, if you
> feel like coaching one submission per week. That would take a load
> of work away from Ricardo and Ludo and improve speed dramatically.

Try running `git log --format=full` to see who is actually pushing
commits. It's a significantly more diverse group than just Ricardo and
Ludo.

> This is the first thing I am trying :). The main difference with the
> existing approach is that I want to have more engagement from fresh
> contributors who can also peer review. Review is an excellent way of
> learning. How exactly we are going to do this is not clear yet. But
> that is what I am thinking. 
> 
> Meanwhile I want to know what limits people actually have. I think 2
> weeks is not acceptable (but that should be obvious).

I'm sure that everyone would like for patches to be handled within two
weeks, 3 days, etc. But, what operating system distribution actually
does that? Guix is already one of the most accessible distributions for
new contributors. Many of us are *at the limit* of what we can do for
Guix.

Describing our efforts as "embarrassing" (which you've done more than
once) is demotivating. Please try something else.

By the way, I know that at least several of us give special attention to
patches from new contributors. We are aware of the effects of speedy (or
slow) review.

Plus, I almost never hear anyone talk about all the other important
"boring" work that goes into the distribution: Package maintenance,
security updates and vulnerability review, and bug triage. These are the
other tasks we must balance against patch review. And after that, we can
actually work on features and refactoring.

And yet, I don't badger anyone to do more of that work, because I think
that would actually make them *less interested* in doing it. If they
skim the commit log and mailing lists, they'll know these tasks exist.

Re: gnu-patches back log

[Pjotr Prins]

On Wed, Mar 01, 2017 at 08:14:48AM -0500, Leo Famulari wrote:
> Try running `git log --format=full` to see who is actually pushing
> commits. It's a significantly more diverse group than just Ricardo and
> Ludo.

Sure, I know that.

> I'm sure that everyone would like for patches to be handled within two
> weeks, 3 days, etc. But, what operating system distribution actually
> does that? Guix is already one of the most accessible distributions for
> new contributors. Many of us are *at the limit* of what we can do for
> Guix.

> Describing our efforts as "embarrassing" (which you've done more than
> once) is demotivating. Please try something else.

Just to make sure no one misunderstands me. We are *all* spread thin
and busy - it is the nature of our respective jobs. I may look like I
have too much time (point taken), but that is not true. It is all
about priorities. We have about 5K packages in Guix - still some 15K
to go, I believe. It may happen automatically (Guix is a successful
project already), but sometimes we can do even better.

> By the way, I know that at least several of us give special attention to
> patches from new contributors. We are aware of the effects of speedy (or
> slow) review.

I have no doubt.

> Plus, I almost never hear anyone talk about all the other important
> "boring" work that goes into the distribution: Package maintenance,
> security updates and vulnerability review, and bug triage. These are the
> other tasks we must balance against patch review. And after that, we can
> actually work on features and refactoring.

Leo, I am just discussing because it may help improve things. I am not
disputing the work we want to do and have to do. 

> And yet, I don't badger anyone to do more of that work, because I think
> that would actually make them *less interested* in doing it. If they
> skim the commit log and mailing lists, they'll know these tasks exist.

OK. I was not planning to badger ;). Sometimes describing a problem
can be valuable.  Feel free to ignore.  We all have different itches
to scratch.  I'll shut up again.

Pj.

-- 

Re: gnu-patches back log

[Leo Famulari]

On Wed, Mar 01, 2017 at 02:45:51PM +0000, Pjotr Prins wrote:
> OK. I was not planning to badger ;). Sometimes describing a problem
> can be valuable.  Feel free to ignore.  We all have different itches
> to scratch.  I'll shut up again.

Okay, I really don't want you to shut up. As you say, we all have our
own itches to scratch (my phrase is "motivation is not fungible"), and
Guix should try to make use of everyone's energy.

But I got the impression (probably mistaken) that you felt the
committers / reviewers were choosing to spurn contributions, and it
really bothered me. Like I said, many of us are giving as much time and
energy as we can.

Re: gnu-patches back log

[Pjotr Prins]

On Wed, Mar 01, 2017 at 10:51:14AM -0500, Leo Famulari wrote:
> On Wed, Mar 01, 2017 at 02:45:51PM +0000, Pjotr Prins wrote:
> > OK. I was not planning to badger ;). Sometimes describing a problem
> > can be valuable.  Feel free to ignore.  We all have different itches
> > to scratch.  I'll shut up again.
> 
> Okay, I really don't want you to shut up. As you say, we all have our
> own itches to scratch (my phrase is "motivation is not fungible"), and
> Guix should try to make use of everyone's energy.
> 
> But I got the impression (probably mistaken) that you felt the
> committers / reviewers were choosing to spurn contributions, and it
> really bothered me. Like I said, many of us are giving as much time and
> energy as we can.

Yes, I don't think anyone is ducking responsibilities or work. I have
a huge appreciation for what everyone here is doing. Maybe I should
have been clearer. Even a one-line commit is a great contribution. And
then there are people who put thousands of lines in. It is awesome.
And then there are people contributing documentation. This is a
massive project in almost all dimensions.

Even so, packaging is no rocket science and it scales with people
contributing.  That is my starting point.

Pj.

-- 

Re: gnu-patches back log

[Catonano]

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

2017-03-01 17:07 GMT+01:00 Pjotr Prins <pjotr.public12@thebird.nl>:

> On Wed, Mar 01, 2017 at 10:51:14AM -0500, Leo Famulari wrote:
> > On Wed, Mar 01, 2017 at 02:45:51PM +0000, Pjotr Prins wrote:
> > > OK. I was not planning to badger ;). Sometimes describing a problem
> > > can be valuable.  Feel free to ignore.  We all have different itches
> > > to scratch.  I'll shut up again.
> >
> > Okay, I really don't want you to shut up. As you say, we all have our
> > own itches to scratch (my phrase is "motivation is not fungible"), and
> > Guix should try to make use of everyone's energy.
> >
> > But I got the impression (probably mistaken) that you felt the
> > committers / reviewers were choosing to spurn contributions, and it
> > really bothered me. Like I said, many of us are giving as much time and
> > energy as we can.
>
> Yes, I don't think anyone is ducking responsibilities or work. I have
> a huge appreciation for what everyone here is doing. Maybe I should
> have been clearer. Even a one-line commit is a great contribution. And
> then there are people who put thousands of lines in. It is awesome.
> And then there are people contributing documentation. This is a
> massive project in almost all dimensions.
>
> Even so, packaging is no rocket science and it scales with people
> contributing.  That is my starting point.
>
> Pj.


Wrapping up, I think 2 interesting ideas popped up in this thread

One is the automation of building of new packages patches

Another one is the weekly report about pending patches and merged patches

Both these things could be done and I think both could be useful

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

Re: gnu-patches back log

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

> Wrapping up, I think 2 interesting ideas popped up in this thread
>
> One is the automation of building of new packages patches

I wouldn’t know how to set this up.  Hydra isn’t powerful enough for our
*current* purposes, so I wouldn’t want to increase the load at this
point.

> Another one is the weekly report about pending patches and merged
>patches

I’d rather not have a weekly report (I get enough email through the
various Guix mailing lists already).  The debbugs interface shows all
open patches already.  (We should get more people to use guix-patches
instead of guix-devel, though.)

Other than that I’d like to second everything Leo has written.

I agree with Pjotr that obviously it would be nice to have faster/more
reviews/mentoring.  That’s something everybody can help with, even if it
is just a matter of reviewing licenses or trying to build or run the
package.  But this all falls apart under stress (speaking from
experience here), so it’s best not to force it.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: gnu-patches back log

[Catonano]

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

2017-03-07 13:09 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Catonano <catonano@gmail.com> writes:
>
> > Wrapping up, I think 2 interesting ideas popped up in this thread
> >
> > One is the automation of building of new packages patches
>
> I wouldn’t know how to set this up.  Hydra isn’t powerful enough for our
> *current* purposes, so I wouldn’t want to increase the load at this
> point.
>

Ok :-)


>
> > Another one is the weekly report about pending patches and merged
> >patches
>
> I’d rather not have a weekly report (I get enough email through the
> various Guix mailing lists already).  The debbugs interface shows all
> open patches already.  (We should get more people to use guix-patches
> instead of guix-devel, though.)
>

Ok ! This is also what Ludo is proposing


>
> Other than that I’d like to second everything Leo has written.
>

Sure ! I didn't mean to put off anyone's work !

If that was your impression I apologize, I gave the wrong impression !

I agree with Pjotr that obviously it would be nice to have faster/more
> reviews/mentoring.  That’s something everybody can help with, even if it
> is just a matter of reviewing licenses or trying to build or run the
> package.  But this all falls apart under stress (speaking from
> experience here), so it’s best not to force it.
>

I reviewed one patch only so far, so I take your word for it

I am gearing up with a viable email service and soon I'll be able to use
the Emacs-Debbugs thing to its full potential ;-)

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

Re: gnu-patches back log

[ng0]

On 17-03-01 11:17:15, Pjotr Prins wrote:
> On Wed, Mar 01, 2017 at 11:42:29AM +0100, Andy Wingo wrote:
> > On Wed 01 Mar 2017 09:17, Pjotr Prins <pjotr.public12@thebird.nl> writes:
> > 
> > > I would like to ask the Guix mailing list members whether it is
> > > *acceptable* that a good looking patch has not been touched for two
> > > weeks. Like this one
> > >
> > >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725
> > 
> > FWIW -- I accept this situation.  I have limited bandwidth and can't do
> > everything and am not always in a very Guixy place.  If I felt that I
> > could not accept this, my life would be much worse -- stress, burnout,
> > etc.
> 
> Last thing we want! And I do appreciate such concerns of every
> individual. We do, however, have some 30 people who can push to
> savannah:
> 
>   https://savannah.gnu.org/project/memberlist.php?group=guix
> 
> and we have another even larger group of people without push rights
> who do not mind commenting on peers. Even today we should be able to
> distribute the load better. 
> 
> I am not asking you in particular, but everyone in general, if you
> feel like coaching one submission per week. That would take a load
> of work away from Ricardo and Ludo and improve speed dramatically.
> 
> This is the first thing I am trying :). The main difference with the
> existing approach is that I want to have more engagement from fresh
> contributors who can also peer review. Review is an excellent way of
> learning. How exactly we are going to do this is not clear yet. But
> that is what I am thinking. 
> 
> Meanwhile I want to know what limits people actually have. I think 2
> weeks is not acceptable (but that should be obvious).
> 
> Pj.
> 
> -- 
> 

What prevents me from doing reviews more regular is time and resources
management. I might not be the best person to call when you are hanging
on a rope over a pit on fire (so to speak) because I'm busy at all
fronts.
I did not ask a second time for push permissions because I don't really
like having many accounts and passwords to remember. If we had a
solution where you'd just pull from my git checkout a specific branch or
I would just have to send my ssh key in an OpenPG encrypted and signed
message, that's different than signing up at savannah.gnu.org just for
pasting my OpenPG + SSH key into the profile.
The trouble with volunteer work is scaling the management and problem
solving, and I think it's working out for Guix. Occasionally I get upset
about having to use email, but as long as there's nothing better around
I won't rant about it anymore. Debbugs is okay for now. I don't have to
send emails to point to emails because it's clear which bugs are open
and which are closed.
Debbugs doesn't assign bugs to people and all sorts of other solutions
you could have in other systems, but one step at a time.

We're having a long discussion about the right system to use with the
focus shifting and positions changing, and we try out solutions, realize
failures of solutions which have been attempted to use, and continue to
improve the situation, that's good.

I don't mind to wait. I think 5 weeks - 2 months is where I start to ask
wether anyone has an opinion about the patch.
I have services and patches I'm fixing since last September, but the
problem there is just the nature of the services and Guile still being
new to me, and some limitations of the qemu VM which can be spawned for
tests. It's slowing you down when you have to reconfigure a bare-metal
system just to find the right solution every time.
Especially gnunet-service I'm talking about here. I know I will find the
solution eventually because I'm willing to fix and debug, but it could
be easier with shepherd and the qemu VM.

Re: gnu-patches back log

[John Darrington]

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

On Wed, Mar 01, 2017 at 08:17:39AM +0000, Pjotr Prins wrote:

     I would like to ask the Guix mailing list members whether it is
     *acceptable* that a good looking patch has not been touched for two
     weeks. Like this one
     
       https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725
     
     Looks to me like it could go right in, even if it has no tests. And I
     bet it was linted. 
     
     I.e., LGTM, and apologies for the submitter. It is just embarrassing
     and as a project we can do better *together*. If two weeks is
     acceptable, will 4 weeks be acceptable? Where do we draw the line?
     

We already have a policy that if nobody comments on a patch the submitter
may commit it after two weeks.

Silence gives consent!

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: gnu-patches back log

[Ludovic Courtès]

Hi Pjotr!

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> Now we have debbugs we can see there is a building back-log:
>
>   https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;max-bugs=100;base-order=1;bug-rev=1
>
> A patch like this one
>
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725
>
> has been two weeks without comment. I think we should not leave patches without
> feedback longer than one week - even 3 days, to be honest. It is the surest way
> to kill enthusiasm.

I’ll echo what others wrote: we don’t want to put more pressure on those
who do that review work.  The last thing I’d want is someone burning out
because of that; it’s already hard enough, believe me.

However, we should try hard to balance the review workload more evenly
among the 30 committers.  I’m not sure how to incentivize that, though;
some projects add Reviewed-by tags and then publish stats; would that
help?  A reviewer’s hall of a fame?  :-)

And of course, we should have more committers.

> Would it be an idea to send out weekly E-mails with patches that had
> no attention to a select list of reviewers? Or maybe to the ML as a
> whole? Basically it would read:

Personally I would not use that, but if others want it, we should
set it up!

Thanks,
Ludo’.

Re: gnu-patches back log

[Hartmut Goebel]

Am 06.03.2017 um 17:14 schrieb Ludovic Courtès:
> add Reviewed-by tags

Can git add this automatically? Otherwise it would mean additional
manual work.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: gnu-patches back log

[Ludovic Courtès]

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

Hi Hartmut,

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 06.03.2017 um 17:14 schrieb Ludovic Courtès:
>> add Reviewed-by tags
>
> Can git add this automatically? Otherwise it would mean additional
> manual work.

Actually Git already distinguishes between committer and author, so
you’re probably right.

Based on that, the attached Guile-Git program gives the number of
patches committed on behalf of someone else, and…  [drum roll] we get:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,pp (sort (reviewers repo) reviewer<)
$6 = ((0 . "Nikita Karetnikov")
 (0 . "Cyril Roelandt")
 (0 . "John Darrington")
 (0 . "Jason Self")
 (0 . "Federico Beffa")
 (0 . "rekado")
 (0 . "Taylan Ulrich Bayırlı/Kammer")
 (0 . "Tomáš Čech")
 (0 . "Paul van der Walt")
 (0 . "Ben J. Woodcroft")
 (0 . "Alex Sassmannshausen")
 (0 . "Julien Lepiller")
 (1 . "Andy Wingo")
 (2 . "cyril")
 (2 . "Manolis Ragkousis")
 (2 . "Roel Janssen")
 (2 . "Tobias Geerinckx-Rice")
 (6 . "Christopher Allan Webber")
 (9 . "Hartmut Goebel")
 (13 . "Danny Milosavljevic")
 (17 . "Mathieu Lirzin")
 (29 . "Eric Bavier")
 (36 . "Andreas Enge")
 (38 . "David Craven")
 (40 . "Ben Woodcroft")
 (51 . "David Thompson")
 (52 . "Kei Kebreau")
 (68 . "宋文武")
 (81 . "Mark H Weaver")
 (88 . "Alex Kost")
 (94 . "Ricardo Wurmus")
 (99 . "Marius Bakke")
 (101 . "Efraim Flashner")
 (336 . "Leo Famulari")
 (641 . "Ludovic Courtès"))
--8<---------------cut here---------------end--------------->8---

Not sure if it’s 100% accurate, but it should be a good approximation.
To those with a 1-digit number, please take a look at
<https://bugs.gnu.org/guix-patches> and try to beat your fellow hackers!
:-)

Ludo’.


[-- Attachment #2: the code --]
[-- Type: text/plain, Size: 2321 bytes --]

(use-modules (git)
             (git repository)
             (git reference)
             (git oid)
             (git tag)
             (git commit)
             (git structs)                        ;signature-email, etc.
             (srfi srfi-1)
             (srfi srfi-26)
             (ice-9 match)
             (ice-9 vlist))

(define commit-author*
  (compose signature-name commit-author))
(define commit-committer*
  (compose signature-name commit-committer))

(define-syntax-rule (false-if-git-error exp)
  (catch 'git-error
    (lambda () exp)
    (const #f)))

(define* (fold-commits proc seed repo
                       #:key
                       (start (reference-target
                               (repository-head repo)))
                       end)
  "Call PROC on each commit of REPO, starting at START (an OID), and until
END if specified."
  (let loop ((commit (commit-lookup repo start))
             (result seed))
    (let ((parent (false-if-git-error (commit-parent commit))))
      (if parent
          (if (and end (oid=? (commit-id parent) end))
              (proc parent result)
              (loop parent (proc parent result)))
          result))))

(define (reviewers repo)
  "Return a list of review count/committer pairs."
  (define vhash
    (fold-commits (lambda (commit result)
                    (if (string=? (commit-author* commit)
                                  (commit-committer* commit))
                        result
                        (vhash-cons (commit-committer* commit) #t
                                    result)))
                  vlist-null
                  repo))

  (define committers
    (delete-duplicates
     (fold-commits (lambda (commit result)
                     (cons (commit-committer* commit)
                           result))
                   '()
                   repo)))

  (map (lambda (committer)
         (cons (vhash-fold* (lambda (_ count)
                              (+ 1 count))
                            0
                            committer
                            vhash)
               committer))
       committers))

(define (reviewer< r1 r2)
  (match r1
    ((count1 . name1)
     (match r2
       ((count2 . name2)
        (< count1 count2))))))

(libgit2-init!)

(define repo
  (repository-open "."))

Re: How to M-x debbugs-gnu with new guix-patches

[Catonano]

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

2017-02-26 20:02 GMT+01:00 Christopher Allan Webber <cwebber@dustycloud.org>
:

> Pjotr Prins writes:
>
> > I submitted my first patch on debbugs. It is a fairly trivial one for
> > speedtest-cli which I need because I move around so much ;)
>

Yes, this writeup is way cool

A great reference !

Thank you Pjotr !

BUT ! ;-)

In asking for directions I was referring to the workflow in using the
debbugs-emacs thing, how to save a patch locally when receiving it on the
mailing list, how to apply it

The way I found is a tiny button in the toolbar that saves a patch locally.

But is there anymore to know ? or example, does the debbugs-emacs thing
offer a way to apply a patch to a branch ?

Thanks again !

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

Re: How to M-x debbugs-gnu with new guix-patches

[Ludovic Courtès]

Hi!

Catonano <catonano@gmail.com> skribis:

> In asking for directions I was referring to the workflow in using the debbugs-emacs thing, how to save a patch locally when receiving it on the mailing list, how to apply it 

I just pipe the message (with ‘|’ in Gnus) to “git am -s” and voilà.

> The way I found is a tiny button in the toolbar that saves a patch locally.
>
> But is there anymore to know ? or example, does the debbugs-emacs thing offer a way to apply a patch to a branch ?

No, nothing more than what I described above.

HTH!

Ludo’.