Re: [Zope-dev] Summary of today's developer meeting
Hi Sebastien, On Fri, Mar 5, 2010 at 1:47 AM, Sebastien Douche wrote: >> 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 new URL is : > http://bluebream.buildbot.securactive.org/ Thanks for setting up Buildbot for BB. Can you please co-ordinate with Christophe Combelles, he already setup a Buildbot for BB: http://zope3.afpy.org/buildbot/waterfall (I have CC'ed him here) > Baiju : Do you want another Buildbots? (za = zopeproject, com = > community, ztk = Zope TollKit, bb = BlueBream). A single build master as you organized looks good. Do we need multiple masters located at different servers ? What I really needed is more slaves. We need to find volunteers to provide Windows slaves (both 32bit & 64bit) 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 )
Re: [Zope-dev] Zope3 sessions and database conflicts
Hermann Himmelbauer writes: > Hi, > For quite some time I see messages like this in my z3.log: > > 2010-03-02T16:27:14 WARNING ZopePublication Competing writes/reads > at /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/images/sponsor_logo.png: > database conflict error (oid 0x063f, class BTrees.OOBTree.OOBucket, serial > this txn started with 0x038484dc7d5ac044 2010-03-02 14:52:29.379960, serial > currently committed 0x038484ff3c6b5455 2010-03-02 15:27:14.160763) I note the conflict happened when the request was just for an image. I've seen this before under Zope2 when a PAS plugin was mis-using the session machinery as a cache during authentication of the request. When ever a session object is accessed it initiates a write transaction in the ZODB. With most, if not all, authentication methods, when a user is logged-in the auth tokens are included in every request which means every request from the logged-in user invokes the authentication machinery, including requests for images. Since every page load involves multiple requests for page resources, the database gets overwhelmed with write transactions which inevitably conflict. When the write conflict occurs, the publisher appropriately retries the request which multiplies the number of requests which multiplies the load which increases the amount of time taken in processing requests which multiplies the likelihood of write conflicts and your off to the races in the wrong direction. So I'd suggest you find out what in a request for a simple resource (images, non-dynamic CSS or JS) is initiating the write transaction by invoking sessions. It's likely there's an inappropriate use of sessions there. HTH, Ross > I followed an advice from the zope-dev list and added some debug messages in > ZODB.Connection.py where the objects are registered for writing. > > The following debug messages (I print the key/values of the object in > question) occur before and after the database conflict error: > > --- > 2010-03-02T16:27:14 DEBUG zbsp keys: > ['6ZZzgjNK0p.bIIlruXb4JkDo-T0J-XipPcVFGtcj0 > LH6dMdI9akYvg', . , '7MmOPQOlkAHoa3T > nydH9IIgKBqoVyn3Q.yH6OXJeLj7epObIy3M5Lg'] > --- > 2010-03-02T16:27:14 DEBUG zbsp values: [ object at 0x43723bec>, 0x4372356c>, , > . > , > , > 0x43640b6c>,] > --- > > So it seems these are the session data containers. > > I wonder why they are written? Perhaps this happens when somebody else is > logging into the system (so a new session is added) and others are > concurrently reading from the session? However, this would mean that the > session mechanism has a flaw, as this is a standard procedure? > > Any ideas of how to fix this? > > Best Regards, > Hermann ___ 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] Automating tests of the ZTK / zopeapp package sets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After successfully configuring the Hudson[1] continuous integration server yesterday to test the various repoze.* packages[2], I thought I would experiment with using it to drive the compatibility tests for ZTK and zopeapp. Here is what I did: In a shell on my server: $ wget http://hudson-ci.org/latest/hudson.war $ java -jar hudson.war --httpPort=1 In the browser, visit 'http://laguna.palladion.com:1, and configure the server: - - Enable security - allow signup - using Matrix - set up 'tseaver' as having all permissions - set up 'anonymous' as having 'Read' permission overall and for jobs - - Register as 'tseaver' - Turn off signup (no, I don't want you guys running arbitrary shell scripts on my server ;). - - Create a job, 'ztk-trunk-py26': http://laguna.palladion.com:1/job/ztk-trunk-py26/ - Use SVN, pointed at 'svn://svn.zope.org/repos/main/zopetoolkit/trunk' - Set to poll SVN every 15 minutes. - Enable using 'svn up' - Added build step as a shell script:: cd trunk /opt/Python-2.6.4/bin/python bootstrap.py bin/buildout bin/test-ztk bin/test-zopeapp - Ran a build manually. The first one barfed due to a typo in my script, but the second one ran, taking 21 minutes. The test runs successfully to completion, but doesn't produce statistics in a form that Hudson understands. The following changes to 'zope.testing.testrunner' would make the output more informative: - Add a flag like the '--with-xunit' flag to the Nose testrunner, which dumped results into a JUnit-compatible XML file[3]. - Add a flag like the '--with-xcompat' flag to the Nose testrunner (when run with the 'nosexcover' plugin), producing a Cobertura- compabtible XML file[4]. At that point, the build process would be nicely automated, with browsable results including coverage, pretty graphs, etc. See the 'repoze' jobs for examples of those outputs. Questions for discussion: - - I find the prettier interface and easier setup than buildbot worth running a 3rd-party Java app (rather than a 3rd party Python app). Would that be acceptable among the folks running our automated tests? - - Is it worth adding the XML support for test results and coverage to 'zope.testing.testrunner'? - - Would people be willing to run Hudson "permanently" on enough hosts to make this a reasonable replacement for buildbot (we need Windows, too)? - - Hudson seems general purpose enough to allow automating other code- related tasks, e.g., production of dependency graphs. Maybe we could even automate building Windows installers? I will try to leave the ZTK Hudson server up for a little bit, to allow folks to see what it can deliver already. [1] http://hudson-ci.org/ [2] http://hudson.repoze.org/ [3] http://old.nabble.com/schema-for-junit-xml-output-td22193385.html [4] http://cobertura.sourceforge.net/xml/coverage-01.dtd Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQIcAACgkQ+gerLs4ltQ61pACfXsIdiRGY2LQ+u8d/qpG2okpT eKQAn0gjegHqlvu7w3RV01IruUx7S5QM =OmZN -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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastien Douche wrote: > On Tue, Mar 2, 2010 at 17:32, Christian Theune wrote: >> 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. > >> 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 new URL is : > http://bluebream.buildbot.securactive.org/ > > Other buildbots : > http://grok.buildbot.securactive.org/ > http://bfg.buildbot.securactive.org/ > http://misc.buildbot.securactive.org/ > >> 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. > > Funny, it's the same thing each year (read the Message-ID: > <20090616060020.gc9...@elzar.ws.whq.gocept.com> for a example), > developers are not affected by the buildbot state and when I (or > other) send a mail about failures, the response is : don't spam the > mailing list. Anybody who complains about legitimate failure reports making it to this list is dead wrong. I think having "sparse" errror messages to this list would be fine (once when a given build failed the first time, another when it built successfully), but others find that too noisy. To that end, We have asked that the run-every-day reports go to a separate list[1], which aggregates them and sends a summary to this list every day. Stefan Holek runs his Zope2 tests and sends the results there. The convention is that the Subject: header for the message starts with 'OK', 'FAILURE', or 'UNKNOWN' (a checkout or build failure), and names the "configuration" being tested. [1] https://mail.zope.org/mailman/listinfo/zope-tests > BTW I'm a volunteer. Thank you very much for your efforts! Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQKosACgkQ+gerLs4ltQ78OQCggIOrjZeh02yv2rNzUqfkEn7E 4PkAn0FRLKpC6XliU9+HWr9ydgxi+ifg =kNiv -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] Uses of the ZTK and how it relates to management
> > One thing that makes problems like this really hard is that email is such > a terrible tool for much of the needed communication. It would be nice > if we could do something more sprinty. I don't want to help if it involves > drawn out email discussions, but, FWIW, I'd be willing to allocate some > concentrated blocks of time for high-bandwidth discussion and work. Fortunately there are all sorts of free/cheap ways for high bandwidth communication. Maybe a free conference call + screen sharing. If there was an agenda -- I would be more than willing to schedule, ensure technology is working, and coordinate people being there. Some people in the plone community have been doing weekly sprints. They just completed their 27th weekly sprint. They spend 6 hours or so on a set of bugs in the issue tracker. They do it over #irc. By this is still lowbandwidth communications. Nothing better than voice + supporting visuals to increase effectiveness. Again if someone wants to setup agenda I can help w/ logistics and ensure voice/screen sharing will work for, say, 20-40 people. Unfortunately I know very little about ZTK and the dependency issues. I would not be good person to setup an agenda. cheers alan ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 2:37 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jim Fulton wrote: > >> On Thu, Mar 4, 2010 at 2:42 AM, Fabio Tranchitella wrote: >>> * 2010-03-03 21:44, Jim Fulton wrote: The ZTK was created in part to deal with instability issues arising from people working on parts without testing the whole. >>> I suppose everybody here agrees that any change to a package which is part >>> of the ZTK *must* be tested against the whole ZTK. >> >> It would be great if that were true. If so, then the recent arguments >> have been a terrible misunderstanding. > > I think that most of the misunderstanding lies in the nature of > "ownership" of the packages in the ZTK: some would like everyone to > care equally about all the packages (including those now factored into > the zopeapp.cfg set), while others want to give most of their attention > to some smaller set of packages which they use every day. We already > have some policies in place which recognize that the "bicycle seat > toolkit" packages need special handling, becaues they are used outside > the Zope ecosystem (one rule is that we attempt to keep Python 2.4 > compatibiltiy for those packages). > > I certainly don't think anybody here would argue against having the big > 'compattest' tests get run: even the "splitters" and "whittlers" (I > might be called one of those) are willing to help fix things when a > change to one package breaks the others. If we could get automated > testing of the various compatibility sets established, with automated > reporting of failures, I think we would see a huge improvement in the > signal here: instead of arguing hypotheticals, we would be focused on > fixing "real" breakages. +1 Hopefully the discussions about buildbots will bear fruit. >>> It would be easier to >>> find leading developers for subgroups of packages (eg. bicycle repair kit, >>> rm generation, ...) willing to raise the quality of a specific subset of >>> packages instead of finding a release manager willing to oversee > 60 >>> packages, which he does not really use (because I don't think we have a >>> single developer using *all* of the packages in the ZTK). >>> >>> These specific leading developers could report and synchronize with a ZTK >>> release manager, though. >> >> There's nothing preventing people from doing this AFAICT. If someone >> is interested in pursuing a change to a package or collection of >> packages, they can do so with or without some organizational >> structure. Problems would arise only if they proposed a backward >> incompatible change, which isn't to say that backward-incompatible >> changes are impossible. > > We still mostly treat them as off-limits, even the three years after we > started the effort to break the monolith apart. That change should have > made it technically feasible to do backward-incompatible changes, but we > haven't yet worked out how to make that happen. I wonder how many situations there are where backward incompatible changes are needed to unblock other work. I don't suppose we have a list of these do we? One thing that makes problems like this really hard is that email is such a terrible tool for much of the needed communication. It would be nice if we could do something more sprinty. I don't want to help if it involves drawn out email discussions, but, FWIW, I'd be willing to allocate some concentrated blocks of time for high-bandwidth discussion and work. 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] Uses of the ZTK and how it relates to management
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: > On Thu, Mar 4, 2010 at 2:42 AM, Fabio Tranchitella wrote: >> * 2010-03-03 21:44, Jim Fulton wrote: >>> The ZTK was created in part to deal with instability issues arising from >>> people working on parts without testing the whole. >> I suppose everybody here agrees that any change to a package which is part >> of the ZTK *must* be tested against the whole ZTK. > > It would be great if that were true. If so, then the recent arguments > have been a terrible misunderstanding. I think that most of the misunderstanding lies in the nature of "ownership" of the packages in the ZTK: some would like everyone to care equally about all the packages (including those now factored into the zopeapp.cfg set), while others want to give most of their attention to some smaller set of packages which they use every day. We already have some policies in place which recognize that the "bicycle seat toolkit" packages need special handling, becaues they are used outside the Zope ecosystem (one rule is that we attempt to keep Python 2.4 compatibiltiy for those packages). I certainly don't think anybody here would argue against having the big 'compattest' tests get run: even the "splitters" and "whittlers" (I might be called one of those) are willing to help fix things when a change to one package breaks the others. If we could get automated testing of the various compatibility sets established, with automated reporting of failures, I think we would see a huge improvement in the signal here: instead of arguing hypotheticals, we would be focused on fixing "real" breakages. >> It would be easier to >> find leading developers for subgroups of packages (eg. bicycle repair kit, >> rm generation, ...) willing to raise the quality of a specific subset of >> packages instead of finding a release manager willing to oversee > 60 >> packages, which he does not really use (because I don't think we have a >> single developer using *all* of the packages in the ZTK). >> >> These specific leading developers could report and synchronize with a ZTK >> release manager, though. > > There's nothing preventing people from doing this AFAICT. If someone > is interested in pursuing a change to a package or collection of > packages, they can do so with or without some organizational > structure. Problems would arise only if they proposed a backward > incompatible change, which isn't to say that backward-incompatible > changes are impossible. We still mostly treat them as off-limits, even the three years after we started the effort to break the monolith apart. That change should have made it technically feasible to do backward-incompatible changes, but we haven't yet worked out how to make that happen. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQC9gACgkQ+gerLs4ltQ4x8QCfXQ2JkuCy4XyJgHDuzrZZjLIc 1wkAn0J7kdM4F4iRcO4OP2EGGsKi+1vB =r+V4 -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
On Tue, Mar 2, 2010 at 17:32, Christian Theune wrote: > 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. > 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 new URL is : http://bluebream.buildbot.securactive.org/ Other buildbots : http://grok.buildbot.securactive.org/ http://bfg.buildbot.securactive.org/ http://misc.buildbot.securactive.org/ > 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. Funny, it's the same thing each year (read the Message-ID: <20090616060020.gc9...@elzar.ws.whq.gocept.com> for a example), developers are not affected by the buildbot state and when I (or other) send a mail about failures, the response is : don't spam the mailing list. BTW I'm a volunteer. > 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. I have Linux (32 & 64 bits) Buildbots for all Zope3 projects (grok, bfg, ztk, bb) > Christian Theune volunteered to consisely document instructions for how to > run the ZTK tests. Cool :) Baiju : Do you want another Buildbots? (za = zopeproject, com = community, ztk = Zope TollKit, bb = BlueBream). -- Sebastien Douche Twitter: http://bit.ly/afkrK (agile, python, open source) ___ 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.component.zcml and global registry
* 2010-03-03 21:35, Tres Seaver wrote: > If the tests all pass, then I would say go ahead and commit it now, but > add tests to verify that the new feature works as you expect. Committed with tests. Best regards, Fabio ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 11:34 AM, Brian Sutherland wrote: > On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote: >> On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland >> wrote: >> > On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: >> >> In the specific case of zope.event, I'd prefer it stay separate. I >> >> want developers to be able to publish events without having to commit >> >> to a subscription mechanism. For example, ZODB depends on zope.event >> >> so it can generate events and provide a generic hook mechanism. I >> >> don't want it to depend on zope.component. >> > >> > I just committed a jinty-optional-event branch for zope.component that's >> > an experiment as to how to make the dependency on zope.event optional. >> >> Maybe I'm missing something, but zope.event is so minimal I can't see >> that making optional is worth the effort. > > Actually, I misunderstood your question. Good, because while reading you're response I was so confused I worried that I had recently had a stroke and not realized it yet. -- Benji York ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote: > On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland > wrote: > > On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: > >> In the specific case of zope.event, I'd prefer it stay separate. I > >> want developers to be able to publish events without having to commit > >> to a subscription mechanism. For example, ZODB depends on zope.event > >> so it can generate events and provide a generic hook mechanism. I > >> don't want it to depend on zope.component. > > > > I just committed a jinty-optional-event branch for zope.component that's > > an experiment as to how to make the dependency on zope.event optional. > > Maybe I'm missing something, but zope.event is so minimal I can't see > that making optional is worth the effort. Actually, I misunderstood your question. Personally, I also don't think it's worth the effort. But it's come up a few times already, so is obviously something some group of people want. The effort, also, is actually quite small as can be seen on the branch. Perhaps it's even an effort saver if it prevents the topic coming up again and again ;) -- 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] Uses of the ZTK and how it relates to management
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote: > On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland > wrote: > > On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: > >> In the specific case of zope.event, I'd prefer it stay separate. I > >> want developers to be able to publish events without having to commit > >> to a subscription mechanism. For example, ZODB depends on zope.event > >> so it can generate events and provide a generic hook mechanism. I > >> don't want it to depend on zope.component. > > > > I just committed a jinty-optional-event branch for zope.component that's > > an experiment as to how to make the dependency on zope.event optional. > > Maybe I'm missing something, but zope.event is so minimal I can't see > that making optional is worth the effort. One point is backwards compatibility, the other is to allow zope.component subscribers to listen to ZODB events if the ZODB only depends on zope.event but not on zope.component. -- 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland wrote: > On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: >> In the specific case of zope.event, I'd prefer it stay separate. I >> want developers to be able to publish events without having to commit >> to a subscription mechanism. For example, ZODB depends on zope.event >> so it can generate events and provide a generic hook mechanism. I >> don't want it to depend on zope.component. > > I just committed a jinty-optional-event branch for zope.component that's > an experiment as to how to make the dependency on zope.event optional. Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort. -- Benji York ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: > On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting wrote: > > On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune wrote: > >> A thought that came up when reading this paragraph: another option > >> restructuring/grouping to reduce the amount of packages may be to join > >> smaller packages with weird boundaries into larger ones again. (Not that > >> I suggest this to be an ultimate option, nor do I know from the top of > >> my head any candidates for this, but we can keep that on the list of > >> options we have.) > > > > I think this is a good idea, but I wouldn't want to do it on a package > > level. Rather do it on the distribution level. Once the distutils2 > > improvements are available, we have the means to say "distribution A > > obsoletes B". > > > > As a simple example that would allow us to put zope.event into the > > zope.component distribution, without having to change any import paths > > or setup.py install_requires lines. The zope.component distribution > > would have the metadata to say "I obsolete zope.event", so if someone > > has such a version of zope.component, requirements of the zope.event > > distribution would be automatically satisfied. > > > > This same method could be taken to build more functional distribution > > out of related packages we have today. These distributions might also > > be easier to market, document and explain. But they come with the > > downside of more buy-in per distribution. Figuring out how packages > > are actually used and which ones are used independently is no small > > task. > > Your description of the mechanism sounds interesting. > > In the specific case of zope.event, I'd prefer it stay separate. I > want developers to be able to publish events without having to commit > to a subscription mechanism. For example, ZODB depends on zope.event > so it can generate events and provide a generic hook mechanism. I > don't want it to depend on zope.component. I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional. zope.event will still be used if it is around but zope.component will provide it's own implementation if not. Other packages which only depend on zope.component can break their dependency on zope.event. > Ideally, I'd like other projects to adopt zope.event, or for something > like zope.event to be included in the standard library, although, I'm > unlikely to push that politically, so it will probably never happen. > :/ > > 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 ) -- 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 2:42 AM, Fabio Tranchitella wrote: > * 2010-03-03 21:44, Jim Fulton wrote: >> The ZTK was created in part to deal with instability issues arising from >> people working on parts without testing the whole. > > I suppose everybody here agrees that any change to a package which is part > of the ZTK *must* be tested against the whole ZTK. It would be great if that were true. If so, then the recent arguments have been a terrible misunderstanding. > It would be easier to > find leading developers for subgroups of packages (eg. bicycle repair kit, > rm generation, ...) willing to raise the quality of a specific subset of > packages instead of finding a release manager willing to oversee > 60 > packages, which he does not really use (because I don't think we have a > single developer using *all* of the packages in the ZTK). > > These specific leading developers could report and synchronize with a ZTK > release manager, though. There's nothing preventing people from doing this AFAICT. If someone is interested in pursuing a change to a package or collection of packages, they can do so with or without some organizational structure. Problems would arise only if they proposed a backward incompatible change, which isn't to say that backward-incompatible changes are impossible. 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting wrote: > On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune wrote: >> A thought that came up when reading this paragraph: another option >> restructuring/grouping to reduce the amount of packages may be to join >> smaller packages with weird boundaries into larger ones again. (Not that >> I suggest this to be an ultimate option, nor do I know from the top of >> my head any candidates for this, but we can keep that on the list of >> options we have.) > > I think this is a good idea, but I wouldn't want to do it on a package > level. Rather do it on the distribution level. Once the distutils2 > improvements are available, we have the means to say "distribution A > obsoletes B". > > As a simple example that would allow us to put zope.event into the > zope.component distribution, without having to change any import paths > or setup.py install_requires lines. The zope.component distribution > would have the metadata to say "I obsolete zope.event", so if someone > has such a version of zope.component, requirements of the zope.event > distribution would be automatically satisfied. > > This same method could be taken to build more functional distribution > out of related packages we have today. These distributions might also > be easier to market, document and explain. But they come with the > downside of more buy-in per distribution. Figuring out how packages > are actually used and which ones are used independently is no small > task. Your description of the mechanism sounds interesting. In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component. Ideally, I'd like other projects to adopt zope.event, or for something like zope.event to be included in the standard library, although, I'm unlikely to push that politically, so it will probably never happen. :/ 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] [Zope-Checkins] SVN: Zope/branches/tseaver-clarify_install_docs/doc/ Split out docs for 'normal' installation from those using 'zc.buildout'.
On Tue, Mar 02, 2010 at 06:12:30PM +, Chris Withers wrote: > 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 wanted to upgrade Zope 2 on a local non-profit's server. I found the INSTALL document. It gave me many options, which was confusing. I picked the buildout option since I thought it was the one blessed by the Zope community. I went through some paint getting it to work, and I consider myself to be pretty familiar with buildout. In retrospect I think I should've used virtualenv + mkzopeinstance. I'm +10 for having a single recommended install option documented in INSTALL.txt. Let the other options be relegated to appendices in a separate file, for people who think they want buildout/rpm/whatever. I don't much care if that option is buildout or virtualenv or anything else, as long as it is reasonably simple and works well for most users. Currently I'm feeling +0.9 towards virtualenv over buildout, but this feeling slowly oscillates over time. A while ago I preferred buildout over virtualenv; now I just need to experience a certain number of virtualenv bugs and issues to swing me back. ;-) > > - - 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. That is a curious observation. I find it much easier to understand what virtualenv does and how it does it: the underlying model is simpler. Of course it has fewer features than buildout, which is why I use buildout for *development*, but I've seen the cost of those features in increased complexity and difficulty of debugging when something goes wrong. Actually, now that I think about it more, a buildout would have one advantage over virtualenv: with a fixed versions.cfg your Zope 2 installs won't start failing when somebody uploads a new-improved-and-incompatible version of zope.component into PyPI. > > - - 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... There will always be people who whine :( Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital 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] Zope3 sessions and database conflicts
Could you please, Kevin, explain how you acheived that ? Thank you - Souheil 2010/3/4 kevin gill : >> Hi, >> For quite some time I see messages like this in my z3.log: >> >> 2010-03-02T16:27:14 WARNING ZopePublication Competing writes/reads >> at >> /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/images/sponsor_logo.png: >> database conflict error (oid 0x063f, class BTrees.OOBTree.OOBucket, serial >> this txn started with 0x038484dc7d5ac044 2010-03-02 14:52:29.379960, >> serial >> currently committed 0x038484ff3c6b5455 2010-03-02 15:27:14.160763) >> >> I followed an advice from the zope-dev list and added some debug messages >> in >> ZODB.Connection.py where the objects are registered for writing. >> >> The following debug messages (I print the key/values of the object in >> question) occur before and after the database conflict error: >> >> --- >> 2010-03-02T16:27:14 DEBUG zbsp keys: >> ['6ZZzgjNK0p.bIIlruXb4JkDo-T0J-XipPcVFGtcj0 >> LH6dMdI9akYvg', . , '7MmOPQOlkAHoa3T >> nydH9IIgKBqoVyn3Q.yH6OXJeLj7epObIy3M5Lg'] >> --- >> 2010-03-02T16:27:14 DEBUG zbsp values: [> object at 0x43723bec>, > 0x4372356c>, , >> . >> , >> , >> > 0x43640b6c>,] >> --- >> >> So it seems these are the session data containers. >> >> I wonder why they are written? Perhaps this happens when somebody else is >> logging into the system (so a new session is added) and others are >> concurrently reading from the session? However, this would mean that the >> session mechanism has a flaw, as this is a standard procedure? >> >> Any ideas of how to fix this? > > I had a serious problem with the session machinery. > > I use a very long timeout on sessions and thus have a large number of > sessions saved (up to 30k). The sweep machinery kicks in and sweeps > everything. It takes so long that all the threads do the sweep and you get > these errors. > > I customised the sweep for my site as follows: > > 1. Only sweep at night > 2. Sweep a random subset of the data (20 records), but sweep very often > 3. Different timeouts for authenticated sessions and anonymous sessions. > > Regards, > > Kevin > > >> >> Best Regards, >> Hermann >> >> -- >> herm...@qwer.tk >> GPG key ID: 299893C7 (on keyservers) >> FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 >> ___ >> Zope-Dev maillist - zope-...@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 maillist - zope-...@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 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] Zope3 sessions and database conflicts
> Hi, > For quite some time I see messages like this in my z3.log: > > 2010-03-02T16:27:14 WARNING ZopePublication Competing writes/reads > at > /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/images/sponsor_logo.png: > database conflict error (oid 0x063f, class BTrees.OOBTree.OOBucket, serial > this txn started with 0x038484dc7d5ac044 2010-03-02 14:52:29.379960, > serial > currently committed 0x038484ff3c6b5455 2010-03-02 15:27:14.160763) > > I followed an advice from the zope-dev list and added some debug messages > in > ZODB.Connection.py where the objects are registered for writing. > > The following debug messages (I print the key/values of the object in > question) occur before and after the database conflict error: > > --- > 2010-03-02T16:27:14 DEBUG zbsp keys: > ['6ZZzgjNK0p.bIIlruXb4JkDo-T0J-XipPcVFGtcj0 > LH6dMdI9akYvg', . , '7MmOPQOlkAHoa3T > nydH9IIgKBqoVyn3Q.yH6OXJeLj7epObIy3M5Lg'] > --- > 2010-03-02T16:27:14 DEBUG zbsp values: [ object at 0x43723bec>, 0x4372356c>, , > . > , > , > 0x43640b6c>,] > --- > > So it seems these are the session data containers. > > I wonder why they are written? Perhaps this happens when somebody else is > logging into the system (so a new session is added) and others are > concurrently reading from the session? However, this would mean that the > session mechanism has a flaw, as this is a standard procedure? > > Any ideas of how to fix this? I had a serious problem with the session machinery. I use a very long timeout on sessions and thus have a large number of sessions saved (up to 30k). The sweep machinery kicks in and sweeps everything. It takes so long that all the threads do the sweep and you get these errors. I customised the sweep for my site as follows: 1. Only sweep at night 2. Sweep a random subset of the data (20 records), but sweep very often 3. Different timeouts for authenticated sessions and anonymous sessions. Regards, Kevin > > Best Regards, > Hermann > > -- > herm...@qwer.tk > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > ___ > 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 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] Zope3 sessions and database conflicts
Hi, For quite some time I see messages like this in my z3.log: 2010-03-02T16:27:14 WARNING ZopePublication Competing writes/reads at /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/images/sponsor_logo.png: database conflict error (oid 0x063f, class BTrees.OOBTree.OOBucket, serial this txn started with 0x038484dc7d5ac044 2010-03-02 14:52:29.379960, serial currently committed 0x038484ff3c6b5455 2010-03-02 15:27:14.160763) I followed an advice from the zope-dev list and added some debug messages in ZODB.Connection.py where the objects are registered for writing. The following debug messages (I print the key/values of the object in question) occur before and after the database conflict error: --- 2010-03-02T16:27:14 DEBUG zbsp keys: ['6ZZzgjNK0p.bIIlruXb4JkDo-T0J-XipPcVFGtcj0 LH6dMdI9akYvg', . , '7MmOPQOlkAHoa3T nydH9IIgKBqoVyn3Q.yH6OXJeLj7epObIy3M5Lg'] --- 2010-03-02T16:27:14 DEBUG zbsp values: [, , , . , , ,] --- So it seems these are the session data containers. I wonder why they are written? Perhaps this happens when somebody else is logging into the system (so a new session is added) and others are concurrently reading from the session? However, this would mean that the session mechanism has a flaw, as this is a standard procedure? Any ideas of how to fix this? Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 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] Uses of the ZTK and how it relates to management
Hello, Wednesday, March 3, 2010, 9:43:44 PM, you wrote: JF> Others, like me and Martijn and probably many many others, see the ZTK JF> as a set of packages that can be used in various subsets and JF> combination. We want as few dependencies as possible. We also want a JF> configuration of versions that are known to work together because they JF> are tested together. We want stability and we want processes that JF> will help us move forward. I don't think the people who want to JF> advance Blue Bream are really all that different. Well said. A big +sys.maxint. -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: In the end it will not matter to us whether we fought with flails or reeds. It will matter to us greatly on what side we fought. - G.K. Chesterton ___ 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 Wed Mar 3 12:00:00 2010 UTC to Thu Mar 4 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: Wed Mar 3 20:36:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013671.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Mar 3 20:38:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013672.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 3 20:40:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013673.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 3 20:42:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013674.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 3 20:44:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013675.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Mar 3 20:46:59 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-March/013676.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 )
[Zope-dev] Zope3 sessions and database conflicts
Hi, For quite some time I see messages like this in my z3.log: 2010-03-02T16:27:14 WARNING ZopePublication Competing writes/reads at /BSPSite/act/++vh++http:zis.act.at:80/bankneu/++/images/sponsor_logo.png: database conflict error (oid 0x063f, class BTrees.OOBTree.OOBucket, serial this txn started with 0x038484dc7d5ac044 2010-03-02 14:52:29.379960, serial currently committed 0x038484ff3c6b5455 2010-03-02 15:27:14.160763) I followed an advice from the zope-dev list and added some debug messages in ZODB.Connection.py where the objects are registered for writing. The following debug messages (I print the key/values of the object in question) occur before and after the database conflict error: --- 2010-03-02T16:27:14 DEBUG zbsp keys: ['6ZZzgjNK0p.bIIlruXb4JkDo-T0J-XipPcVFGtcj0 LH6dMdI9akYvg', . , '7MmOPQOlkAHoa3T nydH9IIgKBqoVyn3Q.yH6OXJeLj7epObIy3M5Lg'] --- 2010-03-02T16:27:14 DEBUG zbsp values: [, , , . , , ,] --- So it seems these are the session data containers. I wonder why they are written? Perhaps this happens when somebody else is logging into the system (so a new session is added) and others are concurrently reading from the session? However, this would mean that the session mechanism has a flaw, as this is a standard procedure? Any ideas of how to fix this? Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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'.
Hi Tres! Tres Seaver wrote: > I recommend virtualenv to anybody who just wants to install and run the > Zope2 appserver, without needing to drink a lot of "kool-aid": just > install it from PyPI, run 'mkzopeinstance', and you're done. Who are these people? Why do they want to install and run Zope2? Is Zope2 in any way useful for non-developers? Is pure TTW development the best way to get started? Or do you recommend virtualenv as well for small file-system based projects? Cheers, Yuppie ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune wrote: > A thought that came up when reading this paragraph: another option > restructuring/grouping to reduce the amount of packages may be to join > smaller packages with weird boundaries into larger ones again. (Not that > I suggest this to be an ultimate option, nor do I know from the top of > my head any candidates for this, but we can keep that on the list of > options we have.) I think this is a good idea, but I wouldn't want to do it on a package level. Rather do it on the distribution level. Once the distutils2 improvements are available, we have the means to say "distribution A obsoletes B". As a simple example that would allow us to put zope.event into the zope.component distribution, without having to change any import paths or setup.py install_requires lines. The zope.component distribution would have the metadata to say "I obsolete zope.event", so if someone has such a version of zope.component, requirements of the zope.event distribution would be automatically satisfied. This same method could be taken to build more functional distribution out of related packages we have today. These distributions might also be easier to market, document and explain. But they come with the downside of more buy-in per distribution. Figuring out how packages are actually used and which ones are used independently is no small task. Hanno ___ 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] Uses of the ZTK and how it relates to management
Hello, * 2010-03-04 09:22, Baiju M wrote: > I wonder whether we can split ztk.cfg & zopeapp.cfg further logically ? > Something like zca.cfg , index.cfg, form.cfg, auth.cfg etc. ? May be we > will end up with one cfg file for each package :) I don't think we need to split the cfg files: IMHO what we are looking for (or should be looking for) is not a technical solution, but something to solve a management issue. Having people responsible for a subset of packages does not involve any change in our technical infrastructure, maybe just a website where to store the documentation. Anyway, this is my "idea" of fragmentation of the ZTK into self-contained reusable groups of packages, you can like it or not like, it is just an idea. :) Best regards, Fabio ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 1:12 PM, Fabio Tranchitella wrote: > * 2010-03-03 21:44, Jim Fulton wrote: >> The ZTK was created in part to deal with instability issues arising from >> people working on parts without testing the whole. > > I suppose everybody here agrees that any change to a package which is part > of the ZTK *must* be tested against the whole ZTK. It would be easier to > nd leading developers for subgroups of packages (eg. bicycle repair kit, > rm generation, ...) willing to raise the quality of a specific subset of > packages instead of finding a release manager willing to oversee > 60 > packages, which he does not really use (because I don't think we have a > single developer using *all* of the packages in the ZTK). > > These specific leading developers could report and synchronize with a ZTK > release manager, though. I wonder whether we can split ztk.cfg & zopeapp.cfg further logically ? Something like zca.cfg , index.cfg, form.cfg, auth.cfg etc. ? May be we will end up with one cfg file for each package :) 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 )
