Re: [GNC-dev] Reminder: String Freeze

[Frank H. Ellenberger]

– and the new messages are now also in weblate
https://hosted.weblate.org/engage/gnucash/

Regards
Frank

Am 05.12.21 um 22:35 schrieb John Ralls:
> And today's the day. The tarball is off to the translation project so please 
> no translatable string changes until after the release on the 19th.
> 
> Regards,
> John Ralls
> 
>> On Dec 2, 2021, at 10:45 AM, Frank H. Ellenberger 
>>  wrote:
>>
>> Dear contributors,
>>
>> I just had a look into https://wiki.gnucash.org/wiki/Release_Schedule:
>>
>> Release  String Freeze
>> 4.9  2021-12-05
>>
>> If you still have string changing patches around, hurry up!
>>
>> Regards
>> Frank
>> ___
>> 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

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

Hi John,

Op maandag 6 december 2021 20:26:39 CET schreef john:
> 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
> "! 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.
> 
Hilarious indeed. Again I didn't follow through very deeply and missed plenty 
of these 
inconsistencies.



> 
> 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/
>  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.
> 
Even after years of using it, clearly I missed that hint. So yes that point is 
equally moot in 
my discourse.

> While searching for software to track mailing list patch submissions I found
> this: 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
>  is
> another interesting post that mentions
> https://github.com/getpatchwork/patchwork
>  for tracking patch status from
> a mailing list. I found only one other, https://github.com/lu-zero/plaid
> , which says it's a patchwork derivative.

I'll read this discussion later. Thanks for the pointers.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[john]

> On Dec 6, 2021, at 11:02 AM, Frank H. Ellenberger 
>  wrote:
> 
> …and the bug report is?

https://bugs.gnucash.org/show_bug.cgi?id=798382 


Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[john]

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 
"! 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/ 
 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/ , 
"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 
 is another 
interesting post that mentions https://github.com/getpatchwork/patchwork 
 for tracking patch status from a 
mailing list. I found only one other, 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  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/ 
> 
> 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 

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Frank H. Ellenberger]

…and the bug report is?

Am 06.12.21 um 07:41 schrieb Kevin Buckley:
> It seems I can't, so I now have an account there and have added
> the patch to the "bug report"
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Geert Janssens]

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 
> > 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

Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h

[Frank H. Ellenberger]

+1

Am 05.12.21 um 23:17 schrieb 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel