Re: [GNC-dev] What about outdated open bugs in Gnucash Bugzilla?

[John Ralls]

Colin,

That's a worthwhile idea that could be easily applied to all bugs over n years 
old. One could start with n around 10, perhaps meaning everything against 
versions before 2.4.0.  Care to spend some quality time in Bugzilla?

Regards,
John Ralls

> On Oct 27, 2019, at 3:14 PM, Colin Law  wrote:
> 
> Possibly an alternative, used in Ubuntu for example, is when a version
> goes out of support that any bugs against that version have a comment
> added saying the version is out of support, saying that if the bug is
> relevant to a later version then please to post a comment, and marking
> the bug as needing info, so it will expire after a time if there is no
> input,
> 
> Colin
> 
> On Sun, 27 Oct 2019 at 21:46, David Cousens  wrote:
>> 
>> John,
>> 
>> Is there perhaps a need to place maintenance limits on GnuCash release
>> versions,  i.e. at a specified time after release they become unsupported,
>> as is bugs and all. This is more than likely what actually happens in
>> practice given limited skilled developer time. As bug reports are often tied
>> to a specific version, bugs could then be removed from bugzilla when the
>> version they apply to becomes unsupported.  Most bugs are not show stoppers
>> and those that are or are particularly inconvenient are usually fixed fairly
>> quickly after release.
>> 
>> Enhancement requests could possibly have a longer lifetime but perhaps there
>> is a need for expiry on those as well. E.g. if they didn't make it into the
>> next major release and you really need that feature you raise the issue
>> again (or work on it yourself).
>> 
>> David Cousens
>> 
>> 
>> 
>> -
>> David Cousens
>> --
>> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
>> ___
>> 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

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

Re: [GNC-dev] What about outdated open bugs in Gnucash Bugzilla?

[John Ralls]

> On Oct 27, 2019, at 2:45 PM, David Cousens  wrote:
> 
> John,
> 
> Is there perhaps a need to place maintenance limits on GnuCash release
> versions,  i.e. at a specified time after release they become unsupported,
> as is bugs and all. This is more than likely what actually happens in
> practice given limited skilled developer time. As bug reports are often tied
> to a specific version, bugs could then be removed from bugzilla when the
> version they apply to becomes unsupported.  Most bugs are not show stoppers
> and those that are or are particularly inconvenient are usually fixed fairly
> quickly after release.
> 
> Enhancement requests could possibly have a longer lifetime but perhaps there
> is a need for expiry on those as well. E.g. if they didn't make it into the
> next major release and you really need that feature you raise the issue
> again (or work on it yourself).

David,

We don't support old versions. If you find a bug in e.g. 2.6.21 we'll tell you 
to try 3.7 to see if it's still valid. That's not the same as you reported a 
bug 2 years ago against 2.6.18 (the current version then) and it hasn't been 
fixed. 

Bug reports are tied to a specific version because that's the version the 
reporter was running when they discovered the bug, not because there's a huge 
difference in the code from one version to the next.

There's plenty of code in GnuCash that's more than 10 years old, so just 
because someone reported a bug 10 years ago doesn't make it invalid.

Regards,
John Ralls

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

Re: [GNC-dev] What about outdated open bugs in Gnucash Bugzilla?

[Colin Law]

Possibly an alternative, used in Ubuntu for example, is when a version
goes out of support that any bugs against that version have a comment
added saying the version is out of support, saying that if the bug is
relevant to a later version then please to post a comment, and marking
the bug as needing info, so it will expire after a time if there is no
input,

Colin

On Sun, 27 Oct 2019 at 21:46, David Cousens  wrote:
>
> John,
>
> Is there perhaps a need to place maintenance limits on GnuCash release
> versions,  i.e. at a specified time after release they become unsupported,
> as is bugs and all. This is more than likely what actually happens in
> practice given limited skilled developer time. As bug reports are often tied
> to a specific version, bugs could then be removed from bugzilla when the
> version they apply to becomes unsupported.  Most bugs are not show stoppers
> and those that are or are particularly inconvenient are usually fixed fairly
> quickly after release.
>
> Enhancement requests could possibly have a longer lifetime but perhaps there
> is a need for expiry on those as well. E.g. if they didn't make it into the
> next major release and you really need that feature you raise the issue
> again (or work on it yourself).
>
> David Cousens
>
>
>
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> 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: [GNC-dev] What about outdated open bugs in Gnucash Bugzilla?

