Jason Cater announced The next version of GNUe Designer will no longer support Python 2.0 or wxPython 2.2 . The new minimum requirements will be Python 2.1+ and wxPython 2.4.0+. Python 2.1 had been out for some time, but wxPython 2.4 was rather newer - however, he felt the change in requirements will benefit everyone in the long run. I will be able to spend more time adding features/fixing shortcomings in GNUe Designer rather than working around wx oddities, as has primarily been the case since the 0.4.x releases. wxPython 2.4 was already in most of the leading GNU/Linux distributions, with the notable exception of the Debian stable distribution ('woody'). However, he had done some (strictly unofficial!) Debian woody packages, backporting the wxPython packages from Debian unstable, which were available on the GNU Enterprise website.

David Sugar summarised some areas of current Bayonne development related to the upcoming 1.3 release and beyond:

• External Bayonne Integration Scripting. As well as allowing scripts more access to the Bayonne server, it can be used to output a valid html document and may be ran directly as a cgi and can also be used to generate and deliver mime attached email through sendmail. External scripting will also be invokable from the Bayonne scheduler. This will allow Bayonne's job scheduler to be used in a complete solution rather than using cron.
• Apennine returns, offering authenticated access to Bayonne services through "soap" and will support soap serverlets that can then be created to support specific bayonne applications.
• Python and Bayonne - a "pybayonne" project would start with a python plugin that allows python to integrate with bayonne much the same way the new external scripting does.
• Giza speech recognition services - Work has also been done on creating speech recognition services in Bayonne and the ability for Bayonne to route audio to a seperate server.

James Thompson (jamest) announced that 0.5.1 is out real soon now. The ui driver work alone was worth a release. He said there was pending buglist cleanup on designer - i really wanted to get input masks in there too but I have yet to start work on them so I'd say that aint going to happen. Jeff Bailey (jbailey) noticed it would be nice to fix the .deb's before 0.5.1 so it would be possible to use the realeased versions for the Debian packages. Jan Ischebeck (siesel) also noticed it would be good if Jeff could package the actual cvs instead of the 0.5.0 release. Derek Neighbors (derek) disagreed with the discussion: we made a CONSCIENCE decision to not bundle cvs several months back. We need to get 'off' using cvs if we want people to use stuff in production and we want stuff in woody. If we want to package a 'cvs' version we need to do separate cvs packages (in the form of snapshots), but i dont think its worth the time unless its automated. Jeff said he could setup automated snapshot packages, but wondered if anyone would actually use them? Jan thought this possibly would be needed short before a new release.

