Bugzilla

[Robert Heller]

At Wed, 5 Oct 2011 18:15 +0100 (BST) gnucash at double-bars.net wrote:

> 
> 
> > Well, something you can do is at least work on trying to
> > verify/reproduce a bug
> 
> Ah.  Is this a general request for your readers to inspect and report on bugs in their spare time?  (Genuine question!)
> 
> > Personally I tend to consider crashers and data corruption/data loss
> > bugs to be extremely high priority
> 
> I'd probably not quarrel with that - especially any data corruption bugs - although IMHO some crashes, depending on circumstances, need not go to the top of the pile
> 
> > and everything else is lower priority.
> 
> The implication is that nothing else gets attention until all of the
> corruption and crash bugs are fixed.  But apparently this is not so, as
> the Team have somehow managed to produce a several new releases
> (presumably including new functionality as well as bug fixes) in the
> past 12 months, whilst leaving some quite serious bugs and design
> defects and deficiencies unattended to.  

I would suspect that the "quite serious bugs and design defects and
deficiencies unattended to" *might* be either bugs and design defects
anddeficiencies that might be either problems causes by various outside
forces (such as user error) or something else or are (more likely) not
ones that affect the developers or (see above!) not verified or
reproducable by the developers.

As a developer myself (of other software) I sometimes get bug reports
from users who experience problems not because of actual software bugs,
but due to things like people failing to read documentation or doing
various things 'wrong' on some level.  Sometimes it is a documentation
error or because someone wants to do something the software is not meant
to do.

In other cases some bugs can only be addressed by making major changes
that the developers might not want to make lightly.  In some case the
the "design defects" are only defects from a certain point of view and
may not be viewed as defects by the developers.

Getting bugs verified and determining that they in fact can be readily
reproduced is allways a good idea and is in fact something *anyone* can
do, since this is just a matter of installing GnuCash and (using a test
data file!) attempt to do whatever the original bug reporter did and
see in the same thing happens.  In some cases, this means getting in
communication with the original bug reporter and getting more detailed
information about the problem.  This could even result in determining
that there is in fact no real programming bug, but maybe a
documentation bug (the original reporter misunderstood the
documentation or something). Some of this might even clear up any
number of bugs listed in the GnuCase bugzilla database.

> Colin
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> 
>                  

-- 
Robert Heller             -- 978-544-6933 / heller at deepsoft.com
Deepwoods Software        -- http://www.deepsoft.com/
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments