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
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
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
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
Well now I'm *completely* confused.
grin
- 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 terminology
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
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
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=40364r1=40360r2=40364
Do you know how it breaks Plone,
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?
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=40364r1=40360r2=40364
I'm in
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
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
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
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
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
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,
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
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
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
On Fri, 18 Nov 2005 05:49:46 -0800, Chris Withers
[EMAIL PROTECTED] wrote:
snip rant /
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
-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
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
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
25 matches
Mail list logo
