Bugzilla

Geert Janssens janssens-geert at telenet.be
Wed Oct 5 13:36:05 EDT 2011


On woensdag 5 oktober 2011, Colin Scott 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. Colin
Indeed. Even though some bugs are considered higher priority in bugzilla, 
other bugs may be fixed first for a plethora of reasons.

Some that come to mind:
* Some of the high priority bugs are either hard to track or may require 
big/complicated changes for which the current devs have no time. Yet some low 
priority bugs could perhaps be fixed easily, or are just a minor change that 
can be done in between other (not GnuCash related) tasks.
* Certain bugs are more visible to the devs than other. When a dev hits a 
certain bug every day during his typical workflow, he's probably more inclined 
to fix that bug first.
* GnuCash is a large project. Each dev typically knows some parts of it very 
well and others hardly at all. If a critical bug is in an area that has 
currently no active developers, that bug will probably stay open because it 
would take a huge effort for another dev to figure out how it works. It's not 
impossible, but it's a matter of trade-off of available time.

I value your (user) view on these things and understand your frustration. But 
at the same time I think it's important to realize GnuCash is not a project 
backed by a big company that has support people and devs to allocate at will. 
Each developer spends his limited available free time on the project and since 
that time is limited probably prefers to work on these parts that matter most 
to him personally. Me, I try to divide my time between bugfixes in areas that 
I know and implementing features I (or my customers) need. That means indeed I 
pass on a number of bugs that are outside those areas, simply because I don't 
have enough time for them.

On the other hand, I heard your initial remark on the number of unconfirmed 
bugs and I believe it would be good if I had some more discipline there. So I 
intend to walk through those in my work areas (being mostly business features 
and GUI) in the near future and see which ones I can confirm at least. I don't 
put timings on the bugs because I don't know how much free time I'll have 
available to work on bugs and I don't know the free time of the other devs 
either.

Geert


More information about the gnucash-user mailing list