Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-10-03 Thread Charlie Clark
Am 03.10.2010, 13:58 Uhr, schrieb CMF Tests Summarizer  
cmf-te...@epy.co.at:

 Subject: FAILED (failures=3, errors=5) : CMF-trunk Zope-2.12  
 Python-2.6.5 : Linux
 From: CMF Tests
 Date: Sat Oct  2 21:56:16 EDT 2010
 URL: http://mail.zope.org/pipermail/cmf-tests/2010-October/013606.html

Mine, of course, but now fixed.

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-09-25 Thread Charlie Clark
Am 25.09.2010, 13:58 Uhr, schrieb CMF Tests Summarizer  
cmf-te...@epy.co.at:

 Subject: FAILED (errors=3) : CMF-trunk Zope-2.12 Python-2.6.5 : Linux
 From: CMF Tests
 Date: Fri Sep 24 21:54:46 EDT 2010
 URL: http://mail.zope.org/pipermail/cmf-tests/2010-September/013574.html

Relates to two changes I made yesterday which should now be resolved, at  
least I can't reproduce them here.

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-09-25 Thread Charlie Clark
Am 25.09.2010, 17:05 Uhr, schrieb Charlie Clark  
charlie.cl...@clark-consulting.eu:

 Relates to two changes I made yesterday which should now be resolved, at
 least I can't reproduce them here.

ah, yuppie fixed things for me. Thanks!

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-06-27 Thread Charlie Clark
Am 27.06.2010, 13:58 Uhr, schrieb CMF Tests Summarizer  
cmf-te...@epy.co.at:

 Subject: FAILED (failures=1) : CMF-trunk Zope-2.12 Python-2.6.5 : Linux
 From: CMF Tests
 Date: Sat Jun 26 21:52:14 EDT 2010
 URL: http://mail.zope.org/pipermail/cmf-tests/2010-June/013216.html

My fault - wrong permssion on @@logged_out.html

As with my other mails from yesterday this test was not failing locally.

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-04-01 Thread yuppie
Hi!


Tres Seaver wrote:
 I also don't know why the 'instance' and 'i18n*' parts are configured in
 these buildouts -- does somebody have a memory of why, or a reason to
 keep them?

I don't use the 'instance' part. For manual testing I prefer using 
mkzopeinstance.

The 'i18n*' parts provide an easy way to create .pot files for CMF.

Maybe we should not run those parts by default. Either by removing them 
from parts= of the [buildout] section or by moving them to a separate 
.cfg file.


Cheers,

 Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CMF Tests Summarizer wrote:

 Test failures
 -
 
 Subject: FAILED (errors=13) : CMF-trunk Zope-trunk Python-2.6.4 : Linux
 From: CMF Tests
 Date: Tue Mar 30 21:52:10 EDT 2010
 URL: http://mail.zope.org/pipermail/cmf-tests/2010-March/012790.html

I can't even get the trunk buildout to build this morning:  Hanno, do
you have any clue what is going on here?

 $ svn co svn+ssh://svn.zope.org/repos/main/CMF.buildout/trunk
 ...
 $ cd trunk
 $ /path/to/python2.6 bootstrap/bootstrap.py
 ...
 $ bin/buildout
 ...
 Installing test-zope212.
 Getting distribution for 'Zope2==2.12.3'.
 ...
 Got Zope2 2.12.3.
 Getting distribution for 'zope.app.schema'.
 Got zope.app.schema 3.5.0.
 Getting distribution for 'zope.app.publisher'.
 Got zope.app.publisher 3.8.3.
 The version, 3.7.1, is not consistent with the requirement, \
   'zope.sendmail3.7.0'.
 While:
   Installing test-zope212.
 Error: Bad version 3.7.1

The 'test-zope212' part uses the following section:

 [test-zope212]
 recipe = zc.recipe.testrunner
 index = http://download.zope.org/Zope2/index/2.12.3/
 eggs =
 Zope2 == 2.12.3
 ${buildout:eggs}
 defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']

Adding 'zope.sendmail3.7.0' to the eggs list doesn't help here.



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