[David Cousens]

John,

Is there perhaps a need to place maintenance limits on GnuCash release
versions,  i.e. at a specified time after release they become unsupported,
as is bugs and all. This is more than likely what actually happens in
practice given limited skilled developer time. As bug reports are often tied
to a specific version, bugs could then be removed from bugzilla when the
version they apply to becomes unsupported.  Most bugs are not show stoppers
and those that are or are particularly inconvenient are usually fixed fairly
quickly after release.

Enhancement requests could possibly have a longer lifetime but perhaps there
is a need for expiry on those as well. E.g. if they didn't make it into the
next major release and you really need that feature you raise the issue
again (or work on it yourself).

David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] What about outdated open bugs in Gnucash Bugzilla?

[Christian Gruber]

Am 27.10.19 um 03:40 schrieb John Ralls:



On Oct 26, 2019, at 2:34 PM, Christian Gruber  
wrote:

Hi, I'm currently looking through the (quite long) buglist on Gnucash Bugzilla 
 to see, where I can provide help. Unfortunatelly 
I'm a little bit frustrated, because of many entries, which are still open (STATUS != 
RESOLVED), but haven't changed for years.

Which of them are still relevant? When is a bug outdated? Are some of them 
maybe already resolved, but haven't been closed? Who actually closes a bug, the 
author or the Gnucash maintainers? Are there any plans to close outdated bugs?

I had a look on Bugzilla Administration 
 page, but this didn't 
answer my questions.


Christian,

The overall problem is too many bugs, not enough developer time to go through 
them, especially old ones. Yes, it's entirely possible that many of them have 
been subsequently fixed by someone working on something else and that someone 
didn't think to go looking for related bugs. Unfortunately it's equally likely 
that some of those old bugs are too hard to fix or even to find the cause, or 
that no developer ever even got interested in looking into them.

Which ones are still relevant is hard to determine: GnuCash is complex and there have 
been lots of bugs over the years that were revealed because of a corner case in someone's 
accounts, so just because a developer or tester can't reproduce a bug doesn't mean that 
it's invalid. I suppose one could declare a bug obsolete if the module that would have 
caused it is easily identifiable and that code has been substantially rewritten since, 
but determining that isn't necessarily easy. The only policy we have is that if a bug is 
marked "NEEDSINFO" and none has been provided after 3 Months it can be resolved 
as INCOMPLETE, usually with a note telling the reporter to reopen it if they ever get 
around to caring about it again.

It's nice but rare when the reporter closes a bug, so it usually falls to a 
developer.

Note that of the 1364 open GnuCash bugs, 489 are enhancement requests.

Non-enhancement bugs 2001-01-01 to 2010-12-31:  155
  2011-01-01 to 2015-12-31:  296
  2016-01-01 to 2016-12-31:   48
  2017-01-01 to 2017-12-31:   77
  2018-01-01 to 2018-12-31:  117
  2019-01-01 to Now: 210

As an illustration of how old bugs can still be relevant, 
https://bugs.gnucash.org/show_bug.cgi?id=88517 is the oldest open bug (from 
July 2002). It's about copying and pasting transactions, was last commented on 
in 2017, and I think
is still valid.

Regards,
John Ralls

Ok, I suspected something like that. I'll do my best to provide 
meaningful help.

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

Re: [GNC-dev] Gnucash built from git doesn't start

[John Ralls]

