[Zope-dev] Re: RFC: The future of Products.Five

[Rocky Burt]

On Mon, 2006-30-10 at 00:01 +0100, Philipp von Weitershausen wrote:
> Proposal
> --------
> 
> So, what I'm proposing is to feature-freeze the Products.Five package 
> and just basically keep making it work for future Zope versions. Five 
> 1.6 (current trunk) will work for Zope 2.11 (current trunk), Five 1.7 
> for 2.12, etc. So, essentially there won't be Five feature releases in 
> between anymore, which means we can put Products.Five into the 
> Zope/lib/python/Products proper.

+1


> New stuff will be added in standard Python packages that may or may not 
> ship with Zope 2, Plone or whoever needs them. I personally almost don't 
> care, it's really only about defining the right egg dependencies in 
> Plone 3.0 or Zope 2.11, I would assume (see also 'Risks' below). This 
> seems like the release manager's job who would include stuff based on 
> requests from the community and package maintainer's recommendations.

+0  We're really not sure what the story here is yet... trying to sort
things out.


> The namespace for these packages should probably be 'five', as we 
> already have five.intid and five.customerize and we are, after all, the 
> Five project.

+1


> Advantages
> ----------
> 
> * We'll be able to use stuff we get for Python packages for free, such 
> as installation via eggs, Cheeseshop presence and much less majyck for 
> initialization.

terrific.


> * Stuff that we create as part of the Five project does not necessarily 
> have to end up in Zope 2. Currently, stuff added to Products.Five 
> eventually always ends up in some Zope 2 release which means we'll have 
> to maintain it forever, no matter how crappy it turns out to be (e.g. 
> Products.Five.site).

great.


> * Development of certain components can move much faster than even Five. 
> New things like five.intid or five.customerize can be experimented with 
> and already be in the right place if they turn out to be stable. If not, 
> they won't harm Products.Five, either. Individual packages rather than 
> one big one also reduces the amount of work that has to be done by the 
> Five release manager (IOW my work ;)).

great.


> Risks
> -----
> 
> * If five.* packages need ZCML config (and I know some will), they will 
> either have to be included the Zope 3 way (site.zcml or package-includes 
> slug in your instance's 'etc' directory), or we need to come up with an 
> approach that Zope 2 people are more comfortable with. I think an egg 
> entry point would be a compelling solution. There are plans to do this 
> in Zope 3 even so that you can provide configuration from Python instead 
> of ZCML. I expect this to land in Zope 3.4 which means we should be able 
> to take advantage of it in 2.11.

Interesting, but definitely needs more thought.


> * It is unclear to me at this point what Zope 2's egg story will be. I 
> *hope* that 2.11 will get the same egg story as the Zope 3.4 that ships 
> with it does, though noone has talked about eggifying Zope 2 yet. We 
> should probably do that.

Indeed.  Zope's eggification story needs to be straightened out.  We see
some of this with Jim's proposals for Zope 3.  I'm inclined to watch the
discussion for Zope 3 and hopefully see a good solution unfold (of
course I won't be afraid to share my opinion).  My suspicion is that
Zope 2's eggification story will be very similar (best case scenario:
identical) to Zope 3's eggification story.  So this is one place where I
say let Zope 3 work it out first :)


> Comments welcome :)

Well... constructive comments at least...

:)


Regards,
Rocky

-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20061029/27a32edf/attachment.bin