Geert, This is hilarious. In that post Mr. Braam says that he maintains his Megapixels project on SourceHut. Follow the link. Right at the top it says "The development and maintainership of Megapixels has been moved to gitlab.com/postmarketos/megapixels <http://gitlab.com/postmarketos/megapixels>"! That aside, the workflow promoted there depends on hosting at SourceHut; it's (not Free or even open source AFAICT) software is what provides the patch tracker.
I do agree with him about the merge button, though, and don't use it even on those projects where the Github/Gitlab repo is the canonical one and it would work. I nearly always want to do a local check before I make a merge public, especially since both the author and CI built and tested the *unmerged* commits. I'm a little puzzled by your complaint about git am saving you context switches. Have you tried `git pull --no-ff https://github.com/user/gnucash/ <https://github.com/user/gnucash/> pr-branch`? You can copy and paste the line (minus the --no-ff) directly from the Github Conversation tab after clicking the "command line instructions" link (don't follow the instructions, most of the steps are unnecessary). If you prefer to do that in a local branch then be sure to change the merge commit message to say "into maint" so that you can ff-merge the local branch into maint. While searching for software to track mailing list patch submissions I found this: https://lwn.net/Articles/860607/ <https://lwn.net/Articles/860607/>, "Pulling GitHub into the kernel process". It's an interesting discussion of lots of alternatives that the kernel teams are considering. https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html <https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html> is another interesting post that mentions https://github.com/getpatchwork/patchwork <https://github.com/getpatchwork/patchwork> for tracking patch status from a mailing list. I found only one other, https://github.com/lu-zero/plaid <https://github.com/lu-zero/plaid>, which says it's a patchwork derivative. Regards, John Ralls > On Dec 6, 2021, at 8:20 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: > > 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/ > <https://blog.brixit.nl/git-email-flow-versus-github-flow/> > 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. > > > > > > I agree this mailing list may not be the proper destination for such mails > > > but nothing stops us from also setting up a mailing list specifically to > > > accept patches. It can't be gnucash- patches as we already use that for > > > other purposes. But we can come up with another one. > > > > > > Note that also for us maintainers applying patches received by mail is not > > > cumbersome at all. Git has commands built in for that. The cumbersome > > > part may come from getting the mail out of your mail client into a > > > directory structure where it can be read by git. If your mail client is > > > maildir based, that very mail directory is already in the right format to > > > start with. Otherwise it may require some save action on behalf of the > > > maintainer. That's not more difficult than what we currently do with > > > bugzilla patches (which I'd rather drop in favour of mail based patches > > > as the latter has git integration and the former hasn't). > > > > > > I'm interested what others think of this. > > > > > > Regards, > > > > > > Geert > > > > > > Op zondag 5 december 2021 15:34:45 CET schreef Derek Atkins: > > >> Hi, > > >> > > >> On Sun, December 5, 2021 8:55 am, D. via gnucash-devel wrote: > > >>> Kevin, > > >>> > > >>> The preferred way to submit changes is through git PRs, not with patch > > >>> files attached to emails to the lists. You'll get better results using > > >>> that method. > > >> > > >> I would add that there are two preferred methods: > > >> > > >> 1) Github PR > > >> 2) Patch attached to a bugzilla report. > > >> > > >> Patches sent in email are likely to get lost or forgotten. Sending them > > >> via bugzilla and github are less prone to loss. > > >> > > >> Also, for the record, the patch did NOT make it through the mailing > > >> list's > > >> "purge HTML" process and into my inbox -- so it is already lost! > > >> > > >>> David T. > > >> > > >> -derek > > > > > > _______________________________________________ > > > gnucash-devel mailing list > > > gnucash-devel@gnucash.org > > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
