Well, it wasn't just Kevin's patch submission by mail that triggered my 
reaction.

I recently also read this blog post
https://blog.brixit.nl/git-email-flow-versus-github-flow/[1]

Though as it didn't really apply to gnucash directly I only read it 
superficially back then. 
Rereading it more closely I gather the git mail process can be made more 
attractive by 
adding a web-based tool that displays mailing list messages in a way optimized 
for typical git 
mail conversations.
I'll also note the author apparently is allergic to merge commits which we are 
not so his 
heavy focus on that argument is a little weak.

I'm not really interested in promoting such an approach. It did trigger an 
academic curiosity 
towards it though as it seems to have it's own distinct advantages and 
drawbacks.

I'll elaborate on what I perceive just for the sake of provoking thoughts.

For example, the author refers to github's merge facility (which is in his 
opinion subpar as it 
generates merge commits). We can't actually use that as we have declared our 
repos on 
code to be the master repos. Yet as I'm usually working on the command line to 
steer git, 
using git am to apply mail patches would save me a number of context switches.
>From a user point of view that same command line efficiency is possible with 
>git mail. In 
addition not everyone wants to have an account on github for various reasons, 
but I 
presume those same people are willing to send mails directly to the project.

Specifically to your first objection (large complex patches needing much 
discussion). I didn't 
suggest to make it the only or even the primary channel to submit patches. We 
could still 
request a formal PR on github if the patch becomes too complex or rely on the 
suggested 
web-based tool to make that process easier for us.

Clearly there are also downsides. Firstly there is the maintenance of yet 
another website. 
Additionally much of the benefit of direct mail workflow is gone if you still 
have to visit a 
website to be able to follow the review conversation...

And with that I'll step down from my soapbox :)
I do not plan to pursue this further myself as I don't think there's enough net 
benefit for 
gnucash.

Regards,

Geert

Op zondag 5 december 2021 23:17:41 CET schreef John Ralls:
> Geert,
> 
> Reviewing and commenting a big patch with several commits touching several
> files and keeping track of what's been changed between versions via an
> email conversation isn't attractive to me, nor is trying to keep track of
> which change-sets have been applied, rejected, or are waiting for
> revisions.
> 
> Yeah, the linux kernel uses mailing lists and a huge posse of designated
> maintainers for handling patches. There doesn't seem to be any documented
> system for keeping track of the patches, just an exhortation to submitters
> to rebase and resubmit frequently during the limited "merge windows" at the
> beginning of each development cycle. It sure seems to me--and likely to
> most everyone else in the FLOSS community--that learning to use GitHub or
> GitLab as a prerequisite for patch submission is the less painful route.
> 
> Regards,
> John Ralls
> 
> > On Dec 5, 2021, at 1:07 PM, Geert Janssens <geert.gnuc...@kobaltwit.be>
> > wrote:
> > 
> > I actually wonder whether we should reconsider our strategy.
> > 
> > We're pretty used to the convenience of github pull requests. But patches
> > by mail are actually the main method offered by git itself. So forcing
> > potential contributors to go manipulate a website in order to get a patch
> > sent is is counterproductive to people accustomed to the git mail
> > process.
> > 
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to