[Zope3-dev] The bug fixing problem

[Jim Fulton]

On Jul 5, 2006, at 5:46 AM, Christian Theune wrote:

> Hi,
>
> 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.)

>
> As I was credited all the time for fixing many bugs for the next  
> release, I'd like to jump in and explain what I think makes me not  
> fix more bugs:
>
> I feel like fixing a bug every now and then when I have like 30  
> minutes spare time and want to do something useful. In my general  
> experience of customer projects 30 minutes usually are enough to  
> squash 1 or 2 (reasonably sized) bugs.
>
> I think we should encourage this pattern. I have a couple of  
> feelings how we could do that, but can't sort those out completely  
> right now. One thing that I'd very much like to see is that people  
> who have an idea or a hint for fixing a bug attach that

I don't have any problem with this pattern, however, many bugs can't  
be fixed
in 30 minutes.  We can't reasonably expect all bugs to be fixed quickly.


> 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. :)

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.

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.

Finally, I'll note that, IMO, Zope is too big.  This refers to both  
Zope 2
and Zope 3.  We have too many batteries included and they are starting
to leak acid because they aren't being properly maintained. :)  I'm
very hopeful that we can move to a more agile package-based release
system in the coming months.

I would actually love to see a distribution-oriented sprint early this
fall to look at:

1. How to better leverage eggs in managing and making distributions

2. How to improve the user experience for installing distributions,
     especially for Zope 3.

3. Get rid of zpkg. :)

4. Find a better way to manage the distribution process.
     My hope is that distributions become more about assembling
     packages, much like linux distributions.  My thought is that core
     developers would no-longer be responsible for making distributions.
    There might even be alternate distributions aimed at different
    audiences.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org