> On Oct 27, 2019, at 3:19 AM, Lothar Paltins  wrote:
> 
> Am 25.10.19 um 21:27 schrieb Geert Janssens:
>> Gnucash historically was using the autotools build system. As far as I know
>> that system did put the config files in /opt/gnucash/etc/gnucash and not in /
>> etc/opt/gnucash(/gnucash)
> 
> Yes, if you run "configure --prefix=/opt/gnucash". There's no automagic 
> splitting of the subdirectories depending on the path. But you could easily 
> split the installation paths if you want to follow the FHS by adding 
> "--sysconfdir=/etc/opt/gnucash --localstatedir=/var/opt/gnucash" and maybe 
> other options.
> 
>> Although the gnucash project since has migrated to exclusively use cmake, it
>> may very well be it still expects the files to be in 
>> /opt/gnucash/etc/gnucash.
>> Does it work if you copy the files in that subdirectory ?
> 
> No, it doesn't.
> 
>> Not that it matters that much, we should eventually fix it to work with the
>> paths as prescribed in the fhs.
> 
> I've seen, that the FHS splitting isn't done by cmake itself, it's done 
> because gnucash includes the GNUInstallDirs module. But as far as I see, the 
> directories can be overwritten by the user by setting the appropriate 
> variables. Therefore gnucash shouldn't assume fixed paths, instead it should 
> use the actual installation paths chosen by the user and by cmake.

Yes, the GNUInstallDirs module is needed to get the build to work correctly for 
the Linux distros.

As it turns out Geert thought that he'd fixed this last year, see 
https://bugs.gnucash.org/show_bug.cgi?id=794916. Note the work-around in that 
bug report to disable binreloc by passing -DENABLE_BINRELOC=OFF to cmake. Note 
also that the reporter on that bug thought that writing the environment file to 
/etc/opt was undesirable.

Regards,
John Ralls

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

[GNC-dev] Fwd: gnucash maint: Multiple changes pushed

[Christopher Lam]

 * [new-owner-report] combined job/owner reports

In addition to today's earlier new-aging-report, the experimental submenu
will also have new-owner-reports i.e. customer/vendor/employee reports.
These are intended to replace old reports. Rewritten, easier to maintain.

Of note:
* will query customers/vendors/employees from all AP/AR accounts instead of
one, therefore the account option is removed
* will optionally show invoice->payments and payment->invoice links... also
supports unattached payments and invoices (i.e. prepayments and unpaid
invoices)
* the aging-table shares code with the aging-report, so, should show
identical aging details
* some assumptions were made re: correctness of book... damaged(*) books
may show a different owner report

Bugs etc still welcome.
(*) eg. whereby payments were made manually, and assigned to a customer
with a different currency
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Gnucash built from git doesn't start

[Lothar Paltins]

Am 25.10.19 um 21:27 schrieb Geert Janssens:

Gnucash historically was using the autotools build system. As far as I know
that system did put the config files in /opt/gnucash/etc/gnucash and not in /
etc/opt/gnucash(/gnucash)


Yes, if you run "configure --prefix=/opt/gnucash". There's no automagic 
splitting of the subdirectories depending on the path. But you could 
easily split the installation paths if you want to follow the FHS by 
adding "--sysconfdir=/etc/opt/gnucash --localstatedir=/var/opt/gnucash" 
and maybe other options.



Although the gnucash project since has migrated to exclusively use cmake, it
may very well be it still expects the files to be in /opt/gnucash/etc/gnucash.

Does it work if you copy the files in that subdirectory ?


No, it doesn't.


Not that it matters that much, we should eventually fix it to work with the
paths as prescribed in the fhs.


I've seen, that the FHS splitting isn't done by cmake itself, it's done 
because gnucash includes the GNUInstallDirs module. But as far as I see, 
the directories can be overwritten by the user by setting the 
appropriate variables. Therefore gnucash shouldn't assume fixed paths, 
instead it should use the actual installation paths chosen by the user 
and by cmake.


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

[GNC-dev] Fwd: gnucash maint: [new-aging] new receivable/payable aging reports

[Christopher Lam]

The refactored payable/receivable aging reports have been merged into maint.

Of note:
1. all AP/AR accounts will be shown, each in their own currency. Every
AP/AR account will get its own subtotal.
2. no more 'bad-url' errors which were caused by prepayments which were not
assigned to any invoices. These prepayments are now shown attached to the
customer/vendor, in its own 'Prepayments' column, and added to total.
3. owner address display is disabled. I am not sure of the utility anymore;
we can add again if there is demand.
4. fewer options altogether.

The intention is to replace the old reports, and I am unable to
exhaustively test everything, the new reports will be in experimental
submenu, eventually to replace the old ones.

C
-- Forwarded message -
Date: Sun, 27 Oct 2019 at 07:03
Subject: gnucash maint: [new-aging] new receivable/payable aging reports
To: 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel