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
