Re: To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/20/2010 12:22 AM, Jonathan Steffan wrote:
>  On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote:
> > The 'zope' package itself is most kept under the same conventions of the
> > legacy 2.10.x 'zope' package.
>
>  We have a unique opportunity to address many of the failings of the
>  current zope namespace. We should get anyone interested (and willing to
>  do the work) into a meeting soon. Every time I go back to building up
>  zope again I run out of steam and end up just being frustrated. I
>  foresee issues with splitting out every module in this stack but it just
>  needs to be discussed. The current package layout is far from optimal
>  and it's not the best idea to ship a default standalone instance with
>  the package. Shipping standalone/zeo instance configs/etc. in
>  subpackages is a far better idea. I've never been able to address this
>  as there is just about no upgrade path (that I've been able to design)
>  that would allow for a safe re-layout of the current package.
>
>  We should consider the current "zope" namespace dead and start from
>  scratch. It's far too complex of an application to be able to have
>  everything in one namespace (speaking to zope2 vs zope3.) I've only
>  briefly looked into all of the specs you've worked on and already can
>  see we are going to run into issues with cross-product dependencies. I
>  could be convinced that the "zope" namespace should be the latest 2.x
>  and then address the need for zope 3 in the zope3 namespace. However,
>  how do we distinguish a module built for zope 2 vs zope 3? This, again,
>  could be solved but will need discussion.
>
>  With zope 2.12 supporting py2.6, I think we might actually have a shot
>  at making this work. However, immediately off the bat if we stick 2.12.x
>  into "zope" what happens to grok? What packages are going to break? Too
>  many things need zope 2.x so updating the "zope" namespace to zope 3
>  would break a lot of good software. What happens to plone? Do we just
>  ditch Plone 3 and only support Plone 4?[2]
>
>  We could also modularize everything and have things like "zope",
>  "plone", "grok" and "zenoss" have dependencies based on
> their release
>  recipes. There are a lot of common modules in these projects, but they
>  all have their own specific version requirements. This would be a lot of
>  work and could potentially cause us to package ourselves into a corner
>  where we are having to do absolute requires or just end up with broken
>  software when absolute requirements are not properly documented.
>
>  I really look forward to others being involved with this. Count me in
>  for the SIG.[2]
>
>  - Jonathan Steffan
>
>  [1] http://plone.org/documentation/faq/plone-versions
>  [2] http://fedoraproject.org/wiki/SIGs/Zope 
I agree, we've got lots to talk about.  The most important things are:
1. Packaging guidelines
2. Component upgrade guidelines
3. Namespace issues (addressed above)
4. Zope 2 vs Zope 3 (again, addressed above)

I think we should talk sooner rather than later.  Anyone want to setup a 
meeting time?

Just an FYI, it is my current plan (probably because I am completely 
ignorant as to how much pain this will cause) is to simply package the 
latest version of all Zenoss dependencies and then work through whatever 
bugs I find.  I'm in a somewhat unique situation though in that I have 
the ability to commit to upstream.  This may be a less than ideal plan 
for other applications.

As I mentioned to Jonathan on IRC, I think the best plan is to try to 
get something working'ish as soon as possible and then try to shakedown 
the details from there.  If we bog ourselves down in policy (an easy 
quagmire to get stuck in when in zopeland) we may get too discouraged to 
continue.  Not to dismiss what will be the very needed policy, I just 
want to make sure no-one gets burned out.

One thing we may want to consider is a "tenant" policy.  That is, the 
zope stack as a whole has "tenants" (Zenoss, Plone, etc).  The tenants 
would be formally defined and any upgrade to any component in the 
platform would require signoff from all the tenants who depend on that 
component (or some derivation thereof).  I suspect that the short-term 
trade-off of buildouts/bundling is not as valuable as the long-term 
value of testing a software product across multiple versions of its 
dependencies.

Nathaniel

To construct a Zope skyscraper on Fedora

[Chen Lei]

>  I agree, we've got lots to talk about.  The most important things
> are:
>  1. Packaging guidelines
>  2. Component upgrade guidelines
>  3. Namespace issues (addressed above)
>  4. Zope 2 vs Zope 3 (again, addressed above)
>
>  I think we should talk sooner rather than later.  Anyone want to setup a
>  meeting time?
>
>  Just an FYI, it is my current plan (probably because I am completely
>  ignorant as to how much pain this will cause) is to simply package the
>  latest version of all Zenoss dependencies and then work through whatever
>  bugs I find.  I'm in a somewhat unique situation though in that I have
>  the ability to commit to upstream.  This may be a less than ideal plan
>  for other applications.
>
>  As I mentioned to Jonathan on IRC, I think the best plan is to try to
>  get something working'ish as soon as possible and then try to shakedown
>  the details from there.  If we bog ourselves down in policy (an easy
>  quagmire to get stuck in when in zopeland) we may get too discouraged to
>  continue.  Not to dismiss what will be the very needed policy, I just
>  want to make sure no-one gets burned out.
>
>  One thing we may want to consider is a "tenant" policy.  That is, the
>  zope stack as a whole has "tenants" (Zenoss, Plone, etc).  The tenants
>  would be formally defined and any upgrade to any component in the
>  platform would require signoff from all the tenants who depend on that
>  component (or some derivation thereof).  I suspect that the short-term
>  trade-off of buildouts/bundling is not as valuable as the long-term
>  value of testing a software product across multiple versions of its
>  dependencies.
>
>  Nathaniel
>  _______________________________________________ 
I suggest to stop of submitting package review for zope components
first before we complete the wiki page and treat all of the above
issues(mainly dependencies and namespace issue), we have a lot of time
to do so. F14 is targeting python2.7, we still need to wait this. Hope
most of those components can be compatible with python2.7.

FYI, zope2 can co-exist with zope3, but plone4 can't co-exist with
plone3(plone4 is an update for plone3).

We also need to set up a maillist like other SIG to talk zope-related issues.


Chen Lei

To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

On 06/20/2010 12:54 AM, Chen Lei wrote:
> > I agree, we've got lots to talk about.  The most important
> things are:
> > 1. Packaging guidelines
> > 2. Component upgrade guidelines
> > 3. Namespace issues (addressed above)
> > 4. Zope 2 vs Zope 3 (again, addressed above)
> >
> > I think we should talk sooner rather than later.  Anyone want to setup a
> > meeting time?
> >
> > Just an FYI, it is my current plan (probably because I am completely
> > ignorant as to how much pain this will cause) is to simply package the
> > latest version of all Zenoss dependencies and then work through whatever
> > bugs I find.  I'm in a somewhat unique situation though in that I have
> > the ability to commit to upstream.  This may be a less than ideal plan
> > for other applications.
> >
> > As I mentioned to Jonathan on IRC, I think the best plan is to try to
> > get something working'ish as soon as possible and then try to shakedown
> > the details from there.  If we bog ourselves down in policy (an easy
> > quagmire to get stuck in when in zopeland) we may get too discouraged to
> > continue.  Not to dismiss what will be the very needed policy, I just
> > want to make sure no-one gets burned out.
> >
> > One thing we may want to consider is a "tenant" policy.  That is, the
> > zope stack as a whole has "tenants" (Zenoss, Plone, etc).  The tenants
> > would be formally defined and any upgrade to any component in the
> > platform would require signoff from all the tenants who depend on that
> > component (or some derivation thereof).  I suspect that the short-term
> > trade-off of buildouts/bundling is not as valuable as the long-term
> > value of testing a software product across multiple versions of its
> > dependencies.
> >
> > Nathaniel
> > _______________________________________________
>
>  I suggest to stop of submitting package review for zope components
>  first before we complete the wiki page and treat all of the above
>  issues(mainly dependencies and namespace issue), we have a lot of time
>  to do so. F14 is targeting python2.7, we still need to wait this. Hope
>  most of those components can be compatible with python2.7.
>
>  FYI, zope2 can co-exist with zope3, but plone4 can't co-exist with
>  plone3(plone4 is an update for plone3).
>
>  We also need to set up a maillist like other SIG to talk zope-related issues. 
I have not submitted any zope packages for review, currently they are 
living in my own git repo.  When I say "get something working" I mean in 
a separate repo.  Once we have something working and with good standards 
learned from actual practice, we can figure out a merge strategy.

I do suspect someone is going to have to port zope2 to python 2.7.  In 
fact, I think we should focus on those packages using CPython right now 
and make sure they work on 2.6 and 2.7.  Pure python is a bit easier.

Who can setup a Zope SIG mailing list?

Nathaniel

To construct a Zope skyscraper on Fedora

[Chen Lei]

2010/6/20 Nathaniel McCallum <nathaniel(a)natemccallum.com&gt;:
> > We have a unique opportunity to address many of the failings of
> the
> > current zope namespace. We should get anyone interested (and willing to
> > do the work) into a meeting >
>  I think we should talk sooner rather than later.  Anyone want to setup a
>  meeting time?
>
>  Just an FYI, it is my current plan (probably because I am completely
>  ignorant as to how much pain this will cause) is to simply package the
>  latest version of all Zenoss dependencies and then work through whatever
>  bugs I find.  I'm in a somewhat unique situation though in that I have
>  the ability to commit to upstream.  This may be a less than ideal plan
>  for other applications.
>
>  As I mentioned to Jonathan on IRC, I think the best plan is to try to
>  get something working'ish as soon as possible and then try to shakedown
>  the details from there.  If we bog ourselves down in policy (an easy
>  quagmire to get stuck in when in zopeland) we may get too discouraged to
>  continue.  Not to dismiss what will be the very needed policy, I just
>  want to make sure no-one gets burned out.
>
>  One thing we may want to consider is a "tenant" policy.  That is, the
>  zope stack as a whole has "tenants" (Zenoss, Plone, etc).  The tenants
>  would be formally defined and any upgrade to any component in the
>  platform would require signoff from all the tenants who depend on that
>  component (or some derivation thereof).  I suspect that the short-term
>  trade-off of buildouts/bundling is not as valuable as the long-term
>  value of testing a software product across multiple versions of its
>  dependencies.
>
>  Nathaniel
>  
I still suggest to do enough investigation first for two reason:

1.Packaging the whole zope stack is a heavy workload( we need some
tools to simply our works)
2.Currently. no linux distributions include zope yet.

I think we need to set up a third party repo first like texlive 2010
before finally determined to submit those components for package
review.


Chen Lei