Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
[snip]
Sounds like the original vision of Zope 3 without the X. I thought we
never got around to developing this stuff the last time.
Actually, no. We originally said that we would provide a transition
path. I said over and over that this was *not* going to be backward
compatibility. I guess this was too complex a message. I think your
post proves that it was.
I know exactly what was said, and we, the Zope community, said it wrong,
including the backwards compatibility bit. I quote the release notes for
Zope X3.0:
"The "X" in the name stands for "experimental", since this release does
not try to provide any backward-compatibility to Zope 2."
What do you think that implied? Maybe you didn't say backwards
compatibility, but our release notes certainly said something about this.
This message wasn't new:
"""
1b. "Zope 3X" is the preliminary version of Zope 3. It is built from the
ground up, paying attention to the lessons learned from Zope 2 and CMF.
It is not a product but intended to let developers get familiar with the
new architecture early.
1c. "Zope 3" is the mainline release intended for production use and
including backwards compatibility to Zope 2.
"""
It was here:
http://cvs.zope.org/Zope3/doc/security/background.rst?rev=1.3
It is frustrating that there were worded this way. If was never
intended that we would promise backward compatibility. I certainly
tried to be clear that there would be a transition path, not backward
compatibility.
But perhaps we are splitting hairs...
I had a lot more to say in this posting which I recommend you read:
http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html
You seem to be calling "vaporware" on even a transition path, implying that
we shouldn't promise one. (BTW, "vaporware" is software that is described
as if it exists, but doesn't. I don't think that applies to anything we are
talking about here.)
I think that a transition plan for Zope 2 applications is critical
and something we should work toward.
I don't see how *saying* what Zope 5 will contain will make it
*exist* any time sooner.
You seem to be arguing against a roadmap, which is puzzling.
Obviously, predictions of the future are imperfect.
I'm not arguing against a vision.
You fooled me.
> I'm worried about marketing and what
we will be implicitly implying. I want to be very careful about roadmaps
as we can't guarantee they will happen,
Of course we can't.
> and broken promises in this will
be worse than no promises at all.
I understand this. I'm more worried about roadmaps that aren't
honest. That say we're working on something that we are not.
I think, for now, our vision should be sketched with what we have right
now (Zope 2 and Zope 3) and where we think they are going.
Exactly.
> Talk about it
names we already know, or if we really make new things, new names that
are not Zope for the time being.
We'll have to agree to disagree.
[snip]
The current story of Zope 2, Five and Zope 3 gets us in the right
direction (Zope 5, if you want to call it that, though I would
definitely want to introduce yet another name in the mix), step by
step. We don't promise too much to people. We don't raise the wrong
expecations anymore.
What expectations did we raise?
See my referenced mail:
http://mail.zope.org/pipermail/zope3-dev/2006-February/017939.html
I think it was right to raise expectations for a transition plan.
Also, as I understand Zope 3 better, I feel that bacward compatibility
*is* possible, at least to the extent that Zope 2 releases are backward
compatible today.
AFAIK, the official story is that Zope 3 will eventually replace
Zope 2 and that Zope 2 will be augmented with Zope 3 technology
to make the transition easier. I don't think there are many people,
if any, really working on making Zope 3 a credible replacement for
Zope 2. There are people working on making it into something
wonderful, but not a replacement for Zope 2. Do you agree that
this is the current story? If not, and if *we* cannot agree on
what the current story is, think how confused everyone else must
be.
I think that is indeed the current story.
Cool, we agree on something ...
> It's not complete:
I think it is also inaccurate, because I don't think people working
on Zope 3 are really working to replace the functionality in Zope 2.
In fact, most of the work on Zope 3 is not on Zope 3 itself, but on
integrating it into Zope 2.
Zope 3 technology is replacing Zope 2 today in that I can write a Zope
3-like application in Zope 2. In that sense, Zope 2.9 *is* the Zope 3
without X. Zope 3 technology is not only in Zope 2 for the transition,
but also because it's cool stuff we can actually use profitably now, not
only because we might be able to transition to Zope 3 more easily in
some future.
This is much closer to the new vision that I proposed than the
current vision.
I think part of this story is that the Zope 2 people will work on Zope
3-based technology to replace bits of Zope 2 step by step, bit by bit. I
believe this is happening in the context of Five, the Zope 2 core (the
event system), and the CMF. I think part of this story is also that Zope
2 is safe and is going to be around for a loooong time.
Yes
Emphasizing these bits of the story would be good, and I think we agree
on that. We need to be careful though we also are seen to stay the
course: introducing new version numbers and names of the mix is I think
right now the wrong action to take.
Again, we'll have to agree to disagree.
> It won't contain the
features you list unless someone actually does all that work.
That's right. Someone needs to do the work. Similarly, Zope 3
won't be a replacement for Zope 2 unless someone does the work.
What's your point? That we shouldn't plan? That we shouldn't
have a common vision for where we're going, or communicate that
vision?
These are rhetorical questions...
Actually, no.
My point is:
Have a vision, but plan step by step. Don't promote the presumed
endpoint of the steps too much yet.
You have to agree on what the endpoint is in order to decide what
the steps are.
> Evolve the message step by step too.
Change the message slowly, not all at once, to avoid creating confusion
and unrest. Don't change the message before we're ready. Introducing a
new message always carries a strong risk of being misunderstood.
I think constantly changing the message and worse, not agreeing on the
message is worse.
The alternative is to put Zope 5 in the nebulous future when all the
work you list is done, and it'll be just like our mythical "Zope 3
without the X" then - confusing people and raising the wrong
expectations.
The Zope 3 that provides support for transitioning from Zope 2
is "mythical" in the sense that it doesn't exist. It is something
that we've been working on. Are you going to call anything that
doesn't exist "mythical"? I don't see how that is useful or productive.
I call vaporware on the promise we made for years on that,
I think the intent to provide a transition was and is reasonable
and necessary.
> sure. I worry
about Zope 5 being vaporware too. We're not close enough yet.
As a community, I think we need a common vision of what we're working
toward. It appears that we have that today.
Sure. I think this thread made this explicit. Let's not stir the pot and
just work on this for a few Zope 2 and Zope 3 releases more. Maybe the
pot's ready for stirring after then.
I don't agree, but there's no point in arguing the point further. I would
just be repeating myself.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
