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:[EMAIL PROTECTED] Python
Powered!
CTO (540) 361-1714
http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
