Re: on the bug tracker (Re: Guix Days: Patch flow discussion)

-- Giovanni Biscuolo writes: > Hi Josselin, > > Josselin Poiret writes: > > [...] > >> One thing I would like to get rid of though is debbugs. > > given that a significant part of the Guix infrastructure is provided by > the GNU project, including the bug/issue tracker, and I don't think

Re: Guix Days: Patch flow discussion

Hi! I'm a complete newbie to Guix, which has the dual effects that I'm much more excited about it than I otherwise might be, but the disadvantage that I know nothing and am more likely to cause problems than not at the moment. Nevertheless I thought I might be able to contribute something to the

Re: Guix Days: Patch flow discussion

> Somehow, the reader will judge if Message-ID is smoothly supported. :-) i regularly meet this most unfortunate attitude in the GNU circles, where oldtimers dismiss any discussion of friendlier defaults for newcomers with the "argument" that it's configurable, and therefore it's a non-issue.

Re: Guix Days: Patch flow discussion

Hello Dan, thanks for your thoughts! I think I will restrict my replies to guix-devel to keep them in one place; the following are just my personal opinions. Am Thu, Feb 29, 2024 at 03:41:41PM + schrieb Daniel Littlewood: > Something that is not obvious to me when people refer to reviewing

on the bug tracker (Re: Guix Days: Patch flow discussion)

Hi Josselin, Josselin Poiret writes: [...] > One thing I would like to get rid of though is debbugs. given that a significant part of the Guix infrastructure is provided by the GNU project, including the bug/issue tracker, and I don't think that GNU will replace https://debbugs.gnu.org/ (or

Re: Guix Days: Patch flow discussion

On Wed, 28 Feb 2024 18:51:16 +0100 Giovanni Biscuolo wrote --- > ...and apologise if I still cannot do more to help. We do what we can when we can. And you have done things to help. Thank you for sharing your thoughts and perspective! If there's nothing you can do at the

Re: Guix Days: Patch flow discussion

Hello Simon, first and foremost: I'd like to say a big thank you to all the people working in the Guix community... ...and apologise if I still cannot do more to help. Simon Tournier writes: [...] > Well, let me try to quickly summarize my conclusion of the session: > > 1. We have a

simple service extensions/composizions (Re: Guix Days: Patch flow discussion)

Tomas Volf <~@wolfsden.cz> writes: > On 2024-02-06 13:09:15 +0100, Clément Lassieur wrote: >> Hi! Why is it more complicated with services? You don't need forks at >> all to use packages and services outside of Guix proper. > > For packages we have transformations, or I can just inherit. But I

Re: Guix Days: Patch flow discussion

Hi Vagrant, On Sun, Feb 11 2024, Vagrant Cascadian wrote: > Are there other downsides to allowing a multiple patches in a single > email? Is it perhaps more difficult to apply those patches? Kind regards Felix

Re: Guix Days: Patch flow discussion

Clément Lassieur writes: >> It seems on the [dev manual] we already have "reviewed-looks-good" >> documented. Thus, I'd like to propose the below *mutually exclusive* >> Debbugs tag set: >> >> - "not-yet-reviewed" :: automatically set for all submissions >> - "reviewed-needs-fix" :: set

Re: Guix Days: Patch flow discussion

Hi Clément, Clément Lassieur writes: [...] >>> I also agree! :-) What appears to me “difficult” is that most of the >>> tools as Email client are poorly supporting Message-ID. >>> >>> For instance, debbugs.el (Gnus). To my knowledge, there is not easy way >>> to get the Message-ID when

Re: Guix Days: Patch flow discussion

Hi Simon, Simon Tournier writes: > Hi, > > On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer > wrote: > >> 'b4 shazam' is probably the most trouble-free way to apply patches; > > I agree*! > >> it >> even selects the latest

Re: Guix Days: Patch flow discussion

