Adopt a patch!

Adopt a patch!

[Ludovic Courtès]

Hello Guix!

There are lots of cute little patches in need for love at
<https://bugs.gnu.org/guix-patches>.  We can’t let them alone, they need
our help.

Sometimes the submitter went away, sometimes the reviewer did, sometimes
both.  Sometimes the discussion entered bikeshedding territory, the
parties eventually agreed to paint the shed like a rainbow but that
never materialized.

Submitters, reviewers, and bikeshedders alike, let’s join forces, pick
the pieces, and apply all the good bits that are lingering there!  Let
this be the week that’ll put an end to patch loneliness!

Thanks in advance.  :-)

Ludo’.

Tips & tricks: If you use Emacs, try Emacs-Debbugs!  If you don’t, don’t
miss the manual at <https://debbugs.gnu.org/Advanced.html>.

Re: Adopt a patch!

[Arun Isaac]

Would it help to have teams of maintainers for specific packages or a
specific category of packages? Perhaps something like Debian has? Right
now, anyone can review any package. But, no one is "responsible" for any
package, and this feels a little chaotic.

Also, should we accept any package into Guix (provided it is free
software, of course)? Or, should we pick and choose, packaging only
sufficiently mature software? What about unmaintained packages? Debian's
policy is to remove unmaintained packages. What is ours? Perhaps we need
some kind of package popularity contest like Debian has.

These questions are bothering me, because I feel we don't have
sufficient labour power to handle the enormous number of packages out
there. I've been meaning to raise these questions at some point. Though
these questions are somewhat tangential to this thread, I thought it
might be ok to raise them here.

Re: Adopt a patch!

[ng0]

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

Arun Isaac transcribed 0.9K bytes:
> 
> Would it help to have teams of maintainers for specific packages or a
> specific category of packages? Perhaps something like Debian has? Right
> now, anyone can review any package. But, no one is "responsible" for any
> package, and this feels a little chaotic.

As far as I see it we already have teams, just sometimes they change or
work together / blend together. For example I do mostly mail, crypto,
IM and WM related stuff but I also have other things on my list which is
due to another project and should hopefully get taken over as more people
join there.
A group of the same people does R. We have one person doing Icecat and linux-libre.
etc. Of course some packages are left behind at the moment, but you can
step on no ones toes by updating them (which happens more often in
maintainer-per-package OS').

> Also, should we accept any package into Guix (provided it is free
> software, of course)? Or, should we pick and choose, packaging only
> sufficiently mature software? What about unmaintained packages? Debian's
> policy is to remove unmaintained packages. What is ours? Perhaps we need
> some kind of package popularity contest like Debian has.

No. I think as long as the source exists it can find its way into Guix.
As soon as security issues start to show up or other problems, we are
dealing with it. There's a policy already we follow (it might not be
written down of course).
I also think that people will take on packages they need as soon as
they realize that no one will be the person they think that could
update the package they are looking at. It's very hands on and if
when the documentation can express this in an empowering way, it's
good. To just expect that "this group will handle it" doesn't
help in the long run.
For example getmail is considered to be "finished" many years ago
by the author, it simply gets tiny fixes and occasionally features
added when people ask for them. It's mostly in maintenance mode.
We look at python packages and don't package unmaintained ones
if they are absolutely not needed. For example I approach upstream
if I see outdated pythong packages and ask for a resolution.
Maybe we should write our current approach to this down. I don't
think a polpularity contest would do any good.

> These questions are bothering me, because I feel we don't have
> sufficient labour power to handle the enormous number of packages out
> there. I've been meaning to raise these questions at some point. Though
> these questions are somewhat tangential to this thread, I thought it
> might be ok to raise them here.
> 
> 

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://www.krosos.org

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

Re: Adopt a patch!

[Ludovic Courtès]

Hi Arun,

You’re raising good questions.  :-)

Arun Isaac <arunisaac@systemreboot.net> skribis:

> Would it help to have teams of maintainers for specific packages or a
> specific category of packages? Perhaps something like Debian has? Right
> now, anyone can review any package. But, no one is "responsible" for any
> package, and this feels a little chaotic.

We discussed this in the past, at a time when I was more leaning towards
having maintainers like Debian does.

At the time, Andy (I think) suggested that collaborative maintainership
the way we do it might actually “work better” and scale better.  In the
meantime, there have been long discussions in Debian about whether
package maintainers should be dropped.  Some rightfully argued that
maintainership gives a sense of “ownership” to the maintainer(s), which,
whether we want it or not, discourages others from contributing to the
package.

I’m really summarizing here (there were a couple of articles on LWN),
but to me that’s a very good argument.  I’d rather have a sense of
shared responsibility that this.

As for chaos, I don’t think it’s that bad.  :-)  As ng0 wrote, there are
de facto people who are more familiar with specific packages.  They
don’t have an official title, but they are the ones who’d review changes
to these packages and provide advice.  It seems to work well so far.

> Also, should we accept any package into Guix (provided it is free
> software, of course)? Or, should we pick and choose, packaging only
> sufficiently mature software? What about unmaintained packages? Debian's
> policy is to remove unmaintained packages. What is ours? Perhaps we need
> some kind of package popularity contest like Debian has.

Currently the rule is to take any free software package that’s
submitted, but that poses the challenges you’re talking about.

So far, we’ve rarely had issues with unmaintained packages, I think.  We
certainly have packages with zero to few users, but they haven’t caused
us too much pain either.

What is more scary is massive imports from external repos (CPAN, etc.).
I think we cannot handle all of it, not with our “quality” guidelines
and not with the pace at which these repos change.

At the GHM, we were discussing that, probably, we’ll have to accept for
Guix to be a gateway to those repos (at least for the “non-core” subsets
of the repos).  Concretely, one could do “guix package -i cpan!Foo::Bar”
and have the package DAG imported and built live.  It’s either that or
people will use CPAN’s own tools to achieve this.

Thoughts?

Thanks,
Ludo’.

Re: Adopt a patch!

[Ricardo Wurmus]

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

> Hi Arun,
> What is more scary is massive imports from external repos (CPAN, etc.).
> I think we cannot handle all of it, not with our “quality” guidelines
> and not with the pace at which these repos change.
>
> At the GHM, we were discussing that, probably, we’ll have to accept for
> Guix to be a gateway to those repos (at least for the “non-core” subsets
> of the repos).  Concretely, one could do “guix package -i cpan!Foo::Bar”
> and have the package DAG imported and built live.  It’s either that or
> people will use CPAN’s own tools to achieve this.

Unfortunately, this cannot be done for all packages from CPAN, because
many of these packages are used as inputs for other packages that cannot
be installed through importers.

For CRAN updates we’re doing pretty well, I think, but we will certainly
need to improve our update efforts for packages from CPAN and Hackage.

I would like to exclude leaf packages from these repositories in the
future (once the importers become more usable for non-developers), but
I’m not sure that this would help much for all the packages we have
added as inputs for non-importable packages.

--
Ricardo

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

Re: Adopt a patch!

[Maxim Cournoyer]

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

[...]

> What is more scary is massive imports from external repos (CPAN, etc.).
> I think we cannot handle all of it, not with our “quality” guidelines
> and not with the pace at which these repos change.
>
> At the GHM, we were discussing that, probably, we’ll have to accept for
> Guix to be a gateway to those repos (at least for the “non-core” subsets
> of the repos).  Concretely, one could do “guix package -i cpan!Foo::Bar”
> and have the package DAG imported and built live.  It’s either that or
> people will use CPAN’s own tools to achieve this.
>
> Thoughts?

I think as long as our tools for massively updating packages
automatically (guix refresh -u) are on par with our tools to massively
import (guix import) there shouldn't be too many problems?

Maxim

Re: Adopt a patch!

[Arun Isaac]

> At the time, Andy (I think) suggested that collaborative maintainership
> the way we do it might actually “work better” and scale better.  In the
> meantime, there have been long discussions in Debian about whether
> package maintainers should be dropped.  Some rightfully argued that
> maintainership gives a sense of “ownership” to the maintainer(s), which,
> whether we want it or not, discourages others from contributing to the
> package.

Yes, makes sense. Sometimes, "ownership" also makes maintainers somewhat
less polite.

> I’m really summarizing here (there were a couple of articles on LWN),

Links to these articles would be nice. Do you have them?

> but to me that’s a very good argument.  I’d rather have a sense of
> shared responsibility that this.
>
> As for chaos, I don’t think it’s that bad.  :-)  As ng0 wrote, there are
> de facto people who are more familiar with specific packages.  They
> don’t have an official title, but they are the ones who’d review changes
> to these packages and provide advice.  It seems to work well so far.

Just thinking out loud: Maybe, we need more people with commit
access. Theoretically, anyone can review a patch, but ultimately it is
people with commit access who will have to finally apply and push the
patch. As the rate of submission of patches grows, this increases the
work load on those with commit access.

More automation with regard to reviewing patches might help. For
example, would it be possible to automatically or semi-automatically
detect the license of a package? Many packages have multiple licenses,
and it is quite tedious to grep through the source code and identify all
the licenses involved. Even partial automation could be useful
here. Github does some kind of license detection. I have no idea what
kind of algorithm they use, though.

Also, I keep forgetting to return #t at the end of phases. Could there
be some way to auto-detect this?

> What is more scary is massive imports from external repos (CPAN, etc.).
> I think we cannot handle all of it, not with our “quality” guidelines
> and not with the pace at which these repos change.

True. It is very difficult to keep up with those gigantic repos.

> At the GHM, we were discussing that, probably, we’ll have to accept for
> Guix to be a gateway to those repos (at least for the “non-core” subsets
> of the repos).  Concretely, one could do “guix package -i cpan!Foo::Bar”
> and have the package DAG imported and built live.  It’s either that or
> people will use CPAN’s own tools to achieve this.

It would be nice to have some kind of "upstream packaging" (like
AppImage), so that developers can package their software themselves. It
would be a quick way for new projects to get people to try out their
work. I believe there has been discussion and work on these lines in
Guix. I'm not very familiar with it. I'll read up.

Re: Adopt a patch!

[Pjotr Prins]

On Tue, Sep 19, 2017 at 07:52:32PM +0530, Arun Isaac wrote:
> Just thinking out loud: Maybe, we need more people with commit
> access. Theoretically, anyone can review a patch, but ultimately it is
> people with commit access who will have to finally apply and push the
> patch. As the rate of submission of patches grows, this increases the
> work load on those with commit access.

Yes. We do need to think of scaling up even if it is not perceived a
direct problem now. The faster the turn around, the better it is for
submitters and therefore the project.

I think if we agreed that NO one can push their own commits directly
into master/gnu/packages and expand the number of committers greatly
(anyone who has successfully submitted a non-trivial package without
real comment) we can ask more people to look over the patch list. It
ain't that hard. And if someone misbehaves just revert on commit
access.

Some people may turn out to be very active when they get the chance.

Take a look at C4.1. Another Guix hacker pointed me to it about a year
ago. There are some solid ideas here:

http://hintjens.com/blog:93

I agree with Hintjens (who was btw one of the original FOSDEM
organizers) that the more dynamic a project becomes the more
contributions it will attract.

Keep experimenting - we can always revert on ideas. That is my motto.

Pj.

PS debbugs was a great step forward already.

Re: Adopt a patch!

[ng0]

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

Pjotr Prins transcribed 1.4K bytes:
> On Tue, Sep 19, 2017 at 07:52:32PM +0530, Arun Isaac wrote:
> > Just thinking out loud: Maybe, we need more people with commit
> > access. Theoretically, anyone can review a patch, but ultimately it is
> > people with commit access who will have to finally apply and push the
> > patch. As the rate of submission of patches grows, this increases the
> > work load on those with commit access.
> 
> Yes. We do need to think of scaling up even if it is not perceived a
> direct problem now. The faster the turn around, the better it is for
> submitters and therefore the project.
> 
> I think if we agreed that NO one can push their own commits directly
> into master/gnu/packages and expand the number of committers greatly
> (anyone who has successfully submitted a non-trivial package without
> real comment) we can ask more people to look over the patch list. It
> ain't that hard. And if someone misbehaves just revert on commit
> access.
> 
> Some people may turn out to be very active when they get the chance.
> 
> Take a look at C4.1. Another Guix hacker pointed me to it about a year
> ago. There are some solid ideas here:
> 
> http://hintjens.com/blog:93
> 
> I agree with Hintjens (who was btw one of the original FOSDEM
> organizers) that the more dynamic a project becomes the more
> contributions it will attract.
> 
> Keep experimenting - we can always revert on ideas. That is my motto.
> 
> Pj.
> 
> PS debbugs was a great step forward already.

Personally among other ideas I already follow,
I like the approach the Linux project has:

https://www.youtube.com/watch?v=KJ9Y0midtW4&feature=youtu.be
http://blog.ffwll.ch/2017/01/maintainers-dont-scale.html
http://blog.ffwll.ch/slides/lca-2017.pdf
https://www.linux.conf.au/schedule/presentation/57/

There's also some interesting links in there aswell.

There are some more recent post of this maintainer
at http://blog.ffwll.ch/
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://www.krosos.org

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

Re: Adopt a patch!

[Arun Isaac]

Pjotr Prins writes:

> On Tue, Sep 19, 2017 at 07:52:32PM +0530, Arun Isaac wrote:
>> Just thinking out loud: Maybe, we need more people with commit
>> access. Theoretically, anyone can review a patch, but ultimately it is
>> people with commit access who will have to finally apply and push the
>> patch. As the rate of submission of patches grows, this increases the
>> work load on those with commit access.
>
> Yes. We do need to think of scaling up even if it is not perceived a
> direct problem now. The faster the turn around, the better it is for
> submitters and therefore the project.
>
> I think if we agreed that NO one can push their own commits directly
> into master/gnu/packages and expand the number of committers greatly
> (anyone who has successfully submitted a non-trivial package without
> real comment) we can ask more people to look over the patch list. It
> ain't that hard. And if someone misbehaves just revert on commit
> access.
>
> Some people may turn out to be very active when they get the chance.
>
> Take a look at C4.1. Another Guix hacker pointed me to it about a year
> ago. There are some solid ideas here:
>
> http://hintjens.com/blog:93

I have not come across C4.1 before, and it seems very interesting. At
the very least, we should try out something similar.

> I agree with Hintjens (who was btw one of the original FOSDEM
> organizers) that the more dynamic a project becomes the more
> contributions it will attract.
>
> Keep experimenting - we can always revert on ideas. That is my motto.

I agree.

> PS debbugs was a great step forward already.

debbugs is probably better than having a single mailing list, but as
Hartmut Goebel mentioned it is far from ideal. We really need gitea,
gitlab or something similar.

The number of things that need to be done manually in our current
workflow is quite painful. It's ok if it was only once in a while, but
having to do it everyday makes it really difficult.

Re: Adopt a patch!

[Adonay Felipe Nogueira]

What about Kallithea ([1])? Alternativelly, we could use the
tasks-and-issue trackers already available from GNU Savannah (although I
don't know if this one supports the so called "pull/merge request"
buttom).

NOTE I don't quite like the "pull/merge request" buttom. I'm in favor of
more people having commit access. However, I don't want myself to have
that commit access --- I don't feel confident enough. ;)

[1] <https://kallithea-scm.org/>.

Arun Isaac <arunisaac@systemreboot.net> writes:

>
> I have not come across C4.1 before, and it seems very interesting. At
> the very least, we should try out something similar.
>
>
> I agree.
>
>
> debbugs is probably better than having a single mailing list, but as
> Hartmut Goebel mentioned it is far from ideal. We really need gitea,
> gitlab or something similar.
>
> The number of things that need to be done manually in our current
> workflow is quite painful. It's ok if it was only once in a while, but
> having to do it everyday makes it really difficult.
>
>

-- 
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
  gratis).
- "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
  Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
  GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
  (apenas sem DRM), PNG, TXT, WEBM.

Re: Adopt a patch!

[ng0]

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

Adonay Felipe Nogueira transcribed 1.5K bytes:
> What about Kallithea ([1])? Alternativelly, we could use the

Kallithea has no issue management (I've been slow on working on
the package, but upstream is slow aswell, so yeah…).

> tasks-and-issue trackers already available from GNU Savannah (although I
> don't know if this one supports the so called "pull/merge request"
> buttom).
> 
> NOTE I don't quite like the "pull/merge request" buttom. I'm in favor of
> more people having commit access. However, I don't want myself to have
> that commit access --- I don't feel confident enough. ;)
> 
> [1] <https://kallithea-scm.org/>.
> 
> Arun Isaac <arunisaac@systemreboot.net> writes:
> 
> >
> > I have not come across C4.1 before, and it seems very interesting. At
> > the very least, we should try out something similar.
> >
> >
> > I agree.
> >
> >
> > debbugs is probably better than having a single mailing list, but as
> > Hartmut Goebel mentioned it is far from ideal. We really need gitea,
> > gitlab or something similar.
> >
> > The number of things that need to be done manually in our current
> > workflow is quite painful. It's ok if it was only once in a while, but
> > having to do it everyday makes it really difficult.
> >
> >
> 
> -- 
> - https://libreplanet.org/wiki/User:Adfeno
> - Palestrante e consultor sobre /software/ livre (não confundir com
>   gratis).
> - "WhatsApp"? Ele não é livre. Por favor, use o GNU Ring ou o Tox.
> - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
> - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
>   Office, MP3, MP4, WMA, WMV.
> - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
>   GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
>   (apenas sem DRM), PNG, TXT, WEBM.
> 
> 

-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://www.krosos.org

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

Re: Adopt a patch!

[Hartmut Goebel]

Am 19.09.2017 um 16:22 schrieb Arun Isaac:
> Just thinking out loud: Maybe, we need more people with commit
> access. Theoretically, anyone can review a patch, but ultimately it is
> people with commit access who will have to finally apply and push the
> patch. As the rate of submission of patches grows, this increases the
> work load on those with commit access.

It is not only the work load, but also the work-flow which makes it hard
for occasional reviewers and committers. The mail-interface might be
great for those who are used to it, but it requires one to subscribe to
the patch-mainling-list, keep an eye on review, download the patch, lint
the patch, reply to the mail. If the patch is okay, I need to
pull--rebase on the current master, push, write a mail for closing the
bug-entry. This means switching forth and back between mail, shell, and
browser.

These are far too much manual steps. An if I only have little time,
patches are piling up. The mailbox  get cluttered by patches I do not
follow.

This woes! And this is why I'm not regularly reviewing patches.

Compare it with an integrated workflow on e.g. Gitlab or github: The
list of patches to review is always up to date, same for the state and
comments. Using CI (gitlabs integrated pipeline are great!) saves me a
lot of work, e.g. linting. If the patch is okay, it is a single click
(okay, maybe 5 clicks) to rebase i on top of master. The patch is closed
automatically, the submitter is notified, bookkeeping (referencing to
the commit) is done.

We already discussed using e.g. goks last year with no result. Maybe
it's time to restart the approach.

-- 
Regards
Hartmut Goebel

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

Re: Adopt a patch!

[Ricardo Wurmus]

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

> It is not only the work load, but also the work-flow […] This means
> switching forth and back between mail, shell, and browser.
[…]
> Compare it with an integrated workflow on e.g. Gitlab or github […]

How does even more reliance on a browser help here?  Surely, we can
automate more things without imposing a web browser-based workflow to
everyone.

--
Ricardo

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

Re: Adopt a patch!

[Maxim Cournoyer]

Ricardo Wurmus <rekado@elephly.net> writes:

> Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
>
>> It is not only the work load, but also the work-flow […] This means
>> switching forth and back between mail, shell, and browser.
> […]
>> Compare it with an integrated workflow on e.g. Gitlab or github […]
>
> How does even more reliance on a browser help here?  Surely, we can
> automate more things without imposing a web browser-based workflow to
> everyone.

+1. I don think the glossy interfaces of Github & co. add much to the
table in terms of automation. If you want to test the software, you
still have to checkout a local copy of it anyway (i.e., leave the
browser).

Maxim

Re: Adopt a patch!

[Adonay Felipe Nogueira]

I agree. :)

I rarely contribute to these places where there is such web interfaces.

I like GNU Savannah (and Savane, the software) because it notifies
through email like a mailing list would do, but I don't know if one can
reply directly to the emails. Debbugs seems supperior because it allows
replying directly and also keeps the bug/item history constant (not by
date like usual mailing lists do).

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

>
> +1. I don think the glossy interfaces of Github & co. add much to the
> table in terms of automation. If you want to test the software, you
> still have to checkout a local copy of it anyway (i.e., leave the
> browser).
>
> Maxim
>
>

Re: Adopt a patch!

[Ricardo Wurmus]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
>>
>>> It is not only the work load, but also the work-flow […] This means
>>> switching forth and back between mail, shell, and browser.
>> […]
>>> Compare it with an integrated workflow on e.g. Gitlab or github […]
>>
>> How does even more reliance on a browser help here?  Surely, we can
>> automate more things without imposing a web browser-based workflow to
>> everyone.
>
> +1. I don think the glossy interfaces of Github & co. add much to the
> table in terms of automation. If you want to test the software, you
> still have to checkout a local copy of it anyway (i.e., leave the
> browser).

FWIW, I didn’t mean to claim that there are no problems with the
email-based workflow.  I just think that we should improve upon it with
deliberation instead of jumping to the conclusion that Gitlab or Github
would be better.

-- 
Ricardo

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

Re: Adopt a patch!

[Pjotr Prins]

On Thu, Sep 21, 2017 at 10:31:29PM +0200, Ricardo Wurmus wrote:
> FWIW, I didn’t mean to claim that there are no problems with the
> email-based workflow.  I just think that we should improve upon it with
> deliberation instead of jumping to the conclusion that Gitlab or Github
> would be better.

I think we can have both. We are still stuck in this idea that there
should only be one tree. The Linux kernel is proving differently.

Pj.

Re: Adopt a patch!

[Kei Kebreau]

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

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

> On Thu, Sep 21, 2017 at 10:31:29PM +0200, Ricardo Wurmus wrote:
>> FWIW, I didn’t mean to claim that there are no problems with the
>> email-based workflow.  I just think that we should improve upon it with
>> deliberation instead of jumping to the conclusion that Gitlab or Github
>> would be better.
>
> I think we can have both. We are still stuck in this idea that there
> should only be one tree. The Linux kernel is proving differently.
>
> Pj.

I agree. As long as we aren't solely reliant on a web browser for
contribution, having two interfaces through which to contribute would be
beneficial to people who aren't already familiar with Emacs. Perhaps the
people streamlining the Gitlab and Emacs interfaces can collaborate to
minimize friction between contributions through each interface.

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

Re: Adopt a patch!

[Thomas Danckaert]

From: Ricardo Wurmus <rekado@elephly.net>
Subject: Re: Adopt a patch!
Date: Thu, 21 Sep 2017 22:31:29 +0200

>>>> It is not only the work load, but also the work-flow […] This means
>>>> switching forth and back between mail, shell, and browser.
>>> […]
>>>> Compare it with an integrated workflow on e.g. Gitlab or github […]
>>>
>>> How does even more reliance on a browser help here?  Surely, we can
>>> automate more things without imposing a web browser-based workflow to
>>> everyone.
>>
>> +1. I don think the glossy interfaces of Github & co. add much to the
>> table in terms of automation. If you want to test the software, you
>> still have to checkout a local copy of it anyway (i.e., leave the
>> browser).
> 
> FWIW, I didn’t mean to claim that there are no problems with the
> email-based workflow.  I just think that we should improve upon it with
> deliberation instead of jumping to the conclusion that Gitlab or Github
> would be better.

I don't mind the e-mail-based workflow in principle, and find it has
some advantages, but there are a few practical issues.  I'll list my
frustrations, maybe there are concrete solutions for some of them:

 - I find that saving a long patch series from a bunch of e-mails, and
   applying them all to a local git checkout is tedious, with a lot of
   potential to miss a patch, apply a wrong one, or otherwise screw up
   (not to mention patches occasionally get mangled somewhere in the
   e-mail pipeline, so git won't apply them).  Also, sometimes patches
   are in the message body, at other times they are attachments,
   ... It *is* a lot of error-prone manual work, compared to just
   fetching a branch with git.  I think this is where the “glossy
   interfaces of Github & co.” do have an advantage.

   Perhaps there are better ways to deal with this, though... Am I
   missing some tricks to easily retrieve a bunch of patches from
   e-mails, and apply them?  Maybe a tutorial by someone who finds the
   current workflow comfortable, could already help.

The other issue is that, in my opinion, the only user-friendly way to
interact with debbugs, is using emacs + debbugs-gnu, once you are
familiar with both.  I think that's a really high barrier.

- I briefly subscribed to the guix-patches mailing list, but found the
  volume of e-mail much too high.

- That leaves debbugs.  I find the web interface quite terrible, it's
   just walls of text you have to find your way through. For example,
   Github's “issues” are much more readable (and you can interact with
   them via e-mail, too).

- The debbugs emacs interface is quite ok (at least there's a threaded
  conversation view), although now you have to learn to use Gnus if
  you want to participate in the conversation.

So I do see the appeal of something like gitlab, but I also wonder how
it could be integrated in the current workflow.  I think it could help
a lot if debbugs took some ideas from github/gitlab, but I don't think
debbugs is actively worked on?

Thomas

Re: Adopt a patch!

[Ludovic Courtès]

Hi Thomas,

I understand and sympathize with your arguments.  In fact, this has been
a long running theme, and we discussed it at last year’s FOSDEM at
length.  :-)

Thomas Danckaert <post@thomasdanckaert.be> skribis:

> So I do see the appeal of something like gitlab, but I also wonder how
> it could be integrated in the current workflow.  I think it could help
> a lot if debbugs took some ideas from github/gitlab, but I don't think
> debbugs is actively worked on?

At FOSDEM, while we have having a drink late at night, someone said
“Let’s just write a nice Web interface to Debbugs in Guile!”, and we
were all like “Yeah, let’s do that!”.  But of course on the next
morning, we were all thinking about something else already.  ;-)

So, I don’t know!  I’m still open to experimenting with a local
GitLab/Kallithea/whatever instance.  If someone writes packages and a
GuixSD service, that could be easy.  Hint, hint!  :-)

Ludo’.

Re: Adopt a patch!

[ng0]

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

Ludovic Courtès transcribed 1.0K bytes:
> Hi Thomas,
> 
> I understand and sympathize with your arguments.  In fact, this has been
> a long running theme, and we discussed it at last year’s FOSDEM at
> length.  :-)
> 
> Thomas Danckaert <post@thomasdanckaert.be> skribis:
> 
> > So I do see the appeal of something like gitlab, but I also wonder how
> > it could be integrated in the current workflow.  I think it could help
> > a lot if debbugs took some ideas from github/gitlab, but I don't think
> > debbugs is actively worked on?
> 
> At FOSDEM, while we have having a drink late at night, someone said
> “Let’s just write a nice Web interface to Debbugs in Guile!”, and we
> were all like “Yeah, let’s do that!”.  But of course on the next
> morning, we were all thinking about something else already.  ;-)
> 
> So, I don’t know!  I’m still open to experimenting with a local
> GitLab/Kallithea/whatever instance.  If someone writes packages and a
> GuixSD service, that could be easy.  Hint, hint!  :-)
> 
> Ludo’.
> 
> 

I would not bet on Kallithea. I hope it changes, but it seemed not
very active. Responsive (the team), but last time I tried working
on it was 6 months ago.

Pagure is a Fedora/Red-Hat project. Seems promising, although a bit
early. It seems functional enough for Fedora, and so far it's the
only one I would use.

There's a ton more we looked at. Building Gitlab from source is
supposedly harder than pagure, as pagure just depends on python
modules. I should pick up this branch again. If you don't mind the
wait, I could arrange this after the majority of the current task
is done.

Of course anyone could pull from my remote and work on pagure ;)
-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://dist.ng0.infotropique.org/dist/keys/
https://www.infotropique.org https://ng0.infotropique.org

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

Re: Adopt a patch!

[Maxim Cournoyer]

Hi Thomas,

Thomas Danckaert <post@thomasdanckaert.be> writes:

> I don't mind the e-mail-based workflow in principle, and find it has
> some advantages, but there are a few practical issues.  I'll list my
> frustrations, maybe there are concrete solutions for some of them:
>
>  - I find that saving a long patch series from a bunch of e-mails, and
>    applying them all to a local git checkout is tedious, with a lot of
>    potential to miss a patch, apply a wrong one, or otherwise screw up
>    (not to mention patches occasionally get mangled somewhere in the
>    e-mail pipeline, so git won't apply them).  Also, sometimes patches
>    are in the message body, at other times they are attachments,
>    ... It *is* a lot of error-prone manual work, compared to just
>    fetching a branch with git.  I think this is where the “glossy
>    interfaces of Github & co.” do have an advantage.
>
>    Perhaps there are better ways to deal with this, though... Am I
>    missing some tricks to easily retrieve a bunch of patches from
>    e-mails, and apply them?  Maybe a tutorial by someone who finds the
>    current workflow comfortable, could already help.

In Gnus, with the cursor on the body of a message, you can pipe the
patch-in-body using the `|' shortcut or M-x gnus-summary-pipe-output and
then giving it the command "git am -s" as Ludovic pointed out some time
ago. It works the same if you place the cursor on a MIME (attachment)
object. You can also apply multiple patches in a row by giving it a
prefix argument (e.g. C-u N |) to apply N patches from N messages
(haven't tried that one yet but it's documented, see C-h f
gnus-summary-pipe-output).

I intend to script this method in Elisp so that would deal with both
types of patches (in-body/as-attachment) transparently but haven't
gotten around it just yet. I packaged the very old emacs-dvc thinking it
could help in doing that but it doesn't, so haven't bothered releasing
it.

> The other issue is that, in my opinion, the only user-friendly way to
> interact with debbugs, is using emacs + debbugs-gnu, once you are
> familiar with both.  I think that's a really high barrier.
>
> - I briefly subscribed to the guix-patches mailing list, but found the
>   volume of e-mail much too high.
> - That leaves debbugs.  I find the web interface quite terrible, it's
>    just walls of text you have to find your way through. For example,
>    Github's “issues” are much more readable (and you can interact with
>    them via e-mail, too).
> - The debbugs emacs interface is quite ok (at least there's a threaded
>   conversation view), although now you have to learn to use Gnus if
>   you want to participate in the conversation.

I can highly recommend Gnus to get some hold of high mailing list
traffic. Expiry is a nifty way to storm through the mails, and there's
always the last resort 'c' catchup that will put you back on top of
things after coming back from a long weekend.

Maxim

Re: Adopt a patch!

[Thomas Danckaert]

Hi Ludo and Maxim,

I knew I wasn't the first one to complain about the e-mail workflow, 
but just wanted to the practical problems I've encountered.  So 
thanks for the hints, sorry I missed them the first time.

I must admit that I'm not very experienced with gitlab or kallithea 
(I just see that gitlab's web interface is better than that of 
debbugs), but hope that someone with stronger experience and opinions 
hears the call for packages and/or services, and packages the best 
one ;-) ).

cheers,

Thomas

Re: Adopt a patch!

[Hartmut Goebel]

Am 21.09.2017 um 16:08 schrieb Ricardo Wurmus:
> How does even more reliance on a browser help here?  Surely, we can
> automate more things without imposing a web browser-based workflow to
> everyone.

Counter question; How does reliance on emacs help here?

Regarding the browser.

* It is much, much easier to use for the casual user.

* Is organizes the workflow, so not everybody needs to build a worklow
for his/herself.

* It can avoid duplicate work since

* And yes, its automation, automation, automation!

Also please keep in mind that not everybody is an emacs-expert an not
everybody want to use an email-based workflow. Yes, one could implement
all this in emacs, too. But this is a kind of reinventing the wheel.

If you want to scale and want guys like me to adopt a patch, you simply
need to retire form this "must be email base" attitude. No offense
meant, but this is quite elite.

-- 
Regards
Hartmut Goebel

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

Re: Adopt a patch!

[Ludovic Courtès]

Hi Arun,

Apologies for taking almost a month to reply!

Arun Isaac <arunisaac@systemreboot.net> skribis:

>> At the time, Andy (I think) suggested that collaborative maintainership
>> the way we do it might actually “work better” and scale better.  In the
>> meantime, there have been long discussions in Debian about whether
>> package maintainers should be dropped.  Some rightfully argued that
>> maintainership gives a sense of “ownership” to the maintainer(s), which,
>> whether we want it or not, discourages others from contributing to the
>> package.
>
> Yes, makes sense. Sometimes, "ownership" also makes maintainers somewhat
> less polite.
>
>> I’m really summarizing here (there were a couple of articles on LWN),
>
> Links to these articles would be nice. Do you have them?

Here there are:

  https://lwn.net/Articles/708163/
  https://lwn.net/Articles/704088/

> Just thinking out loud: Maybe, we need more people with commit
> access. Theoretically, anyone can review a patch, but ultimately it is
> people with commit access who will have to finally apply and push the
> patch. As the rate of submission of patches grows, this increases the
> work load on those with commit access.

I agree we need more people with commit access.  I very much encourage
every committer to offer commit access to contributors who they deem
ready for that.  I think we’re often too shy, and that’s sad, because
that means the project doesn’t scale up as well as it could.

> More automation with regard to reviewing patches might help. For
> example, would it be possible to automatically or semi-automatically
> detect the license of a package? Many packages have multiple licenses,
> and it is quite tedious to grep through the source code and identify all
> the licenses involved. Even partial automation could be useful
> here. Github does some kind of license detection. I have no idea what
> kind of algorithm they use, though.

‘guix lint’ and ‘etc/indent-code.el’ provide some automation, but I
agree we could do better.

For license detection though, a tool could give a good guess, which
would already be an improvement, but people would still have to review a
bit more closely.  Some tools exist, such as Fossology, but I think
they’re pretty much designed to run as a Web service and are rather hard
to install and run directly on one’s machine.

If someone would like to investigate things that could be done here,
that could be very fruitful!

> Also, I keep forgetting to return #t at the end of phases. Could there
> be some way to auto-detect this?

It’s hard to detect.  Maybe ‘gnu-build-system’ could print something
when a phase returns the unspecified value, for instance?

>> At the GHM, we were discussing that, probably, we’ll have to accept for
>> Guix to be a gateway to those repos (at least for the “non-core” subsets
>> of the repos).  Concretely, one could do “guix package -i cpan!Foo::Bar”
>> and have the package DAG imported and built live.  It’s either that or
>> people will use CPAN’s own tools to achieve this.
>
> It would be nice to have some kind of "upstream packaging" (like
> AppImage), so that developers can package their software themselves. It
> would be a quick way for new projects to get people to try out their
> work. I believe there has been discussion and work on these lines in
> Guix. I'm not very familiar with it. I'll read up.

‘guix package/build/environment’ support loading definitions from a
‘guix.scm’ file, which goes in that direction.  However we could
certainly make it easier to use and advertise it more.

Happy Friday!  :-)

Ludo’.