[ZWeb] Zope.org and New zope.org status

[Paul Everitt]

Sidnei da Silva wrote:
> | Another thing I'd recommend (in case this hasn't already been done) - 
> | NZO should stick with released software wherever possible, and avoid 
> | running on betas or even release candidates (and Plone is still at RC1 
> | status) and should definitely avoid running on CVS checkouts.  Meaning 
> | - if Plone is wanted, we should make sure that we test heavily against 
> | what's there and try to help them get to a bug-free 1.0 release (RC1 
> | has a couple of bugs that are easily fixable (and are fixed in CVS)).
> 
> Thats something that will not be easy to avoid. Of course we will
> stick with the known-to-be-stable released python and zope
> versions. (Well, actually we're running from the Zope-2_6-branch but I
> would consider that branch stable). OTOH, its impossible to get a
> stable and released CMFBackTalk. The same to CMFPackage, which was
> developed only for NZO. ZWiki is working very nicely on the latest
> release, but ZPT support isnt 100% there yet, and new fixes are added
> every day to the cvs version. We may need to discuss this a little more.

I think user management might also fall into that boat.  I know there 
have been some offline discussions about this.  I'm pretty sure we 
aren't using a zodb-based user folder.  I'm also pretty sure we're not 
using LDAP, like the existing NZO sandbox machinery that ChrisM busted 
his butt producing.

What's the plan for user management, and does this plan fit into the 
"released software" criteria?  I know some of the answer, but not all of 
the answer.

> | There also seems to be some decent update/customization tools for 
> | Plone.  The other thing that the NZO software should take into 
> | consideration is upgradability so that it doesn't get stuck on a 
> | heavily modified version of Zope 2.6.1 for years :).  Again, I'm sure 
> | this thought has crossed everyone's mind.  Plone and ZopeZen seem to 
> | have made some progress in this area offering Tools to aid in executing 
> | update / configuration scripts.
> 
> Yes, the MigrationTool its working very nicely on the last two
> releases. But sometimes its just a matter of testing it before putting
> in production. CZO's Data.fs started up very nicely on Zope2.6. (CZO
> is running Zope2.3) And everything seemed to work well, except for
> some dtml methods that were using variables starting with an

This is an important reminder to all of us.  Old *content* (e.g. 
Formatted Document) on czo that used DTML will not migrate, I think. 
There were some test run a year ago to find out how much member content 
would disappear, but I don't think it has been run in while.

Sidnei, does the migration script report rejections?

Point: expect turbulence.

> underscore. I dont know if someone did tried to put CZO on Zope2.6
> before, but it was a very smooth upgrade. So, if it was so easy, why
> no one did it? Sometimes its not just a matter of providing smooth
> upgrades, and, specially in this case, we need to ensure that the
> human resource will be available when needed.

You nailed it on the last point.  IMO, it shouldn't be attempted without 
blocked off, dedicated, assigned time from the ZC sysadmins.

However, it's a new year.  Shane advocated doing this last year, and you 
know have as much knowledge as anybody.

Breaking the single huge step into a number of smaller steps (move to 
the new boxes, upgrade to Python2.x and Zope 2.6.x, switch to ZPT, 
switch to CMF/Plone, etc.) might be more manageable.  But I think the 
schedule is set now, so this is probably a tangent.

--Paul