[Zope3-dev] Re: [Zope-dev] Two visions
Jim Fulton
jim at zope.com
Sun Mar 5 09:24:17 EST 2006
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:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Zope-Dev
mailing list