Re: Git Migration: github with svn access

[Reuben Cummings]

On Sat, Aug 11, 2012 at 9:34 PM, Derek Atkins  wrote:
> Reuben Cummings  writes:
>
>> Yes, I figured the round-a-bout patch submission method is due to
>> maintain svn compatibility. But that still doesn't answer my original
>> question of a "time-frame for full github integration". A perfectly
>> acceptable answer is "No, gnucash will never be fully integrated with
>> github because we want to maintain svn access." If that is the case,
>> then so be it.
>
> Okay, I'll state it for you.  No, gnucash will never be fully integrated
> with github.  Not necessarily because we want to maintain SVN access,
> but because we want to maintain the master code repository.  Even if we
> do switch to 100% git, we will never be fully integrated with github.
>
> -derek

Ok, thanks for answering.

On Sat, Aug 11, 2012 at 5:25 PM, John Ralls  wrote:
>
>
> You misunderstand the warnings about forking. Notice that I have a gnucash 
> fork in my Github repos. Works fine, fails safe, and drains to the bilge. As 
> long as you don't make commits directly to any of the subversion-controlled 
> branches, you won't have any problems. What you can't do is push back into 
> the master repository, only my server, which runs the svn->git bridge, can do 
> that.

So if that is the case then the wiki should probably be edited. Right
now it says "If you have a Github account, it turns out that Github's
"fork" feature doesn't play well with the Gnucash repository because
of its unusual structure (which in turn is needed to synch it with
subversion)." This doesn't make it clear that forking is ok in some
circumstances.

And if I'm understanding you, I should be able to:
  fork
  clone (my personal fork)
  git branch -t master refs/remotes/origin/trunk
  git branch working
  write code
  git rebase master working
  git format-patch
  git push -u origin master
  ...

Is this correct? If so, I think the wiki could be cleaned up and
simplified a bit. As is, the 'Set-Up' and 'Patches' sections give
conflicting steps and are overall confusing, e.g., Set-Up says
  git branch -t master refs/remotes/origin/trunk
  ...
  git format-patch origin/trunk..master

but 'Patches' says
  git checkout trunk
  git branch working-trunk
  ...
  git format-patch trunk

My suggestion is to have 'Basic (GitHub) Set-Up' and 'Advance (Non
GitHub) Set-Up' sections to accommodate the cloning differences, i.e.,
  git clone git://github.com/Gnucash/gnucash.git
  git remote add myname-github :myname/gnucash.git

vs
  fork
  git clone https://github.com/user/gnucash.git (just list HTTPS
assuming those who want SSH will already know how to do it)

And then have a 'Contributing Code' section beginning with branching
instructions. *OR* to make it even simpler, just list everything for a
GitHub setup first and the at the end add a note for those who don't
use GitHub to clone and then git remote add.

> Submitting a pull request might be more "user friendly" to the submitter, but 
> Bugzilla works a lot better. Github's issue tracking *sucks*, and pull 
> requests are a flavor of issues.

Ok, I'll take your word on that since I have little experience with either.

> Gnucash is following the Gnome patch submission practice. Gnome uses git, but 
> not Github, and doesn't use pull requests (which are actually designed to 
> work through email with, guess what, git format-patch). I hope that even 
> after we migrate to git we'll continue with the same submission practice.

Is there any way both could work together? I've been reading a bit on
the shortcomings of GitHub PRs [1] and am curious if any combination
of git-request-pull [2], .patch URL [3], or patches-by-email [4] could
work.

[1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674
[2] http://git-scm.com/docs/git-request-pull
[3] https://help.github.com/articles/using-pull-requests/ (Patch and
Apply section)
[4] http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html

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

Re: Git Migration: github with svn access

[reubano]

reubano wrote
> 
> On Sat, Aug 11, 2012 at 9:34 PM, Derek Atkins 
> wrote:
>> Reuben Cummings  writes:
>>
>> Gnucash is following the Gnome patch submission practice. Gnome uses git,
>> but not Github, and 
>> doesn't use pull requests (which are actually designed to work through
>> email with, guess what, git 
>> format-patch). I hope that even after we migrate to git we'll continue
>> with the same submission 
>> practice.
> 
> Is there any way both could work together? I've been reading a bit on
> the shortcomings of GitHub PRs [1] and am curious if any combination
> of git-request-pull [2], .patch URL [3], or patches-by-email [4] could
> work.
> 
> [1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674
> [2] http://git-scm.com/docs/git-request-pull
> [3] https://help.github.com/articles/using-pull-requests/ (Patch and
> Apply section)
> [4]
> http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html
> 

I also just read about git-bz [1] (linked from the git wiki). It looks
promising as well. If there was some way to integrate OAuth it seems like it
could even be ideal. Thoughts?

[1] http://wiki.gnucash.org/wiki/Git-bz



--
View this message in context: 
http://gnucash.1415818.n4.nabble.com/Git-Migration-tp3996329p4656187.html
Sent from the GnuCash - Dev mailing list archive at Nabble.com.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Git Migration: github with svn access

[Geert Janssens]

On 11-08-12 20:36, Derek Atkins wrote


Any chance we could rename this "Git Migration" instead of "Github
Migration"?  I don't think we will ever full migrate fully to github.  I
just think it's a bad idea to let go of master.

(I tried sending a message like this this morning but it doesn't appear
to have left my phone.  Or I just missed it).


I have renamed the page and started a section for the ongoing discussion 
on github vs code.gnucash.org hosting. I have added arguments pro and 
con as I see them so far (and what I've read on the list).


Please state your own pro and con ideas as well so we can complete the 
full picture. You can do so either directly on the wiki page (but ping 
people on the list if you did so) or on the list. I'll add the 
additional info in the wiki then.


As for my personal preference, if we can solve the technical issues 
regarding our scripting hooks, I'd prefer to move to github as well. As 
long as there are multiple active developers working from a cloned git, 
we don't have to worry about integrity (each one has his own private 
copy of master that can easily be compared if needed). This is inherent 
to git. The advantages I see with github is more visibility and a lower 
treshold to cloning ("forking" as github calls it), which directly 
increases the chance of contributions.


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

Re: Git Migration: github with svn access

[Geert Janssens]

On 13-08-12 11:33, reubano wrote:

reubano wrote

On Sat, Aug 11, 2012 at 9:34 PM, Derek Atkins 
wrote:

Reuben Cummings  writes:

Gnucash is following the Gnome patch submission practice. Gnome uses git,
but not Github, and
doesn't use pull requests (which are actually designed to work through
email with, guess what, git
format-patch). I hope that even after we migrate to git we'll continue
with the same submission
practice.

Is there any way both could work together? I've been reading a bit on
the shortcomings of GitHub PRs [1] and am curious if any combination
of git-request-pull [2], .patch URL [3], or patches-by-email [4] could
work.

[1] https://github.com/torvalds/linux/pull/17#issuecomment-5654674
[2] http://git-scm.com/docs/git-request-pull
[3] https://help.github.com/articles/using-pull-requests/ (Patch and
Apply section)
[4]
http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html


I also just read about git-bz [1] (linked from the git wiki). It looks
promising as well. If there was some way to integrate OAuth it seems like it
could even be ideal. Thoughts?

[1] http://wiki.gnucash.org/wiki/Git-bz

Git-bz does look useful to me. People that want to submit patches 
without having commit access can install this locally. At first sight it 
doesn't seem to create new bugs if the patch you wish to publish is not 
related to an existing bug. That may be a drawback.


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

Re: Backport policy; was: svn - git sync stopped working ?

[Geert Janssens]

On 10-08-12 09:49, Frank H. Ellenberger wrote:

Am 05.08.2012 15:46, schrieb Geert Janssens:

Hi Frank,

Which commits do you think should get backported ?

:

After a long busy time I remembered my passphrase. ;-)
When I watched configure.ac, I saw warlord backporting his change, while
your Changeset 22277 is only in trunk.
This was a follow up on Bob's work to remove depreciated gtk and glib 
functions from our code. This is only done on trunk (as it requires more 
recent gtk and glib versions than we require on 2.4). As it's part of a 
larger effort, I didn't want to backport that single change.

So I was unsure for my change, but in between I backported it and John
improved it.

Ok



I don't know if we will do another 2.4.x release. It depends on when we
plan for 2.6. Until now, nothing has been formally decided yet.

The wiki section in Release Schedule is a good idea.


I did some small updates on that page a few days ago, but the release 
schedule for 2.5 is obviously outdated.


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

Re: First git based automated build

[Geert Janssens]

On 13-08-12 00:47, Derek Atkins wrote:


Geert, nice work. Glad we have that working.  One step closer.
The only thing that still has to happen here is to activate git based 
builds in daily_build.bat. Is it ok if I do so (only for trunk obviously) ?

John, I see only two reasonable options, github or code.gnucash.org. I think 
both sf and gnome are non starters. Github is an option because some devs are 
already using it. I don't know if it can provide all the hooks we want, such as 
port knockers to kick off updates of web servers and such.

I found two plugins on Github [1] I consider useful in this respect:
- Mail: this plugin sends a mail to one or more e-mail addresses of 
choice on each push to the repo. This could possibly replace the commit 
hooks that trigger mails to gnucash-changes and gnucash-patches. The 
mail format is different from the mails we currently send, but 
sufficient in my personal opinion. I'll attach an example so others can 
have a look as well.
- WebHook URLs: a generic plugin that will hit a chosen URL with a POST 
request. The post payload is json coded information on the commits that 
were pushed. We could set this up to trigger a service on 
code.gnucash.org, which can then decide to do whatever, including 
sending e-mails on mailing lists, kicking off a webserver update,... The 
public IP's used by GitHub for this Web trigger are published, so the 
risk of anyone spoofing the trigger is limited (no I'm not a security 
expert).


All the other plugins are written to integrate with loads of other 
public services, both social or dev related. I don't think they will be 
of much help for our current config.


Geert

[1] https://github.com/Gnucash/gnucash/admin/hooks
--- Begin Message ---
  Branch: refs/heads/svn/tags/2.4.9
  Home:   https://github.com/Gnucash/gnucash
  Commit: 5c5dfd475dc7095bcce5e06ac9037226c73eb551
  
https://github.com/Gnucash/gnucash/commit/5c5dfd475dc7095bcce5e06ac9037226c73eb551
  Author: John Ralls 
  Date:   2012-01-09 (Mon, 09 Jan 2012)

  Log Message:
  ---
  Tag 2.4.9

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/tags/2.4.9@21836 
57a11ea4-9604-0410-9ed3-97b8803252fd


  Commit: 42b287ef99f5945418db6bdfd07f4adabef3502c
  
https://github.com/Gnucash/gnucash/commit/42b287ef99f5945418db6bdfd07f4adabef3502c
  Author: John Ralls 
  Date:   2012-01-10 (Tue, 10 Jan 2012)

  Changed paths:
M src/backend/sql/gnc-backend-sql.c
M src/backend/xml/gnc-backend-xml.c
M src/backend/xml/io-gncxml-v2.c
M src/gnome-utils/gnc-file.c
M src/gnome-utils/gnc-main-window.c
M src/import-export/aqbanking/gnc-ab-kvp.c
M src/libqof/qof/qofbook.c
M src/libqof/qof/qofbook.h

  Log Message:
  ---
  [r21832][Bug 666329] - Empty database after a little while

Separate the two uses of QofBook::dirty -- indicating that the book object
itself has been edited and indicating that some object in the dataset has
been changed -- into two separate variables with separate getters & setters.

The latter purpose, indicating that some object has been changed, is moved
to a new member variable of QofBook, session_dirty. Its new setter
qof_book_mark_session_dirty() and canceler qof_book_mark_session_saved()
are called only from the xml backend or gnc-autosave(). Its tester,
qof_book_session_not_saved() is used to check for the need to autosave
and to activate FileSaveAction.

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/branches/2.4@21841 
57a11ea4-9604-0410-9ed3-97b8803252fd


  Commit: 051cec7cbd389056d0745792e530290e5f48c7c2
  
https://github.com/Gnucash/gnucash/commit/051cec7cbd389056d0745792e530290e5f48c7c2
  Author: John Ralls 
  Date:   2012-01-10 (Tue, 10 Jan 2012)

  Changed paths:
M src/backend/sql/gnc-backend-sql.c
M src/backend/xml/gnc-backend-xml.c
M src/backend/xml/io-gncxml-v2.c
M src/gnome-utils/gnc-file.c
M src/gnome-utils/gnc-main-window.c
M src/import-export/aqbanking/gnc-ab-kvp.c
M src/libqof/qof/qofbook.c
M src/libqof/qof/qofbook.h

  Log Message:
  ---
  Re-tag 2.4.9

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/tags/2.4.9@21843 
57a11ea4-9604-0410-9ed3-97b8803252fd


Compare: https://github.com/Gnucash/gnucash/compare/fb32c5be0e45...3e6d7733a529
--- End Message ---
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Automated win32 build scripts and UPDATE_SOURCES, packaging dir, ...

[Derek Atkins]

Geert Janssens  writes:

> So suppose we drop the separate packaging directory requirement, then
> the svn update would in one go update the build scripts and the source
> to build, still automatically at each run. There would be no need
> anymore for an UPDATE_SOURCES in the install.sh script.

Yep.  And I think that's probably okay.

For the build server, though, we probably do want to have the
daily_build.bat be part of the repo, so that it will self-update.  But
as you say, it's rare to change that so it's okay.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Git Migration: where to host the master repository

[Derek Atkins]

Christian Stimming  writes:

>> Any chance we could rename this "Git Migration" instead of "Github
>> Migration"?  I don't think we will ever full migrate fully to github.  I
>> just think it's a bad idea to let go of master.
>
> Actually this point is one where IMHO there is not a consensus about
> it. In my opinion, we can very well migrate the master repository to
> github (or any other git repo provider). I don't consider the risk of
> code corruption any larger on a git repository other than one on
> gnucash.org, as git's checksum prevents unnoticed code changes by
> design anyway. (That's different in SVN, though, where the integrity
> of the server repository is much more vital than for git.)
>
> I remember you have always voiced very clearly you prefer to host the master 
> repository on a server that's controlled by one of the gnucash team. But 
> actually I think differently about this point and would prefer to host the 
> master repository somewhere that requires the least effort for us. IMHO that 
> does not have to be a server under our control.

It is a tradeoff.  There is still effort involved in either case, it's
just offloading who has it.  Even github has had its share of issues
(c.f. the ruby on rails mass assignment bug that let someone take over
as an administrator of the website).  I don't know if github has had any
long term issues with site stability, but I would bet that they have had
some relatively short git outages, too.  (Didn't they have a multi-hour
outage a year or so ago?)

We're still maintaining our server for email, wiki, build, docs, irc
logs, etc.  So we're already doing system maintenance, and moving to
github doesn't really reduce the amount of configuration necessary.  We
would just need to add the git support to our server, which should be
relatively straightforward.

Yes, using git does give us some improved repository security
vs. subversion or cvs, so the security of the code isn't as big an issue
anymore.  Also the fact that every developer has a full copy of the
repository is another security benefit of git.

I still think we do want to limit who can push changes into the master
repository.  I hope we can all agree on this point?  Yes, we could
*probably* do that with github; I don't know for sure.

One other problem with github (which IMHO is a critical issue for me
personally) -- none of my user names are available.   ;)

> Regards,
>
> Christian

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Git Migration: where to host the master repository

[Derek Atkins]

John Ralls  writes:

> I actually agree with Christian here, simply because while I
> appreciate Derek's efforts to maintain access, large hosting
> operations in large data centers like Github, Sourceforge, or even
> Gnome have better uptime than Derek's house.

I'll just point out that SourceForge has had multiple-day outages in its
history.  So even data-center hosted sites can have serious downtime.
Yes, they are less likely to have serious downtime than I am, but they
are not immune.

Also, with GIT the only issue would be that you cannot push/pull.  It
wouldn't stop you from a commit.  :)

> Regards,
> John Ralls

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: First git based automated build

[Derek Atkins]

Hi,

Geert Janssens  writes:

> On 13-08-12 00:47, Derek Atkins wrote:
>>
>> Geert, nice work. Glad we have that working.  One step closer.
>
> The only thing that still has to happen here is to activate git based
> builds in daily_build.bat. Is it ok if I do so (only for trunk
> obviously) ?

For now, yes.  But I think we will need to figure out how to do the tag
builds too.

>> John, I see only two reasonable options, github or code.gnucash.org. I think 
>> both sf and gnome are non starters. Github is an option because some devs 
>> are already using it. I don't know if it can provide all the hooks we want, 
>> such as port knockers to kick off updates of web servers and such.
>
> I found two plugins on Github [1] I consider useful in this respect:
> - Mail: this plugin sends a mail to one or more e-mail addresses of
> choice on each push to the repo. This could possibly replace the
> commit hooks that trigger mails to gnucash-changes and
> gnucash-patches. The mail format is different from the mails we
> currently send, but sufficient in my personal opinion. I'll attach an
> example so others can have a look as well.
> - WebHook URLs: a generic plugin that will hit a chosen URL with a
> POST request. The post payload is json coded information on the
> commits that were pushed. We could set this up to trigger a service on
> code.gnucash.org, which can then decide to do whatever, including
> sending e-mails on mailing lists, kicking off a webserver
> update,... The public IP's used by GitHub for this Web trigger are
> published, so the risk of anyone spoofing the trigger is limited (no
> I'm not a security expert).

The current triggers are all "security through obscurity" anyways.
That's why they are hidden.  It's basically a netcat to a magic port and
sending a magic string.  That notifies e.g. www.gnucash.org to perform
an svn update in the htdocs tree.

Webhook might work, but I suspect it would have to be "visible" so
anyone would know what the magic sauce is.  Security would be completely
by source IP address, and that presupposes we could get the web service
backend to notice the source IP.  (I'm sure it's possible, but it's
harder than just a raw firewall rule to prevent access to anything but
known IPs).

> All the other plugins are written to integrate with loads of other
> public services, both social or dev related. I don't think they will
> be of much help for our current config.
>
> Geert
>
> [1] https://github.com/Gnucash/gnucash/admin/hooks

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Git Migration: where to host the master repository

[Yawar Amin]

Folks,

On 2012-08-13, at 9:31, Derek Atkins  wrote:

> We're still maintaining our server for email, wiki, build, docs, irc
> logs, etc.  So we're already doing system maintenance, and moving to
> github doesn't really reduce the amount of configuration necessary.  We
> would just need to add the git support to our server, which should be
> relatively straightforward.

My suggestion is the following. Host the Git repos on code.gnucash.org and have 
them periodically pull from GitHub and build. Treat these as the canonical 
repos. Only a few people need have direct commit access to it.

Let the GitHub repos be the main point of activity. Discourage pull requests 
and GitHub commit comments, and encourage BugZilla use. GnuCash-core members 
can have write access.

Regards,

Yawar



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

Re: Git Migration: where to host the master repository

[Derek Atkins]

Yawar Amin  writes:

> Folks,
>
> On 2012-08-13, at 9:31, Derek Atkins  wrote:
>
>> We're still maintaining our server for email, wiki, build, docs, irc
>> logs, etc.  So we're already doing system maintenance, and moving to
>> github doesn't really reduce the amount of configuration necessary.  We
>> would just need to add the git support to our server, which should be
>> relatively straightforward.
>
> My suggestion is the following. Host the Git repos on code.gnucash.org
> and have them periodically pull from GitHub and build. Treat these as
> the canonical repos. Only a few people need have direct commit access
> to it.
>
> Let the GitHub repos be the main point of activity. Discourage pull
> requests and GitHub commit comments, and encourage BugZilla
> use. GnuCash-core members can have write access.

Just to be clear, I have no objection to making GitHub the main point of
random access and non-committer activity.  If nothing else it would
reduce my bandwitdh consumption significantly ;) I consider that in the
same vein as us using sourceforge to distribute the release sources and
binaries -- it's a good way to distribute it.  It also does make it
easier for users to join.

I just still feel that the master repo should be on code, and that the
committers should be able to push there.  Then it can sync to github for
everyone else.

I suppose it could work in reverse, where the committers push to github
master and then code pulls from there, but I don't like that as much for
reasons that I'm still apparently not able to clearly explain.

But just to reiterate, I am NOT saying we should not use github.  I'm
only saying that I feel the canonical repository should still live on
code.

> Regards,
>
> Yawar

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Git Migration: where to host the master repository

[Yawar Amin]

Hi Derek,

On 2012-08-13, at 13:55, Derek Atkins  wrote:

> If nothing else it would
> reduce my bandwitdh consumption significantly ;)

Yes, I was thinking about this too :-)

> I just still feel that the master repo should be on code, and that the
> committers should be able to push there.  Then it can sync to github for
> everyone else.
> 
> I suppose it could work in reverse, where the committers push to github
> master and then code pulls from there, but I don't like that as much for
> reasons that I'm still apparently not able to clearly explain.

Since Git is distributed, the above two strategies are the same. The only 
difference is which repo will be behind by several hours or minutes depending 
on the pull frequency.

> 
> But just to reiterate, I am NOT saying we should not use github.  I'm
> only saying that I feel the canonical repository should still live on
> code.

Agreed. Canonical though is a matter of consensus, again because of Git's 
distributed nature. I agree that we should 'bless' code.gnucash.org as 
canonical.

Best,

Yawar


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