Clément Lassieur writes: > On Fri, Feb 16 2024, Andreas Enge wrote: > >> Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur: >>> Would it makes sense to have a "does-not-apply" tag too? >> >> Should this not appear in the QA page, assuming that once all the new >> issues are

Re: Guix Days: Patch flow discussion

On Fri, Feb 16 2024, Andreas Enge wrote: > Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur: >> Would it makes sense to have a "does-not-apply" tag too? > > Should this not appear in the QA page, assuming that once all the new > issues are closed, older ones will bubble to the

Re: Guix Days: Patch flow discussion

Am Fri, Feb 16, 2024 at 11:56:50AM +0100 schrieb Clément Lassieur: > Would it makes sense to have a "does-not-apply" tag too? Should this not appear in the QA page, assuming that once all the new issues are closed, older ones will bubble to the top and be treated by QA? (I am not sure if just

Re: Guix Days: Patch flow discussion

On Tue, Feb 06 2024, Suhail wrote: > Steve George writes: > >> elsewhere in the thread someone mentions some tags we could use >> consistently so maintainers can find patches that have been reviewed >> easily. > > It seems on the [dev manual] we already have "reviewed-looks-good" > documented.

Re: Guix Days: Patch flow discussion

On Thu, Feb 15 2024, Simon Tournier wrote: > Hi Clément, > > If read correctly, you answered about Gnus (debbugs.el): > --8<---cut here---start->8--- (with-current-buffer gnus-original-article-buffer (message-fetch-field "Message-ID"))

Re: Guix Days: Patch flow discussion

Hi Clément, If read correctly, you answered about Gnus (debbugs.el): >>> --8<---cut here---start->8--- >>> (with-current-buffer gnus-original-article-buffer >>> (message-fetch-field "Message-ID")) >>> --8<---cut

Re: Guix Days: Patch flow discussion

re, open a feature request is low on my list of TODO. ;-) Cheers, simon 1: Re: Guix Days: Patch flow discussion Simon Tournier Wed, 14 Feb 2024 16:48:07 +0100 id:87mss3kpxk@gmail.com https://lists.gnu.org/archive/html/guix-devel/2024-02 https://yhetil.org/guix/87mss3kpxk@gmail.com

Re: Guix Days: Patch flow discussion

On Thu, Feb 15 2024, Simon Tournier wrote: > Hi Clément, > > On jeu., 15 févr. 2024 at 12:45, Clément Lassieur > wrote: > 'b4 shazam' is probably the most trouble-free way to apply patches; >>> >>> I agree*! >> >> I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and >>

Re: Guix Days: Patch flow discussion

Hi Josselin, On jeu., 15 févr. 2024 at 12:07, Josselin Poiret wrote: > I think b4's ML is more active than the GitHub issues, I have already > sent some bug reports and patches there that were picked up quite fast. Yeah, Kyle pointed me that out months ago. Then I have never taken the time to

Re: Guix Days: Patch flow discussion

Hi Clément, On jeu., 15 févr. 2024 at 12:45, Clément Lassieur wrote: >>> 'b4 shazam' is probably the most trouble-free way to apply patches; >> >> I agree*! > > I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and > allow to apply a range of n patches at once) but I don't

Re: Guix Days: Patch flow discussion

Hi Simon, On Thu, Feb 15 2024, Clément Lassieur wrote: > May I add too, that you can add "Message-ID" in gnus-visible-headers. The author of Debbugs.el, Michael Albinus, said this was likely the best solution. To request a feature in Debbugs.el, please file a bug against the "debbugs.gnu.org"

Re: Guix Days: Patch flow discussion

On Thu, Feb 15 2024, Clément Lassieur wrote: > Hey Simon! > > On Wed, Feb 14 2024, Simon Tournier wrote: > >> Hi, >> >> On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer >> wrote: >> >>> 'b4 shazam' is probably the most trouble-free way to apply patches; >> >> I agree*! > > I don't agree (both

Re: Guix Days: Patch flow discussion

Hey Simon! On Wed, Feb 14 2024, Simon Tournier wrote: > Hi, > > On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer > wrote: > >> 'b4 shazam' is probably the most trouble-free way to apply patches; > > I agree*! I don't agree (both Gwene + Gnus or Emacs Debbugs work perfectly too and allow to

Re: Guix Days: Patch flow discussion

Hi Simon, Simon Tournier writes: > PS: *agree on B4 although there is tricky bugs as reported here: > . I think b4's ML is more active than the GitHub issues, I have already sent some bug reports and patches there that were picked up quite fast. Best, --

Re: Guix Days: Patch flow discussion

Hi, On dim., 11 févr. 2024 at 11:38, Maxim Cournoyer wrote: > 'b4 shazam' is probably the most trouble-free way to apply patches; I agree*! > it > even selects the latest revision it finds in the issue thread. To make >

Re: Guix Days: Patch flow discussion

Hi Steve, ( On a side note, the triage of old bugs is a similar problem. They are easy to find [2], read, check and send an email to 12...@debbugs.gnu.org does not appear to me an issue with any tool. For what it is worth and without any willing of being harsh, I am able

Re: Guix Days: Patch flow discussion

Hi Felix, Felix Lechner writes: > Hi Josselin, > > On Tue, Feb 13 2024, Josselin Poiret wrote: > >> As long as Debbugs is modifying mails on the MLs it's being >> troublesome. > > Will you please show an example? You mentioned it before but I cannot > find your message. Thanks! > > Kind

Re: Guix Days: Patch flow discussion

Hi Josselin, On Tue, Feb 13 2024, Josselin Poiret wrote: > As long as Debbugs is modifying mails on the MLs it's being > troublesome. Will you please show an example? You mentioned it before but I cannot find your message. Thanks! Kind regards Felix P.S. With a bug tracker, our discussion

Re: Guix Days: Patch flow discussion

Hi Felix, Felix Lechner writes: > Hi Josselin, > > On Mon, Feb 12 2024, Josselin Poiret wrote: > >> 1) Doesn't modify any incoming mail; > > What if, in addition, Debbugs were to publish bug reports and their > comments via public-inbox? Why “in addition” though? As long as Debbugs is

Re: Guix Days: Patch flow discussion

Hi Josselin, On Mon, Feb 12 2024, Josselin Poiret wrote: > 1) Doesn't modify any incoming mail; What if, in addition, Debbugs were to publish bug reports and their comments via public-inbox? > 2) Provides a way to look-up the bugs related to a thread and their > status, preferably using

Re: Guix Days: Patch flow discussion

On Mon, Feb 12 2024, Josselin Poiret wrote: > Hi Felix, > > Felix Lechner writes: > >> Could a modified version of Debbugs group submissions by Message-IDs >> instead of bug numbers? Would it allow subsequent emails to be sent >> before the initial message was acknowledged? > > To me, an ideal

Re: Guix Days: Patch flow discussion

Hi Felix, Felix Lechner writes: > Could a modified version of Debbugs group submissions by Message-IDs > instead of bug numbers? Would it allow subsequent emails to be sent > before the initial message was acknowledged? To me, an ideal solution would be a service that 1) Doesn't modify any

Re: Guix Days: Patch flow discussion

On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote: > Hi Clément, > > On Sun, Feb 11 2024, Clément Lassieur wrote: > >> On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU >> System distribution." wrote: >> >> Each

Re: Guix Days: Patch flow discussion

Hi Clément, On Sun, Feb 11 2024, Clément Lassieur wrote: > On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU > System distribution." wrote: > > Each email has its own message id, so how would you group them? As author, I'll respond. I was thinking of the In-Reply-To:

Re: Guix Days: Patch flow discussion

On Sun, Feb 11 2024, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote: > Hi Josselin, > > On Wed, Feb 07 2024, Josselin Poiret wrote: > >> The fact that you have to wait for Debbugs's response after the first >> mail to get the proper mail to reply to means that

