Guix package incubator (later a channel)

Guix package incubator (later a channel)

[Pjotr Prins]

Hi all,

After yesterday's FOSDEM discussion I propose to set up a 'Guix
incubator' git tree using Gitlab. The master branch will track the
main Guix master but project can run on forked trees and branches. The
idea is to have patches prepared by new committers or by people who
simply prefer to use a web-based git environment. Each of these trees
can become a guix channel - once we have channels to support that.

It won't hamper the normal process since ready patches still get
compiled and submitted through the mailing list (ML). In fact it may
help scale the review process by getting peer reviewers involved. The
idea is that we have an incubator environment before the ML which
allows for playful learning and tracking of patches that may (or may
not) make it into main line. I think it is very important to have a
low barrier to entry when it comes to submitting package recipes.

Gitlab may help. I'll take the lead and maybe I'll start submitting my
own patches again ;)

How about using http://notabug.org/? Will they be happy to host us and
is that the best place for gitlab?

Pj.

Re: Guix package incubator (later a channel)

[ng0]

On 17-02-06 19:09:23, Pjotr Prins wrote:
> Hi all,
> 
> After yesterday's FOSDEM discussion I propose to set up a 'Guix
> incubator' git tree using Gitlab. The master branch will track the
> main Guix master but project can run on forked trees and branches. The
> idea is to have patches prepared by new committers or by people who
> simply prefer to use a web-based git environment. Each of these trees
> can become a guix channel - once we have channels to support that.
> 
> It won't hamper the normal process since ready patches still get
> compiled and submitted through the mailing list (ML). In fact it may
> help scale the review process by getting peer reviewers involved. The
> idea is that we have an incubator environment before the ML which
> allows for playful learning and tracking of patches that may (or may
> not) make it into main line. I think it is very important to have a
> low barrier to entry when it comes to submitting package recipes.
> 
> Gitlab may help. I'll take the lead and maybe I'll start submitting my
> own patches again ;)
> 
> How about using http://notabug.org/? Will they be happy to host us and
> is that the best place for gitlab?
> 
> Pj.
> 

Just a reply on the notabug question (I don't have much time otherwise):
Notabug will eventually move to an instance of pagure.io, you can read
about this in their own issues where I asked about some question back
then (no link, sorry .. my name was 'ng0' back on there). Developing
with pagure might be easier (fedora and surrounding communities)
compared to the situation they describe in the issue.
I started packaging pagure for this reason, which is about ~85% done
(services + pagure itself left to wrap it up ... pagure itself is more
or less done, just the service are needed. I'm more than happy to pass
this on (could rebase the pagure patch), as I know I have taken on some
tasks which would be better handled by different people :)
That is in case you want to use a GuixSD as a host, otherwise you should
not have many problems.



-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Guix package incubator (later a channel)

[Pjotr Prins]

On Mon, Feb 06, 2017 at 09:44:48PM +0000, ng0 wrote:
> Just a reply on the notabug question (I don't have much time otherwise):
> Notabug will eventually move to an instance of pagure.io, you can read
> about this in their own issues where I asked about some question back
> then (no link, sorry .. my name was 'ng0' back on there). Developing
> with pagure might be easier (fedora and surrounding communities)
> compared to the situation they describe in the issue.
> I started packaging pagure for this reason, which is about ~85% done
> (services + pagure itself left to wrap it up ... pagure itself is more
> or less done, just the service are needed. I'm more than happy to pass
> this on (could rebase the pagure patch), as I know I have taken on some
> tasks which would be better handled by different people :)
> That is in case you want to use a GuixSD as a host, otherwise you should
> not have many problems.

That would be a great result :). Also pagure looks very interesting -
simpler than gitlab. I like simple.

I think we should view the incubator as a list of 'throw-away' repo's.
I.e., only the final result matters as and will go into Guix which
means we can start anywhere. If we start on notabug and notabug
migrates, only the better and we can host ourselves when we decide the
process is workable. When we get channels anyone can set up such an
incubator anyway. The incubator is not Guix (tiing).

Pj.

Re: Guix package incubator (later a channel)

[Christopher Allan Webber]

Pjotr Prins writes:

> On Mon, Feb 06, 2017 at 09:44:48PM +0000, ng0 wrote:
>> Just a reply on the notabug question (I don't have much time otherwise):
>> Notabug will eventually move to an instance of pagure.io, you can read
>> about this in their own issues where I asked about some question back
>> then (no link, sorry .. my name was 'ng0' back on there). Developing
>> with pagure might be easier (fedora and surrounding communities)
>> compared to the situation they describe in the issue.
>> I started packaging pagure for this reason, which is about ~85% done
>> (services + pagure itself left to wrap it up ... pagure itself is more
>> or less done, just the service are needed. I'm more than happy to pass
>> this on (could rebase the pagure patch), as I know I have taken on some
>> tasks which would be better handled by different people :)
>> That is in case you want to use a GuixSD as a host, otherwise you should
>> not have many problems.
>
> That would be a great result :). Also pagure looks very interesting -
> simpler than gitlab. I like simple.

It does look good:

  Open data: Sources, doc, ticket and pull-requests meta-data are
  available in the web interface but also in git repos which can thus be
  cloned and changed locally.

That's really appealing.

Re: Guix package incubator (later a channel)

[ng0]

On 17-02-07 12:59:22, Christopher Allan Webber wrote:
> Pjotr Prins writes:
> 
> > On Mon, Feb 06, 2017 at 09:44:48PM +0000, ng0 wrote:
> >> Just a reply on the notabug question (I don't have much time otherwise):
> >> Notabug will eventually move to an instance of pagure.io, you can read
> >> about this in their own issues where I asked about some question back
> >> then (no link, sorry .. my name was 'ng0' back on there). Developing
> >> with pagure might be easier (fedora and surrounding communities)
> >> compared to the situation they describe in the issue.
> >> I started packaging pagure for this reason, which is about ~85% done
> >> (services + pagure itself left to wrap it up ... pagure itself is more
> >> or less done, just the service are needed. I'm more than happy to pass
> >> this on (could rebase the pagure patch), as I know I have taken on some
> >> tasks which would be better handled by different people :)
> >> That is in case you want to use a GuixSD as a host, otherwise you should
> >> not have many problems.
> >
> > That would be a great result :). Also pagure looks very interesting -
> > simpler than gitlab. I like simple.
> 
> It does look good:
> 
>   Open data: Sources, doc, ticket and pull-requests meta-data are
>   available in the web interface but also in git repos which can thus be
>   cloned and changed locally.
> 
> That's really appealing.
> 

The only thing we found (not answered, but I didn't check so far with
pagure development team) is that issues and pull requests are read-only
git repositories. Maybe our short trip into pagure was too short to
answer this, but it looked like read-only, no push. One reason why I
want an local instance to play with so I can check wether my
feature-issues are really issues or just pagure.io instance
configuration settings.
Also no trace of the "pull requests" across different hosted
instance of it, but that can be solved aswell later.

I agree with Pjotr, doesn't matter for now, might matter later.


-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Guix package incubator (later a channel)

[Ricardo Wurmus]

Hi Pjotr,

during the panel on the Future of Guix we all agreed that there is a
need to lower the barrier to entry for package submissions to Guix, so
it is good to start a discussion about actionable steps we can take to
make this happen.

> After yesterday's FOSDEM discussion I propose to set up a 'Guix
> incubator' git tree using Gitlab. The master branch will track the
> main Guix master but project can run on forked trees and branches. The
> idea is to have patches prepared by new committers or by people who
> simply prefer to use a web-based git environment. Each of these trees
> can become a guix channel - once we have channels to support that.

During the panel we had a question from the audience about alternative
tools, e.g. to allow a workflow that is not email-based.  While I can
understand the desire to use a workflow that you may be used to from
other projects (this goes both ways) there is a danger in establishing
alternatives to the channels on which we accept contributions.

At this point in the evolution of Guix we have many more contributors
than people who can mentor the contributors, polish their patches for
inclusion upstream, or provide constructive comments.  Having so many
people contribute is great!  But it also means that we need to be
careful with our limited number of mentors.

I see two possible outcomes of establishing an additional “incubator”
repository: it might fragment our review community as some people will
try to upstream incubator patches and others handle mailing list
patches; another outcome is that the incubator never gets accepted by
reviewers and mentors because it is more work, leading to growing
parallel infrastructure and second-class code.  Neither of these
outcomes is desirable in my opinion.

> It won't hamper the normal process since ready patches still get
> compiled and submitted through the mailing list (ML). In fact it may
> help scale the review process by getting peer reviewers involved. The
> idea is that we have an incubator environment before the ML which
> allows for playful learning and tracking of patches that may (or may
> not) make it into main line. I think it is very important to have a
> low barrier to entry when it comes to submitting package recipes.

I appreciate your desire to reduce the work load of reviewers/mentors on
the mailing list.  I have some doubts about whether this approach would
be feasible, though.  There already *are* external repositories outside
of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as
your own “genenetwork/guix-bioinformatics” repo or the MDC’s
“guix-bimsb”) or as forks of Guix (e.g. public versions of what most
Guix developers do locally to add packages).  I have not seen any
concerted efforts to upstream package definitions from either of these
classes of repositories.

This makes me wonder if the presumed benefits of an incubator could
actually be realised.  I would like to advise against recommending an
“incubator” procedure like this as an official alternative to
submissions to the mailing list.

Our workflow involving the mailing list is far from perfect.  We had
further discussions over post-FOSDEM dinner and drinks and there seemed
to be consensus among the people present (including long time
contributors, reviewers, and successful mentors) that it would be a
great improvement to keep track of package contributions in a separate
Debbugs instance (e.g. one “bug” per package submission).  It gives us a
way to track the state of things more easily, it accomodates people who
prefer to use a web browser, it permits us to continue to use email, and
it doesn’t force yet another account onto submitters.

Admittedly, the web interface that Debbugs comes with is kinda bland and
hard to use, so a second step would be to develop a better UI frontend
to Debbugs that would be closer to what people expect from an issue
tracker.

This was discussed before at
<https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00140.html>
and we could request a separate Debbugs instance for
“guix-packages@gnu.org” *right now* if we wanted to.

What do other people think about this?

--
Ricardo

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

Re: Guix package incubator (later a channel)

[ng0]

On 17-02-07 20:38:58, Ricardo Wurmus wrote:
> 
> Hi Pjotr,
> 
> during the panel on the Future of Guix we all agreed that there is a
> need to lower the barrier to entry for package submissions to Guix, so
> it is good to start a discussion about actionable steps we can take to
> make this happen.
> 
> > After yesterday's FOSDEM discussion I propose to set up a 'Guix
> > incubator' git tree using Gitlab. The master branch will track the
> > main Guix master but project can run on forked trees and branches. The
> > idea is to have patches prepared by new committers or by people who
> > simply prefer to use a web-based git environment. Each of these trees
> > can become a guix channel - once we have channels to support that.
> 
> During the panel we had a question from the audience about alternative
> tools, e.g. to allow a workflow that is not email-based.  While I can
> understand the desire to use a workflow that you may be used to from
> other projects (this goes both ways) there is a danger in establishing
> alternatives to the channels on which we accept contributions.
> 
> At this point in the evolution of Guix we have many more contributors
> than people who can mentor the contributors, polish their patches for
> inclusion upstream, or provide constructive comments.  Having so many
> people contribute is great!  But it also means that we need to be
> careful with our limited number of mentors.
> 
> I see two possible outcomes of establishing an additional “incubator”
> repository: it might fragment our review community as some people will
> try to upstream incubator patches and others handle mailing list
> patches; another outcome is that the incubator never gets accepted by
> reviewers and mentors because it is more work, leading to growing
> parallel infrastructure and second-class code.  Neither of these
> outcomes is desirable in my opinion.
> 
> > It won't hamper the normal process since ready patches still get
> > compiled and submitted through the mailing list (ML). In fact it may
> > help scale the review process by getting peer reviewers involved. The
> > idea is that we have an incubator environment before the ML which
> > allows for playful learning and tracking of patches that may (or may
> > not) make it into main line. I think it is very important to have a
> > low barrier to entry when it comes to submitting package recipes.
> 
> I appreciate your desire to reduce the work load of reviewers/mentors on
> the mailing list.  I have some doubts about whether this approach would
> be feasible, though.  There already *are* external repositories outside
> of Guix, either implemented to be used with GUIX_PACKAGE_PATH (such as
> your own “genenetwork/guix-bioinformatics” repo or the MDC’s
> “guix-bimsb”) or as forks of Guix (e.g. public versions of what most
> Guix developers do locally to add packages).  I have not seen any
> concerted efforts to upstream package definitions from either of these
> classes of repositories.
> 
> This makes me wonder if the presumed benefits of an incubator could
> actually be realised.  I would like to advise against recommending an
> “incubator” procedure like this as an official alternative to
> submissions to the mailing list.
> 
> Our workflow involving the mailing list is far from perfect.  We had
> further discussions over post-FOSDEM dinner and drinks and there seemed
> to be consensus among the people present (including long time
> contributors, reviewers, and successful mentors) that it would be a
> great improvement to keep track of package contributions in a separate
> Debbugs instance (e.g. one “bug” per package submission).  It gives us a
> way to track the state of things more easily, it accomodates people who
> prefer to use a web browser, it permits us to continue to use email, and
> it doesn’t force yet another account onto submitters.
> 
> Admittedly, the web interface that Debbugs comes with is kinda bland and
> hard to use, so a second step would be to develop a better UI frontend
> to Debbugs that would be closer to what people expect from an issue
> tracker.
> 
> This was discussed before at
> <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00140.html>
> and we could request a separate Debbugs instance for
> “guix-packages@gnu.org” *right now* if we wanted to.
> 
> What do other people think about this?
> 
> --
> Ricardo
> 
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
> 
> 

