Re: [Zope3-dev] The bug fixing problem
On Sep 11, 2006, at 5:47 AM, Patrick Gerken wrote: On 7/16/06, Jim Fulton <[EMAIL PROTECTED]> wrote: On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: > On 7/7/06, Julien Anguenot <[EMAIL PROTECTED]> wrote: ... > I marked the bug as bug + bugfix but nobody cares. That is much more > discouraging than what I can not do nice wiki links to in my bugreport > other bugtracker items or svn sources like it is possible in trac > itself. What is the issue number you are referring to? I don't see any bug+solution issues that seem to be from you. Perhaps you submitted 572? Or perhaps your issue was resolved. Sorry for the very late answer, but our employee put us into a tourist place with no internet access, and before I sent the link I wanted to ensure that the tests still work. This is the issue: http://www.zope.org/Collectors/Zope/1944 Hm, That is the Zope collector not the Zope 3 collector. That's why I didn't see it. Perhaps you could bring this on on the zope-dev list. But the original issue is just, that it turns one off, to see no response, of course I'm giving a bad example in responding so late. You are giving a very realistic example. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: [Zope3-dev] The bug fixing problem
On 7/16/06, Jim Fulton <[EMAIL PROTECTED]> wrote: On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: > On 7/7/06, Julien Anguenot <[EMAIL PROTECTED]> wrote: ... > I marked the bug as bug + bugfix but nobody cares. That is much more > discouraging than what I can not do nice wiki links to in my bugreport > other bugtracker items or svn sources like it is possible in trac > itself. What is the issue number you are referring to? I don't see any bug+solution issues that seem to be from you. Perhaps you submitted 572? Or perhaps your issue was resolved. Sorry for the very late answer, but our employee put us into a tourist place with no internet access, and before I sent the link I wanted to ensure that the tests still work. This is the issue: http://www.zope.org/Collectors/Zope/1944 But the original issue is just, that it turns one off, to see no response, of course I'm giving a bad example in responding so late. Best regards, Patrick ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
--On 16. Juli 2006 09:33:33 -0400 Jim Fulton <[EMAIL PROTECTED]> wrote: I'll note that *none* of the solutions include tests. Tests are often the bulk of the work. A submitter should not assume that just because a patch is provided, than someone only has to check it in. Submitter do often provide unit tests if you gripe about the missing tests. At least griping in the Zope 2 world worked out fine in the past :-) -aj pgpSNFRmFBpcW.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: On 7/7/06, Julien Anguenot <[EMAIL PROTECTED]> wrote: ... I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. What is the issue number you are referring to? I don't see any bug+solution issues that seem to be from you. Perhaps you submitted 572? Or perhaps your issue was resolved. I'll note that *none* of the solutions include tests. Tests are often the bulk of the work. A submitter should not assume that just because a patch is provided, than someone only has to check it in. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: [Zope3-dev] The bug fixing problem
On Jul 11, 2006, at 8:49 AM, Martijn Faassen wrote: Jim Fulton wrote: ... A way to mark bugs for milestones is in my opinion, for instance, a better way to handle bugs than having to mark them critical to get them picked up and considered before a Zope release happens. More modest submitters may mark something as 'bug', and their bug might not be seen.. With a milestone mechanism instead of relying on 'critical' it becomes a lot easier to defer things to a following release, with less risk of actually losing track of issues. I believe that without deferring issues, a release of a large piece of software like Zope 3 is in fact not possible, given limited resources. I've updated the collector with release targets as possible importance values. I've also reset all of the current critical items to point to the 3.3 release. If anyone wants me to add other milestones, let me know and I will. So, now, to see what has to be resolved for the 3.3 release, just select the "3.3 Release" importance. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: [Zope3-dev] The bug fixing problem
One way of adding tests would be to make a branch and add the tests there. But having a standard for branch naming (such as bug-3675) you could add the test and mention this in the tracker. Somebody else could then come in and fix the bug on the same branch. or? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Martijn Faassen wrote: The other suggestion I made elsewhere is the ability for developers to add breaking tests to the codebase (explicitly marked as such, and not normally run). +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Jim Fulton wrote: On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: ... As a non committer I would like to note that it was easy for me to search if somebody already submitted a bug I found, and submit a new patch, it was also trivial to add the for the bugfix and the test. The only thing which IS still not easy is to find a way to see that patch appear in Zope itself. I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. Well said. There are people who care. A few of us have biin working through the bugs. I wish more people were. (I'm stuck on a fairly hairy one myself.) Regardless of what tool we use, we need to be committed to not letting bug reports languish in the collector. Personally, I'd like to have a feature freeze until we've cleane dup *all* of the outstanding bugs, not just the critical ones. While I'm not against a period of time where we're committed to cleaning out bugs from the tracker, I find myself wondering whether that won't mean an indefinite feature freeze... Will that really get people more motivated to fix bugs? Better information for both developers and bug submitters and a better way to defer bugs for following releases might give us more flexibility and a better ability to select the issues we consider truly important and might increase our collective memory. The other suggestion I made elsewhere is the ability for developers to add breaking tests to the codebase (explicitly marked as such, and not normally run). This might make it easier for people who got halfway fixing a bug to let their knowledge not be lost, and might also make it easier for people to find bugs to fix (that already have tests!). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Jim Fulton wrote: [snip] Snipping further collector complaints. The bug fiing problem is *not* a tool issue. I agree it isn't primarily or just a tool issue, but we do have tool issues and there are better tools out there. Developers would be helped by a tool which encourages people to interact with it instead of scares it, and people who submit bugs would be helped by getting clearer information about the status of their bug. A way to mark bugs for milestones is in my opinion, for instance, a better way to handle bugs than having to mark them critical to get them picked up and considered before a Zope release happens. More modest submitters may mark something as 'bug', and their bug might not be seen.. With a milestone mechanism instead of relying on 'critical' it becomes a lot easier to defer things to a following release, with less risk of actually losing track of issues. I believe that without deferring issues, a release of a large piece of software like Zope 3 is in fact not possible, given limited resources. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote: ... As a non committer I would like to note that it was easy for me to search if somebody already submitted a bug I found, and submit a new patch, it was also trivial to add the for the bugfix and the test. The only thing which IS still not easy is to find a way to see that patch appear in Zope itself. I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. Well said. There are people who care. A few of us have biin working through the bugs. I wish more people were. (I'm stuck on a fairly hairy one myself.) Regardless of what tool we use, we need to be committed to not letting bug reports languish in the collector. Personally, I'd like to have a feature freeze until we've cleane dup *all* of the outstanding bugs, not just the critical ones. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: [Zope3-dev] The bug fixing problem
On 7/7/06, Julien Anguenot <[EMAIL PROTECTED]> wrote: 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. As a non committer I would like to note that it was easy for me to search if somebody already submitted a bug I found, and submit a new patch, it was also trivial to add the for the bugfix and the test. The only thing which IS still not easy is to find a way to see that patch appear in Zope itself. I marked the bug as bug + bugfix but nobody cares. That is much more discouraging than what I can not do nice wiki links to in my bugreport other bugtracker items or svn sources like it is possible in trac itself. Patrick ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
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 signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
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 was just saying that it's not hard to find out what bugs need to be fixed for the next release. 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. :( 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. Snipping further collector complaints. The bug fiing problem is *not* a tool issue. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
Re: [Zope3-dev] The bug fixing problem
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 signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Jim Fulton wrote: 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. I agree on that. Quality is why we fix the bugs in first place, isn't it? :) 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. Right. I agree on that. Especially on the idea to distribute the maintainership amongs more people so that taking over responsibility for an individual package does not become too much of a burden for the individual. This also goes along the ZF effort to communicate about the reusability of Zope 3's packages. 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. This sounds good and is very interesting for me. The DZUG has a meeting on 14th and 15th of September. We could organize a sprint around that easily. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
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 Corporationhttp://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
Re: [Zope3-dev] The bug fixing problem
Hi, Marius Gedminas wrote: I do not think that the requirements to 4. Write unit tests 5. Merge bugfixes from trunk to the release branch 6. Wait for the incredibly slow updates on the collector discourage me all that much. Right. They don't discourage me either, but there is a special case in 4) which I hit several times lately, where the unit tests need very special effort. I think that if more bug reports had a solution outlined in English, I'd be more likely to go fix them every now and them. Indeed! Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: There are bugs that do not need a test once they are fixed. All kinds of "NameError" and "AttributeError" fall into this category. The point of a test in most such cases is that there is a code path that isn't covered by tests, or it would have been caught earlier. A test that exercises the modified bit of code helps assure that future changes to the code don't introduce similar problems by providing at least one pass through the block containing the problem. How pressing the need for the test really is, is a matter for discussion, because the cost of writing the first test for an existing piece of code can be much higher than the cost of the fix. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
Christian Theune wrote at 2006-7-5 11:46 +0200: > ... >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? >We should find and announce a reasonable answer for the procedure in >this case. Although I have (so far) never fixed a bug in Zope 3 (but posted several patches for Zope 2), I can confirm this: There are bugs that do not need a test once they are fixed. All kinds of "NameError" and "AttributeError" fall into this category. Requiring to write a unit test for these or similarly trivial bugs is silly -- especially if there is not yet a testing file for the module (such that a trivial test would suffice). -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] The bug fixing problem
On Wed, Jul 05, 2006 at 11:46:52AM +0200, 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. ... > I feel like fixing a bug every now and then when I have like 30 minutes > spare time and want to do something useful. This happens to me about once a month. I get the "wanna fix a bug in 30 minutes" feeling, head over to the Zope 3 collection, and start browsing. Almost always I find no bug that I'd want to fix at the time. There are several reasons: 1. Some of the bug reports I do not understand. 2. Some of the bugs need changes in code that I'm not familiar with. 3. For some of the bugs it is unclear what ought to be done. (2) and (3) are pretty close, but (3) refers to behaviour visible from the outside, while (2) refers to implementation details. I do not think that the requirements to 4. Write unit tests 5. Merge bugfixes from trunk to the release branch 6. Wait for the incredibly slow updates on the collector discourage me all that much. I think that if more bug reports had a solution outlined in English, I'd be more likely to go fix them every now and them. Marius Gedminas -- We'll show a small example here with one user calling another. (Under international treaties describing technical papers these users must be called "Alice" and "Bob".) -- Anthony Baxter signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] The bug fixing problem
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. 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 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? We should find and announce a reasonable answer for the procedure in this case. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
