[Zope3-dev] Zope.org - SteveVisitingFredericksburgSprint

[Martijn Faassen]

Jim Fulton wrote:
> Well, I disagree.  I am going to try to start the Zope 2.8 release cycle
> in January.  This depends on the MVCC work. As soon as that's done, we'll
> do a feature freeze for Zope 2.8.

[snip]

> >Maybe you can speed up Zope 2.x releases to be half a year again,
> >which would be impressive as Zope 2.8 and 2.9 are going to have 
> >large changes which will take a while to settle down. This still means 
> >that Zope 2.9 final is at least a year off. 2004 if we're being optimistic,
> >with customer deployments in 2005.
> 
> As I mentioned a few weeks ago, we are intentionally limiting the scope of
> Zope 2.8 so that we can have a shorter release cycle.

You'll certainly have me (pleasantly) surprised if 2.9 stable is out before 
the end of 2004. Since I don't feel I can count on this to happen, I'll
just continue with my project to use Z3 stuff in the Zope 2.7 
platform.

> >I want to be able to use parts of the component architecture (and 
> >later parts of ZCML) in Zope 2.7.
> 
> In fact, we (ZC) have been doing this for some time, even with Zope 2.6.

I know. This is existence proof that what I want is possible. :) But it's not 
helping anyone else, and we can't help you.

> > The first thing I need is interface-based
> >adapter lookup, and after that parts of the view system. I am not
> >prepared to wait a year.
> >
> >My timeframe of starting to use Zope 3 technology in Zope 2 is february,
> >2004. I want to deploy in mid 2004. I think this is possible, but
> >not with Zope 2.9, but with 2.7.
> >
> >I strongly urge a focus on trying to make Zope 3 functionality 
> >deployable and integratable into Zope 2.7 by installing the right Python
> >packages.   A focus on *not* modifying 2.7 and still offering Zope 3
> >functionality. Being able to modify Zope 2 to do this doesn't mean that
> >is actually the right solution for getting Zope 3 technology in the
> >hands of Zope 2 developers. 
> 
> I couldn't follow the last part of that paragraph.

You being able to change Zope 2 architecturally does not mean that this 
is the fastest way to get Zope 3 technology in the hands of Zope 2 
developers. I would argue that architectural changes of Zope 2 (Zope 2.9)
would cost more time and effort that is unnecessary if the goal is to
get some Zope 3 technologies into the hands of Zope 2 developers soon.
It's the more risky strategy.

Of course something like Zope 2.9 will have the opportunity to put more
Zope 3 technologies into the hands of end users than 2.7 + Z3 would, but 
I personally am not willing to put up with the increased risk and the
longer wait.

> It's too late to add new features to 2.7.

(mumble string exception geddon)

Exactly; a focus on *not* modifying 2.7. Take 2.7 as a base and move to
the best way to deploy things like the CA in it on a Python level.

[snip interfaces integration discussion]
> Ok, I've considered it. I think it's a bad idea.

:)

Okay, I'll see whether we will run into any problems then. It'd be easy
enough to switch over to whatever technology becomes available in 
2.8 or 2.9.

> I'm sorry, but it's just not that hard to change the path.
> 
> I'd be willing to consider including Z3 interfaces in 2.8 if people
> think that would be very desireable.  I expect Zope 2.8 to be released
> no later than February.

Well, if that happens of course I'm happy to switch over to using that,
though it may actually be easier to just keep on importing the new style
interfaces directly.

I'm just worried that the integration will flush out a lost of obscure
bugs if there's a mismatch between the two interface packages, but 
perhaps I'm overly worried here.

> >Jim, you have the power to change Zope 2 all around in order to support
> >Zope 3. That doesn't mean that this is actually the best approach to get
> >some Zope 3 technology in Zope 2 users' hands within a reasonable 
> >timeframe.
> >
> >I can't make it to this sprint, but if your solution is going to sit off
> >in some CVS branch somewhere for a year or more and isn't useful and
> >deployable in Zope 2.7 then I'll be forced to have to duplicate some
> >of your work, as I'll be focusing on my own strategy of making Zope 3 
> >technology work in Zope 2.7. I'd prefer working together with you instead.
> >
> >I'm sure what I'll come up with will be less powerful than what you
> >are planning for Zope 2.9 and be able to do far less with it. But the
> >gain is that customer deployments of Zope 2+3 technology could happen
> >at least half a year earlier..
> 
> We've been aboe to use Z3 in Z2 for some time. It's not that hard.  Perhaps
> we should write up our experiences with doing so.

That would indeed be extremely useful. It's a real shame that efforts are so 
disjoint in this department.

Regards,

Martijn