Florent Guillaume wrote:
I'd like to have some clarifications from the Plone team about what
they expect to do w.r.t. events in CMF 1.6.
I see two possibilities:
1. you guys are prepared to do the work needed for Plone products to
use super() in manage_afterAdd & co, in which case I can merg
Alec Mitchell wrote:
[..]
The big problem with this move is there's no way to give product developers
warning. They can't start using super now, because none of the base classes
use it, but once super is in place in the base classes developers will need
to start using it immediately or risk st
Florent Guillaume wrote:
I'd like to have some clarifications from the Plone team about what they
expect to do w.r.t. events in CMF 1.6.
I see two possibilities:
1. you guys are prepared to do the work needed for Plone products to use
super() in manage_afterAdd & co, in which case I can merge
Chris Withers wrote:
Alec Mitchell wrote:
to start using it immediately or risk strange breakages. Maintaining
product compatibility between versions of CMF/Plone will become nearly
impossible.
I'm sorry, I really couldn't resist this...
neither can I ...
And that differs from other P
On Fri, 18 Nov 2005 00:37:47 -0800, Chris Withers
<[EMAIL PROTECTED]> wrote:
Alec Mitchell wrote:
to start using it immediately or risk strange breakages. Maintaining
product compatibility between versions of CMF/Plone will become nearly
impossible.
I'm sorry, I really couldn't resist t
Alexander Limi wrote:
And that differs from other Plone releases how exactly? ;-)
And what, exactly, have you done to help Plone have less bugs?
*sigh* there's not a lot I can do, the problems with Plone are cultural.
There seems to be a pervasive culture of monkey patching and
bludegeon
On Fri, 18 Nov 2005 05:49:46 -0800, Chris Withers
<[EMAIL PROTECTED]> wrote:
Rant accepted, and understood. Still, you could try to help out instead of
*just* bitching. I am an expert bitcher myself, but at least I do
something about it. Thread closed? Feel free to follow up with me in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guys,
I'll ask that this end here on the zope-cmf list (well, Alex is entitled
to one public rebuttal, I guess). We need to focus the list's
discussion and attention on ways to improve the architecture, rather
than engaging in a "your code is crap" f
Cool, thanks for that work.
Florent
Rob Miller wrote:
okay, brent hendricks and i managed to put a few more hours into CMF 1.6
today. here's an update:
- ActionsTool import node now purges auto-created actions and correctly
reads in a CMF 1.5 syntax actions.xml file, creating old style acti
Rob Miller wrote:
the following is still to be accomplished:
- need to readd the PortalGenerator portal creation mechanism for
CMFDefault.Portal, for backwards compatibility
this is done. the unit test is still failing, however. for some
reason, in CMFDefault.tests.test_Portal.CMFSiteTests
Rob Miller wrote:
- i've removed the CMFTopic setup stuff from the default profile, but
have not yet replaced it with the extension profile in the CMFTopic
product; for this reason CMFTopic unit tests are broken
urgh... CMFTopic tests are passing as reported, but forgot to mention
that there
Rob Miller wrote:
- need to readd the PortalGenerator portal creation mechanism for
CMFDefault.Portal, for backwards compatibility
this is done. the unit test is still failing, however. for some
reason, in CMFDefault.tests.test_Portal.CMFSiteTests,
globals()["__warningregistry__"] doesn't s
Florent Guillaume wrote:
Rob Miller wrote:
- need to readd the PortalGenerator portal creation mechanism for
CMFDefault.Portal, for backwards compatibility
this is done. the unit test is still failing, however. for some
reason, in CMFDefault.tests.test_Portal.CMFSiteTests,
globals()["__wa
Hi,
The following checkin on the 1.6 branch, which looks like a pure cleanup
item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was
not the intention.
http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?
rev=40364&r1=40360&r2=40364
Do you know how it breaks Plone, e
Hi Jens!
Jens Vagelpohl wrote:
The following checkin on the 1.6 branch, which looks like a pure cleanup
item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was
not the intention.
http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?rev=40364&r1=40360&r2=40364
I'm in t
On 20 Dec 2005, at 19:53, yuppie wrote:
The intention was to make things consistent. CMF 1.5 and CMF 2.0
have different ways to register custom type info classes. Before
that change both machineries were broken on the 1.6 branch because
they were merged in an insane way.
I fixed the new m
Jens Vagelpohl wrote:
On 20 Dec 2005, at 19:53, yuppie wrote:
The intention was to make things consistent. CMF 1.5 and CMF 2.0 have
different ways to register custom type info classes. Before that
change both machineries were broken on the 1.6 branch because they
were merged in an insane
Hi Rob! Hi Jens!
Rob Miller wrote:
Jens Vagelpohl wrote:
On 20 Dec 2005, at 19:53, yuppie wrote:
The intention was to make things consistent. CMF 1.5 and CMF 2.0
have different ways to register custom type info classes. Before
that change both machineries were broken on the 1.6 branch be
On 20 Dec 2005, at 21:56, yuppie wrote:
yes, i believe the agreement was to try to keep 1.6 as close to
1.5 as possible, with the exception of GenericSetup. the types
stuff is the greyest area, however, because the changes in the way
TypeInfo objects are handled btn 1.5 and 2.0 has a consi
Hi!
Jens Vagelpohl wrote:
On 20 Dec 2005, at 21:56, yuppie wrote:
I really don't care much about how this is resolved. But from Rob's
checkins and the discussion following this mail
http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html
I had the impression that CMF 1.6 should p
On 20 Dec 2005, at 23:32, yuppie wrote:
After reading the thread you mention, which isn't all that clear
when it comes to outlining what the consequences of some of these
code changes are, I'm confused. I think I can boil it down to one
question: What is the use of the CMF 1.6 branch if it
Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6
branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF
1.6. This is like a stalemate. Can you suggest how to add a new kind of
factory information class similar to appending it to that typeClasses
struc
On Wed, 21 Dec 2005 00:32:02 +0100, yuppie
<[EMAIL PROTECTED]> wrote:
AFAICT the original target audience were people that want to switch to
Plone 2.2 and reuse Products written for 2.1.
Just a terminology correction here, the next version of Plone is 2.5, not
2.2 - we changed our version
Jens Vagelpohl wrote:
On 20 Dec 2005, at 23:32, yuppie wrote:
After reading the thread you mention, which isn't all that clear
when it comes to outlining what the consequences of some of these
code changes are, I'm confused. I think I can boil it down to one
question: What is the use of t
Jens Vagelpohl wrote:
[..]
Thanks a lot Florent, I assume Martin can go off and do his magic with
that description.
Just a note in passing to those of us that are more on the CMF-users
than developers side:
Starting to look into this myself I just wasted a couple of minutes
because of my outd
Well now I'm *completely* confused.
- Rocky
Alexander Limi wrote:
> On Wed, 21 Dec 2005 00:32:02 +0100, yuppie
> <[EMAIL PROTECTED]> wrote:
>
>> AFAICT the original target audience were people that want to switch
>> to Plone 2.2 and reuse Products written for 2.1.
>
>
> Just a terminolog
Raphael Ritz wrote:
> Looking at INSTALL.txt from the CMF-1.6 bundle I found
>
> Requirements
>
> - Zope 2.8.1 or later
> ...
>
> so I thought I'm on the safe side but digging deeper one
> actually sees in GenericSetup.DEPENDENCIES.txt:
>
> Zope >= 2.8.5
> Five >= 1.2
>
> So I got a Zo
Florent Guillaume wrote:
Jens Vagelpohl wrote:
Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF
1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2
against CMF 1.6. This is like a stalemate. Can you suggest how to add
a new kind of factory information class si
Rocky Burt wrote:
Raphael Ritz wrote:
Looking at INSTALL.txt from the CMF-1.6 bundle I found
Requirements
- Zope 2.8.1 or later
...
so I thought I'm on the safe side but digging deeper one
actually sees in GenericSetup.DEPENDENCIES.txt:
Zope >= 2.8.5
Five >= 1.2
So I got a Zope-2.8.5-
apologies in advance for not engaging this conversation as deeply as i'd
like to... i'm under the gun to get something done before leaving
tomorrow for a brief holiday, back on the 29th.
Jens Vagelpohl wrote:
I don't quite understand the distinction between "compatible with
products written f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jens Vagelpohl wrote:
>
> On 22 Dec 2005, at 03:10, Rob Miller wrote:
>
>> Jens Vagelpohl wrote:
>>
>>> I don't quite understand the distinction between "compatible with
>>> products written for Plone 2.1 but not with Plone 2.1", I can't see
>>>
Jens Vagelpohl wrote:
I think this brings up the need for a slightly more formalized planning
and release process. Given the requisite backing by at least the main
developers (meaning their agreement that they would actually use such a
thing) I'd like to set up a release plan page on zope.org
On Wed, 21 Dec 2005 13:29:09 +0100, Rocky Burt
<[EMAIL PROTECTED]> wrote:
Just a terminology correction here, the next version of Plone is 2.5,
not 2.2 - we changed our version policy a while back:
Well now I'm *completely* confused.
s/Plone 2.2/Plone 2.5/g
Better? ;)
--
__
On Thu, 22 Dec 2005 04:10:30 +0100, Rob Miller
<[EMAIL PROTECTED]> wrote:
it would be great if Plone 2.1.X could work w/ CMF 1.6, but it is not
absolutely necessary.
In general, we consider Plone tied to one particular CMF version (which is
also why we ship with a particular version of th
On 20 Dec 2005, at 13:10, Martin Aspeli wrote:
Hi,
The following checkin on the 1.6 branch, which looks like a pure
cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I
assume that was not the intention.
http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?
rev=40364&r1=4
On 21 Dec 2005, at 11:14, Florent Guillaume wrote:
Unless someone fixes that CMFDynamicsomethingFTI thing (or the
CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or
2.2 against CMF 1.6. This is like a stalemate. Can you suggest
how to add a new kind of factory information cla
On 21 Dec 2005, at 12:06, Raphael Ritz wrote:
Starting to look into this myself I just wasted a couple of minutes
because of my outdated setup (I had a plain Zope-2.8.4-final release)
Looking at INSTALL.txt from the CMF-1.6 bundle I found
Requirements
- Zope 2.8.1 or later
...
so I t
On 22 Dec 2005, at 03:10, Rob Miller wrote:
Jens Vagelpohl wrote:
I don't quite understand the distinction between "compatible with
products written for Plone 2.1 but not with Plone 2.1", I can't
see any sense in that route... it all comes back to one question:
What is the goal for the
On 22 Dec 2005, at 17:09, Martin Aspeli wrote:
Jens Vagelpohl wrote:
I think this brings up the need for a slightly more formalized
planning
and release process. Given the requisite backing by at least the
main
developers (meaning their agreement that they would actually use
such a
thi
Jens Vagelpohl wrote:
On 14 Nov 2005, at 22:28, Rob Miller wrote:
okay, i've created a CMF-1.6 branch that has branched everything from
CMF-1.5 with the exception of CMFSetup and GenericSetup, which are
svn:externals from the CMF trunk.
note that i've haven't actually started any backport
40 matches
Mail list logo