iEYEARECAAYFAkuzZAkACgkQ+gerLs4ltQ7v2QCfQe0zU3OpBt6CUX2724APnrfP
YLIAnAzO6N4CYxsgFBr/w0kvIAxpp2Ma
=z80S
-END PGP SIGNATURE-

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tres Seaver wrote:
 Hanno Schlichting wrote:
 Hi Tres,
 
 On Wed, Mar 31, 2010 at 5:02 PM, Tres Seaver tsea...@palladion.com wrote:
 I can't even get the trunk buildout to build this morning:  Hanno, do
 you have any clue what is going on here?

  The version, 3.7.1, is not consistent with the requirement, \
   'zope.sendmail3.7.0'.
  While:
   Installing test-zope212.
  Error: Bad version 3.7.1
 I added lots of version pins for all unpinned packages to the
 buildout. I guess some of those loose ends suddenly became
 problematic. I'm not sure which one exactly caused this, though.
 
 This is a problem with trying to run both the Zope-trunk tests and the
 Zope-2.12 tests in the same buildout:  we should ideally be able to have
 *both* zope.sendmail versions in the 'eggs' directory, with the
 correct one for each testrunner configured somehow.  I don't think the
 testrunner recipe is clever enough for this usage, though.
 
 After my change the buildout runs at least. Judging from your commits,
 you are working on the test failures. I'll leave you to it for a while
 :) I was planning to look at them later today.
 
 I've squished them all, I think, running against the trunk.  There are
 still a bunch of errors / failures running under 2.12.3, though, which I
 can't figure out.

I believe the root of this problem is that the 'index' and 'versions'
bits of a buildout.cfg are effectively Highlanders (there can only be
one).  I gave up on trying to get the two, two, two Zopes in one
buildout to work, and instead created a separate buildout.cfg for
running CMF's tests against Zope 2.12.3.

Unless somebody objects violently, I plan to check the attached config
in on a branch of the main CMF buildout, and rip out the stuff which
tries to do both from the trunk version.  This change will require
Stefan's nightly runner to be adjusted, so I'm CC'ing him.


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

iEYEARECAAYFAkuzjjUACgkQ+gerLs4ltQ6cVACg1RC0QGs2TYfJTuKprgGIsox2
RAEAoJ8Qokke0sN2W+ir3lkT3z7ksNAS
=WlVc
-END PGP SIGNATURE-
# CMF trunk + Zope trunk

[buildout]
parts =
zopepy
test
eggs =
Zope2
Products.CMFCalendar
Products.CMFCore [test]
Products.CMFDefault
Products.CMFTopic
Products.CMFUid
Products.DCWorkflow
Products.GenericSetup
five.localsitemanager
develop =
src/Products.CMFCalendar
src/Products.CMFCore
src/Products.CMFDefault
src/Products.CMFTopic
src/Products.CMFUid
src/Products.DCWorkflow
src/Products.GenericSetup
src/five.localsitemanager
index = http://download.zope.org/Zope2/index/2.12.3

[versions]
# CMF-only dependencies
five.formlib = 1.0.2

[zopepy]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}
interpreter = zopepy
scripts = zopepy

[test]
recipe = zc.recipe.testrunner
eggs = ${buildout:eggs}
defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Hanno Schlichting
2010/3/31 Tres Seaver tsea...@palladion.com:
 I believe the root of this problem is that the 'index' and 'versions'
 bits of a buildout.cfg are effectively Highlanders (there can only be
 one).  I gave up on trying to get the two, two, two Zopes in one
 buildout to work, and instead created a separate buildout.cfg for
 running CMF's tests against Zope 2.12.3.

Yeah, that sounds sensible. The extra test part with an index was a
hack in the first place.

 Unless somebody objects violently, I plan to check the attached config
 in on a branch of the main CMF buildout, and rip out the stuff which
 tries to do both from the trunk version.  This change will require
 Stefan's nightly runner to be adjusted, so I'm CC'ing him.

Looks all good, except for this first line of comment, which should be
CMF trunk + Zope 2.12 :)

 # CMF trunk + Zope trunk

Personally I prefer versions.cfg files, so we could use an:

extends = http://download.zope.org/Zope2/index/2.12.3/versions.cfg

instead of the index = line. But I don't care much for this specific
test buildout.

 [buildout]
 parts =
    zopepy
    test
 eggs =
    Zope2
    Products.CMFCalendar
    Products.CMFCore [test]
    Products.CMFDefault
    Products.CMFTopic
    Products.CMFUid
    Products.DCWorkflow
    Products.GenericSetup
    five.localsitemanager
 develop =
    src/Products.CMFCalendar
    src/Products.CMFCore
    src/Products.CMFDefault
    src/Products.CMFTopic
    src/Products.CMFUid
    src/Products.DCWorkflow
    src/Products.GenericSetup
    src/five.localsitemanager
 index = http://download.zope.org/Zope2/index/2.12.3

 [versions]
 # CMF-only dependencies
 five.formlib = 1.0.2

 [zopepy]
 recipe = zc.recipe.egg
 eggs = ${buildout:eggs}
 interpreter = zopepy
 scripts = zopepy

 [test]
 recipe = zc.recipe.testrunner
 eggs = ${buildout:eggs}
 defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hanno Schlichting wrote:
 2010/3/31 Tres Seaver tsea...@palladion.com:
 I believe the root of this problem is that the 'index' and 'versions'
 bits of a buildout.cfg are effectively Highlanders (there can only be
 one).  I gave up on trying to get the two, two, two Zopes in one
 buildout to work, and instead created a separate buildout.cfg for
 running CMF's tests against Zope 2.12.3.
 
 Yeah, that sounds sensible. The extra test part with an index was a
 hack in the first place.
 
 Unless somebody objects violently, I plan to check the attached config
 in on a branch of the main CMF buildout, and rip out the stuff which
 tries to do both from the trunk version.  This change will require
 Stefan's nightly runner to be adjusted, so I'm CC'ing him.
 
 Looks all good, except for this first line of comment, which should be
 CMF trunk + Zope 2.12 :)
 
 # CMF trunk + Zope trunk
 
 Personally I prefer versions.cfg files, so we could use an:
 
 extends = http://download.zope.org/Zope2/index/2.12.3/versions.cfg
 
 instead of the index = line. But I don't care much for this specific
 test buildout.

OK, the change I'm planning on the trunk essentially reverts your last
commit (all the extra version pins to make the 'test-zope212' part
build), plus deleting the test-zope212 part (see attached patch).

BTW, I think the other test buildouts which do not run aganst the Zope2
trunk should probably also be adjusted to use released Zope 2.12.x eggs
as well:  we aren't co-developing the Zope 2.12 branch along with CMF
2.2 (any more, at least).

I also don't know why the 'instance' and 'i18n*' parts are configured in
these buildouts -- does somebody have a memory of why, or a reason to
keep them?



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

iEYEARECAAYFAkuzlXcACgkQ+gerLs4ltQ6GtgCePELI/PiWKI71CESkmn6ybLou
YFgAoJHrg5d2A4wTIsc1jeh8UjUqCqOD
=N8Fu
-END PGP SIGNATURE-
Index: buildout.cfg
===
--- buildout.cfg	(revision 110373)
+++ buildout.cfg	(working copy)
@@ -1,15 +1,12 @@
 # CMF trunk + Zope trunk
 
 [buildout]
-extensions = buildout.dumppickedversions
-
 extends = src/Zope2/versions.cfg
 parts =
 zope2
 instance
 zopepy
 test
-test-zope212
 i18n-cmfcalendar
 i18n-cmfdefault
 eggs =
@@ -34,39 +31,10 @@
 src/five.localsitemanager
 
 [versions]
-# Override of a Zope2 trunk version pin
-zope.sendmail = 3.5.1
-# CMF-only dependencies
 five.formlib = 1.0.2
-plone.recipe.zope2instance = 4.0a4
-z3c.recipe.i18n = 0.7.0
-zope.authentication = 3.7.0
-zope.cachedescriptors = 3.5.0
-zope.componentvocabulary = 1.0
-zope.copy = 3.5.0
-zope.copypastemove = 3.5.2
-zope.deprecation = 3.4.0
-zope.dublincore = 3.4.3
-zope.error = 3.6.0
+plone.recipe.zope2instance = 4.0a1
 zope.formlib = 3.10.0
-zope.hookable = 3.4.1
-zope.minmax = 1.1.1
-zope.password = 3.5.1
-zope.session = 3.9.2
-zope.app.applicationcontrol = 3.5.0
-zope.app.appsetup = 3.11
-zope.app.component = 3.8.3
-zope.app.container = 3.8.0
-zope.app.debug = 3.4.1
-zope.app.dependable = 3.4.0
 zope.app.form = 3.12.1
-zope.app.locales = 3.5.1
-zope.app.pagetemplate = 3.7.1
-zope.app.publication = 3.7.0
-zope.app.publisher = 3.8.3
-zope.app.schema = 3.5.0
-zope.app.testing = 3.6.2
-zLOG = 2.11.1
 
 [zope2]
 recipe = zc.recipe.egg
@@ -91,14 +59,6 @@
 eggs = ${buildout:eggs}
 defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']
 
-[test-zope212]
-recipe = zc.recipe.testrunner
-index = http://download.zope.org/Zope2/index/2.12.3/
-eggs =
-Zope2 == 2.12.3
-${buildout:eggs}
-defaults = ['--module', '^Products[.](CMF|DC|GenericSetup)|^five[.]']
-
 [i18n-cmfcalendar]
 recipe = z3c.recipe.i18n:i18n
 eggs =
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Hanno Schlichting
On Wed, Mar 31, 2010 at 8:33 PM, Tres Seaver tsea...@palladion.com wrote:
 OK, the change I'm planning on the trunk essentially reverts your last
 commit (all the extra version pins to make the 'test-zope212' part
 build), plus deleting the test-zope212 part (see attached patch).

Sure. That wasn't much more than a band-aid.

 BTW, I think the other test buildouts which do not run aganst the Zope2
 trunk should probably also be adjusted to use released Zope 2.12.x eggs
 as well:  we aren't co-developing the Zope 2.12 branch along with CMF
 2.2 (any more, at least).

Well, it is nice to catch problems introduced in Zope 2 on the day
after they are made. And not when someone tries to update the buildout
to a new version at some later point. The risk is much lower for
stable branches, but it still exists.

As seen from todays test failures, they nicely showed how I screwed
some things up a bit too much on Zope trunk :)

 I also don't know why the 'instance' and 'i18n*' parts are configured in
 these buildouts -- does somebody have a memory of why, or a reason to
 keep them?

Yvo has to comment this. I think he sometimes rebuilds the pot files
in CMF with the i18n part. Not sure about the instance.

Hanno
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Jens Vagelpohl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/31/10 20:33 , Tres Seaver wrote:
 I also don't know why the 'instance' and 'i18n*' parts are configured in
 these buildouts -- does somebody have a memory of why, or a reason to
 keep them?

The instance part is a pure convenience to quickly fire up an instance
if I need to look at something in the ZMI while doing development. If
there's no pressing reason to remove it I'd really like to keep it.

jens

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkuzpC8ACgkQRAx5nvEhZLIQqgCbBHzB46qtTkc+MUpK0Wu8OoOM
mM0Anjpp3i/yfLNEeLJoNmkq2R1KZ9Kp
=RF/w
-END PGP SIGNATURE-
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jens Vagelpohl wrote:
 On 3/31/10 20:33 , Tres Seaver wrote:
 I also don't know why the 'instance' and 'i18n*' parts are configured in
 these buildouts -- does somebody have a memory of why, or a reason to
 keep them?
 
 The instance part is a pure convenience to quickly fire up an instance
 if I need to look at something in the ZMI while doing development. If
 there's no pressing reason to remove it I'd really like to keep it.

I can see leaving that alone for the trunk-on-trunk buildout:  do you
need it for the buildouts used to test against other Zope versions?
The extra clutter and build time seems untidy to me.


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

iEYEARECAAYFAkuzq4QACgkQ+gerLs4ltQ5RjACgrtFddsSOiSc3Kam9sSRYt09V
J4QAoM6tUIpfiW5tsbWDGvaEy1c0Bevm
=IKyY
-END PGP SIGNATURE-

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Jens Vagelpohl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/31/10 22:07 , Tres Seaver wrote:
 Jens Vagelpohl wrote:
 On 3/31/10 20:33 , Tres Seaver wrote:
 I also don't know why the 'instance' and 'i18n*' parts are configured in
 these buildouts -- does somebody have a memory of why, or a reason to
 keep them?
 The instance part is a pure convenience to quickly fire up an instance
 if I need to look at something in the ZMI while doing development. If
 there's no pressing reason to remove it I'd really like to keep it.
 
 I can see leaving that alone for the trunk-on-trunk buildout:  do you
 need it for the buildouts used to test against other Zope versions?
 The extra clutter and build time seems untidy to me.

I'm surprised that you want to remove it. I use it for all buildout
combinations. How do you start an instance while doing work on CMF
proper? Or do you never need any ZMI access or test portal instances? Do
you manually create a separate buildout extending CMF.buildout? IMHO
that would be a needless obstancle as opposed to keeping the instance
part.

jens

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkuzsGoACgkQRAx5nvEhZLJSDQCfV6Gue1BBSzQwrj0qd41ecAJ3
1pkAoKzOzmnYUxX6D6h6HnvFYahnVm+6
=3lsZ
-END PGP SIGNATURE-
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed

2010-03-31 Thread Charlie Clark
Am 31.03.2010, 22:07 Uhr, schrieb Tres Seaver tsea...@palladion.com:

 The instance part is a pure convenience to quickly fire up an instance
 if I need to look at something in the ZMI while doing development. If
 there's no pressing reason to remove it I'd really like to keep it.
 I can see leaving that alone for the trunk-on-trunk buildout:  do you
 need it for the buildouts used to test against other Zope versions?
 The extra clutter and build time seems untidy to me.

Nice to see there is life on this list! :-D

If Jens is using it as I understand it, it's for when developing against  
trunk. This maybe less of an issue at the moment than it was while CMF 2.2  
was in development but still helpful. But, as you say, this is for  
trunk-on-trunk work.

Charlie
-- 
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests