[Zope3-dev] Re: Zope 3 Roadmap thoughts

[THoffman@indtech.wa.gov.au]

HI Paul

I would say I STRONGLY agree with everything you have mentioned here.

Management of the transition and user/customer expectation is vitally
important.

Rgds

Tim Hoffman

On Wed, 2003-01-29 at 15:19, Paul Everitt wrote:
> Jim Fulton wrote:
> > Hi,
> > 
> > Here is an update on my thoughts with respect to the timeline for
> > Zope 3 releases:
> > 
> > For Zope 3x:
> > 
> >    - I'd like to release Zope 3x by September 1.
> > 
> >      This will be a production-quality release of Zope 3x.
> >      It will not be compatible with Zope 2 data or applications.
> > 
> >    - I'd like to release Zope 3x beta 1 by June 1.
> > 
> >    - I'd like to release alpha 3 by May 1.
> > 
> >    - I'd like to release alpha 2 by March 1.
> > 
> > For Zope 3.0:
> > 
> >    Note that Zope 3.0 will provide support for migrating
> >    Zope 2 data and applications to Zope 3. This will probably take the
> >    form of migration tools, rather than direct backward
> >    compatability.
> 
> Can you describe this more?  I'm not exactly sure the depth to which 
> Zope 3 can migrate applications.
> 
> For instance, in Rotterdam I found out that the syntax has changed for 
> getting parents in the request URL.  Will the migration machinery check 
> for things like that and convert it?  (Note, there are probably a lot of 
> little things like that used by people to build their sites.)
> 
> How about things like CMF and DTML?  For CMF, if I create three skins in 
> my site with various layers and whatnot, will there be the logical 
> equivalent to migrate it to?  For DTML, if it exists in Zope 3, I think 
> its syntax will change.  Will people be able to migrate their existing
DTML?
> 
> IMO, we need to set expectations on migration before we discuss shipping 
> a production-ready 3x.  The discussion could have the negative effect 
> that clients stop new Zope 2 deployments until they know what pain they 
> are signing themselves up for.  If you think they won't figure it out, 
> well, competitors in the RFP process will, and I doubt they will portray 
> it in a kind light.
> 
> I've been talking to Kai Wu, a former engineering manager at ArsDigita 
> who is now in the Zope community.  His lessons-learned on the transition 
> to ACS 4 might be informative:
> 
> """
> The ACS never gained major momentum largely because, I believe, there 
> were several major technology jumps (ACS 3, to ACS 4, then ACS Java, all 
> within 2 years) that made it difficult for users and customers to keep 
> pace and ultimately they lost trust in our management of the product. 
> Even though we felt we had to upgrade the ACS "plumbing," of course this 
> too-rapid rate of change entailed a host of other problems: missing 
> documentation, missing functionality, client and user wait-and-see 
> syndrome, and Faith That the Next Version Will Deliver Us (and users) 
>  From Evil that causes undue optimism on delivery dates - and 
> compromises on quality that come back to haunt you.
> 
> Zope2 and Plone let me do what I've always wanted with a web app 
> framework: deploy a community and content-driven site quickly that looks 
> great out of the box, with the knowledge that the technical engine 
> underneath is powerful and flexible. I would hate to see a crippling 
> loss of leadership and momentum around what already works and works 
> well, with room to grow further still. With such a skilled and involved 
> community, surely a way to continue wowing the world with 
> Zope2/CMF/Plone can be balanced with a smooth introduction and long-term 
> transition to Zope3.
> """
> 
> IMO, we should give some priority to investigate ways to manage the 
> transition.  And we need to communicate more about this, so business 
> people know what to expect, and feel comfortable using Zope 2, CMF, and 
> friends.
> 
> >    - I'd like to release Zope 3.0 alpha 1 by Dec 1
> > 
> >    - I'd like to release Zope 3.0 beta 1 by Feb 1, 2004
> > 
> >    - I'd like to release Zope 3.0 by Mar 1, 2004
> > 
> >    This schedule will depend on the level of community desire for
> >    and commitment to Zope 3.0.
> 
> Yep, well said!
> 
> > For Zope 2.0 and CMF releases:
> > 
> >    I expect Zope 2.0 and CMF releases to continue well into 2004.
> >    Zope 2.0 releases could extend farther if there is community
interest.
> 
> With 2.6.0 and 2.6.1 betas, we've had trouble getting the releases out 
> the door.  We're having trouble, it seems, just in talking about the 
> schedule.  Does Zope 2 have a BDFL?  If so, who is it, and will they be 
> more active "well into 2004"?
> 
> >    I expect, as part of the migration effort, to start migrating some 
> > Zope 3
> >    technologies into Zope 2.  I don't want this to slow Zope 3
development,
> >    so I don't expect much to be done on this until this summer.
> 
> On this point, I imagine I'm a contrarian on this list.  But I'm willing 
> to slow development of Zope 3 in support of smoothing the transition 
> through backporting and related activities.
> 
> IMO, business people (who think differently than zope3-dev folks) will 
> evaluate this whole Zope2-Zope3 situation using different criteria than 
> us.  I realize, though, that my opinion might be in the minority, so 
> I'll try not to continually harp about it. :^)
> 
> --Paul
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev



DISCLAIMER: This email, including any attachments, is intended only for use
by the addressee(s) and may contain confidential and/or personal information
and may also be the subject of legal privilege. Any personal information
contained in this email is not to be used or disclosed for any purpose other
than the purpose for which you have received it. If you are not the intended
recipient, you must not disclose or use the information contained in it. In
this case, please let me know by return email, delete the message
permanently from your system and destroy any copies. Emails and their
attachments may be interfered with, may contain computer viruses or other
defects and may not be successfully replicated on other systems. All
attachments are opened at the recipient's risk.