The here mentioned debbugs solution would work now and it would have
an immediate 
effect. I really welcome this solution as a first step to try out
alternatives and I would make use of it.

Regarding the approach Pjotr suggested: would it be like
https://wiki.gentoo.org/wiki/Gentoo_Github ( See also:
https://wiki.gentoo.org/wiki/Gentoo_Github#See_also ) ?

I do share the voiced concerns - there are little reviewers, and while the
situation with reviews is bad it is really a people problem. Tools can
improve access for newcomers, but they won't fix the reviewers > patches
ratio.

Here are further ideas to motivate newcomers:
We regulary get questions on HOW to start and WHAT to use (for
contributing) etc. Okay,
improving upstream documentation would be ideal, but until then we can
have a better "get started contributing to Guix" section, and maybe a
link on the website to this (we already kind of have), Encourage to read
the open bugs (point to a "low hanging fruits" list of bugs and things
to do around Guix), and even more get people to review through
encouragment and ...stuff... (kind words, etc etc).

Goodnight!


-- 
ng0 -- https://www.inventati.org/patternsinthechaos/

Re: Guix package incubator (later a channel)

[Pjotr Prins]

On Tue, Feb 07, 2017 at 08:38:58PM +0100, Ricardo Wurmus wrote:
> This makes me wonder if the presumed benefits of an incubator could
> actually be realised.  I would like to advise against recommending an
> “incubator” procedure like this as an official alternative to
> submissions to the mailing list.

I don't have the intention of making the incubator a formal part of
the Guix package submission system, so there is no reason to recommend
it. It is also clear to me that the current workflow works for the
current and experienced package maintainers.  The current ML-based and
bug-tracking system remains the authoritative one. You don't have to
be involved with the incubator.

It is also clear to me that the current system has a high barrier to
entry and actively prevents people from starting up and even
continuing. So, I want an alternative. 

The incubator invites anyone to submit patches in their own way on
their own trees. These contributors are encouraged to work towards a
final patch which will be submitted to the ML - that is when you take
over.  Exactly what an incubator does: small chicks get to be full
grown and egg laying chicken (what happens to the males you don't want
to know).  Maybe some of us will never outgrow being chicks. It will
be a learning experience for me too.

The current state of affairs is that people are working off the main
ML and packages never make it into Guix. I am a case in point. I want
more people to track my 100+ packages. With the incubator I hope to
increase visibility of people dabbling in Guix. It is not a large step
since I have been working this way with a number of other people for
some time. You can check the logs of genenetwork/guix-bioinformatics
on github. Some packages made it into main line, including the ldc D
compiler.

So, it serves a purpose. It does not require your involvement. It may
lead to more people contributing. In the worst case, the incubator
fails as an experiment. Main choice now is that we move away from
github - and I think that is a good idea. If the GNU git repo could be
forked on savannah we would do that - but that is no option. So, I am
looking for an alternative. 

Pj.

Debbugs handling of packages

[Ludovic Courtès]

Hello Guix!

Ricardo Wurmus <rekado@elephly.net> skribis:

> I see two possible outcomes of establishing an additional “incubator”
> repository: it might fragment our review community as some people will
> try to upstream incubator patches and others handle mailing list
> patches; another outcome is that the incubator never gets accepted by
> reviewers and mentors because it is more work, leading to growing
> parallel infrastructure and second-class code.  Neither of these
> outcomes is desirable in my opinion.

Yeah, I share the same concerns.  The example of external repos that you
gave seems to confirm this.

But like Pjotr said, if people want to have their own package set
somewhere else, that’s also fine.  We’ll just work hard to make sure
there’s no real incentive to do that.  :-)

> Our workflow involving the mailing list is far from perfect.  We had
> further discussions over post-FOSDEM dinner and drinks and there seemed
> to be consensus among the people present (including long time
> contributors, reviewers, and successful mentors) that it would be a
> great improvement to keep track of package contributions in a separate
> Debbugs instance (e.g. one “bug” per package submission).  It gives us a
> way to track the state of things more easily, it accomodates people who
> prefer to use a web browser, it permits us to continue to use email, and
> it doesn’t force yet another account onto submitters.
>
> Admittedly, the web interface that Debbugs comes with is kinda bland and
> hard to use, so a second step would be to develop a better UI frontend
> to Debbugs that would be closer to what people expect from an issue
> tracker.
>
> This was discussed before at
> <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00140.html>
> and we could request a separate Debbugs instance for
> “guix-packages@gnu.org” *right now* if we wanted to.
>
> What do other people think about this?

I think we should just go ahead and setup that Debbugs instance like I
said I’d do back in September.  It can only be an improvement over what
we have now anyway.

Objections?

Thanks,
Ludo’.

Re: Debbugs handling of packages

[Ricardo Wurmus]

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

>> This was discussed before at
>> <https://lists.gnu.org/archive/html/guix-devel/2016-09/msg00140.html>
>> and we could request a separate Debbugs instance for
>> “guix-packages@gnu.org” *right now* if we wanted to.
>>
>> What do other people think about this?
>
> I think we should just go ahead and setup that Debbugs instance like I
> said I’d do back in September.  It can only be an improvement over what
> we have now anyway.
>
> Objections?

No objections, please go ahead!

Just a question: does this mean that patch *sets* should be flattened
before sending them so that they are part of the *same* debbugs issue
(instead of being scattered across as many issues as there are patches)?

