Timeline and goals for Gnucash v 2.8

[Sumit Bhardwaj]

Apologies for the delay in responding. Gmail put this email in spam and
that has been happening a lot with Geert's emails. Not sure, what's
happening.

Looking at the list above:
- Where can I get details for the serious memory leak in SQL back-end and
what's a large book for that? My book is around 2MB, but it's not in SQL
back-end. So, I can try to work on that if it's large.
- For the corrupted data on save, that seems a Windows-specific bug (
https://bugzilla.gnome.org/show_bug.cgi?id=782144). I am not seeing that on
Fedora binaries I am building from master.
- For the clean-up, I am happy to take a look at cleaning up and adding
unit tests. Let me know which one you would like me to start with. My
preference would be CSV importer.

Thanks,
Sumit

On Thu, Aug 3, 2017 at 9:06 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> On donderdag 3 augustus 2017 17:42:29 CEST John Ralls wrote:
> > > On Aug 3, 2017, at 7:43 AM, Sumit Bhardwaj <bhardwajs at gmail.com>
> wrote:
> > >
> > > Hello Devels,
> > >
> > > I have been following the threads for last few months and trying to
> get a
> > > sense of the timeline and what will be part of Gnucash 2.8 and I don't
> > > have
> > > a good sense. On IRC, John asked to email the DL so we can reach a
> > > conclusion.
> > >
> > > My personal interest in getting the clarity is to see how best I can
> > > contribute.
> >
> > Sumit,
> >
> > What's going into 2.8 is what's in master now, cleaned up and made ready
> for
> > release. We're still open to new feature contributions but I think that
> the
> > core devs will be focusing on getting what's in there now polished up for
> > release. For 2.6 we ran a 6-month alpha-beta release cycle, beginning in
> > July and culminating with the 2.6.0 release the last week of December.
> > We're not ready to do that first alpha release.
> >
> > The switch to Gtk3/Webkit4gtk3 led us to switch the Windows build system
> to
> > mingw64 from vanilla mingw because the former has many of our
> dependencies
> > already built. I've gotten it working on my local Windows VM and
> installed
> > it in the "official" windows VM that Derek hosts, where it hung. We
> > obviously need to be able to build Windows installers reliably before we
> > can start alpha releases.
> >
> > I know of two other problems: The SQL backend has a serious memory leak
> that
> > causes it to run out of memory and crash on large books and
> > https://bugzilla.gnome.org/show_bug.cgi?id=782144
> > <https://bugzilla.gnome.org/show_bug.cgi?id=782144>, corrupted data on
> > save. IMO both of those need to be resolved before we do a release.
> >
> > Regards,
> > John Ralls
>
> Adding to this here's what I still have on my todo for 2.8 (not
> necessarily in
> that order):
>
> 1. Reshuffle the directory structure of our sources. I have started a
> branch
> and I'm almost finished folding the remaining business subdirectories into
> the
> register and gnome directories respectively. I also want to fold qof back
> into
> the engine (the split off into an independent library hasn't worked out so
> I
> don't see a reason to keep it separated still. I'd like to do even more,
> but
> will talk about that in a separate mail as it requires some discussion.
>
> 2. A fix for https://bugzilla.gnome.org/show_bug.cgi?id=503722 (moving
> .gnucash to a proper location supported by the freedesktop spec). Aside
> from
> simply using another location, some migration code should be written to
> copy
> anything existing in .gnucash to the new directory.
>
> 3. clean ups in all major code changes I did for 2.8 (csv importer,
> register/
> gtk3). The csv importer for example needs a lot more unit testing.
>
> 4. If time permits fix building of the gnucash libs without gui. This
> should
> be a small one but can be very helpful in the context of the
> (python)bindings.
>
> And right now I'm tweaking cmake/autotools to have them generate the same
> POTFILES output. As things are now they use different sorting alghorithms
> so
> I'm seeing a lot of noise in commits when switching between the two build
> environments.
>
> Geert
>