Jim Fulton wrote: > > On Jul 7, 2006, at 9:45 AM, Julien Anguenot wrote: > >> 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. >> > > I wasn't suggesting that we couldn't use a better bug tracker.
I understood your point. I just wanted to emphasis the fact that the bug tracker tool is more than critical. > I was just saying that it's not hard to find out what bugs need > to be fixed for the next release. Ok maybe for *next* release then, if we follow your pattern. But what about roadmaps ? Do you agree we can't currently do any proper project management for Zope ? >> 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. > > > No. you just go to the collector and search for accepted or > pending bugs or bugs with solutions. That's it. If we are focussed on > a release, you should further limit this to critical items. All of this > is easy to do with the existing UI. > >> 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. > > No. they use the collector. The to-do file was checked in by accident. :( really ? It's been the "bugs to be fixed" reference for a while though... (at least for 3.1 release AFAICR) > >> 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. > > No. Bugs that need to be fixed for the next release are marked critical. > As I mentioned, this can and probably should be improved. Improved using another bug tracking system ;) > Snipping further collector complaints. The bug fiing problem is > *not* a tool issue. Ok for the fact that it's not the main reason for the bug fixing issue. As I wrote, I believe the problem is that Zope3 is not used as much as Zope2 in production for customers which doesn't ease the allocation of resources within companies (Take our case at Nuxeo as an illustration of this point, for instance) 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
Description: OpenPGP digital signature
_______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com