Re: Stabilizing 2.4.0

[Phil Longstaff]

On Sun, 2010-03-07 at 22:31 +0100, Christian Stimming wrote:
> Am Sonntag, 7. März 2010 schrieb John Ralls:
> > > http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.4.0
> > 
> > I've added a couple of OSX status items for things I know about.
> > 
> > I also fixed up the releases table to reflect the actual releases so far,
> >  and assigned some dates for two more unstable releases (for string freeze
> >  and release candidate) and the stable ship date.
> 
> I think by the end of march another unstable release would be good. I'm not 
> sure whether this would also be string freeze or not, though...

I added a March 15 release, and maybe we want a March 31 release as
well, before April 15 string freeze.  There's a lot being done on the
code base, which tends to make me want to release more often.

Phil

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Bill Nottingham]

Derek Atkins (warl...@mit.edu) said: 
> > - QSF export (or was this active in 2.2.9 already?)
> 
> This should be off unless the crashing issues have been fixed.  And even
> if those issues HAVE been fixed we might want to disable it because we
> have no QSF import.

Exporting of account tree to QSF was enabled in 2.2.9, but crashes
due to a GTK bug. 2.3.x doesn't hit the GTK bug, so it doesn't crash.

Bill
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Derek Atkins]

Christian Stimming  writes:

>> Should we declare "feature freeze" at this point, and perhaps make a 2.4
>>  branch?
>
> A 2.4 branch should not yet be made, but rather closely around the
> actual 2.4.0 release date. Even though there is also experimental work
> going on, there is still a lot of bugfixing everywhere. If we branched
> now, we would have a heck of a lot of merging / cherry-picking back
> and forth between branches. I definitely prefer a 2.4 branch only very
> close before 2.4.0 date - something like 2-3 weeks before that date.

Seconded -- let's not branch 2.4 unless after 2.4.0 is released.  If we
want we can make the 2.4.0 tag be the 'base' of the 2.4.0 branch too.

For 2.2 we didn't actually create the 2.2 branch until about 2.2.2.

> Regards,
>
> Christian

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Derek Atkins]

Just my $0.02

Christian Stimming  writes:

> There are additional new features, which might still have problems, so we can 
> decide whether to disable them for 2.4 or test and fix them:
> - eguile reports

This should be in 2.4.

> - CSV importer (or was this active in 2.2.9 already?)

This was not in 2.2.9.  It can remain off unless it's fixed.

> - QSF export (or was this active in 2.2.9 already?)

This should be off unless the crashing issues have been fixed.  And even
if those issues HAVE been fixed we might want to disable it because we
have no QSF import.

> - Check printing features (but I think those work without problems)

This should be safe in 2.4.

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Jeff Kletsky]

For me, at least, not having eguile reports and a CSS-compatible 
renderer are show-stoppers. I've seen that the vast majority of time in 
reporting is due to the current HTML-render. 20-30 seconds to render a 
budget report just isn't acceptable for us. Between that and that it 
strips out CSS so you can't even create a decent report to render 
externally, these, for me are beyond critical.


I'm working on patching up the budget code (which is presently blind to 
the UI sign-reversal selections) and would like to try to get them in, 
but I don't know how long it will take to resolve the Scheme/C issues 
related to variables and initialization (for example, the patch in 
 
doesn't look to be localizable), even if the problem with kvp not being 
compatible across different locales (the key generally changes when your 
locale does). While I would like to get this in so that the change in 
budgets is at a major release, I don't want to hold things up.


Jeff


Christian Stimming wrote:

Am Samstag, 6. März 2010 schrieb John Ralls:
  

On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:


Do we want to release a stable 2.4.0?  What do we need to finish to do
that.  There are lots of things happening in trunk, all of which will be
useful at some point, but many of which are destabilizing things.
  

My feeling from the users list says they want the dbi backend and the new
 reporting made possible by WebKit, and that they'd like it soon. Maybe we
 should ask them what they want.



That's my understanding as well.

However, dbi already comes with several variants: sqlite3 file, mysql 
bindings, postgresql bindings. Which one of those should work? All three?


So we need to make up lists of features new in 2.4 which need to be verified 
to work correctly:

- webkit reporting
- dbi backend with sqlite3 file
- dbi backend with mysql bindings
- dbi backend with postgresql bindings

There are additional new features, which might still have problems, so we can 
decide whether to disable them for 2.4 or test and fix them:

- eguile reports
- CSV importer (or was this active in 2.2.9 already?)
- QSF export (or was this active in 2.2.9 already?)
- Check printing features (but I think those work without problems)

(As you might have guessed, I need none of those features mentioned above. So 
I neither test them nor care about whether they are included in 2.4.0. But 
that's just my personal motivation here.)


Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
  

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Christian Stimming]

Am Sonntag, 7. März 2010 schrieb John Ralls:
> > http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.4.0
> 
> I've added a couple of OSX status items for things I know about.
> 
> I also fixed up the releases table to reflect the actual releases so far,
>  and assigned some dates for two more unstable releases (for string freeze
>  and release candidate) and the stable ship date.

I think by the end of march another unstable release would be good. I'm not 
sure whether this would also be string freeze or not, though...

>  They're not terribly
>  aggressive (I set April 15 for the string freeze release that was
>  mentioned in January, with the RC/code freeze and initial ship following
>  at 1 month intervals), but there's a fair amount of bug-fixing to do and
>  Phil still hasn't worked out WebKit for MSWin.

Sounds good to me.

> Should we declare "feature freeze" at this point, and perhaps make a 2.4
>  branch?

A 2.4 branch should not yet be made, but rather closely around the actual 
2.4.0 release date. Even though there is also experimental work going on, 
there is still a lot of bugfixing everywhere. If we branched now, we would 
have a heck of a lot of merging / cherry-picking back and forth between 
branches. I definitely prefer a 2.4 branch only very close before 2.4.0 date - 
something like 2-3 weeks before that date.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[John Ralls]

On Mar 7, 2010, at 1:34 AM, Christian Stimming wrote:

> 
> I've started at list at 
> http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.4.0
> and I've inserted items and statuses all that I know of. Please add any 
> information which you encounter.
> 

I've added a couple of OSX status items for things I know about.

I also fixed up the releases table to reflect the actual releases so far, and 
assigned some dates for two more unstable releases (for string freeze and 
release candidate) and the stable ship date. They're not terribly aggressive (I 
set April 15 for the string freeze release that was mentioned in January, with 
the RC/code freeze and initial ship following at 1 month intervals), but 
there's a fair amount of bug-fixing to do and Phil still hasn't worked out 
WebKit for MSWin. 

Should we declare "feature freeze" at this point, and perhaps make a 2.4 branch?

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Phil Longstaff]

On Sat, 2010-03-06 at 11:41 +0100, Christian Stimming wrote:
> Am Samstag, 6. März 2010 schrieb John Ralls:
> > On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:
> > > Do we want to release a stable 2.4.0?  What do we need to finish to do
> > > that.  There are lots of things happening in trunk, all of which will be
> > > useful at some point, but many of which are destabilizing things.
> > 
> > My feeling from the users list says they want the dbi backend and the new
> >  reporting made possible by WebKit, and that they'd like it soon. Maybe we
> >  should ask them what they want.
> 
> That's my understanding as well.
> 
> However, dbi already comes with several variants: sqlite3 file, mysql 
> bindings, postgresql bindings. Which one of those should work? All three?
> 
> So we need to make up lists of features new in 2.4 which need to be verified 
> to work correctly:
> - webkit reporting
> - dbi backend with sqlite3 file
> - dbi backend with mysql bindings
> - dbi backend with postgresql bindings
> 
> There are additional new features, which might still have problems, so we can 
> decide whether to disable them for 2.4 or test and fix them:
> - eguile reports
> - CSV importer (or was this active in 2.2.9 already?)
> - QSF export (or was this active in 2.2.9 already?)
> - Check printing features (but I think those work without problems)
> 
> (As you might have guessed, I need none of those features mentioned above. So 
> I neither test them nor care about whether they are included in 2.4.0. But 
> that's just my personal motivation here.)

CSV is new in 2.4
QSF export was in 2.2.9, but never used it, so I don't know how well it
worked.

Phil

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Christian Stimming]

Am Sonntag, 7. März 2010 schrieb Mike Alexander:
> On Mar 6, 2010, at 11:41 PM, Christian Stimming wrote:
> > Am Samstag, 6. März 2010 schrieb John Ralls:
> >> On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:
> >>> Do we want to release a stable 2.4.0?  What do we need to finish
> >>> to do
> >>> that.  There are lots of things happening in trunk, all of which
> >>> will be
> >>> useful at some point, but many of which are destabilizing things.
> >>
> >> My feeling from the users list says they want the dbi backend and
> >> the new
> >> reporting made possible by WebKit, and that they'd like it soon.
> >> Maybe we
> >> should ask them what they want.
> 
> The trading account changes are another new feature in trunk.  I think
> they are working ok, but they need to be documented.  The minimal
> documentation could be pretty simple, perhaps with a reference to
> Peter Selinger's web pages for background information.

I've started at list at 
http://wiki.gnucash.org/wiki/Release_Schedule#Feature_Checklist_for_2.4.0
and I've inserted items and statuses all that I know of. Please add any 
information which you encounter.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Mike Alexander]

On Mar 6, 2010, at 11:41 PM, Christian Stimming wrote:


Am Samstag, 6. März 2010 schrieb John Ralls:

On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:
Do we want to release a stable 2.4.0?  What do we need to finish  
to do
that.  There are lots of things happening in trunk, all of which  
will be

useful at some point, but many of which are destabilizing things.


My feeling from the users list says they want the dbi backend and  
the new
reporting made possible by WebKit, and that they'd like it soon.  
Maybe we

should ask them what they want.


That's my understanding as well.

However, dbi already comes with several variants: sqlite3 file, mysql
bindings, postgresql bindings. Which one of those should work? All  
three?


So we need to make up lists of features new in 2.4 which need to be  
verified

to work correctly:
- webkit reporting
- dbi backend with sqlite3 file
- dbi backend with mysql bindings
- dbi backend with postgresql bindings

There are additional new features, which might still have problems,  
so we can

decide whether to disable them for 2.4 or test and fix them:
- eguile reports
- CSV importer (or was this active in 2.2.9 already?)
- QSF export (or was this active in 2.2.9 already?)
- Check printing features (but I think those work without problems)


The trading account changes are another new feature in trunk.  I think  
they are working ok, but they need to be documented.  The minimal  
documentation could be pretty simple, perhaps with a reference to  
Peter Selinger's web pages for background information.


 Mike



smime.p7s
Description: S/MIME cryptographic signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0

[Christian Stimming]

Am Samstag, 6. März 2010 schrieb John Ralls:
> On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:
> > Do we want to release a stable 2.4.0?  What do we need to finish to do
> > that.  There are lots of things happening in trunk, all of which will be
> > useful at some point, but many of which are destabilizing things.
> 
> My feeling from the users list says they want the dbi backend and the new
>  reporting made possible by WebKit, and that they'd like it soon. Maybe we
>  should ask them what they want.

That's my understanding as well.

However, dbi already comes with several variants: sqlite3 file, mysql 
bindings, postgresql bindings. Which one of those should work? All three?

So we need to make up lists of features new in 2.4 which need to be verified 
to work correctly:
- webkit reporting
- dbi backend with sqlite3 file
- dbi backend with mysql bindings
- dbi backend with postgresql bindings

There are additional new features, which might still have problems, so we can 
decide whether to disable them for 2.4 or test and fix them:
- eguile reports
- CSV importer (or was this active in 2.2.9 already?)
- QSF export (or was this active in 2.2.9 already?)
- Check printing features (but I think those work without problems)

(As you might have guessed, I need none of those features mentioned above. So 
I neither test them nor care about whether they are included in 2.4.0. But 
that's just my personal motivation here.)

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0 (was Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

[Donald Allen]

On Fri, Mar 5, 2010 at 7:04 PM, John Ralls  wrote:

>
> On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:
>
> > Do we want to release a stable 2.4.0?  What do we need to finish to do
> > that.  There are lots of things happening in trunk, all of which will be
> > useful at some point, but many of which are destabilizing things.
>
> My feeling from the users list says they want the dbi backend and the new
> reporting made possible by WebKit, and that they'd like it soon. Maybe we
> should ask them what they want.
>

In addition to the new features, there are also bug fixes in the trunk
(e.g., the incorrect mortgage amortization calculation in scheduled loan
payments in 2.2.9; Derek sent a message to the users list saying  that he
thought that this problem had been fixed) that will be of value to the user
community.

/Don

>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Stabilizing 2.4.0 (was Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

[John Ralls]

On Mar 5, 2010, at 2:59 PM, Phil Longstaff wrote:

> Do we want to release a stable 2.4.0?  What do we need to finish to do
> that.  There are lots of things happening in trunk, all of which will be
> useful at some point, but many of which are destabilizing things.

My feeling from the users list says they want the dbi backend and the new 
reporting made possible by WebKit, and that they'd like it soon. Maybe we 
should ask them what they want.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Stabilizing 2.4.0 (was Re: Announcing a new sub-project in gnucash: GUI in C++, Qt, CMake.)

[Phil Longstaff]

On Fri, 2010-03-05 at 22:14 +0100, Christian Stimming wrote:
> Am Freitag, 5. März 2010 schrieb Phil Longstaff:
> > > To give this a try, have qt4 (>=4.5.0) and cmake (>= 2.6.0) installed
> > > and:
> > >
> > >   mkdir build-cutecash
> > >   cd build-cutecash
> > >   cmake ..
> > >   make
> > >   ./src/gnc/cutecash
> > 
> > It doesn't seem able to read any of my XML files.  Oh well.
> 
> Could you try again after r18841? This could very well be due to the business 
> data types missing yesterday, but I've added them today.
> 

Yes, that fixed it.

> > I would also like to suggest that work on this take a back seat to
> > getting 2.4 out the door.  Boring, yes, but there are lots of bugs in
> > bugzilla.  Can we go through and identify which ones we would like fixed
> > by 2.4?
> 
> Sure. However, I think the actual problem looks as follows: In order to 
> finish 
> a 2.4.0 release in finite time, we would finally have to look through those 
> features which are again and again buggy, then disable those, and call the 
> rest (which is relatively non-buggy) the next stable series. I think 
> everything else is prone to cause delay after delay again, without much fun 
> for the developers. However, decisions about which features better be 
> disabled 
> for a stable series are never easy to do. The infamous CSV importer comes to 
> mind... Nevertheless, I will agree with and support everyone who concentrates 
> on finishing a 2.4.0 release in near future. Thanks for reminding.

Do we want to release a stable 2.4.0?  What do we need to finish to do
that.  There are lots of things happening in trunk, all of which will be
useful at some point, but many of which are destabilizing things.  I am
not immune - by adding gobject properties to some of the engine objects
and converting the sql backend to use them, I broke some things.  Note
that one reason I am doing this is to make a more general CSV importer
which can handle importing any type of object much easier to implement.
Geert is doing good work factoring out URI routines, but by moving them
around, my win32 build isn't working.  My win32 build is using the mingw
gcc 4.4.0 compiler so that I can try a webkit 1.1.22 build (built with
4.4.3) that may fix the "can't load an logo into an invoice" problem.

If it were just me and my own personal use, I'd say all of the new stuff
is great.  I can build trunk whenever I want so can wait for the dust to
settle.  For my personal use, I like the cutecash effort.  One thing I'd
like to see is a dashboard idea (page of small graphs/tables which
highlight important info) which seems to fit into cutecash (and would
probably be easier to implement).

Since I was the one who originally made the push for 2.3.X/2.4.0, I feel
some responsibility to get 2.4.0 out the door.  I'm worried that we're
fragmented and making it harder on ourselves.

Do we just put out a new 2.3.X once a month and never come to a stable
version?  Works for me for my personal stuff, but what do other people
want?

Phil

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel