all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* [REQ/DISCUSSION] patch managing system
@ 2016-03-20 22:35 Nils Gillmann
  2016-03-21 13:58 ` Nils Gillmann
  0 siblings, 1 reply; 27+ messages in thread
From: Nils Gillmann @ 2016-03-20 22:35 UTC (permalink / raw)
  To: guix-devel

As you maybe already noticed, and I hope this is not just a
temporary impression I have after ~4 months or so, guix-devel is
getting an increasing amount of messages per day and per month.

In my opinion this makes it hard to keep track of patches and
maybe also makes the workflow of people with commit access
harder and we need a patch managing solution.

If you are okay with a temporary (until I find a way for guixsd
dedicated server hosting with them) solution which involves a
virtual server, I can spawn another instance at in-berlin.de and
let some software we decide upon run to help the situation.
This is just a proposal for a discussion, I have not looked into
which software would be useful for us and suitable.

I can do some search on my own, but the base system in my case is
currently limited to debian.

thanks,
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-20 22:35 [REQ/DISCUSSION] patch managing system Nils Gillmann
@ 2016-03-21 13:58 ` Nils Gillmann
  2016-03-21 14:15   ` Ricardo Wurmus
  2016-03-21 15:48   ` [REQ/DISCUSSION] patch managing system Mathieu Lirzin
  0 siblings, 2 replies; 27+ messages in thread
From: Nils Gillmann @ 2016-03-21 13:58 UTC (permalink / raw)
  To: guix-devel

First follow up idea:

Ideal case would be:
 - integration with Guix in the future (the emacs interface and
   other potential future interfaces)
 - integration into Guix website
 - patches can be marked:
   - state (done/open)
   - priority
 - patches can be assigned to more than 1 person
 - webinterface

As we are not at the ideal case and need a software until we get
there, most projects seem to either use mailman, bugzilla,
something equal to prmon.freebsd.org (ports monitor), simple pull
requests on a mirror on a bigger source control system.


what are your thoughts?
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 13:58 ` Nils Gillmann
@ 2016-03-21 14:15   ` Ricardo Wurmus
  2016-03-21 14:34     ` Nils Gillmann
  2016-03-21 16:43     ` Ludovic Courtès
  2016-03-21 15:48   ` [REQ/DISCUSSION] patch managing system Mathieu Lirzin
  1 sibling, 2 replies; 27+ messages in thread
From: Ricardo Wurmus @ 2016-03-21 14:15 UTC (permalink / raw)
  To: Nils Gillmann; +Cc: guix-devel


Nils Gillmann <niasterisk@grrlz.net> writes:

> First follow up idea:
>
> Ideal case would be:
>  - integration with Guix in the future (the emacs interface and
>    other potential future interfaces)
>  - integration into Guix website
>  - patches can be marked:
>    - state (done/open)
>    - priority
>  - patches can be assigned to more than 1 person
>  - webinterface
>
> As we are not at the ideal case and need a software until we get
> there, most projects seem to either use mailman, bugzilla,
> something equal to prmon.freebsd.org (ports monitor), simple pull
> requests on a mirror on a bigger source control system.

I have a very strong aversion to bugzilla and other complicated tracking
systems.  All of the above points are covered by debbugs, which we
already use for bug tracking.

debbugs has an Emacs interface as well as a read-only web interface.

I must admit that I’m not using debbugs regularly for our bug tracker
because I’m not working on bugs very often.  If we really wanted to
track progress on patches we could be using debbugs, but I don’t
actually think it would improve the situation much.

Right now I’m capturing guix-devel emails that I want to look at later
with Org capture, or I simply leave them in an unread state.  The
problem, in my opinion, is not so much keeping track of patches, but
taking the time to review and engage in discussions.  I cannot review as
much as I would like to and for follow up discussions I often miss time
(in front of the computer, and in a reasonably awake state).

I don’t think it’s a software problem, but a people problem.  To deal
with more patches we need more people reviewing patches.  We already
have “guix lint” to point out common problems.  We probably should add a
little helper script for all non-Emacsers that runs Emacs over the
expression to check the indentation.  But other than that I’d just say:
resend a patch if you haven’t received any response within five days or
so.

~~ Ricardo

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 14:15   ` Ricardo Wurmus
@ 2016-03-21 14:34     ` Nils Gillmann
  2016-03-21 15:10       ` Nils Gillmann
  2016-03-21 16:43     ` Ludovic Courtès
  1 sibling, 1 reply; 27+ messages in thread
From: Nils Gillmann @ 2016-03-21 14:34 UTC (permalink / raw)
  To: guix-devel

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> Nils Gillmann <niasterisk@grrlz.net> writes:
>
>> First follow up idea:
>>
>> Ideal case would be:
>>  - integration with Guix in the future (the emacs interface and
>>    other potential future interfaces)
>>  - integration into Guix website
>>  - patches can be marked:
>>    - state (done/open)
>>    - priority
>>  - patches can be assigned to more than 1 person
>>  - webinterface
>>
>> As we are not at the ideal case and need a software until we get
>> there, most projects seem to either use mailman, bugzilla,
>> something equal to prmon.freebsd.org (ports monitor), simple pull
>> requests on a mirror on a bigger source control system.
>
> I have a very strong aversion to bugzilla and other complicated tracking
> systems.  All of the above points are covered by debbugs, which we
> already use for bug tracking.

That's right, rain1 pointed this out to me in irc some moments ago.

> debbugs has an Emacs interface as well as a read-only web interface.
>
> I must admit that I’m not using debbugs regularly for our bug tracker
> because I’m not working on bugs very often.  If we really wanted to
> track progress on patches we could be using debbugs, but I don’t
> actually think it would improve the situation much.
>
> Right now I’m capturing guix-devel emails that I want to look at later
> with Org capture, or I simply leave them in an unread state.  The
> problem, in my opinion, is not so much keeping track of patches, but
> taking the time to review and engage in discussions.  I cannot review as
> much as I would like to and for follow up discussions I often miss time
> (in front of the computer, and in a reasonably awake state).

Would it make sense to have a patches-only list or at least a
separation between [general not-patch-related disussions,
questions, pre-bug report questions] and [patches and their
discussions]?
This would not fix the people and times situation
but eventually prevent situations in the future where we only
have -devel for discussions, questions, patches, pre-bug
questions, and with a growing number of participants more
reviewers might come, but also more questions and other non-patch
related input on the list, making it /maybe/ difficult to
follow.
I think it's better to think ahead and solve problems
before they become problems, but maybe this is too soon.

(sidenote:
I envision something for much later which I will discuss in
another project and see if it fits into what we (in that project)
focus on, maybe in a couple of years it could be useful.)

> I don’t think it’s a software problem, but a people problem.  To deal
> with more patches we need more people reviewing patches.  We already
> have “guix lint” to point out common problems.  We probably should add a
> little helper script for all non-Emacsers that runs Emacs over the
> expression to check the indentation.  But other than that I’d just say:
>
> resend a patch if you haven’t received any response within five days or
> so.

From my perspective, resending does not really help either. It
fills up the mailinglist with duplicates and unless I mention
which of these threads can be considered closed, any version
could be seen as the patch and it only works around the problem
you mentioned and I see - too little people to review and apply
patches.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 14:34     ` Nils Gillmann
@ 2016-03-21 15:10       ` Nils Gillmann
  0 siblings, 0 replies; 27+ messages in thread
From: Nils Gillmann @ 2016-03-21 15:10 UTC (permalink / raw)
  To: guix-devel

Nils Gillmann <niasterisk@grrlz.net> writes:

> Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
>
>> Nils Gillmann <niasterisk@grrlz.net> writes:
>>
>>> First follow up idea:
>>>
>>> Ideal case would be:
>>>  - integration with Guix in the future (the emacs interface and
>>>    other potential future interfaces)
>>>  - integration into Guix website
>>>  - patches can be marked:
>>>    - state (done/open)
>>>    - priority
>>>  - patches can be assigned to more than 1 person
>>>  - webinterface
>>>
>>> As we are not at the ideal case and need a software until we get
>>> there, most projects seem to either use mailman, bugzilla,
>>> something equal to prmon.freebsd.org (ports monitor), simple pull
>>> requests on a mirror on a bigger source control system.
>>
>> I have a very strong aversion to bugzilla and other complicated tracking
>> systems.  All of the above points are covered by debbugs, which we
>> already use for bug tracking.
>
> That's right, rain1 pointed this out to me in irc some moments ago.
>
>> debbugs has an Emacs interface as well as a read-only web interface.
>>
>> I must admit that I’m not using debbugs regularly for our bug tracker
>> because I’m not working on bugs very often.  If we really wanted to
>> track progress on patches we could be using debbugs, but I don’t
>> actually think it would improve the situation much.
>>
>> Right now I’m capturing guix-devel emails that I want to look at later
>> with Org capture, or I simply leave them in an unread state.  The
>> problem, in my opinion, is not so much keeping track of patches, but
>> taking the time to review and engage in discussions.  I cannot review as
>> much as I would like to and for follow up discussions I often miss time
>> (in front of the computer, and in a reasonably awake state).
>
> Would it make sense to have a patches-only list or at least a
> separation between [general not-patch-related disussions,
> questions, pre-bug report questions] and [patches and their
> discussions]?
> This would not fix the people and times situation
> but eventually prevent situations in the future where we only
> have -devel for discussions, questions, patches, pre-bug
> questions, and with a growing number of participants more
> reviewers might come, but also more questions and other non-patch
> related input on the list, making it /maybe/ difficult to
> follow.
> I think it's better to think ahead and solve problems
> before they become problems, but maybe this is too soon.

Appended: maybe not, just went through emacs-devel and it seems
to be working out with discussion and patches.
Only -help at our side, there are some threads in -devel which
would be more suited for -help.

> (sidenote:
> I envision something for much later which I will discuss in
> another project and see if it fits into what we (in that project)
> focus on, maybe in a couple of years it could be useful.)
>
>> I don’t think it’s a software problem, but a people problem.  To deal
>> with more patches we need more people reviewing patches.  We already
>> have “guix lint” to point out common problems.  We probably should add a
>> little helper script for all non-Emacsers that runs Emacs over the
>> expression to check the indentation.  But other than that I’d just say:
>>
>> resend a patch if you haven’t received any response within five days or
>> so.
>
> From my perspective, resending does not really help either. It
> fills up the mailinglist with duplicates and unless I mention
> which of these threads can be considered closed, any version
> could be seen as the patch and it only works around the problem
> you mentioned and I see - too little people to review and apply
> patches.

-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 13:58 ` Nils Gillmann
  2016-03-21 14:15   ` Ricardo Wurmus
@ 2016-03-21 15:48   ` Mathieu Lirzin
  2016-03-21 16:08     ` Mathieu Lirzin
  2016-03-30 20:52     ` Cyril Roelandt
  1 sibling, 2 replies; 27+ messages in thread
From: Mathieu Lirzin @ 2016-03-21 15:48 UTC (permalink / raw)
  To: Nils Gillmann; +Cc: guix-devel

Hi,

Nils Gillmann <niasterisk@grrlz.net> writes:

> As you maybe already noticed, and I hope this is not just a
> temporary impression I have after ~4 months or so, guix-devel is
> getting an increasing amount of messages per day and per month.

Same feeling here.

> In my opinion this makes it hard to keep track of patches and
> maybe also makes the workflow of people with commit access
> harder and we need a patch managing solution.
[...]
> Ideal case would be:
>  - integration with Guix in the future (the emacs interface and
>    other potential future interfaces)
>  - integration into Guix website
>  - patches can be marked:
>    - state (done/open)
>    - priority
>  - patches can be assigned to more than 1 person
>  - webinterface
[...]
> what are your thoughts?

I think keeping track of patches is a valid concern.  However I think
you are not focusing on the actual problem by speaking of adding other
interfaces.  IMO the crucial point to make life of reviewer easier,
would be to automate the repetitive tasks and to have a way to not
forget old unpushed patches.  I think providing interfaces that are not
email based is orthogonal to this.

To automate the repetitive tasks, Cyril Roelandt had started sometimes
ago to work on a bot that was continuously applying and building
incoming patches on top of master and report (by email) if things were
building correctly.  I think that is a good idea that could be extended
by providing a way to send commands to the bot like what is done for
Debbugs.

Cyril: Do you think the bot option is feasible?

-- 
Mathieu Lirzin

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 15:48   ` [REQ/DISCUSSION] patch managing system Mathieu Lirzin
@ 2016-03-21 16:08     ` Mathieu Lirzin
  2016-03-30 20:52     ` Cyril Roelandt
  1 sibling, 0 replies; 27+ messages in thread
From: Mathieu Lirzin @ 2016-03-21 16:08 UTC (permalink / raw)
  To: Cyril Roelandt; +Cc: guix-devel

Mathieu Lirzin <mthl@gnu.org> writes:

> Cyril: Do you think the bot option is feasible?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 14:15   ` Ricardo Wurmus
  2016-03-21 14:34     ` Nils Gillmann
@ 2016-03-21 16:43     ` Ludovic Courtès
  2016-03-22 11:53       ` Nils Gillmann
  2016-04-16 11:13       ` Ludovic Courtès
  1 sibling, 2 replies; 27+ messages in thread
From: Ludovic Courtès @ 2016-03-21 16:43 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Nils Gillmann

Hi!

The best patch-tracking candidate I’ve seen so far is “patches”, written
by/for the QEMU people (the ‘patches’ package in Guix.)

  https://www.gnu.org/software/guix/packages/#patches

I think it has everything most of us want, including an Emacs interface.

The main “difficulty” is setting it up on a machine where it can serve
those patches.json files over HTTP based on the mailing list archive
(which could be synced from <ftp://lists.gnu.org/guix-devel/>) and Git
repo.  There’s a README in the the source tree that explains the
details:

  https://github.com/aliguori/patches/blob/master/README-server.md

Would someone like to set it up somewhere and share a recipe?  I’d be
happy to beta-test it as soon as it’s available!  :-)

Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 16:43     ` Ludovic Courtès
@ 2016-03-22 11:53       ` Nils Gillmann
  2016-03-22 16:26         ` Ludovic Courtès
  2016-04-16 11:13       ` Ludovic Courtès
  1 sibling, 1 reply; 27+ messages in thread
From: Nils Gillmann @ 2016-03-22 11:53 UTC (permalink / raw)
  To: guix-devel

ludo@gnu.org (Ludovic Courtès) writes:

> Hi!
>
> The best patch-tracking candidate I’ve seen so far is “patches”, written
> by/for the QEMU people (the ‘patches’ package in Guix.)
>
>   https://www.gnu.org/software/guix/packages/#patches
>
> I think it has everything most of us want, including an Emacs interface.
>
> The main “difficulty” is setting it up on a machine where it can serve
> those patches.json files over HTTP based on the mailing list archive
> (which could be synced from <ftp://lists.gnu.org/guix-devel/>) and Git
> repo.  There’s a README in the the source tree that explains the
> details:
>
>   https://github.com/aliguori/patches/blob/master/README-server.md
>
> Would someone like to set it up somewhere and share a recipe?  I’d be
> happy to beta-test it as soon as it’s available!  :-)
>
> Ludo’.

Yesterday I got my domains moved back into their old place, so I
will try to read into this and see if I can setup a system
dedicated to this so we could test it.

I agree that we need more people to test and check patches and as
soon as I feel like I can do it I will test and check for other
people, right now I am not 110% sure.
-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-22 11:53       ` Nils Gillmann
@ 2016-03-22 16:26         ` Ludovic Courtès
  2016-03-23  4:44           ` Chris Marusich
  0 siblings, 1 reply; 27+ messages in thread
From: Ludovic Courtès @ 2016-03-22 16:26 UTC (permalink / raw)
  To: Nils Gillmann; +Cc: guix-devel

Nils Gillmann <niasterisk@grrlz.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hi!
>>
>> The best patch-tracking candidate I’ve seen so far is “patches”, written
>> by/for the QEMU people (the ‘patches’ package in Guix.)
>>
>>   https://www.gnu.org/software/guix/packages/#patches
>>
>> I think it has everything most of us want, including an Emacs interface.
>>
>> The main “difficulty” is setting it up on a machine where it can serve
>> those patches.json files over HTTP based on the mailing list archive
>> (which could be synced from <ftp://lists.gnu.org/guix-devel/>) and Git
>> repo.  There’s a README in the the source tree that explains the
>> details:
>>
>>   https://github.com/aliguori/patches/blob/master/README-server.md
>>
>> Would someone like to set it up somewhere and share a recipe?  I’d be
>> happy to beta-test it as soon as it’s available!  :-)
>>
>> Ludo’.
>
> Yesterday I got my domains moved back into their old place, so I
> will try to read into this and see if I can setup a system
> dedicated to this so we could test it.

Awesome, thank you!

Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-22 16:26         ` Ludovic Courtès
@ 2016-03-23  4:44           ` Chris Marusich
  2016-03-23  7:41             ` Ricardo Wurmus
  2016-03-23 16:02             ` Leo Famulari
  0 siblings, 2 replies; 27+ messages in thread
From: Chris Marusich @ 2016-03-23  4:44 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Nils Gillmann

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


While we're talking about patches, I'm curious: how are other people
managing the patches?  In particular, what does the workflow look like
for people who are committing?  Do you manually download the patch (or
patches) to a temporary folder, view it/them, and if you like what you
see, commit it with "git am" to a local repo, then push to origin?

I ask because when I see a patch on the email list, there seems to be a
bit of manual work involved in actually committing it into a local repo.

-- 
Chris

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  4:44           ` Chris Marusich
@ 2016-03-23  7:41             ` Ricardo Wurmus
  2016-03-23  8:15               ` Chris Marusich
  2016-03-23  8:36               ` Alex Kost
  2016-03-23 16:02             ` Leo Famulari
  1 sibling, 2 replies; 27+ messages in thread
From: Ricardo Wurmus @ 2016-03-23  7:41 UTC (permalink / raw)
  To: Chris Marusich; +Cc: guix-devel, Nils Gillmann


Chris Marusich <cmmarusich@gmail.com> writes:

> While we're talking about patches, I'm curious: how are other people
> managing the patches?  In particular, what does the workflow look like
> for people who are committing?  Do you manually download the patch (or
> patches) to a temporary folder, view it/them, and if you like what you
> see, commit it with "git am" to a local repo, then push to origin?

I’m using an email client in Emacs, so the email as well as the attached
patch is shown in a regular text buffer.  When I see the patch I can
directly apply it by running “git am” on the buffer contents, or by
opening a shell and running “git am” on the file associated with the
buffer.

Using Emacs it’s very little work.  It would be more work and probably
more awkward when using an external email client or a web browser.

~~ Ricardo

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  7:41             ` Ricardo Wurmus
@ 2016-03-23  8:15               ` Chris Marusich
  2016-03-23  8:57                 ` Andy Wingo
  2016-03-23  8:36               ` Alex Kost
  1 sibling, 1 reply; 27+ messages in thread
From: Chris Marusich @ 2016-03-23  8:15 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Nils Gillmann

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

Ricardo Wurmus <rekado@elephly.net> writes:

> I’m using an email client in Emacs, so the email as well as the attached
> patch is shown in a regular text buffer.  When I see the patch I can
> directly apply it by running “git am” on the buffer contents, or by
> opening a shell and running “git am” on the file associated with the
> buffer.
>
> Using Emacs it’s very little work.  It would be more work and probably
> more awkward when using an external email client or a web browser.

Fascinating!  I'm also using emacs.  When you say that you run "git am"
on the buffer contents, how do you do that?  I don't see any likely
procedures with "git" in their name (searching via "C-h a").

-- 
Chris

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  7:41             ` Ricardo Wurmus
  2016-03-23  8:15               ` Chris Marusich
@ 2016-03-23  8:36               ` Alex Kost
  2016-03-23  8:54                 ` Chris Marusich
  2016-03-23 22:24                 ` Ludovic Courtès
  1 sibling, 2 replies; 27+ messages in thread
From: Alex Kost @ 2016-03-23  8:36 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel, Nils Gillmann

Ricardo Wurmus (2016-03-23 10:41 +0300) wrote:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> While we're talking about patches, I'm curious: how are other people
>> managing the patches?  In particular, what does the workflow look like
>> for people who are committing?  Do you manually download the patch (or
>> patches) to a temporary folder, view it/them, and if you like what you
>> see, commit it with "git am" to a local repo, then push to origin?
>
> I’m using an email client in Emacs, so the email as well as the attached
> patch is shown in a regular text buffer.  When I see the patch I can
> directly apply it by running “git am” on the buffer contents, or by
> opening a shell and running “git am” on the file associated with the
> buffer.

In Magit, one can use "w w" to apply patches, and "w m" if they
are saved in a "maildir" file, as can be done in Gnus by selecting
several articles (in Summary buffer) and pressing "o".

See (info "(magit) Applying patches") and (info "(gnus) Saving Articles")

-- 
Alex

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  8:36               ` Alex Kost
@ 2016-03-23  8:54                 ` Chris Marusich
  2016-03-23 22:24                 ` Ludovic Courtès
  1 sibling, 0 replies; 27+ messages in thread
From: Chris Marusich @ 2016-03-23  8:54 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel, Nils Gillmann

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

Alex Kost <alezost@gmail.com> writes:

>> I’m using an email client in Emacs, so the email as well as the attached
>> patch is shown in a regular text buffer.  When I see the patch I can
>> directly apply it by running “git am” on the buffer contents, or by
>> opening a shell and running “git am” on the file associated with the
>> buffer.
>
> In Magit, one can use "w w" to apply patches, and "w m" if they
> are saved in a "maildir" file, as can be done in Gnus by selecting
> several articles (in Summary buffer) and pressing "o".
>
> See (info "(magit) Applying patches") and (info "(gnus) Saving Articles")

Wow!  Thanks for the tip.  I'll have to try that one of these days.

-- 
Chris

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  8:15               ` Chris Marusich
@ 2016-03-23  8:57                 ` Andy Wingo
  0 siblings, 0 replies; 27+ messages in thread
From: Andy Wingo @ 2016-03-23  8:57 UTC (permalink / raw)
  To: Chris Marusich; +Cc: guix-devel, Nils Gillmann

On Wed 23 Mar 2016 09:15, Chris Marusich <cmmarusich@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> I’m using an email client in Emacs, so the email as well as the attached
>> patch is shown in a regular text buffer.  When I see the patch I can
>> directly apply it by running “git am” on the buffer contents, or by
>> opening a shell and running “git am” on the file associated with the
>> buffer.
>>
>> Using Emacs it’s very little work.  It would be more work and probably
>> more awkward when using an external email client or a web browser.
>
> Fascinating!  I'm also using emacs.  When you say that you run "git am"
> on the buffer contents, how do you do that?  I don't see any likely
> procedures with "git" in their name (searching via "C-h a").

In Gnus, I use gnus-summary-pipe-output, which is bound to `|'.  Usually
I have to then pipe to ( cd ~/src/guix; git am ).  Low-tech :)

Andy

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  4:44           ` Chris Marusich
  2016-03-23  7:41             ` Ricardo Wurmus
@ 2016-03-23 16:02             ` Leo Famulari
  1 sibling, 0 replies; 27+ messages in thread
From: Leo Famulari @ 2016-03-23 16:02 UTC (permalink / raw)
  To: Chris Marusich; +Cc: guix-devel, Nils Gillmann

On Tue, Mar 22, 2016 at 09:44:47PM -0700, Chris Marusich wrote:
> 
> While we're talking about patches, I'm curious: how are other people
> managing the patches?  In particular, what does the workflow look like
> for people who are committing?  Do you manually download the patch (or
> patches) to a temporary folder, view it/them, and if you like what you
> see, commit it with "git am" to a local repo, then push to origin?
> 
> I ask because when I see a patch on the email list, there seems to be a
> bit of manual work involved in actually committing it into a local repo.

I normally read the patches in mutt.

For application, it varies a bit depending on how many patches there are
and if they are in the same thread, from different people, etc.

For single patches I can use mutt's pipe command (press | in mutt) and
pipe to 'cd ~/guix && git am`.

If there are multiple messages, I tag the messages that contain the
patches I want to apply, and then save all the tagged messages to a
temporary mailbox ~/foo. Then, I just use `git am ~/foo`.

It gets a bit messy if contributors have not used git-send-email.

I bet this workflow be improved with some macros, or by using Emacs ;)
But, applying patches is definitely not a bottleneck for me yet.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23  8:36               ` Alex Kost
  2016-03-23  8:54                 ` Chris Marusich
@ 2016-03-23 22:24                 ` Ludovic Courtès
  2016-03-24  8:53                   ` Alex Kost
  1 sibling, 1 reply; 27+ messages in thread
From: Ludovic Courtès @ 2016-03-23 22:24 UTC (permalink / raw)
  To: Alex Kost; +Cc: guix-devel, Nils Gillmann

Alex Kost <alezost@gmail.com> skribis:

> Ricardo Wurmus (2016-03-23 10:41 +0300) wrote:
>
>> Chris Marusich <cmmarusich@gmail.com> writes:
>>
>>> While we're talking about patches, I'm curious: how are other people
>>> managing the patches?  In particular, what does the workflow look like
>>> for people who are committing?  Do you manually download the patch (or
>>> patches) to a temporary folder, view it/them, and if you like what you
>>> see, commit it with "git am" to a local repo, then push to origin?
>>
>> I’m using an email client in Emacs, so the email as well as the attached
>> patch is shown in a regular text buffer.  When I see the patch I can
>> directly apply it by running “git am” on the buffer contents, or by
>> opening a shell and running “git am” on the file associated with the
>> buffer.
>
> In Magit, one can use "w w" to apply patches, and "w m" if they
> are saved in a "maildir" file, as can be done in Gnus by selecting
> several articles (in Summary buffer) and pressing "o".
>
> See (info "(magit) Applying patches") and (info "(gnus) Saving Articles")

That seems less efficient than what Andy suggests (which is what I do as
well), no?

Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-23 22:24                 ` Ludovic Courtès
@ 2016-03-24  8:53                   ` Alex Kost
  0 siblings, 0 replies; 27+ messages in thread
From: Alex Kost @ 2016-03-24  8:53 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel

Ludovic Courtès (2016-03-24 01:24 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ricardo Wurmus (2016-03-23 10:41 +0300) wrote:
>>
>>> Chris Marusich <cmmarusich@gmail.com> writes:
>>>
>>>> While we're talking about patches, I'm curious: how are other people
>>>> managing the patches?  In particular, what does the workflow look like
>>>> for people who are committing?  Do you manually download the patch (or
>>>> patches) to a temporary folder, view it/them, and if you like what you
>>>> see, commit it with "git am" to a local repo, then push to origin?
>>>
>>> I’m using an email client in Emacs, so the email as well as the attached
>>> patch is shown in a regular text buffer.  When I see the patch I can
>>> directly apply it by running “git am” on the buffer contents, or by
>>> opening a shell and running “git am” on the file associated with the
>>> buffer.
>>
>> In Magit, one can use "w w" to apply patches, and "w m" if they
>> are saved in a "maildir" file, as can be done in Gnus by selecting
>> several articles (in Summary buffer) and pressing "o".
>>
>> See (info "(magit) Applying patches") and (info "(gnus) Saving Articles")
>
> That seems less efficient than what Andy suggests (which is what I do as
> well), no?

I just named one of the possibilities.  People are free to decide what
is more efficient for them :-)

-- 
Alex

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 15:48   ` [REQ/DISCUSSION] patch managing system Mathieu Lirzin
  2016-03-21 16:08     ` Mathieu Lirzin
@ 2016-03-30 20:52     ` Cyril Roelandt
  2016-03-31  6:39       ` Efraim Flashner
  2016-03-31  7:53       ` Ludovic Courtès
  1 sibling, 2 replies; 27+ messages in thread
From: Cyril Roelandt @ 2016-03-30 20:52 UTC (permalink / raw)
  To: Mathieu Lirzin, Nils Gillmann; +Cc: guix-devel

On 03/21/2016 04:48 PM, Mathieu Lirzin wrote:
> To automate the repetitive tasks, Cyril Roelandt had started sometimes
> ago to work on a bot that was continuously applying and building
> incoming patches on top of master and report (by email) if things were
> building correctly.  I think that is a good idea that could be extended
> by providing a way to send commands to the bot like what is done for
> Debbugs.

Yeah, it was a fun experiment. The main issue is that reading mail is
harder than it looks. People attach patches to their mails, they send
them using git-send-email, they attach the output of "git format-patch"
to a regular mail, they have weird encodings, etc. That means there are
lots of cases to tests, and lots of potential bugs. If the "patches"
tool from QEMU does that well already, I'd be in favor of not recoding it :)

That being said, something we really need is a tool that helps us handle
trivial update patches (basically, patches that just update the version
and the hash of a given package). It should apply the patch and run a
script like this one:

$ cat check-update.sh
make || exit 1
for pkg in $(./pre-inst-env guix refresh -l $1 | sed 's/.*: //')
do
        echo "[+] Rebuilding $pkg"
        ./pre-inst-env guix build $pkg
        if [ "$?" -ne "0" ]; then
                echo "[+] Rebuilding $pkg: KO"
                exit 1
        else
                echo "[+] Rebuilding $pkg: OK"
        fi
done

I think we could have a mailing-list dedicated to these trivial update
patches. I'd also be in favor of splitting the mailing-list into many
smaller ones, such as:
- core;
- packages;
- trivial updates.

WDYT?

Cyril.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-30 20:52     ` Cyril Roelandt
@ 2016-03-31  6:39       ` Efraim Flashner
  2016-03-31  7:53       ` Ludovic Courtès
  1 sibling, 0 replies; 27+ messages in thread
From: Efraim Flashner @ 2016-03-31  6:39 UTC (permalink / raw)
  To: Cyril Roelandt; +Cc: guix-devel, Nils Gillmann

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

On Wed, Mar 30, 2016 at 10:52:15PM +0200, Cyril Roelandt wrote:
> On 03/21/2016 04:48 PM, Mathieu Lirzin wrote:
> > To automate the repetitive tasks, Cyril Roelandt had started sometimes
> > ago to work on a bot that was continuously applying and building
> > incoming patches on top of master and report (by email) if things were
> > building correctly.  I think that is a good idea that could be extended
> > by providing a way to send commands to the bot like what is done for
> > Debbugs.
> 
> Yeah, it was a fun experiment. The main issue is that reading mail is
> harder than it looks. People attach patches to their mails, they send
> them using git-send-email, they attach the output of "git format-patch"
> to a regular mail, they have weird encodings, etc. That means there are
> lots of cases to tests, and lots of potential bugs. If the "patches"
> tool from QEMU does that well already, I'd be in favor of not recoding it :)
> 
> That being said, something we really need is a tool that helps us handle
> trivial update patches (basically, patches that just update the version
> and the hash of a given package). It should apply the patch and run a
> script like this one:
> 
> $ cat check-update.sh
> make || exit 1
> for pkg in $(./pre-inst-env guix refresh -l $1 | sed 's/.*: //')
> do
>         echo "[+] Rebuilding $pkg"
>         ./pre-inst-env guix build $pkg
>         if [ "$?" -ne "0" ]; then
>                 echo "[+] Rebuilding $pkg: KO"
>                 exit 1
>         else
>                 echo "[+] Rebuilding $pkg: OK"
>         fi
> done

It'd be best to have it check against hydra also, so we would know to
"not care" if a package that failed to build previously still fails to
build.

> 
> I think we could have a mailing-list dedicated to these trivial update
> patches. I'd also be in favor of splitting the mailing-list into many
> smaller ones, such as:
> - core;
> - packages;
> - trivial updates.
> 
> WDYT?
> 
> Cyril.
> 

I think it really comes down to if we've outgrown GNU's mailing-lists.
We have guix-devel, bugs-guix and help-guix (and guix-commits). As an
interm suggestion we might do better with tagging the subject line with
what it is. The gnunet patches were much easier to find with the [PATCH]
tag.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-30 20:52     ` Cyril Roelandt
  2016-03-31  6:39       ` Efraim Flashner
@ 2016-03-31  7:53       ` Ludovic Courtès
  1 sibling, 0 replies; 27+ messages in thread
From: Ludovic Courtès @ 2016-03-31  7:53 UTC (permalink / raw)
  To: Cyril Roelandt; +Cc: guix-devel, Nils Gillmann

Cyril Roelandt <tipecaml@gmail.com> skribis:

> I think we could have a mailing-list dedicated to these trivial update
> patches. I'd also be in favor of splitting the mailing-list into many
> smaller ones, such as:
> - core;
> - packages;
> - trivial updates.

I’m not sure it would help much because it is often quite easy to
categorize patches in one of these categories just by looking at the
subject line.

However, having that ‘patches’ tool up and running would make a big
difference, I’m sure.  For me, debbugs made a huge difference, in part
thanks to its Emacs mode which integrates well in my workflow; I no
longer lose track of bug reports.  I would expect similar benefits here.

My 2¢,
Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [REQ/DISCUSSION] patch managing system
  2016-03-21 16:43     ` Ludovic Courtès
  2016-03-22 11:53       ` Nils Gillmann
@ 2016-04-16 11:13       ` Ludovic Courtès
  2016-04-28  8:24         ` Patch tracking Ludovic Courtès
  1 sibling, 1 reply; 27+ messages in thread
From: Ludovic Courtès @ 2016-04-16 11:13 UTC (permalink / raw)
  To: guix-devel

ludo@gnu.org (Ludovic Courtès) skribis:

> The best patch-tracking candidate I’ve seen so far is “patches”, written
> by/for the QEMU people (the ‘patches’ package in Guix.)
>
>   https://www.gnu.org/software/guix/packages/#patches
>
> I think it has everything most of us want, including an Emacs interface.
>
> The main “difficulty” is setting it up on a machine where it can serve
> those patches.json files over HTTP based on the mailing list archive
> (which could be synced from <ftp://lists.gnu.org/guix-devel/>) and Git
> repo.  There’s a README in the the source tree that explains the
> details:
>
>   https://github.com/aliguori/patches/blob/master/README-server.md

As an experiment (it may disappear anytime), I generated the
‘patches.json’ file for “patches”, so you can now run:

  guix package -i patches
  patches fetch https://mirror.hydra.gnu.org/patches/patches.json
  patches list status:committed

The “documentation” is at:

  https://github.com/aliguori/patches/blob/master/README.md

The project appears to be inactive though.  :-/

For the record, on the server side, updating involves fetching the
mailing list archive, converting it to Maildir, updating the notmuch
database, the Git repo, and then the patch list (pheew!):

--8<---------------cut here---------------start------------->8---
top_dir="$HOME/patches"
maildir="$top_dir/mail"
checkout="$top_dir/guix"
date_month="`date +'%Y-%m'`"

cd "$top_dir"
wget -q -O "$date_month" "ftp://lists.gnu.org/guix-devel/$date_month"
mb2md -s "$top_dir/$date_month" -d "$maildir"
notmuch new
(cd "$checkout"; git pull)
patches scan
--8<---------------cut here---------------end--------------->8---

Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Patch tracking
  2016-04-16 11:13       ` Ludovic Courtès
@ 2016-04-28  8:24         ` Ludovic Courtès
  2016-04-28 11:30           ` Ben Woodcroft
  0 siblings, 1 reply; 27+ messages in thread
From: Ludovic Courtès @ 2016-04-28  8:24 UTC (permalink / raw)
  To: guix-devel

ludo@gnu.org (Ludovic Courtès) skribis:

> As an experiment (it may disappear anytime), I generated the
> ‘patches.json’ file for “patches”, so you can now run:
>
>   guix package -i patches
>   patches fetch https://mirror.hydra.gnu.org/patches/patches.json
>   patches list status:committed

Please try!  :-)

> The “documentation” is at:
>
>   https://github.com/aliguori/patches/blob/master/README.md
>
> The project appears to be inactive though.  :-/

Good news: development has moved to:

  https://github.com/stefanha/patches

The QEMU folks also suggested looking at “patchew”:

  https://github.com/famz/patchew

An instance for QEMU can be seen at:

  http://140.211.15.4:8383/

Currently it looks very similar to Patchwork (or “patches”).

Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Patch tracking
  2016-04-28  8:24         ` Patch tracking Ludovic Courtès
@ 2016-04-28 11:30           ` Ben Woodcroft
  2016-04-28 12:17             ` Ludovic Courtès
  0 siblings, 1 reply; 27+ messages in thread
From: Ben Woodcroft @ 2016-04-28 11:30 UTC (permalink / raw)
  To: Ludovic Courtès, guix-devel



On 28/04/16 18:24, Ludovic Courtès wrote:
> ludo@gnu.org (Ludovic Courtès) skribis:
>
>> As an experiment (it may disappear anytime), I generated the
>> ‘patches.json’ file for “patches”, so you can now run:
>>
>>    guix package -i patches
>>    patches fetch https://mirror.hydra.gnu.org/patches/patches.json
>>    patches list status:committed
> Please try!  :-)

I quite like the concept and it was easy to get started, but I didn't 
have a lot of success applying patches - I tried one from Rob, Ricardo 
and Manolis. Rob's patch was malformed, while Ricardo's and Manolis' was 
empty.

e.g.

$ patches apply id:87h9emxnk5.fsf@elephly.net
Patch is empty. Was it split wrong?
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

I'm running that version of patches that you just pushed Ludo. Have you 
had a similar experience?

ben

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Patch tracking
  2016-04-28 11:30           ` Ben Woodcroft
@ 2016-04-28 12:17             ` Ludovic Courtès
  2016-05-02  8:25               ` Ricardo Wurmus
  0 siblings, 1 reply; 27+ messages in thread
From: Ludovic Courtès @ 2016-04-28 12:17 UTC (permalink / raw)
  To: Ben Woodcroft; +Cc: guix-devel

Ben Woodcroft <woodibe@gmail.com> skribis:

> On 28/04/16 18:24, Ludovic Courtès wrote:
>> ludo@gnu.org (Ludovic Courtès) skribis:
>>
>>> As an experiment (it may disappear anytime), I generated the
>>> ‘patches.json’ file for “patches”, so you can now run:
>>>
>>>    guix package -i patches
>>>    patches fetch https://mirror.hydra.gnu.org/patches/patches.json
>>>    patches list status:committed
>> Please try!  :-)
>
> I quite like the concept and it was easy to get started, but I didn't
> have a lot of success applying patches - I tried one from Rob, Ricardo
> and Manolis. Rob's patch was malformed, while Ricardo's and Manolis'
> was empty.
>
> e.g.
>
> $ patches apply id:87h9emxnk5.fsf@elephly.net
> Patch is empty. Was it split wrong?
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> I'm running that version of patches that you just pushed Ludo. Have
> you had a similar experience?

Yeah, I think the tool assumes that patches appear right in the message
body, as with ‘git send-email’, but some of us send patches as
attachments (I know Ricardo does).

If we choose to use the tool, we may have to bend our practices a little
bit to placate it.

Thanks for trying it out!

Ludo’.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Patch tracking
  2016-04-28 12:17             ` Ludovic Courtès
@ 2016-05-02  8:25               ` Ricardo Wurmus
  0 siblings, 0 replies; 27+ messages in thread
From: Ricardo Wurmus @ 2016-05-02  8:25 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel, Ben Woodcroft


Ludovic Courtès <ludo@gnu.org> writes:

> Ben Woodcroft <woodibe@gmail.com> skribis:
>
>> On 28/04/16 18:24, Ludovic Courtès wrote:
>>> ludo@gnu.org (Ludovic Courtès) skribis:
>>>
>>>> As an experiment (it may disappear anytime), I generated the
>>>> ‘patches.json’ file for “patches”, so you can now run:
>>>>
>>>>    guix package -i patches
>>>>    patches fetch https://mirror.hydra.gnu.org/patches/patches.json
>>>>    patches list status:committed
>>> Please try!  :-)
>>
>> I quite like the concept and it was easy to get started, but I didn't
>> have a lot of success applying patches - I tried one from Rob, Ricardo
>> and Manolis. Rob's patch was malformed, while Ricardo's and Manolis'
>> was empty.
>>
>> e.g.
>>
>> $ patches apply id:87h9emxnk5.fsf@elephly.net
>> Patch is empty. Was it split wrong?
>> When you have resolved this problem, run "git am --continue".
>> If you prefer to skip this patch, run "git am --skip" instead.
>> To restore the original branch and stop patching, run "git am --abort".
>>
>> I'm running that version of patches that you just pushed Ludo. Have
>> you had a similar experience?
>
> Yeah, I think the tool assumes that patches appear right in the message
> body, as with ‘git send-email’, but some of us send patches as
> attachments (I know Ricardo does).
>
> If we choose to use the tool, we may have to bend our practices a little
> bit to placate it.

Okay, I’ll send patches inline in the future.  I think I set up git
send-mail a while ago, but I’m not yet in the habit of using it
consistently.  I’ll try!

~~ Ricardo

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2016-05-02  8:26 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-20 22:35 [REQ/DISCUSSION] patch managing system Nils Gillmann
2016-03-21 13:58 ` Nils Gillmann
2016-03-21 14:15   ` Ricardo Wurmus
2016-03-21 14:34     ` Nils Gillmann
2016-03-21 15:10       ` Nils Gillmann
2016-03-21 16:43     ` Ludovic Courtès
2016-03-22 11:53       ` Nils Gillmann
2016-03-22 16:26         ` Ludovic Courtès
2016-03-23  4:44           ` Chris Marusich
2016-03-23  7:41             ` Ricardo Wurmus
2016-03-23  8:15               ` Chris Marusich
2016-03-23  8:57                 ` Andy Wingo
2016-03-23  8:36               ` Alex Kost
2016-03-23  8:54                 ` Chris Marusich
2016-03-23 22:24                 ` Ludovic Courtès
2016-03-24  8:53                   ` Alex Kost
2016-03-23 16:02             ` Leo Famulari
2016-04-16 11:13       ` Ludovic Courtès
2016-04-28  8:24         ` Patch tracking Ludovic Courtès
2016-04-28 11:30           ` Ben Woodcroft
2016-04-28 12:17             ` Ludovic Courtès
2016-05-02  8:25               ` Ricardo Wurmus
2016-03-21 15:48   ` [REQ/DISCUSSION] patch managing system Mathieu Lirzin
2016-03-21 16:08     ` Mathieu Lirzin
2016-03-30 20:52     ` Cyril Roelandt
2016-03-31  6:39       ` Efraim Flashner
2016-03-31  7:53       ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.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.