Re: Guix Days: Patch flow discussion

Hi Josselin, On Wed, Feb 07 2024, Josselin Poiret wrote: > The fact that you have to wait for Debbugs's response after the first > mail to get the proper mail to reply to means that we can't automate > sending whole patchsets Could a modified version of Debbugs group submissions by Message-IDs

Re: Guix Days: Patch flow discussion

On 2024-02-07, Josselin Poiret wrote: > The fact that you have to wait for Debbugs's response after the first > mail to get the proper mail to reply to means that we can't automate > sending whole patchsets, and have to resort to hacks like the CLI `mumi` > tool uses. I can't just send a patchset

Re: Guix Days: Patch flow discussion

Hi, Kyle Meyer writes: > Hi Ricardo, > > Ricardo Wurmus writes: > >> Hi Josselin, > >>> They both can co-exist with debbugs, and for now the patchwork instance >>> of QA is not usable for status tracking (because it is not meant to be >>> used as such for now). One can already use both of

Re: Guix Days: Patch flow discussion

On 9 Feb, Edouard Klein wrote: > > Skyler Ferris writes: > > > On 2/6/24 05:39, Steve George wrote: > >> I agreed to organise some 'patch review' online sessions in the next > >> couple of > >> weeks. > >> > >> Organising a basic process is a good topic for that online session. For > >>

Re: Guix Days: Patch flow discussion

Hello, Am Fri, Feb 09, 2024 at 05:35:44PM +0100 schrieb Edouard Klein: > Am Thu, Feb 08, 2024 at 07:56:48PM + schrieb Skyler Ferris: > > I'd like to do my part to keep the project in a good state. However, I > > am new to interacting with large FLOSS projects so I'm nervous about > > causing

Re: Guix Days: Patch flow discussion

Skyler Ferris writes: > On 2/6/24 05:39, Steve George wrote: >> I agreed to organise some 'patch review' online sessions in the next couple >> of >> weeks. >> >> Organising a basic process is a good topic for that online session. For >> example, elsewhere in the thread someone mentions some

Re: Guix Days: Patch flow discussion

On 2/6/24 05:39, Steve George wrote: > I agreed to organise some 'patch review' online sessions in the next couple of > weeks. > > Organising a basic process is a good topic for that online session. For > example, elsewhere in the thread someone mentions some tags we could use > consistently so

patch workflow without emacs (Was: Re: Guix Days: Patch flow discussion)

