[Zope3-dev] Re: [Zope-dev] Two visions

[Jim Fulton]

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