Gnucash 2.5.4

[John Ralls]

On Aug 6, 2013, at 6:36 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On 02-08-13 16:23, John Ralls wrote:
>> July flew by, at least for me, and it's the first weekend in August already, which means it's time for another alpha release of Gnucash 2.5.
>> 
>> I'll apply Robert's patches 26-28 today; Christian Marchi, can you get Aurimas's in today as well?
>> Anything else?
>> 
>> Slightly longer term, the release schedule [1] says 2013-10-01 for 2.6.0. Is this feasible? If so, we need to declare string freeze Really Soon and alert the translators. I've started going through the 2.5.x bugs and putting them on the 2.6.0 roadmap; everyone please review any other bugs you're working on and put ones you think appropriate on the roadmap as well. (In the unlikely event that someone doesn't know how, that means setting the "target" of the bug to 2.6.0). Any new 2.5 bugs should be evaluated for the roadmap, of course.
> I'm not sure if October 2013 is doable. Here's what I currently see:
> 
> - register 2: this is well under way but it still needs quite some tuning. And the business registers (invoice/bill/voucher) aren't converted yet. I am not actively working on this part so I can't estimate how much additional time will be needed, but we're not there yet. Worst case we could revert this and postphone until 2.8, but that would be very unfortunate.
> 
> - gconf to gsettings migration: I have a private branch for this work. It has equivalent gsettings based functions for our gconf wrapper functions and a number of gconf calls replaced with gsettings calls. The biggest work here is to convert all other gconf calls for the remaining parameters. This is mostly a fairly easy job. It just takes time to find each parameter we use, convert it and then test it. And one caveat: gsettings requires a schema definition for each parameter. In gconf this was optional and not all of our parameters had one. So for each parameter we have to verify if a schema definition exists and create one if not. Not difficult, just time consuming. Based on my current availability this could be ready by the end of September, unless someone steps in to help out.
> 
> - There are a few minor bugs related to the credit note feature (bills due reminder not working properly for example). I intend to fix these before release. I expect some of them to come with string changes though. This would clash with a string freeze "really soon" idea.
> 
> - Last on my list are a few minor bugs regarding to changes in the report system I introduces. Those may take some time, but I expect to fix them in time for 2.6 whenever it will be released.
> 
> I would like item 1 and 2 to make it into 2.6 because the old register ties us into gtk2 and gconf is holding the OS X and Windows builds back (newer versions of gconf require dbus, which IMO we don't want to introduce in these environments).
> 
> If you agree to include these, releasing 2.6 early December looks more realistic.
>> One other thing on bugs: Creating the new defaults didn't change existing reports, so when reviewing older bugs, check that the assignee is set to gnucash-foo-maint at gnome.bugs. If it isn't, click the edit button, then check "reset to default" and commit the changes along with any others you make.
> I sometimes assign bugs to myself explicitly. In that case I make sure the QA contact is set to "gnucash-foo-maint at gnome.bugs" to keep the same mail behaviour.
> 
> And if you don't want to be added to the cc list automatically when only changing default contact, remember to untick the "Add me to cc" tickbox.

Actually, OSX does ship with dbus, but I'd really like to get rid of it: Making it work in an application bundle requires some
seriously ugly hacks. I'm generally in favor of the switch to GSettings, but are you sure that it actually works on both Win32 and OSX? Given the current state of glib maintenance, I haven't any confidence that anyone has actually tested it under anything but Linux.

The problem with the old register is less that it ties us to Gtk2 than that it's getting harder to keep its obsolete, unmaintained dependencies alive as other packages progress. That's also true of GConf.

I'm fine with a December release.That would put the string freeze on the October release, 2.5.6.

Regards,
John Ralls