[Bug 631972] Review Request: plone3 - Plone CMS

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=631972

--- Comment #8 from Julien Anguenot <julien at enfoldsystems.com> 2010-09-09 19:27:24 EDT ---
Hey Robin,

(In reply to comment #1)
> * The package 'plone', though retired, has already been in Fedora. You should
> request for surviving that package instead of submitting the same package with
> a different name.
> 
> Refer to: https://admin.fedoraproject.org/pkgdb/acls/name/plone

The main difference with the package we submitted is that it does not use a
buildout based approach to bundle Python egg dependencies. Something worth
noticing is the fact that we were thinking of providing 2 RPMs for Plone:

 - plone-core: zope and plone core libs bundled as eggs using buildout (the one
we submitted)
 - plone-default: default buildout configuration depending on plone-core
   Here it would contain default policies such as the numbers of Zope clients /
ZEO or single client instance / object cache size, number of threads etc...

Advantage of this separation is that a custom application could be simply built
using a "standard" buildout and then be packaged as an RPM that would then
define plone-core as a dependency.  

On very important thing to notice is that if devels are not able to use
buildout to define their custom Plone application and then be able to generate
a RPM based on a buildout, in a *transparent* way, they will simply *not* use
any RPMs at all. I believe this is one if the key point here: the RPM
generation has to be transparent for developers and no involve any changes at
application level.

But yes, we could try to resubmit using the same name and try to survive that
package. The challenge will probably be around backward compatibility depending
on how that package had been implemented. 

Thank you for the pointer we will take a look.

> * You should submit the latest version of that package for review. The latest
> version of Plone is 4.0.
> 
> Refer to: http://pypi.python.org/pypi/Plone/

We are actually planning on doing it but at first we need the latest Plone3.x
stable release in the / a repository as we are sponsored on our side to
implement and maintain these packages.

> * If you are sponsored, you may help updating Plone for epel5, which needs
> Plone 3.
> 
> Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=497933

This is our actual primary target: RHEL5

Please note that we already have in place continuous integration taking care of
building RPMs automatically for different platforms in house. We will be glad
to offer infrastructure for others Zope based packages if needed. We are in the
process of migrating from buildbot to Hudson at the moment and we should be
done beginning of next week with public builders for the RPMs we submitted.

Again thank you for the pointer. We will take a look at it.

> * Will you join the Zope SIG? We are a little group trying to package all Zope
> programs, including Zope2, Plone, Grok, BlueBream, etc., for Fedora.
> 
> Refer to: https://fedoraproject.org/wiki/SIGs/Zope

Absolutely, how can I join?

I would be happy to answer questions and provide you more information.

Thank you.

  J.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.