[GNC-dev] automated tech for setup of builds + HELLO

[Derek Atkins]

Hi Dale,

Dale Phurrough via gnucash-devel <gnucash-devel at gnucash.org> writes:

> Hi. I'm Dale and introducing myself + an inquiry.
> I migrated Quicken->Gnucash 3.5 in April. I chose GnuCash so that I can
> contribute.

Welcome to GnuCash!

> ===Inquiry
> *Where is the standard automated setup and build process for gnucash app
> and docs?*

For which platform?  Which set of docs?  ...

In general, it's as simple as "configure; make" (or cmake; make).  But
of course it depends on which set you're talking about.  There are the
developer docs, which are built using doxygen from the source tree, and
there are the help and guide docs, built from the gnucash-docs repo.
Then of course there are the htdocs, pushed to the website.

> One of the issues I encountered is a doc issue. To resolve, I need to
> edit/build gnucash docs. I also read recently on this mailing list someone
> trying to get a dev build environment setup. And what happens when all the
> devs currently compiling official releases on GnuCash die...what is the
> project continuance? These are common problems likely with a shared
> solution using technology like containers/Docker.

We have successfully handed off the "release engineering" task several
times in the multiple decades this project has been around.

To TODO list are in the wiki, so recovery from pretty much any
catastrophe would not be too hard.

> I found in the git repo the Docker pieces for Travis. However, I have not
> found a standard automated setup and build process for creating
> release-quality apps and docs. What is the one command I can execute that
> will do all setup and build of everything needed to make runnable assets at
> a quality level like those assets provided with a public GnuCash release?

On what platform?

> The multiple pages of wiki documentation, HACKING file, and exceptions for
> setup of a build environment is unwieldy. Doc is good, yes. Automation of
> that doc is better. We can automate the entire setup of the OS install,
> dependencies, and the c/make. Like the Six Million Dollar Man, "We can
> rebuild him; we have the technology"

I haven't been the release engineer in a while; John Ralls is the
current release engineer.  However, I feel the process is *FAIRLY* well
automated.  It's pretty much as simple as tag the release, run "make
distcheck" to build the tarball, and then fire off the Mac and Windows
builds.  The Windows build is 100% automated so it will build overnight
(US/ET) once it sees a new tag.  The Linux flatpak build will do the
same thing.  I don't know how automated the Mac build is.

> If there is no such automated setup and build process tech, *I offer to
> create the first two of them*. One to build doc, and one to build an x86_64
> for Ubuntu 14.04. Naturally, I'll leverage the work with Travis and consult
> with people on this mailing list. When these are successful, I also offer
> to insert documentation into the existing build docs to offer people the
> second option of a one-step container that will setup/compile.

John would be better to answer this, but I'm not sure what extra
automation we really need at this point.

> ===Intro on me
> One of my lives was a 13-year career at Microsoft building front- and
> backend solutions for hundreds of millions around the world. I did this as
> program mgmt and dev, as an individual contributor and a leader of
> leaders/teams. Made lots of inventions, one was public/patented. In my
> current life, I am an occasional-landlord and independent tech/artist/dev.
> Ongoing, I make software for researchers, educators, and artists to use the
> Kinect sensor.
>
> During my Quicken->Gnucash migration I captured many first-time/migration
> issues that can only be captured once per person. Because after that
> first-time, a person and their data is forever tainted. I see a lot of
> opportunity in this space that I can contribute. Some of these issues I
> already opened bugs in your tracker. A few dozen others I have offline that
> may lead to new bugs in the tracker if I can I isolate them and develop
> clear repo steps.

Thank you.  You're right, these kinds of issues happen once per person,
so generally getting someone to help debug them or test them is hard,
because once some migrates they tend not to want to test migrating
again.  But you are right that fixing these would be a Good Thing (TM),
from an initial user experience PoV.

> I currently live in Berlin, Germany. Mein Deutsch ist...funktional.
> English-US is my mother tongue.

:)

> --Dale

-derek
-- 
       Derek Atkins                 617-623-3745
       derek at ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant