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] AssertionError in ZEO cache
[EMAIL PROTECTED] wrote: Almost surely, the code should be cur_tid = tid rather than cur_tid tid. But there is nobody that is sure about it. Well, as I've asked before, what needs to happen for someone to _become_ sure about it? (or at least change it and see what happens? ;-) ) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-Users] Re: [Zope3-dev] AssertionError in ZEO cache
[Dieter M] Almost surely, the code should be cur_tid = tid rather than cur_tid tid. But there is nobody that is sure about it. [Chris W] Well, as I've asked before, what needs to happen for someone to _become_ sure about it? Same answer as before: someone who understands the intended invariants during cache verification needs to stare at the mutually inconsistent code and comments, and figure out was intended. (or at least change it and see what happens? ;-) ) You could do that immediately :-) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] running tests from src as opposed to an instance
Hi All, Is there any more graceful way to run the zope.i18n tests from the Zope core than the following from an instance: bin\tests --path=/../lib/python -s zope.i18n cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: language availablity
Hi. Chris Withers wrote: Been looking more into getting lists of available languages for a domain out of Zope 3. Just curious, do you use only the zope domain or some other domains as well? Philipp pointed me to zope.i18n.interfaces.ILanguageAvailability, which appears to be a tiny interface that's not used anywhere. It's just an interface for which you can write your own implementation. What I'd like to do as give ITranslationDomain a getAvailableLanguages() method and get rid of ILanguageAvailability. Would anyone have any problems with this? Is there a procedure for deprecating interfaces and adding methods to existing interfaces? Personally I think you are mixing responsibilities here. Available languages might have something to do with registered translation domains in your case, but that's not an assumption that holds in general. For instance if I have quite a lot of different domains for various products which one would be the master domain that defines if a language is available? Or you might want to have some criteria that only lists translations which are complete and not list those which are just registered but have no real translations available... What I would do in your case is to write a small global utility that implements ILanguageAvailability and returns the list of registered languages for the domain you had in mind. If you should ever need to filter the list according to some criteria this utility would be the right place to do it. Right, regardless of the above, I'd like zope.i18n.translationdomain.TranslationDomain to grow a getAvailableLanguages method. Is anyone working on this? If you follow my suggestion you could use the getCatalogsInfo method implemented for translationdomains, no need to add this to the official interface. I would rather try to keep the interface small and a basic domain should know how to translate text, not anything more. Just my humble opinion, Hanno ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: language availablity
Hanno Schlichting wrote: Chris Withers wrote: Been looking more into getting lists of available languages for a domain out of Zope 3. Just curious, do you use only the zope domain or some other domains as well? Other domains as well. In fact, the only domain I care about is one specific to the project ;-) Philipp pointed me to zope.i18n.interfaces.ILanguageAvailability, which appears to be a tiny interface that's not used anywhere. It's just an interface for which you can write your own implementation. Are there any existing implementations? Personally I think you are mixing responsibilities here. Having read your comments, I absolutely agree... Available languages might have something to do with registered translation domains in your case, but that's not an assumption that holds in general. Completely agree. OK, modified proposal: TranslationDomain should still implement ILanguageAvailability and zope.i18n.zcml.registerTranslations should register domains for that interface as well as ITranslationDomain, but I agree that you may want to register another utility, probably with no name, that gives you the overall translation domain. Does that sounds like a plan? What I would do in your case is to write a small global utility that implements ILanguageAvailability and returns the list of registered languages for the domain you had in mind. If you should ever need to filter the list according to some criteria this utility would be the right place to do it. Yes, this would be done in the little utility, global or local, that is registered for ILanguageAvailability without a domain... If you follow my suggestion you could use the getCatalogsInfo method implemented for translationdomains, no need to add this to the official interface. I would rather try to keep the interface small and a basic domain should know how to translate text, not anything more. Well, I don't think getCatalogsInfo is a very useful method, since it's effectively just a nice name for reaching into the guts of the translation domain. In any case, I have a need now for several things, so I'm working on a package called simplistix.translations that implements ITranslationDomain and the clarified ILanguageAvailability and runs off an i18n directory full of .po files just like PTS did. It'll also have an option to turn on a special message catalog that spits out something like the .missing files you used to be able to get out of PTS. If anyone's interested in this, please contact me and I'll release it when I get a chance :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The bug fixing problem
[EMAIL PROTECTED] wrote: 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). I disagree. How would you make sure that your fix for even a trivial NameError actually works? Perhaps you introduced another typo in the bugfix? Or perhaps another problem pops up in the same codepath. Clearly, since the NameError didn't occur in any other tests, the codepath hasn't been tested yet, so it should be no matter what. There's another aspect to tests for bugs: reproduceability. Especially when fixing bugs I tend to write tests first in order to be absolutely sure that I can reproduce the problem in an automated manner. Then fixing the bug is easy: Just make the test pass... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: running tests from src as opposed to an instance
Chris Withers wrote: Hi All, Is there any more graceful way to run the zope.i18n tests from the Zope core than the following from an instance: bin\tests --path=/../lib/python -s zope.i18n $ svn co .../trunk Zope3 $ cd Zope3 $ make $ python test.py -s zope.i18n Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
Hi there, I see a few packages lurking in svn.zope.org that I can't make much sense of: * For example, what is zope.generic? I can't find a README.txt anywhere in the top-level directories. What I *can* see is that it seems to be another big bag for subpackages like zope.app. I thought we were getting rid of those? I'm also wondering why it carries the 'zope' top-level namespaces. Judging from the checkins, it seems to be a Dominik + Roger project. Last but not least there's the name generic that I can't make much sense of... * For example, what does the 'z3c' namespace package stand for? Who's behind this stuff? And why does it sometimes use 'sandbox' or 'Sandbox' instead of or in parallel of 'trunk' for its main development branch? * For example, is ldapauth still maintained? Is it bitrotting? Can it go away? So, there you have typical cases of three problems I currently see with stuff in svn.zope.org: * Uncontrolled package proliferation w/o consistent naming * Inconsistent use of subversion conventions * Undocumented packages (no package metadata available) Basically, what I'm really asking is: - Do other people also think it'd be a good idea to come up with some repository guidelines? Stephan had a proposal about specifying package metadata and code maturity/quality, I think it's worth working towards easily accessible info like that. If others agree, then let's get started. - Should this be part of the Zope Foundation development process (which again seems to be worked out by the Zope Management Organization)? If so, I'll hereby volunteer to join such a committee and contribute my ideas (especially on package organization in the repository and the associated development process). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: language availablity
Chris Withers wrote: Hi All, Been looking more into getting lists of available languages for a domain out of Zope 3. Philipp pointed me to zope.i18n.interfaces.ILanguageAvailability, which appears to be a tiny interface that's not used anywhere. Not within in Zope 3 at least... What I'd like to do as give ITranslationDomain a getAvailableLanguages() method and get rid of ILanguageAvailability. As I said on IRC, enhancing ITranslationDomain would change the contract of this interface. Third party implementations of ITranslationDomain would no longer comply with the old contract. It'd therefore be better to come up with a new interface that combines ITranslationDomain and ILanguageAvailability. zope.i18n.translationdomain.TranslationDomain could then easily implement this interface and also be registered for this interface... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: language availablity
Chris Withers wrote: TranslationDomain should still implement ILanguageAvailability and zope.i18n.zcml.registerTranslations should register domains for that interface as well as ITranslationDomain, I'd prefer to create an interface extending ITranslationDomain and ILanguageAvailability, making TranslationDomain implement that and have it its instances also registered for that as utility. but I agree that you may want to register another utility, probably with no name, that gives you the overall translation domain. Overall translation domain?!? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
On 7/6/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: - Do other people also think it'd be a good idea to come up with some repository guidelines? Stephan had a proposal about specifying package metadata and code maturity/quality, I think it's worth working towards easily accessible info like that. If others agree, then let's get started. Whether Stephan's proposal is exactly the right thing, I don't know (I didn't read it carefully), but something is clearly needed. At the very least, a README.txt at the top-level of each project's trunk seems reasonable (and yes, I know many of the zc.* packages don't have that at the top level). I suspect it's worth reading Stephan's proposal carefully as soon as time allows. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com 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
[Zope3-dev] Re: The bug fixing problem
Philipp von Weitershausen wrote at 2006-7-6 18:29 +0200: ... fixing a trivial error without a unit test ... How would you make sure that your fix for even a trivial NameError actually works? Perhaps you introduced another typo in the bugfix? Obviously, I have considerable more confidence in my ability to fix bugs than you do... Or perhaps another problem pops up in the same codepath. Right, that would be possible. But, at least, one bug was fixed... Clearly, since the NameError didn't occur in any other tests, the codepath hasn't been tested yet, so it should be no matter what. If the test is as trivial as the fix, then one can easily add it (if one is not confident that the bug is truely fixed). If not, the about a quarter to half an hour timeframe is easily exhausted and if you insist on the test, you get neither the test nor the fix. There's another aspect to tests for bugs: reproduceability. Especially when fixing bugs I tend to write tests first in order to be absolutely sure that I can reproduce the problem in an automated manner. Then fixing the bug is easy: Just make the test pass... You use the personal form correctly. Not everybody does it like you do. When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. -- 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] Re: The bug fixing problem
On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. Sure. The point of the tests is not to prevent this. The point of them is mainly to make sure that the thing you fixed says fixed. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] Re: The bug fixing problem
Lennart Regebro wrote at 2006-7-6 20:03 +0200: On 7/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: When I have introduced secondary bugs in my fixes (which occasionally happened), then a unit test would not have helped. The reason was then that the affected code was used in unanticipated ways -- and because it was unanticipated, I would not have written a test for it. Sure. The point of the tests is not to prevent this. The point of them is mainly to make sure that the thing you fixed says fixed. I hear (also) other sounds than unit tests ;-) Thus, my fixes can say fixed differently (without a passing unit test)... -- 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] What are zope.generic, z3c, ldapauth, et.al.?
Hi Philipp good idea, just some update what allready happen when you where in China ;-) [...] I see a few packages lurking in svn.zope.org that I can't make much sense of: * For example, what is zope.generic? I can't find a README.txt anywhere in the top-level directories. What I *can* see is that it seems to be another big bag for subpackages like zope.app. I thought we were getting rid of those? I'm also wondering why it carries the 'zope' top-level namespaces. Judging from the checkins, it seems to be a Dominik + Roger project. Last but not least there's the name generic that I can't make much sense of... If you take a closer look at this package and you will see that each subpackage is well documented. The generic package collection is/was developed/mentained by Dominik. The zope.generic sub-package are very well layered and have clear dependency that's the reason why they are containd in a collection package. I'm not fimilar with the state of the 'generic' project right now. But it's a really cool concept. * For example, what does the 'z3c' namespace package stand for? Who's behind this stuff? And why does it sometimes use 'sandbox' or 'Sandbox' instead of or in parallel of 'trunk' for its main development branch? The z3c top level package is a namespace for additional packages where I and Bernd started to use at the SwissEasterSprint. We like to provide usefull implementations there, which are useable for Zope3. The packages in the z3c namespace should follow the ZSCP proposal that's the reason why we started to use the zope repository. Please take also a closer look at the ZSCP concept where we implemented based on Stephans work at the sprint http://svn.zope.org/zf.zscp/ btw, this application is ready to use, perhaps it needs some adapter refactoring migration work. * For example, is ldapauth still maintained? Is it bitrotting? Can it go away? So, there you have typical cases of three problems I currently see with stuff in svn.zope.org: * Uncontrolled package proliferation w/o consistent naming * Inconsistent use of subversion conventions * Undocumented packages (no package metadata available) Basically, what I'm really asking is: - Do other people also think it'd be a good idea to come up with some repository guidelines? Stephan had a proposal about specifying package metadata and code maturity/quality, I think it's worth working towards easily accessible info like that. If others agree, then let's get started. Not started, just make progress in what allready started with Stephans proposal and the ZSCP implementation ;-) Yes, I agree Perhaps you can check the proposal and see what we did in http://svn.zope.org/zf.zscp/. I guess there is more to implement but right now it's working and very professional looking. Thanks to Kamal Gill for the great desing work! - Should this be part of the Zope Foundation development process (which again seems to be worked out by the Zope Management Organization)? If so, I'll hereby volunteer to join such a committee and contribute my ideas (especially on package organization in the repository and the associated development process). I really hope that we adapt the prosess described in Stephans ZSCP proposal. http://svn.zope.org/zf.zscp/trunk/src/zf/zscp/ProcessAndRepository.txt?rev=6 6671view=markup Whould be cool if we could make progress on what Stephan started with the proposal and your ideas. Regards Roger Ineichen Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: language availablity
Philipp von Weitershausen wrote: Chris Withers wrote: TranslationDomain should still implement ILanguageAvailability and zope.i18n.zcml.registerTranslations should register domains for that interface as well as ITranslationDomain, I'd prefer to create an interface extending ITranslationDomain and ILanguageAvailability, making TranslationDomain implement that and have it its instances also registered for that as utility. Why? What exactly is the point of creating yet another interface? More interfaces for more interfaces sake is bad :-( but I agree that you may want to register another utility, probably with no name, that gives you the overall translation domain. Overall translation domain?!? Sorry, brain fart... An unnamed ILanguageAvailability would give a utility that listed what languages the project thought were available. This could be the superset of all languages found in all domains, maybe only the languages found in all domains, maybe something else completely as Hanno described. Local or global 'cos I can imagine this being different for two sites existing in the same zope instance. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] What are zope.generic, z3c, ldapauth, et.al.?
Hi Philipp, Dominik Dominik, can you give a short overview what zope.generic can do? [...] If you take a closer look at this package and you will see that each subpackage is well documented. Right. But that information isn't easily accessible. You have to go to zope.generic/trunk/src/zope/generic/foobar. That's FIVE directory layers down from zope.generic! Yes, that's true, but if you install only one package from the 'zope.generic' collection you need to have that README.txt in this package and not more then that. Another question I raise: Why are there subpackages in the first place? And what's the rationale for calling it 'generic'. It's be like calling it 'zope.fast' or 'zope.easy': you get no idea about the contents of the package. Of course, I know why it's called 'zope.generic'. Because it's a package *collection*. I think package collections (e.g. like zope.app or zope.products which we used to have some years ago) are a mistake... I'm not sure if that is also right for the generic package. The generic package is ONE concept which is implemented in different reusable sub-packages which also can be used as single packages for just one aspect of the generic concept. The generic package collection is/was developed/mentained by Dominik. The zope.generic sub-package are very well layered and have clear dependency that's the reason why they are containd in a collection package. I'm not fimilar with the state of the 'generic' project right now. But it's a really cool concept. I'm not convinced that easily :). Perhaps sketching out what it really is and what its purpose is would help. I think Dominik can explain the generic pattern. All I can say this quickly, you can define new instances only based on schemas without a class implementation. It's a kind of ZClasses, Archetypes in a clean Zope3 like implementation. Generic means you can define generic components which are initializable and configurable during the runtime. There is also a pattern for enhance such a generic instances via plugins. All I can say, it's generic ;-) * For example, what does the 'z3c' namespace package stand for? Who's behind this stuff? And why does it sometimes use 'sandbox' or 'Sandbox' instead of or in parallel of 'trunk' for its main development branch? The z3c top level package is a namespace for additional packages where I and Bernd started to use at the SwissEasterSprint. Great. This should be written down somewhere. (I'm not blaming you for not having done this; we have no rule for this right now. I think we should have a rule, though). no problem, I agree to have a place for such infos. The README.txt files are not good enough for give a overview because you have to checkout first or browse the really slow repos with a browser. Tell me where is somewhere and I can write something ;-) - Do other people also think it'd be a good idea to come up with some repository guidelines? Stephan had a proposal about specifying package metadata and code maturity/quality, I think it's worth working towards easily accessible info like that. If others agree, then let's get started. Not started, just make progress in what allready started with Stephans proposal and the ZSCP implementation ;-) Yes, I agree Perhaps you can check the proposal and see what we did in http://svn.zope.org/zf.zscp/. I guess there is more to implement but right now it's working and very professional looking. Thanks to Kamal Gill for the great desing work! I'm not as much looking for a website that gathers all the ZSCP information as much as for guidelines that help us maintain a certain quality of documentation within the repository. I think the proposal from Stephan should catch all your questions. If not feel free to define and propose them. I agree with have a more clear process for all you are asking. - Should this be part of the Zope Foundation development process (which again seems to be worked out by the Zope Management Organization)? If so, I'll hereby volunteer to join such a committee and contribute my ideas (especially on package organization in the repository and the associated development process). I really hope that we adapt the prosess described in Stephans ZSCP proposal. http://svn.zope.org/zf.zscp/trunk/src/zf/zscp/ProcessAndRepository.txt ?rev=6 6671view=markup Whould be cool if we could make progress on what Stephan started with the proposal and your ideas. Yup. I'll reiterate over Stephan's proposal once again and provide my comments. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: What are zope.generic, z3c, ldapauth, et.al.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: no problem, I agree to have a place for such infos. The README.txt files are not good enough for give a overview because you have to checkout first or browse the really slow repos with a browser. Tell me where is somewhere and I can write something ;-) snip Maybe there should be a top-level README (a peer of the 'src' directory) which outlines the overall architecture and points to the individual sub-packages as they fit into that concept. Then, anybody who checks out the trunk, or a tag, or a branch, will get that overview in the top of their checkout. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErcF/+gerLs4ltQ4RAh5gAKCD9ybcmAExAfrKFEYQu8qft8SwvQCfZWDc QvSFKo7PF7XXgP0fODhhgvw= =nqOe -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: The bug fixing problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: 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! I would say that there are two bugs in the case you are describing: the one you meant to fix and the one which is the lack of any tests for the module / class / whatever. I would bet that spending your thirty minutes adding minimal tests to such a module is a *higher* value activity than fixing most bugs, because it makes it easier for you (or someone else) to fix that bug and others in that module. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFErcLD+gerLs4ltQ4RAhSxAJ9xmfzyQILaq0/aVZr/ELlQOGu4dgCfQog8 YK2w5mPjtW7mAfpzFDYqS0Y= =m9Cv -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
