[Zope3-dev] The bug fixing problem

[Julien Anguenot]

Hi there,

Jim Fulton wrote:
> On Jul 5, 2006, at 5:46 AM, Christian Theune wrote:
>> I'm sitting at EuroPython right now, and a small discussion came up,
>> trying to find out why nobody seems motivated to fix bugs came up.
>>
>> Martijn Fassen noted that the tools we use should be better (I agree
>> on that, especially making it easy to find which bugs need to be
>> urgently fixed for the next release). Obviously that isn't a pure
>> problem on it's own.
> 
> There are certainly many problems with the current bug trackers,
> which were written several years ago.  Finding out quickly which bugs
> need to be fixed for the next release isn't one of them. (Although
> discovering how to do this isn't obvious and could be trivially improved
> through configuration.)

I tried to raise the discussion last year about this topic :
http://mail.zope.org/pipermail/zope3-dev/2005-May/014588.html

... but didn't go far.

I believe the bug tracker is certainly the most important tool for a
project like Zope3.

Nowadays, to know what bugs need to big fixed I need to :

 - Consult a TODO.txt file within the trunk ....
   (like in the good old days...) And hope nobody forgot any bug.

 - Then go the issue tracker to get the description and possible comments.

It's painful but as a commiter I could do it. Now imagine someone that
would like to participate outside of the Zope community.

It means basically that we are dealing with the Zope3 *releases* using
text files... Bug trackers such as Trac, Bugzilla, Mantis or the really
best one Jira are doing that properly for you using milestone or releases.

So finding bugs that need to be fixed can be done easily but finding
bugs that need to be fixed *for* a given release is another story. Even
with critical or important issues (or whatever they are called within
the issue tracker) we might want to re-target them to aonther release /
milestone etc... to meet the release deadline. As well, it's important
to let non developers the ability to vote / comment on the issues since
they are the consumers.

*Every* serious open source projects are using one of the trackers
above. Why not Zope ?

Other problems with the Issue Tracker are:

 - Notifications sucks : a user can't be notified if he wants to (except
if he's asking Jim or granted people), no rss available etc....

 - Zope.org is really slow and buggy.

 - You want to avoid using it as much as you can ;)

Trac for instance is really well integrated with subversion an would
certainly be a sane option for the Zope development. (it's not as good
as Jira but it's free) Currently, CPS, Plone, twisted to talk about the
projects we know the best are using it with success.

I believe this is an error to underestimate the importance of the bug
tracking system for a project like Zope.

At Nuxeo, we tried in order : bugzilla, mantis, trac and now we are
switching to Jira because it really really improves the development process.

As well, dog food is interesting (meaning issue tracker) when the food
is not terrible....

[...]

>> Another thing are the rules about unit tests. Some bugs touch areas
>> that are poorly tested. When I fix a bug over there, do I have to work
>> harder to introduce the fix because I have to start introducing tests?
> 
> See Tres' answer.
> 
> I think there is a deeper issue, or set of issues.
> 
> 1. Most people don't like to fix bugs. :)

You're right on this.

> 2. We generally fix bugs when we want to make a release.
>     There is tremendous pressure to take shortcuts  like
>     downgrading bugs from critical, pushing them off to later
>     releases, or not writing missing tests.

yep that's a fact. I guees the main problem is that almost nobody is
using Zope3 for productions compared to Zope2. So bugs are not critical
for production projects which doesn't ease the allocation of resources
in the various companies...

> I think we need to be more draconian about quality.  Because
> we are late for this release, we will need to take the usual shortcuts,
> however, if we find missing tests, we should report them as non-critical
> bugs.  In addition, we should disallow any new features that would
> affect a release until all outstanding bugs, including missing tests
> have been resolved.

That's probably the best way to get bugs fixed. ;)

[...]

My 2 cents.

Cheers,

	J.

-- 
Julien Anguenot | Nuxeo R&D (Paris, France)
Open Source ECM - www.nuxeo.com
CPS Platform - http://www.cps-project.org
Mobile: +33 (0) 6 72 57 57 66

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20060707/4f6988bd/signature.bin