[REQ/DISCUSSION] patch managing system

[REQ/DISCUSSION] patch managing system

[Nils Gillmann]

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

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

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

Re: [REQ/DISCUSSION] patch managing system

[Ricardo Wurmus]

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

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

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

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

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

Re: [REQ/DISCUSSION] patch managing system

[Ludovic Courtès]

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

Re: [REQ/DISCUSSION] patch managing system

[Nils Gillmann]

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

Re: [REQ/DISCUSSION] patch managing system

[Ludovic Courtès]

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

Re: [REQ/DISCUSSION] patch managing system

[Chris Marusich]

[-- 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 --]

Re: [REQ/DISCUSSION] patch managing system

[Ricardo Wurmus]

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

Re: [REQ/DISCUSSION] patch managing system

[Chris Marusich]

[-- 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 --]

Re: [REQ/DISCUSSION] patch managing system

[Andy Wingo]

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

Re: [REQ/DISCUSSION] patch managing system

[Alex Kost]

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

Re: [REQ/DISCUSSION] patch managing system

[Chris Marusich]

[-- 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 --]

Re: [REQ/DISCUSSION] patch managing system

[Ludovic Courtès]

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

Re: [REQ/DISCUSSION] patch managing system

[Alex Kost]

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

Re: [REQ/DISCUSSION] patch managing system

[Leo Famulari]

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.

Re: [REQ/DISCUSSION] patch managing system

[Ludovic Courtès]

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

Patch tracking

[Ludovic Courtès]

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

Re: Patch tracking

[Ben Woodcroft]

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

Re: Patch tracking

[Ludovic Courtès]

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

Re: Patch tracking

[Ricardo Wurmus]

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

Re: [REQ/DISCUSSION] patch managing system

[Mathieu Lirzin]

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

Re: [REQ/DISCUSSION] patch managing system

[Mathieu Lirzin]

Mathieu Lirzin <mthl@gnu.org> writes:

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

Re: [REQ/DISCUSSION] patch managing system

[Cyril Roelandt]

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.

Re: [REQ/DISCUSSION] patch managing system

[Efraim Flashner]

[-- 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 --]

Re: [REQ/DISCUSSION] patch managing system

[Ludovic Courtès]

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