Later, James said he would like debs working for 0.5.1 as well - i wouldn't use snapshots. Derek agreed with him - as long as we are current on releases im happy. Jan would like to use snapshots for pre 0.5.1 versions, as I don't think that it makes sense to package 0.5.0 without any patches - IMHO its important to have debs to test BEFORE the 0.5.1 version is out, rather than to have to fix bugs for the release first and than have to fix bugs in debs afterwards. He never wanted OFFICIAL debian packages from cvs, rather than snapshots to do developing and testing Jeff explained - I'm not thinking official debs, but snapshots that I could post on people.debian.org. If I did that, i'd prefer to make them only for sid, though (and they'd never be uploaded to the main archive). Jan agreed that SID would be ok for me.

Some days later, Jan was interested in progress on GNUe packaging. Jeff said he haven't had a chance to sit down with James as of time of writing. Jan asked where he could get latest debian packaging diffs. Jeff thought he had that thing setup for apt-get source. I've been using DBS packaging, so it's not suitable to keep them in CVS. He was going to update the GNUe Debian packages to use the dbs tarball functionality - this would be easier to work with, and open up the possibility of producing automated Debian packages from CVS. At that point I could more easily integrate the packaging into GNUe's own CVS again, but he personally was not keen on this - in principle, all the fiddling in the debian/ directories was really the responsibility of the Debian maintainer, not the "upstream" developers of the underlying software. Jan felt the only advantage of having debian directories in cvs is that its easier to apply changes etc..

Further to previous discussions about using SAB-DB as a back-end database for GNUe in various threads (including ), Jason Cater (jcater) noted all this negativity around the SAP-DB license change - lots of fud (fear, uncertainty, doubt). Derek Neighbors (dneighbo) felt that SAP-DB went about it all wrong. the more i see the change and talk to SAP, the more I _like_ the change. My understanding is that they will continue to own SAP-DB and develop it. They are jsut 'sub licensing' it to MySQL AB - and MySQL AB will add some 'features/fluff' and put under a different license and try to make money on it. In doing so SAP-DB has become protective (in a good way) and made the whole shooting match GPL - instead of just the engine (so they can continue to make money sub licensing). Thtis to me is good news not bad news - my original understanding is they were selling SAP-DB to MySQL and never touching it again, but it looked now as if this was not the case. Some of the complaints were from people who objected that they had made the client libraries GPL (instead of LGPL as they used to be), but the strong copyleft of the full GNU General Public License (as opposed to the weaker Lesser GPL) would actually encourage people to release SAP-DB-based products as free software. The discussions drifted into a general discussion of the merits of the existing MySQL database system, including issues like scalability, views and sub-selects.

Chan Min Wai (dcmwai) said he was the developer of arias, a fork of the NOLA software, previously discussed in several threads, including . Dmitry Sorokin (ra3vat) noted that it was discussed at one time to use nola db schema for gnue accounting, but he was not sure what the outcome of this had been. Looking at the screenshots for aria, Dmitry felt they may be easily converted to gnue forms. Chan felt that gnue proved to be more customizable but that arias just need a web browser as a client, as the application was written in PHP with MySQL as the back-end database. Dmitry noted that, as of time of writing, gnue is mostly a set of tools - we just do not have official gnue applications like acounting. Chan was thinking maybe I can intreged gnue to arias so that when having web access can also have gnue access as well.

Some days later, Derek Neighbors (derek) said that some of the GNUe developers had snarfed the NOLA tree sometime ago - and redid their structure - and fixed a lot of the bugs - and put in private cvs under the name acclite with the intention of porting it to the GNU Enterprise Framework. More recently, he had looked at arias and considered using it as the basis for GNUe Small Business (gnue-sb), but had not gone any further with this - gnue-sb was going really well until real life hit me :( Chan asked if the changes from NOLA to acclite had included any fixes to Inventory - he was looking at this area next, and would prefer not to have to re-fix anything that the GNUe developers had already fixed. Derek said they had not really looked at Inventory - the priority had been to convert it to use PostgreSQL instead of MySQL, and then a few bugs in the accounting. This first priority had taken quite a bit of work, as NOLA took full advantedge of the non-standard features of MySQL (e.g. assigning NULL to a primary key).

Derek admitted he was not really keen on web applications, especially for Financials, and had been looking to 'clean up' NOLA as a prelude to converting it to the GNU Enterprise framework (i.e. using Forms, Reports and Navigator). Chan asked if the GNUe developers would consider contributing their patches in acclite to arias. Derek said that, if the directory structure was fixed and PostgreSQL support added to arias, he personally would gladly do all future fixes on ARIAS and would consider working directly with ARIAS on schemas - he could even envisage gnue-sb and arias as complementary projects (gnue-sb using the GNUe Tools and arias using PHP) sharing the same schema. ultimately we could have ARIAS use the web UI of the GNU Enterprise Framework - it just isnt ready yet. He explained that the concept of GNUe was a framework - so you write one "form" - and instantly (without code modifications) it will run on curses (text based ui), win32, mac, gtk2, qt, html etc - just our 'html' client isnt ready yet.

Chan said he wasn't keen on the NOLA directory structure either, but that we don't have time to clean all that creep/ - so we plan to clean up the creep on the rewrite... and For the time being, I will just stick to the old structure and fix all bug. Once a Stable release is being release... A rewrite will begain... Derek wondered if it might be easier to apply the patches from arias to acclite - and have postgres support and a clean dir structure with minial work - but im not pushing that. Chan was worried about upgrade paths for existing NOLA users, but Derek suspects the number of folks using NOLA that arent noguska's customers is so small - that backwards compatiability would be the most minimal of concerns - acclite had no schema changes from NOLA.