E.g. for submitting the last 10 commits:

    git format-patch -10 --stdout > series.patch
    git send-email --to=guix-packages@gnu.org series.patch

I guess we can play with this once we have the debbugs instance.

--
Ricardo

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

Re: Debbugs handling of packages

[Andreas Enge]

On Wed, Feb 08, 2017 at 03:29:31PM +0100, Ricardo Wurmus wrote:
> Just a question: does this mean that patch *sets* should be flattened
> before sending them so that they are part of the *same* debbugs issue
> (instead of being scattered across as many issues as there are patches)?

This would be desirable, I think.

> E.g. for submitting the last 10 commits:
>     git format-patch -10 --stdout > series.patch
>     git send-email --to=guix-packages@gnu.org series.patch

Alternatively, one can send only the first patch. This will open a new issue,
and the submitter obtains the bug number with the corresponding e-mail
address in reply. Then one can send the remaining patches message by message
to this address.

Andreas

Re: Debbugs handling of packages

[ng0]

On 17-02-08 20:15:46, Andreas Enge wrote:
> On Wed, Feb 08, 2017 at 03:29:31PM +0100, Ricardo Wurmus wrote:
> > Just a question: does this mean that patch *sets* should be flattened
> > before sending them so that they are part of the *same* debbugs issue
> > (instead of being scattered across as many issues as there are patches)?
> 
> This would be desirable, I think.
> 
> > E.g. for submitting the last 10 commits:
> >     git format-patch -10 --stdout > series.patch
> >     git send-email --to=guix-packages@gnu.org series.patch
> 
> Alternatively, one can send only the first patch. This will open a new issue,
> and the submitter obtains the bug number with the corresponding e-mail
> address in reply. Then one can send the remaining patches message by message
> to this address.
> 
> Andreas

Okay, the mailman list is now live, I assume the debbugs part is fixed
too reading in the child threads here. We now have to reflect the
suggested use as described in this email in the contributing guide and
inform the help and devel list about this change.

Thanks,
--
ng0 -- https://www.inventati.org/patternsinthechaos/

Debbugs handling of Guix patches

[Ludovic Courtès]

Hello Debbugs!

We’d like to use Debbugs to handle some of the patches we get for Guix,
and I have just created guix-patches@gnu.org for that purpose.

Looking at <https://debbugs.gnu.org/Using.html>, I think the name for
Debbugs should be “guix-patches”.  The email address could be
bug-guix@gnu.org, but that’s another Debbugs instance (what is this
address actually used for?).  The URL is
<https://www.gnu.org/software/guix/>.

We’d use it in “exclusive mode”.

We’re wondering about patch series as sent by ‘git send-email’ though.
What would be your suggestion for those?

Thanks,
Ludo’.

Re: Debbugs handling of Guix patches

[Glenn Morris]

Ludovic Courtès wrote:

> We'd like to use Debbugs to handle some of the patches we get for Guix,
> and I have just created guix-patches@gnu.org for that purpose.
>
> Looking at <https://debbugs.gnu.org/Using.html>, I think the name for
> Debbugs should be "guix-patches".  The email address could be
> bug-guix@gnu.org, but that's another Debbugs instance (what is this
> address actually used for?).  The URL is
> <https://www.gnu.org/software/guix/>.
>
> We'd use it in "exclusive mode".

This is fine, but I'm confused by you saying the email address could be
bug-guix@gnu. The email address is guix-patches@gnu.

> We're wondering about patch series as sent by 'git send-email' though.
> What would be your suggestion for those?

You'll get one debbugs report created for each mail in a given series.
This is explained at https://debbugs.gnu.org/15361, along with the
workaround: first create a report ("here's the problem for which I will
send a patch"), then send patches to that bug number rather than bug-foo.

Re: Debbugs handling of Guix patches

[Ludovic Courtès]

Hi Glenn,

Glenn Morris <rgm@gnu.org> skribis:

> Ludovic Courtès wrote:
>
>> We'd like to use Debbugs to handle some of the patches we get for Guix,
>> and I have just created guix-patches@gnu.org for that purpose.
>>
>> Looking at <https://debbugs.gnu.org/Using.html>, I think the name for
>> Debbugs should be "guix-patches".  The email address could be
>> bug-guix@gnu.org, but that's another Debbugs instance (what is this
>> address actually used for?).  The URL is
>> <https://www.gnu.org/software/guix/>.
>>
>> We'd use it in "exclusive mode".
>
> This is fine, but I'm confused by you saying the email address could be
> bug-guix@gnu. The email address is guix-patches@gnu.

Sorry for the confusion.  I was referring to the “maintainer email
address” as mentioned in Using.html.  Can it be bug-guix@gnu.org or
guix-devel@gnu.org?

>> We're wondering about patch series as sent by 'git send-email' though.
>> What would be your suggestion for those?
>
> You'll get one debbugs report created for each mail in a given series.
> This is explained at https://debbugs.gnu.org/15361, along with the
> workaround: first create a report ("here's the problem for which I will
> send a patch"), then send patches to that bug number rather than bug-foo.

Great, thanks!

Ludo’.

Re: Debbugs handling of Guix patches

[Glenn Morris]

Ludovic Courtès wrote:

> Sorry for the confusion.  I was referring to the "maintainer email
> address" as mentioned in Using.html.  Can it be bug-guix@gnu.org or
> guix-devel@gnu.org?

guix-patches IS the maintainer.

package = guix-patches
maintainer = guix-patches@gnu

Opening a bug in "guix-patches" sends a mail to guix-patches@gnu.

In exclusive mode, sending a mail to guix-patches@gnu creates (or
replies to) a bug in the "guix-patches" package.


guix-patches isn't listed at
https://lists.gnu.org/mailman/listinfo/guix-patches

When it is, I can finish setting this up.

Re: Debbugs handling of Guix patches

[Ludovic Courtès]

Glenn Morris <rgm@gnu.org> skribis:

> Ludovic Courtès wrote:
>
>> Sorry for the confusion.  I was referring to the "maintainer email
>> address" as mentioned in Using.html.  Can it be bug-guix@gnu.org or
>> guix-devel@gnu.org?
>
> guix-patches IS the maintainer.
>
> package = guix-patches
> maintainer = guix-patches@gnu
>
> Opening a bug in "guix-patches" sends a mail to guix-patches@gnu.
>
> In exclusive mode, sending a mail to guix-patches@gnu creates (or
> replies to) a bug in the "guix-patches" package.

Oh, OK.

> guix-patches isn't listed at
> https://lists.gnu.org/mailman/listinfo/guix-patches

It does show up at <https://savannah.gnu.org/mail/?group=guix> though.
I wonder if there’s just a delay somewhere (24h already), or if
something’s wrong on Savannah.

Ludo’.

Re: Debbugs handling of Guix patches

[Christopher Allan Webber]

Ludovic Courtès writes:

>> guix-patches isn't listed at
>> https://lists.gnu.org/mailman/listinfo/guix-patches
>
> It does show up at <https://savannah.gnu.org/mail/?group=guix> though.
> I wonder if there’s just a delay somewhere (24h already), or if
> something’s wrong on Savannah.

Yeah, I tried submitting a patch to the new list and it didn't go
through.  I'm looking forward to it being in place, though! :)

New guix-patches mailing list not showing up on Mailman

[Ludovic Courtès]

Hello!

I created a new ‘guix-patches’ mailing lists ~48h ago on Savannah.  The
list shows up on <https://savannah.gnu.org/mail/?group=guix> but still
not on lists.gnu.org.

Did something go wrong?

TIA!
Ludo’.

Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman

[Assaf Gordon]

Hello,

On Sat, Feb 11, 2017 at 03:37:43PM +0100, Ludovic Courtès wrote:
>I created a new ‘guix-patches’ mailing lists ~48h ago on Savannah.  The
>list shows up on <https://savannah.gnu.org/mail/?group=guix> but still
>not on lists.gnu.org.
>
>Did something go wrong?

Perhaps the required cron-jobs on mgt0 (or internal0) are not working
properly. On the old 'internal', it was the 'sv_mailman' cronjob.

source: https://savannah.gnu.org/maintenance/SavannahInternals/
under sections "Project administration - mailing lists (frontend)"
and "Cron jobs on internal".

I'll look into it.

-assaf

Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman

[Karl Berry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

    I created a new œôòøguix-patchesœôòù mailing lists ~48h ago on Savannah.  

I just created it by hand. Assaf is looking into the PHP<->Savannah
linkage/breakage. --best, karl.

Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman

[Ludovic Courtès]

Karl Berry <karl@freefriends.org> skribis:

>     I created a new ‘guix-patches’ mailing lists ~48h ago on Savannah.  
>
> I just created it by hand. Assaf is looking into the PHP<->Savannah
> linkage/breakage. --best, karl.

Perfect.  Thank you Karl & Assaf!

Ludo’.

Re: Debbugs handling of Guix patches

[Glenn Morris]

I see you got this sorted out, so I've now completed the debbugs part.
It may take an hour or so for the mailing list redirection to take effect.

Re: Debbugs handling of Guix patches

[Ludovic Courtès]

Glenn Morris <rgm@gnu.org> skribis:

> I see you got this sorted out, so I've now completed the debbugs part.
> It may take an hour or so for the mailing list redirection to take effect.

It seems to be working now:

  https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix-patches

Thanks, Glenn!

Ludo'.

Re: Debbugs handling of Guix patches

[Pjotr Prins]

I think the web page for patches is rather good :) Especially that you
can sort by date and the 'Toggle all extra information' switch. Nice.
The emacs plugin, as usual, is amazing. I ought to try and submit a
patch again ;)

Pj.

On Sun, Feb 12, 2017 at 03:01:07PM +0100, Ludovic Courtès wrote:
> Glenn Morris <rgm@gnu.org> skribis:
> 
> > I see you got this sorted out, so I've now completed the debbugs part.
> > It may take an hour or so for the mailing list redirection to take effect.
> 
> It seems to be working now:
> 
>   https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=guix-patches
> 
> Thanks, Glenn!
> 
> Ludo'.
> 

-- 

New guix-patches mailing list hooked to Debbugs!

[Ludovic Courtès]

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

Hello Guix!

We now have a new guix-patches@gnu.org mailing list hooked to Debbugs to
handle patches!

  https://bugs.gnu.org/guix-patches
  https://lists.gnu.org/mailman/listinfo/guix-patches

You’re welcome to subscribe to it right away.

Patches should now be sent to guix-patches@gnu.org, especially patches
that relate to packaging (other patches that touch Guix or GuixSD core
can still be discussed on guix-devel@gnu.org, if you prefer).  General
development discussions will still take place on guix-devel@gnu.org.

Each message sent to guix-patches creates a Debbugs entry, as is the
case with bug-guix.  One can then follow up to NNN@debbugs.gnu.org,
where NNN is the bug number.

For patch series, please read Glenn’s suggestions at:

  https://debbugs.gnu.org/15361

For general questions about Debbugs, see:

  https://debbugs.gnu.org/Advanced.html

If you’re using Emacs, consider installing ‘emacs-debbugs’ to access the
patch database; it’s very convenient.

Last, I need a couple of people to sign up as admins for the mailing
list, as we did for the other MLs.  If nobody volunteers, I’ll take two
people at random, muahaha.  ;-)  (Being an ML admin requires no work,
except in the occasional cases where the ML parameters need to be
tweaked, etc.)

Enjoy!

Ludo’.

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