On Mon, Feb 05, 2024 at 10:50:36PM +, Steve George wrote: > Hi Hartmut, > > Apologies, my reply-to went a bit mad and I sent you empty emails :-( > > You said: > > > The current mail-based workflow is too complicated for new and > > occasional committers. This is the main reason I gave up

Re: Guix Days: Patch flow discussion

Hi Ricardo, Ricardo Wurmus writes: > Hi Josselin, >> They both can co-exist with debbugs, and for now the patchwork instance >> of QA is not usable for status tracking (because it is not meant to be >> used as such for now). One can already use both of them, but using both >> supercedes

Re: Guix Days: Patch flow discussion

Hi Josselin, >>> b4/lei is a nice example (we already have yhetil.org as a back-end, >>> but maybe a more blessed one would be better) of a tool that lets you >>> completely automate applying a patchset to a branch. >>> >>> patchwork is a nice tool to gather up and track patchsets, with status

Re: Guix Days: Patch flow discussion

Hello, On Wed, Feb 07 2024, Josselin Poiret wrote: > With a properly configured b4, one > could simply run `b4 shazam some-msg-id` and it would automatically > apply the corresponding patchset. Note that you can do the same with one Emacs command while browsing Gnus mailing lists:

Re: Guix Days: Patch flow discussion

Hi again Sunhail, Josselin Poiret writes: > Hi Sunhail, > >> Josselin Poiret writes: >> >>> One thing I would like to get rid of though is debbugs. It causes a >>> lot of pain for everyone, eg. when sending patchsets, it completely >>> breaks modern email because it insists on rewriting

Re: Guix Days: Patch flow discussion

Hi Sunhail, > Josselin Poiret writes: > >> One thing I would like to get rid of though is debbugs. It causes a >> lot of pain for everyone, eg. when sending patchsets, it completely >> breaks modern email because it insists on rewriting DMARC-protected >> headers, thus needing to also rewrite

Re: Debbugs update (Was: Guix Days: Patch flow discussion)

Hi Felix, > I also packaged and deployed on GNU Guix > > (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4] > (B) the modern Debbugs version deployed at debian.org [5][6][7] > (C) and a custom version of Mumi for my own bug fixes [8][9] > > Together with the official

Re: Guix Days: Patch flow discussion

Josselin Poiret writes: > Your mailing system is sending out emails that contain an invalid > Message-ID header (missing right part of the msgid as specified in > [1]), > ... > [1] https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.4 My apologies (to everyone)! Thank you for bringing

Re: Guix Days: Patch flow discussion

Josselin Poiret writes: > One thing I would like to get rid of though is debbugs. It causes a > lot of pain for everyone, eg. when sending patchsets, it completely > breaks modern email because it insists on rewriting DMARC-protected > headers, thus needing to also rewrite "From:" to avoid

Re: Guix Days: Patch flow discussion

Steve George writes: > The general opinion seemed to be, that it was better to fix small > issues and commit the change for new users, so they had the > satisfaction of their contribution making it into the repository. One > proposal was to do the 'fix', and to then reply back to the bug with a

Re: Guix Days: Patch flow discussion

Steve George writes: > elsewhere in the thread someone mentions some tags we could use > consistently so maintainers can find patches that have been reviewed > easily. It seems on the [dev manual] we already have "reviewed-looks-good" documented. Thus, I'd like to propose the below *mutually

Re: Guix Days: Patch flow discussion

Hi Suhail, On 5 Feb, Suhail wrote: > Felix Lechner via writes: > > > Another is that committers should commit what they think is right > > rather than ask for revised patches. > > I could be mistaken, but I believe this does happen today at least some > of the time. Is your position that >

Debbugs update (Was: Guix Days: Patch flow discussion)

Hi Hartmut & Josselin, On Mon, Feb 05 2024, Hartmut Goebel wrote: > Am 05.02.24 um 10:39 schrieb Steve George: > > [order of quotations reversed] > > The current mail-based workflow is too complicated ... which has been > discussed several times already without any result: Well, that's not

Re: Guix Days: Patch flow discussion

Hi Edouard, On 6 Feb, Edouard Klein wrote: > I, for one, would be willing to review patches, hoping that in turn my > patches would be reviewed instead of staying in limbo forever, which is > a drag on me submitting more patches. > > Is there a procedure to follow, or do I just start replying

Re: Guix Days: Patch flow discussion

I, for one, would be willing to review patches, hoping that in turn my patches would be reviewed instead of staying in limbo forever, which is a drag on me submitting more patches. Is there a procedure to follow, or do I just start replying "LGTM" to patch email threads ? Cheers, Edouard. Steve

Re: Guix Days: Patch flow discussion

On 2024-02-06 13:09:15 +0100, Clément Lassieur wrote: > Hi! Why is it more complicated with services? You don't need forks at > all to use packages and services outside of Guix proper. For packages we have transformations, or I can just inherit. But I am not aware of such option for services

Re: Guix Days: Patch flow discussion

On Tue, Feb 06 2024, Tomas Volf wrote: > On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote: >> Guix offers ways to use packages outside of Guix proper in a pretty feasible >> and maintainable way (manifests, setting up channels), maybe promoting them >> as >> an alternative to having things in

Re: Guix Days: Patch flow discussion

On 2024-02-05 23:08:29 +0100, Wilko Meyer wrote: > Guix offers ways to use packages outside of Guix proper in a pretty feasible > and maintainable way (manifests, setting up channels), maybe promoting them as > an alternative to having things in guix proper "as soon as possible" (as > that's not

Re: Guix Days: Patch flow discussion

Hi Sunhail, Your mailing system is sending out emails that contain an invalid Message-ID header (missing right part of the msgid as specified in [1]), which causes erratic behavior from other participants (the gmail smtp servers for example just rewrite the message id to indicate it is malformed,

Re: Guix Days: Patch flow discussion

Hi Hartmut, Hartmut Goebel writes: > Anyhow, all of this has been discussed several times already. And as > long as vocal (and active :-) members of the community insist on being > able to work via e-mail — while also not adopting modern e-mail-capable > forges — this situation will not

Re: Guix Days: Patch flow discussion

What I proposed is in terms of the scope of a single package. The teams cover much larger and broader scope, like Gnome or Python. On Mon, Feb 5, 2024 at 12:50 PM Clément Lassieur wrote: > On Mon, Feb 05 2024, Andy Tai wrote: > > Thus this creates kind of pseudo package maintainer in Guix,

Re: Guix Days: Patch flow discussion

Hi Guix, Tomas Volf <~@wolfsden.cz> writes: > Or, to put it in a different way: The problem is not that too few patches get > merged. The problem is that too few patches get reviewed. I'd say that both things stem from the same premise, a disproportion of available resources to the work that

Re: Guix Days: Patch flow discussion

Hi Hartmut, Apologies, my reply-to went a bit mad and I sent you empty emails :-( You said: > The current mail-based workflow is too complicated for new and > occasional committers. This is the main reason I gave up reviewing patches. > In the case of *reviewing patches* can you give some

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

Re: Guix Days: Patch flow discussion

On 05/02/2024 15:57, Clément Lassieur wrote: Hello, On Mon, Feb 05 2024, Steve George wrote: Hi, Our goal for the discussion: How do we double the number of patches that are *reviewed* and *applied* to Guix in the next six months? Patch flow is a pipeline, to change it we

Re: Guix Days: Patch flow discussion

Hi Leo, On 05/02/2024 14:07, Leo Famulari wrote: On Mon, Feb 5, 2024, at 04:39, Steve George wrote: Our goal for the discussion: How do we double the number of patches that are *reviewed* and *applied* to Guix in the next six months? Patch flow is a pipeline, to change it we

Re: Guix Days: Patch flow discussion

Hartmut, thank you for elaborating. Hartmut Goebel writes: > * when has this issue/patch been worked on last - is somebody >currently working on it > * what issue/patches I started to review? > ... > * Even when using the debbugs interface in emacs > ... > o It does not tell what

Re: Guix Days: Patch flow discussion

On Mon, Feb 05 2024, Andy Tai wrote: > Hi, this is a sugestion on guix patches: > > Other GNU/Linux distributions often have fixed maintainers (or > packagers) for specific packages. > While that model may not apply directly to the Guix project as anyone > can send in patches for anything in the

Re: Guix Days: Patch flow discussion

Am 05.02.24 um 19:44 schrieb Suhail: Could you please share a reference where the key difficulties you encountered wrt the "current mail-based workflow" are summarized. Is the difficulty regd. checking out the code at the right commit and installing the patches, or something else? It's not

Re: Guix Days: Patch flow discussion

Hi Suhail, On Mon, Feb 05 2024, suh...@bayesians.ca wrote: > Felix Lechner via writes: > > Is your position that First off, I'm sorry I write so much today. For a project the size of Guix, it's not good for one person to belabor a point repeatedly. I am responding to your request for a

Re: Guix Days: Patch flow discussion

Hi, this is a sugestion on guix patches: Other GNU/Linux distributions often have fixed maintainers (or packagers) for specific packages. While that model may not apply directly to the Guix project as anyone can send in patches for anything in the git repo, maybe one thing the Guix project can do

Re: Guix Days: Patch flow discussion

Felix Lechner via writes: > Another is that committers should commit what they think is right > rather than ask for revised patches. I could be mistaken, but I believe this does happen today at least some of the time. Is your position that 1. this never happens today and thus, should happen

Re: Guix Days: Patch flow discussion

On Mon, Feb 05 2024, Felix Lechner via wrote: > On Mon, Feb 05 2024, Clément Lassieur wrote: > >> On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU >> System distribution." wrote: >> >> I see no evidence here. And I'm unsure which plan you are talking >> about (the

Re: Guix Days: Patch flow discussion

Hartmut Goebel writes: > This list is missing one point - which has been discussed several > times already without any result: > > The current mail-based workflow is too complicated for new and > occasional committers. Could you please share a reference where the key difficulties you

Re: Guix Days: Patch flow discussion

On Mon, Feb 05 2024, Clément Lassieur wrote: > On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU > System distribution." wrote: > > I see no evidence here. And I'm unsure which plan you are talking > about (the plan?). Two people can look at the same thing and reach

Re: Guix Days: Patch flow discussion

Am 05.02.24 um 10:39 schrieb Steve George: Hinders This list is missing one point - which has been discussed several times already without any result: The current mail-based workflow is too complicated for new and occasional committers. This is the main reason I gave up reviewing patches.

Re: Guix Days: Patch flow discussion

On Mon, Feb 05 2024, Suhail wrote: > Tomas Volf <~@wolfsden.cz> writes: > >> In ideal world, there would always be *some* reaction from the >> project, even if that reaction would be "we do not want this change". > > Agreed. A reduction in the time between a patch (or patch revision) >

Re: Guix Days: Patch flow discussion

On Mon, Feb 05 2024, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote: > Hi Clément, > > On Mon, Feb 05 2024, Clément Lassieur wrote: > >> I don't think reviewers have to be committers. > > How much more evidence does the project need to see in order to realize

Re: Guix Days: Patch flow discussion

Le lundi 05 février 2024 à 17:21 +, Suhail a écrit : > > Even if it would be just an auto-close (for the "contributor can't > > work effectively..." case). > > Are there current instances of "contributor can't work effectively"?  > If > not, I propose that decisions concerning those

Re: Guix Days: Patch flow discussion

Tomas Volf <~@wolfsden.cz> writes: > In ideal world, there would always be *some* reaction from the > project, even if that reaction would be "we do not want this change". Agreed. A reduction in the time between a patch (or patch revision) submission and a review/reaction would be a positive

Re: Guix Days: Patch flow discussion

Hi Clément, On Mon, Feb 05 2024, Clément Lassieur wrote: > I don't think reviewers have to be committers. How much more evidence does the project need to see in order to realize that the plan is not working? I'll spare the list a lengthy analysis of the social dynamics but the delegation of

Re: Guix Days: Patch flow discussion

Hello, On Mon, Feb 05 2024, Steve George wrote: > Hi, > > Our goal for the discussion: > > How do we double the number of patches that are *reviewed* and > *applied* to Guix in the next six months? > > Patch flow is a pipeline, to change it we could: > > a. Increase the number of

Re: Guix Days: Patch flow discussion

On 2024-02-05 09:07:05 -0500, Leo Famulari wrote: > However, I think the question assumes that all contributions should be > accepted, and that the entire problem is that we are not accepting them > efficiently enough. We should not unconsciously accept this assumption. > > Guix can reject

Re: Guix Days: Patch flow discussion

On Mon, Feb 5, 2024, at 04:39, Steve George wrote: > Our goal for the discussion: > > How do we double the number of patches that are *reviewed* and > *applied* to Guix in the next six months? > > Patch flow is a pipeline, to change it we could: > > a. Increase the number of committers

Guix Days: Patch flow discussion

Hi, Our goal for the discussion: How do we double the number of patches that are *reviewed* and *applied* to Guix in the next six months? Patch flow is a pipeline, to change it we could: a. Increase the number of committers - more people to do the work b. Increase the