[Zope-dev] Reminder: IRC meeting today at 3pm UTC
Hi, today we'll start the experiment of having a short IRC meeting to talk about organisational issues. I've had some input for the agenda and mixed with my own questions here's the list of topics: ZTK / Infrastructure - Test runners / nightly builds - Review open issues - Bug tracking / working on bugs regularly Frameworks - Will Zope 2.13 use the ZTK? - Zope 3.5 release I think that will already be enough stuff for 30 minutes. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Reminder: IRC meeting today at 3pm UTC
Hi, today we'll start the experiment of having a short IRC meeting to talk about organisational issues. Also, as Alan asked for this, here's a Google Calendar for you: http://www.google.com/calendar/ical/5f83vmc2vka8vbmvr4ck79m...@group.calendar.google.com/public/basic.ics I've had some input for the agenda and mixed with my own questions here's the list of topics: ZTK / Infrastructure - Test runners / nightly builds - Review open issues - Bug tracking / working on bugs regularly Frameworks - Will Zope 2.13 use the ZTK? - Zope 3.5 release I think that will already be enough stuff for 30 minutes. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reminder: IRC meeting today at 3pm UTC
On 3/2/10 09:31 , Christian Theune wrote: Hi, today we'll start the experiment of having a short IRC meeting to talk about organisational issues. I've had some input for the agenda and mixed with my own questions here's the list of topics: ZTK / Infrastructure - Test runners / nightly builds - Review open issues - Bug tracking / working on bugs regularly Frameworks - Will Zope 2.13 use the ZTK? - Zope 3.5 release I thought Zope 3.x is no more. Did you mean Bluebream? Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reminder: IRC meeting today at 3pm UTC
- Zope 3.5 release I would like to hear from others what is missing in BlueBream 1.0 (to be released on May 31st) as a logical up-gradation path from Zope 3.4 Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Evaluating a zope.i18nmessageid memory leak patch
Hi all, We've been using this patch in production for some weeks and testing for months: http://launchpadlibrarian.net/37237733/_zope_i18nmessageid_message.c.patch To resolve this bug: https://bugs.launchpad.net/zope3/+bug/257657 The patch seems to do what it claims and I've not noted any nasty side-effects thus far. However, before I commit it, I'd appreciate it if someone with knowledge of python C-extension fu had a look at it. I attempted to write a test for this, but my only idea (using weakref.ref) failed. If no-one objects, I'll probably just commit the patch anyway after some time. -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reminder: IRC meeting today at 3pm UTC
On 03/02/2010 09:47 AM, Wichert Akkerman wrote: On 3/2/10 09:31 , Christian Theune wrote: Hi, today we'll start the experiment of having a short IRC meeting to talk about organisational issues. I've had some input for the agenda and mixed with my own questions here's the list of topics: ZTK / Infrastructure - Test runners / nightly builds - Review open issues - Bug tracking / working on bugs regularly Frameworks - Will Zope 2.13 use the ZTK? - Zope 3.5 release I thought Zope 3.x is no more. Did you mean Bluebream? I simply included the topics as they were handed to me to reflect that there definitely is discussion/explanation needed. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.form IGroupForm unused?
z3c.form.interfaces.IGroupForm does not appear to be used anywhere. Is that an oversight, or should the interface be deleted? Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Mon Mar 1 12:00:00 2010 UTC to Tue Mar 2 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 1 20:36:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013659.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 1 20:38:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013660.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 1 20:40:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013661.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 1 20:42:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013662.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 1 20:44:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013663.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Mar 1 20:46:28 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013664.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Reminder: IRC meeting today at 3pm UTC
On 03/02/2010 09:31 AM, Christian Theune wrote: Hi, today we'll start the experiment of having a short IRC meeting to talk about organisational issues. Oh, and it's supposed to be #zope (*not* #zope3-dev) on freenode. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Summary of today's developer meeting
Hi, here's my first shot at a summary of today's meeting. I found the meeting itself very positive and energetic - thanks again to everyone who joined. If anyone knows another good place to announce this summary (we should be more visible to the outside world!), please feel free to post them (or link to them) somewhere and maybe tell me for the future. Cheers, Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development = Weekly Zope developer meeting = This is the summary of the weekly Zope developer meeting which happened on Tuesday, 2010-03-02 on #z...@irc.freenode.org from 3pm to 3:30pm (UTC). The agenda for this meeting is available in the mailing list archives: https://mail.zope.org/pipermail/zope-dev/2010-March/039633.html The IRC logs are located here: http://zope3.pov.lt/irclogs-zope Infrastructure - Test runners and nightly builds The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional. The visibility of the nightly test results is also not very good, except for those buildbots running the Zope 2 tests whose results get aggregated and send to the zope-dev mailinglist. The goals we identified are: - Get a volunteer who will oversee our buildbot installations. The job description would mainly include coordination efforts: ensuring consistent configuration, visibility, reporting and helping people to get nightly builds or contribute builders. mgedmin is pondering until next week whether he volunteers. - We need to put down a list of projects (Zope 2, grok, BB, ZTK, ...), branches and platforms (64-bit!) which we want the nightly builds to be executed on/for. Alan Runyan offered supporting Windows builds. No action/responsibility was agreed upon for this. - Christian Theune volunteered to consisely document instructions for how to run the ZTK tests. ZTK - Open issues = Over the holidays and with Martijn leaving the steering group our velocity on the ZTK got lost, so we need to get back on track here. A quick survey showed that there is some usage of the ZTK in the wild already: SchoolTool, Zope Corp, Launchpad/Landscape, Grok, and Zope 2 being ready to go back to the ZTK with Zope 2.13 (if a ZTK release exists). Our issues fall in to multiple categories (general government and process, definition of goals, roadmap, release manager, and others). The discussion on goals cooled down a bit, as the split between ZTK and zopeapp seems to have been an acceptable step. The biggest current goal is to get a release of the ZTK and zope.app. However, we need to answer some questions first: - What exactly is needed for a release? - Who's the release manager? - Can we ensure building Windows binaries? On the question of a release manager it was pointed out that the ZF could appoint the release manager (and maybe stipend it) although it's not clear whether we really need the ZF authority or funding. Zope 3.5 There will be no explicit Zope 3.5 release and BlueBream 1.0 is considered to be the appropriate successor. The work needed on BlueBream 1.0 is a release of the ZTK and a migration path from Zope 3.4. Post-poned and new issues = The following agenda items did not make it within the time limit: - Bug tracking/working on bugs regularly The following issues were raised newly: - Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
On Tue, Mar 2, 2010 at 11:32 AM, Christian Theune c...@gocept.com wrote: here's my first shot at a summary of today's meeting. Thanks, Christian! I definitely appreciate this summary, since I was visually impaired at the time of the meeting (and still am, but it's returning...). -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
Tres Seaver wrote: Installing Zope -=== +--- -Unless using buildout to build a zope instance as described -:ref:`below buildout-instances`, you will need to install Zope -separately. If you want to create a buildout-based Zope instance, -please skip directly to that section. +The recommended way to install Zope is within a virtualized Python environment +using ``virtualenv`` as follows:: Really? I wouldn't recommend virtualenv... Myself, I find the buildout instance the easiest and lightest weight method... By all means, document virtualenv as an option, but blessing it as the one true way is a bit much... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
Tres Seaver wrote:
Installing Zope
-===
+---
-Unless using buildout to build a zope instance as described
-:ref:`below buildout-instances`, you will need to install Zope
-separately. If you want to create a buildout-based Zope instance,
-please skip directly to that section.
+The recommended way to install Zope is within a virtualized Python
environment
+using ``virtualenv`` as follows::
Really? I wouldn't recommend virtualenv...
Myself, I find the buildout instance the easiest and lightest weight
method...
By all means, document virtualenv as an option, but blessing it as the
one true way is a bit much...
Here's my rationale:
- - The docs are intended primarily for folks who want to install and
run Zope, rather than hack on it.
- - zc.buildout is *super* heavyweight compared to virtualenv
- - zc.buildout creates an environment which is puzzling as hell for
anybody who hasn't already drunk the koolaid ('parts'? 'eggs'?
WTF?)
- - virtualenv, or something damn near it, is likely to land in Python
itself.
- - Nearly anybody else in the Python world is more likely to be
familiar with the virtualenv stuff than with buildout.
- - We have two alternate zc.buildout scenarios (install Zope + run
mkzopeinstance vs. self-contained environment). The first has no
real advantage over the virtualenv one, except being able to
run buildout to update the software (heaven help you if you forget
to configure the index properly!). The second leaves you without
the annotated config file, a *major* faux pas.
I plan to merge that branch to the 2.12 branch and the trunk, assuming
no further objections.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuNTyUACgkQ+gerLs4ltQ7i/wCfeWwoIe1pqmjAgtOlKbb7km7O
xyUAnjgyYNcaz3qIIMB9ZKMn1F+NBcha
=CRlO
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. For now, just see the extra packages as the ultimate in compatibility tests and run them please. Furthermore, the bicycle toolkit is the only candidate for such splitting up right now; other groupings don't seem to be well defined. Finally, people who want fine grained already have the ultimate in fine-grained in the form of individual releases. Maybe next year. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
Tres Seaver wrote:
- - The docs are intended primarily for folks who want to install and
run Zope, rather than hack on it.
Says who? The last comment I had on those docs was from Marius when he
had to go back to a Zope 2 project and wanted to make it buildout based.
I've also used those docs myself when doing upgrades to Zope 2.12 (one
of the reasons I did all the work on them!)
- - zc.buildout is *super* heavyweight compared to virtualenv
A point of view, I don't happeen to agree, especially for the simple
case of an instance... virtualenv doesn't fit my brain, buildout does.
I'd hazard a guess that people still interested in Zope 2 might fall
into that category too...
- - zc.buildout creates an environment which is puzzling as hell for
anybody who hasn't already drunk the koolaid ('parts'? 'eggs'?
WTF?)
...or not.
bin/zopectl
...which is what you've done in Zope instances for years now...
having to guess where to find zopectl in a virtual env is not something
that comes naturally to all of us...
- - virtualenv, or something damn near it, is likely to land in Python
itself.
I don't think that discussion is anywhere near done yet ;-)
- - Nearly anybody else in the Python world is more likely to be
familiar with the virtualenv stuff than with buildout.
Not 100% on that either, buildout has been active service in the Django
community, and for all I know, elsewhere too..
- - We have two alternate zc.buildout scenarios (install Zope + run
mkzopeinstance vs. self-contained environment).
Yes, I'm much more for the latter, but when I tried to make that the
only way, someone whined, so I tried to stay neutral...
run buildout to update the software (heaven help you if you forget
to configure the index properly!).
How is that any different from the virtual env route?!
The second leaves you without
the annotated config file, a *major* faux pas.
If someone wants to knock up a paster template, go right ahead. Myself,
I'm not that fussed. I always trim away all the default values and
commentary from my zope.conf anyway, since I know where to find the
skeleton (wouldn't it be great if that figured in the Zope 2 docs where
it belongs, since it really is documentation) and I like short config
files that say what *is* actually configured rather than what *might* be
a default value...
I plan to merge that branch to the 2.12 branch and the trunk, assuming
no further objections.
Well, maybe wait to see what other people think. The above is obviously
my personal view, but I'd be surprised if I was the only person who had
that view...
Chris
--
Simplistix - Content Management, Batch Processing Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
Excellent, I hope it's a regular feature. The summary should probably go on some blog that will be picked up by planetzope.org/planet.zope.org, too. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
On 3/2/10 1:09 PM, Martijn Faassen wrote: Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. I don't know who people are, and I don't know who they are, and I don't know who broke what. The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional Zope Form Generation package that it would be for them to need to extract such a thing from the ZTK wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named zope.* if they were better organized into functional categories. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonough chr...@plope.com wrote: On 3/2/10 1:09 PM, Martijn Faassen wrote: Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. I don't know who people are, and I don't know who they are, and I don't know who broke what. The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional Zope Form Generation package that it would be for them to need to extract such a thing from the ZTK wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named zope.* if they were better organized into functional categories. I think you're confusing management and reuse (packaging including dependencies). We all want people to be able to reuse parts of the ZTK. There's broad agreement that we want to clean up dependencies. What's being advocated by many of us is that the ZTK be managed as a whole (for some definition of the whole that shrinks somewhat over time) to allow us to clean things up without causing breakage for people using the ZTK. No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution. Jim -- Jim Fulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
Hi there, I've said my piece. I'm not going to argue about it. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
On 3/2/10 2:50 PM, Jim Fulton wrote: On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonoughchr...@plope.com wrote: On 3/2/10 1:09 PM, Martijn Faassen wrote: Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. I don't know who people are, and I don't know who they are, and I don't know who broke what. The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional Zope Form Generation package that it would be for them to need to extract such a thing from the ZTK wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named zope.* if they were better organized into functional categories. I think you're confusing management and reuse (packaging including dependencies). We all want people to be able to reuse parts of the ZTK. There's broad agreement that we want to clean up dependencies. What's being advocated by many of us is that the ZTK be managed as a whole (for some definition of the whole that shrinks somewhat over time) to allow us to clean things up without causing breakage for people using the ZTK. No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution. You've both successfully beaten any initiative out of me again. Well done. Full speed ahead. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of today's developer meeting
Morning, On 03/02/2010 07:09 PM, Martijn Faassen wrote: Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 Uhh. -1 for what? -1 for pondering *something*? The note I took was a request for thinking about something. No *I'm* confused about stop energy. Also: we probably should move actual discussions out of the summary thread. ;) Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
