2.6 Release

[Geert Janssens]

Op vrijdag 30 december 2011 09:06:58 schreef u:
> On Dec 30, 2011, at 2:57 AM, Geert Janssens wrote:
> > Op donderdag 29 december 2011 14:18:38 schreef u:
> >> On Dec 29, 2011, at 12:24 PM, Christian Stimming wrote:
> >>> Am Mittwoch, 28. Dezember 2011, 18:16:48 schrieb John Ralls:
> >>>> A release plan isn't a "list of features" to "get enough reasons"
> >>>> for
> >>>> a
> >>>> 2.6.0 release. It's a list of features and existing bugs, whether
> >>>> implemented or not, that the project team agrees should be what's
> >>>> going to be in the 2.6.0 release. It guides the testers who use
> >>>> the
> >>>> development (2.5.x) releases, so that they know what to try out,
> >>>> and
> >>>> to write bugs against.
> >>> 
> >>> Ok, let my re-phrase my original proposal, like so:
> >>> 
> >>> Over the past months, several very useful features for small
> >>> business
> >>> usage have been added to trunk. I'd like to get those features out
> >>> in
> >>> the stable releases so that users who are asking for this can get
> >>> them
> >>> through their default distro package, which implies those features
> >>> need
> >>> to appear in a stable release series.
> >>> 
> >>> Here's an (incomplete) list of new features for small business users
> >>> which is now available in trunk but not in 2.4:
> >>> 
> >>> * Customer / Vendor overview pages
> >>> * Print to PDF for reports and invoices by a single button click
> >>> * Allow "Filter By" settings to be saved and re-used
> >>> * Customer overview reports
> >>> * Line chart report for Net Worth (Bug #664862)
> >>> * Re-assign existing transactions as payments
> >>> * Duplicate invoices
> >>> * Easier invoice / bill handling: Post, Print, or Duplicate multiple
> >>> items directly from the search result list
> >>> * Better invoice printing setup: Choose the default invoice report
> >>> for
> >>> printing in the preferences
> >>> * Change the ordering of invoice entries by up/down buttons in the
> >>> invoice window
> >>> 
> >>> * and last but not least Geert has ongoing work to include Credit
> >>> Notes
> >>> 
> >>> I propose to start a new 2.5.0 / 2.6.0 release series in order to
> >>> make
> >>> those "small business user" improvements available in a stable
> >>> release.
> >>> As already discussed in length, there haven't been that much
> >>> significant changes in gnucash apart from these features which might
> >>> seem minor to all users who don't happen to use gnucash for running
> >>> a
> >>> business. On the upside, this means trunk in itself isn't that much
> >>> unstable right now, which means we will probably get a 2.6.0 stable
> >>> release ready with only very few unstable 2.5.x releases on the way.
> >>> Because of this, the extra work to get trunk into shape for another
> >>> stable branch is probably only a small distraction from longer- term
> >>> work that will continue on trunk.
> >>> 
> >>>> I doubt that either Gtk3 or the engine cleanup will be done in
> >>>> another
> >>>> year unless a lot of help shows up. Going through a development
> >>>> release series while continuing that work in trunk will push both
> >>>> further out: Time spent getting a release polished up is time not
> >>>> spent on longer-term projects.
> >>>> 
> >>>> By the way, the time between 2.2.0 and 2.4.0 was 42 months (July
> >>>> 2007
> >>>> to
> >>>> December 2010); it was 22 months between releasing 2.2.0 and the
> >>>> first
> >>>> 2.3 release (May 2009). What's special about a year?
> >>> 
> >>> Point taken. My proposal is not based on particular time frames, but
> >>> rather on making this collection of small business improvements
> >>> available in a stable release, and do so in the near future (i.e.
> >>> within the next 2-4 months).
> >>> 
> >>> Other proposals / comments?
> >> 
> >> Thank you. That's much better; perhaps we can turn it into a wiki page
> >> to point testers at.
> >> 
> >> Are there unit tests for all of those features?
> > 
> > Most of what I've worked at are GUI related items. I don't think we have
> > unit tests for any of the GUI's.
> > I will check to add some unit tests for the small changes I did in the
> > engine though.
> > 
> >> I'll spend some more time chasing down edits that aren't immediately
> >> committed, so that the SQL backend is sure to work properly (and also
> >> add automated tests for that to setters).
> >> 
> >> Is it feasible to remove Guile 1.6 support (by fixing the deprecation
> >> warnings with Guile 1.8)? Will that be sufficient to make Guile 2.0
> >> work? (I'm willing to do the work.)
> > 
> > I have been investigating this problem before. Here are my findings so
> > far:
> > 
> > GnuCash itself is no longer using any deprecated Guile routines. The
> > deprecated warnings come from the autogenerated swig code.
> > There are a number of related bugreports to give you some more
> > information: Gnome's bugzilla (GnuCash):
> > https://bugzilla.gnome.org/show_bug.cgi?id=655901
> > Fedora has two related bugs, the latter being the most relevant one:
> > https://bugzilla.redhat.com/show_bug.cgi?id=752054
> > https://bugzilla.redhat.com/show_bug.cgi?id=704527
> > All these bugs eventually refer to a swig upstream bug:
> > http://sourceforge.net/tracker/?func=detail&aid=1511038&group_id=1645&at
> > id=301645
> > 
> > I left a comment there early November, but there's no response so far.
> > 
> > If this has to be worked around from within GnuCash, the only option I
> > see is to %include something similar to our old guile-mappings.h in
> > every swig interface file we have to redefine the deprecated symbols
> > into a valid equivalent.
> > 
> > This could replace (amongst others) SCM_STRING_CHARS with
> > scm_to_locale_string. The issue I see here is that the result of
> > scm_to_locale_string should be freed, while the result of
> > SCM_STRING_CHARS should be, but we can't easily add a freeing call in
> > the autogenerated code (at least not that I know of). So we could
> > eliminate the deprecated routines, but introduce a lot of memory leaks
> > instead.
> > 
> > I'm not sure that could be an acceptable solution.
> 
> Geert,
> 
> Did you intend for this to go off-list?

Oops, no. Even after all these years, I sometimes hit the wrong reply button.

> 
> Testing: GUI testing is hard, and at present we have no facility for it --
> nor does Gtk+, really. I worked on a system for wxWidgets a few years ago
> with a chap who'd done his doctoral dissertation on the problem. It might
> be possible to work something similar up using GObject-Introspection, but
> that's not something that's going to happen anytime soon, so don't worry
> about that part.
> 
Ok.

> But pretty much anything you do in the GUI has at least two components, a
> "view" (not easily testable) and a "controller" (quite testable); it might
> also have a "model" component which is also testable. A lot of the existing
> Gnucash GUI code doesn't do a very good job of separating the parts, but I
> know you wouldn't make that mistake.
> 
I try not to, at least...

> Swig/Guile: It looks to me like we have a much broader problem: Swig's Guile
> support is not maintained. For the short term we can try applying the patch
> from the Swig bug report and see if that gets us Guile 2.0 support, but in
> the longer run it looks like we need to either switch back to GWrap or
> replace Guile with something that's better supported.
> 
Yes, this is a bad problem.

> As for the string problem, we may have to modify the C-side functions to
> require gstrdup'd strings that the consumer function frees. I'll have to
> have a look at how those strings are being used to suggest something more
> concrete.
> 
Ok, thanks.

Geert