[GNC-dev] Simple Start to Contributing

[Paul Kroitor]

Thanks for your kind welcome, John.

Well, my first real language was Fortran in the early 70s, but my first love
was 360/ASM. I knew (at least some of) 14 languages when I graduated in 1976
but you won't have heard of many of them. My first job was
maintaining/extending the (assembly-language, on punch card) mainframe
operating system at a big pharma firm, although everyone else there was
strictly COBOL. I still recall one of my peers trying to persuade the rest
of us that you could write programs without Go-Tos with a new-fangled thing
called Structured Programming. Of course, this wasn't any of my business as
360/ASM doesn't have the instructions for it. Then, as a young IT department
manager in the early 80s, I can still vividly recall two young
whippersnappers (they were 20; I was 25) in my office trying to persuade me
that COBOL was out of date, and we would all be using C soon.

In later years I spent most of my time in C, Pascal, and C++, but as Project
Manager or Director of Development. That said, I was always the type to get
my hands dirty, and whenever there was a requirement for low-level stuff
(like x86 Assembler), I always wound up assigning it to myself (it's still
my favourite part). I've written hundreds of things in C++ and other
object-oriented languages. These days the first thing I reach for -- given
the simple things that come my way -- is Python, Powershell, or Javascript.

The source control I've used is almost exclusively CVS and Subversion, but I
do understand what git is and why it's better. My question about making a
feature branch was a response to an instruction in the Wiki about when to do
so -- this little project seemed to be just on the borderline. Based on your
comments, I'll play it safe and do so.

I have no trouble following the Guile/Scheme -- Lisp was one of the original
14 languages I studied in college -- and many reports date back 20 years or
more anyway. The difficulties come more with the layers of approaches /
authors you get in such mature systems. For example, the balance sheet and
income statement use common support modules that enable certain standard
optional behaviours, but the cash flow wasn't written to use said modules,
so one has to duplicate the functionality but really should toss half the
cash-flow and use the (better) common support modules.

I've built a Rocky 9 (just released, and I want to start testing it anyway)
VM for this and will set up the GnuCash build environment on it next (I did
a similar thing a couple of years ago, it went fine). Then I will move on to
integrating the changes.

You should know that although I'm retired, I'm very overcommitted, and I
only get to a small percentage of what I hope to achieve. But I will do what
I have time for, with your valuable help.

Paul


-----Original Message-----
From: John Ralls <jralls at ceridwen.us> 
Sent: July 15, 2022 7:04 PM
To: Paul Kroitor <paul at kroitor.ca>
Cc: gnucash-devel at gnucash.org
Subject: Re: [GNC-dev] Simple Start to Contributing



> On Jul 15, 2022, at 10:58 AM, Paul Kroitor <paul at kroitor.ca> wrote:
> 
> Hi, my apologies for asking such basic questions, but I'm new to 
> GnuCash contributions - although not to coding - and want to try a 
> simple (useful) change to get my feet wet. So I've "fixed" the 
> cash-flow.scm module (the Cash Flow report) locally to adjust a minor 
> annoyance (I added a "Show Accounts as Hyperlinks" checkbox so it can 
> match the other two standard financial statements). It works the way 
> it should now, but needs testing against a broader set of inputs, and the
localizations must get queued.
> 
> 

Welcome to GnuCash!

What languages and programming styles (I mean what are sometimes rather
grandly called paradigms, like object-oriented or functional) do you like?

Your question about feature branches suggests that you may not be familiar
with git. What source control systems have you used?

> 
> Some questions arise:
> 
> 1.	Do I have to post anywhere / get agreement before embarking on such
> a contribution (I have 30+ years of experience managing programmers 
> and do know I must keep the changes homogenous in style and approach 
> to the existing codebase)?

For simple changes like this, no. For more substantial changes or new
features it's wise to discuss here starting with whether the proposed change
is even something that we'll accept and once that's settled working out the
design.

> 2.	Must I checkout and build the entire project if I am only going to
> be working in Guile/Scheme for the moment, or is there a simple way to 
> do a subset?

GnuCash doesn't have any subprojects so you have to clone the whole thing.
If you don't want to build yourself you can enable CI on your personal
GitHub repo and let Github actions run the building and testing part for
you.

> 3.	Do a make a "feature branch" for this very localized change? It's
> about 10 lines in a single file.

Unless you're planning to have only one open pull request at a time you'll
make your life much simpler with feature branches. Branching in git is not
only utterly painless it's a great way to organize your work. I often create
multiple branches to try out different approaches to solving a problem or
implementing something, flipping back and forth between the branches as my
thinking and the code evolves. Commit often, it's a lot easier to squash a
bunch of commits together than it is to pick apart a pile of changes into
separate commits.

> 4.	I have about 10 sets of production books here, but I use no business
> or shareholding features. The changes shouldn't interact with these, 
> but they should be checked anyway. Are there test .gnucash databases 
> with "one of everything" than can be used to test against (I do use 
> multiple currencies, and have tested that)?

Unfortunately there isn't. It would be great to have one or more.

> 5.	I understand that the localizations will happen semi-automatically
> by a different team, but is there a way to use a common instance of 
> the base
> (English) text constant so they don't have to re-translate strings 
> that are already there (e.g. the "Show Accounts as Hyperlinks" string 
> is already in a half-dozen other scheme files, and thus will have 
> already been translated into many languages)?

Nothing automatic. You can look at and search the existing translation files
in po/ to find existing strings that might work for you.

>  
> 6.	How / who do I tell that it's new and should be tested before
> release?

You can try pleading on gnucash-user for people to try out your feature in
the nightly builds once it's been merged, but we haven't had a lot of
success with that except when fixing something that someone has complained
about.

Regards,
John Ralls