2010/6/20 Nathaniel McCallum <nathaniel(a)natemccallum.com>:
> 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