* Guix package incubator (later a channel) @ 2017-02-06 19:09 Pjotr Prins 2017-02-06 21:44 ` ng0 2017-02-07 19:38 ` Ricardo Wurmus 0 siblings, 2 replies; 26+ messages in thread From: Pjotr Prins @ 2017-02-06 19:09 UTC (permalink / raw) To: rekado; +Cc: guix-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-06 19:09 Guix package incubator (later a channel) Pjotr Prins @ 2017-02-06 21:44 ` ng0 2017-02-07 5:42 ` Pjotr Prins 2017-02-07 19:38 ` Ricardo Wurmus 1 sibling, 1 reply; 26+ messages in thread From: ng0 @ 2017-02-06 21:44 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-06 21:44 ` ng0 @ 2017-02-07 5:42 ` Pjotr Prins 2017-02-07 18:59 ` Christopher Allan Webber 0 siblings, 1 reply; 26+ messages in thread From: Pjotr Prins @ 2017-02-07 5:42 UTC (permalink / raw) To: guix-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-07 5:42 ` Pjotr Prins @ 2017-02-07 18:59 ` Christopher Allan Webber 2017-02-07 20:37 ` ng0 0 siblings, 1 reply; 26+ messages in thread From: Christopher Allan Webber @ 2017-02-07 18:59 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-07 18:59 ` Christopher Allan Webber @ 2017-02-07 20:37 ` ng0 0 siblings, 0 replies; 26+ messages in thread From: ng0 @ 2017-02-07 20:37 UTC (permalink / raw) To: Christopher Allan Webber; +Cc: guix-devel 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-06 19:09 Guix package incubator (later a channel) Pjotr Prins 2017-02-06 21:44 ` ng0 @ 2017-02-07 19:38 ` Ricardo Wurmus 2017-02-07 20:59 ` ng0 ` (2 more replies) 1 sibling, 3 replies; 26+ messages in thread From: Ricardo Wurmus @ 2017-02-07 19:38 UTC (permalink / raw) To: Pjotr Prins; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-07 19:38 ` Ricardo Wurmus @ 2017-02-07 20:59 ` ng0 2017-02-08 6:58 ` Pjotr Prins 2017-02-08 13:46 ` Debbugs handling of packages Ludovic Courtès 2 siblings, 0 replies; 26+ messages in thread From: ng0 @ 2017-02-07 20:59 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Guix package incubator (later a channel) 2017-02-07 19:38 ` Ricardo Wurmus 2017-02-07 20:59 ` ng0 @ 2017-02-08 6:58 ` Pjotr Prins 2017-02-08 13:46 ` Debbugs handling of packages Ludovic Courtès 2 siblings, 0 replies; 26+ messages in thread From: Pjotr Prins @ 2017-02-08 6:58 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Debbugs handling of packages 2017-02-07 19:38 ` Ricardo Wurmus 2017-02-07 20:59 ` ng0 2017-02-08 6:58 ` Pjotr Prins @ 2017-02-08 13:46 ` Ludovic Courtès 2017-02-08 14:29 ` Ricardo Wurmus 2 siblings, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2017-02-08 13:46 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of packages 2017-02-08 13:46 ` Debbugs handling of packages Ludovic Courtès @ 2017-02-08 14:29 ` Ricardo Wurmus 2017-02-08 19:15 ` Andreas Enge 2017-02-09 23:12 ` Debbugs handling of Guix patches Ludovic Courtès 0 siblings, 2 replies; 26+ messages in thread From: Ricardo Wurmus @ 2017-02-08 14:29 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of packages 2017-02-08 14:29 ` Ricardo Wurmus @ 2017-02-08 19:15 ` Andreas Enge 2017-02-12 11:05 ` ng0 2017-02-09 23:12 ` Debbugs handling of Guix patches Ludovic Courtès 1 sibling, 1 reply; 26+ messages in thread From: Andreas Enge @ 2017-02-08 19:15 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of packages 2017-02-08 19:15 ` Andreas Enge @ 2017-02-12 11:05 ` ng0 0 siblings, 0 replies; 26+ messages in thread From: ng0 @ 2017-02-12 11:05 UTC (permalink / raw) To: Andreas Enge; +Cc: guix-devel 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/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Debbugs handling of Guix patches 2017-02-08 14:29 ` Ricardo Wurmus 2017-02-08 19:15 ` Andreas Enge @ 2017-02-09 23:12 ` Ludovic Courtès 2017-02-10 0:40 ` Glenn Morris 1 sibling, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2017-02-09 23:12 UTC (permalink / raw) To: help-debbugs; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-09 23:12 ` Debbugs handling of Guix patches Ludovic Courtès @ 2017-02-10 0:40 ` Glenn Morris 2017-02-10 12:41 ` Ludovic Courtès 2017-02-12 14:11 ` New guix-patches mailing list hooked to Debbugs! Ludovic Courtès 0 siblings, 2 replies; 26+ messages in thread From: Glenn Morris @ 2017-02-10 0:40 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, help-debbugs 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-10 0:40 ` Glenn Morris @ 2017-02-10 12:41 ` Ludovic Courtès 2017-02-10 17:41 ` Glenn Morris 2017-02-12 14:11 ` New guix-patches mailing list hooked to Debbugs! Ludovic Courtès 1 sibling, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2017-02-10 12:41 UTC (permalink / raw) To: Glenn Morris; +Cc: guix-devel, help-debbugs 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’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-10 12:41 ` Ludovic Courtès @ 2017-02-10 17:41 ` Glenn Morris 2017-02-10 22:46 ` Ludovic Courtès 0 siblings, 1 reply; 26+ messages in thread From: Glenn Morris @ 2017-02-10 17:41 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, help-debbugs 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-10 17:41 ` Glenn Morris @ 2017-02-10 22:46 ` Ludovic Courtès 2017-02-11 1:43 ` Christopher Allan Webber 2017-02-12 1:51 ` Debbugs handling of Guix patches Glenn Morris 0 siblings, 2 replies; 26+ messages in thread From: Ludovic Courtès @ 2017-02-10 22:46 UTC (permalink / raw) To: Glenn Morris; +Cc: guix-devel, help-debbugs 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’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-10 22:46 ` Ludovic Courtès @ 2017-02-11 1:43 ` Christopher Allan Webber 2017-02-11 14:37 ` New guix-patches mailing list not showing up on Mailman Ludovic Courtès 2017-02-12 1:51 ` Debbugs handling of Guix patches Glenn Morris 1 sibling, 1 reply; 26+ messages in thread From: Christopher Allan Webber @ 2017-02-11 1:43 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, Glenn Morris, help-debbugs 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! :) ^ permalink raw reply [flat|nested] 26+ messages in thread
* New guix-patches mailing list not showing up on Mailman 2017-02-11 1:43 ` Christopher Allan Webber @ 2017-02-11 14:37 ` Ludovic Courtès 2017-02-11 22:11 ` [Savannah-hackers-public] " Assaf Gordon 2017-02-11 22:51 ` Karl Berry 0 siblings, 2 replies; 26+ messages in thread From: Ludovic Courtès @ 2017-02-11 14:37 UTC (permalink / raw) To: savannah-hackers-public; +Cc: guix-devel 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’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman 2017-02-11 14:37 ` New guix-patches mailing list not showing up on Mailman Ludovic Courtès @ 2017-02-11 22:11 ` Assaf Gordon 2017-02-11 22:51 ` Karl Berry 1 sibling, 0 replies; 26+ messages in thread From: Assaf Gordon @ 2017-02-11 22:11 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, savannah-hackers-public 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman 2017-02-11 14:37 ` New guix-patches mailing list not showing up on Mailman Ludovic Courtès 2017-02-11 22:11 ` [Savannah-hackers-public] " Assaf Gordon @ 2017-02-11 22:51 ` Karl Berry 2017-02-12 13:54 ` Ludovic Courtès 1 sibling, 1 reply; 26+ messages in thread From: Karl Berry @ 2017-02-11 22:51 UTC (permalink / raw) To: ludo; +Cc: guix-devel, savannah-hackers-public [-- 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Savannah-hackers-public] New guix-patches mailing list not showing up on Mailman 2017-02-11 22:51 ` Karl Berry @ 2017-02-12 13:54 ` Ludovic Courtès 0 siblings, 0 replies; 26+ messages in thread From: Ludovic Courtès @ 2017-02-12 13:54 UTC (permalink / raw) To: Karl Berry; +Cc: guix-devel, savannah-hackers-public 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’. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-10 22:46 ` Ludovic Courtès 2017-02-11 1:43 ` Christopher Allan Webber @ 2017-02-12 1:51 ` Glenn Morris 2017-02-12 14:01 ` Ludovic Courtès 1 sibling, 1 reply; 26+ messages in thread From: Glenn Morris @ 2017-02-12 1:51 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, help-debbugs 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-12 1:51 ` Debbugs handling of Guix patches Glenn Morris @ 2017-02-12 14:01 ` Ludovic Courtès 2017-02-26 8:42 ` Pjotr Prins 0 siblings, 1 reply; 26+ messages in thread From: Ludovic Courtès @ 2017-02-12 14:01 UTC (permalink / raw) To: Glenn Morris; +Cc: guix-devel, help-debbugs 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'. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Debbugs handling of Guix patches 2017-02-12 14:01 ` Ludovic Courtès @ 2017-02-26 8:42 ` Pjotr Prins 0 siblings, 0 replies; 26+ messages in thread From: Pjotr Prins @ 2017-02-26 8:42 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guix-devel, Glenn Morris, help-debbugs 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'. > -- ^ permalink raw reply [flat|nested] 26+ messages in thread
* New guix-patches mailing list hooked to Debbugs! 2017-02-10 0:40 ` Glenn Morris 2017-02-10 12:41 ` Ludovic Courtès @ 2017-02-12 14:11 ` Ludovic Courtès 1 sibling, 0 replies; 26+ messages in thread From: Ludovic Courtès @ 2017-02-12 14:11 UTC (permalink / raw) To: guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2017-02-26 8:46 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-06 19:09 Guix package incubator (later a channel) Pjotr Prins 2017-02-06 21:44 ` ng0 2017-02-07 5:42 ` Pjotr Prins 2017-02-07 18:59 ` Christopher Allan Webber 2017-02-07 20:37 ` ng0 2017-02-07 19:38 ` Ricardo Wurmus 2017-02-07 20:59 ` ng0 2017-02-08 6:58 ` Pjotr Prins 2017-02-08 13:46 ` Debbugs handling of packages Ludovic Courtès 2017-02-08 14:29 ` Ricardo Wurmus 2017-02-08 19:15 ` Andreas Enge 2017-02-12 11:05 ` ng0 2017-02-09 23:12 ` Debbugs handling of Guix patches Ludovic Courtès 2017-02-10 0:40 ` Glenn Morris 2017-02-10 12:41 ` Ludovic Courtès 2017-02-10 17:41 ` Glenn Morris 2017-02-10 22:46 ` Ludovic Courtès 2017-02-11 1:43 ` Christopher Allan Webber 2017-02-11 14:37 ` New guix-patches mailing list not showing up on Mailman Ludovic Courtès 2017-02-11 22:11 ` [Savannah-hackers-public] " Assaf Gordon 2017-02-11 22:51 ` Karl Berry 2017-02-12 13:54 ` Ludovic Courtès 2017-02-12 1:51 ` Debbugs handling of Guix patches Glenn Morris 2017-02-12 14:01 ` Ludovic Courtès 2017-02-26 8:42 ` Pjotr Prins 2017-02-12 14:11 ` New guix-patches mailing list hooked to Debbugs! Ludovic Courtès
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).