Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Review Request: plone3 - Plone CMS
https://bugzilla.redhat.com/show_bug.cgi?id=631972
Summary: Review Request: plone3 - Plone CMS Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: nikolay@enfoldsystems.com QAContact: extras-qa@fedoraproject.org CC: notting@redhat.com, fedora-package-review@redhat.com Estimated Hours: 0.0 Classification: Fedora
Spec URL: https://svn.enfoldsystems.com/trac/public/export/4306/plone-rpm/plone/plone3... SRPM URL: https://svn.enfoldsystems.com/trac/public/export/4306/plone-rpm/plone/SRPMS/... Description: A powerful, flexible Content Management solution that is easy to install, use and extend Plone lets non-technical people create and maintain information using. only a web browser. Perfect for web sites or intranets, Plone offers. superior security without sacrificing extensibility or ease of use.
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
Nikolay Kim nikolay@enfoldsystems.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |177841(FE-NEEDSPONSOR)
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
Robin Lee robinlee.sysu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |robinlee.sysu@gmail.com
--- Comment #1 from Robin Lee robinlee.sysu@gmail.com 2010-09-08 21:08:31 EDT --- * 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
* 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/
* 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
* 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
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
Chen Lei supercyper1@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |supercyper1@gmail.com
--- Comment #2 from Chen Lei supercyper1@gmail.com 2010-09-09 00:13:19 EDT --- Packging plone is not an easy task, we still wait for the final release of zope 2.13 which is compatible with python 2.7.
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 #3 from Nikolay Kim nikolay@enfoldsystems.com 2010-09-09 11:33:31 EDT --- (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
i think Plone 3 should have separate rpm because in many cases exact version of plone is required. for most of our customers we are still using plone 3. also i don't think split zope and plone is a good idea, each plone version require exact zope version and python packages.
- 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 willing to make plone4 rpm as well.
- 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
i can rename plone3 rpm to plone. but in any case plone 4 should have different rpm name.
(In reply to comment #2)
Packging plone is not an easy task, we still wait for the final release of zope 2.13 which is compatible with python 2.7.
i don't think using zope rpm for plone is good idea.
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 #4 from Chen Lei supercyper1@gmail.com 2010-09-09 13:07:03 EDT --- Bundling several projects in one rpm is strictly forbidden by Fedora[1] and many other linux distributions like debian, gentoo. You should package every python egg seperately to match Fedora Packaging guideline.
The only python2 runtime for fedora 14 is python 2.7, you may have to package plone4 for fedora. Fedora also don't want to ship deprecated software is distributions[2]
[1]http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_proj... [2]http://fedoraproject.org/wiki/Objectives.
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 #5 from Nikolay Kim nikolay@enfoldsystems.com 2010-09-09 13:16:07 EDT --- (In reply to comment #4)
Bundling several projects in one rpm is strictly forbidden by Fedora[1] and many other linux distributions like debian, gentoo. You should package every python egg seperately to match Fedora Packaging guideline.
well, plone3 has at least 110 eggs and plone4 has at least 270 eggs do you think this is possible to pack each egg to separate rpm? and don't forget about different versions of plone has different eggs version requirements.
The only python2 runtime for fedora 14 is python 2.7, you may have to package plone4 for fedora. Fedora also don't want to ship deprecated software is distributions[2]
[1]http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_proj... [2]http://fedoraproject.org/wiki/Objectives.
i want make rpm for EPEL5
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 #6 from Chen Lei supercyper1@gmail.com 2010-09-09 13:31:08 EDT --- (In reply to comment #5)
(In reply to comment #4)
Bundling several projects in one rpm is strictly forbidden by Fedora[1] and many other linux distributions like debian, gentoo. You should package every python egg seperately to match Fedora Packaging guideline.
well, plone3 has at least 110 eggs and plone4 has at least 270 eggs do you think this is possible to pack each egg to separate rpm? and don't forget about different versions of plone has different eggs version requirements.
So we may need to write some scripts to help us to maintain so many eggs in fedora. Please note bundling many python eggs in one rpm is absolutely unacceptable by Fedora.
The only python2 runtime for fedora 14 is python 2.7, you may have to package plone4 for fedora. Fedora also don't want to ship deprecated software is distributions[2]
[1]http://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_proj... [2]http://fedoraproject.org/wiki/Objectives.
i want make rpm for EPEL5
No sure if one can make a EPEL5 only package which is also useful for Fedora. Normally all package should be built for Fedora rawhide first except some special packages(e.g. python26).
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
Julien Anguenot julien@enfoldsystems.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julien@enfoldsystems.com
--- Comment #7 from Julien Anguenot julien@enfoldsystems.com 2010-09-09 15:13:44 EDT --- Hey Chen,
We have been working together on these RHEL RPMs with Nikolay.
Packaging each Zope and Plone egg dependencies as RPMs doesn't make sense for us and we will not be interested in implementing, maintaining and deploying something like that for our customers.
We believe this is not the right approach. At least for the Zope and Plone dependencies. We could discuss the case of Python low level component dependencies for Zope and Plone though. (think lxml, twisted, zope.interface, etc...) and even here I would have some serious concerns: see below.
We believe the Zope and Plone application level Python component dependencies should be managed by buildout, only, without adding extra complexity at OS level:
http://pypi.python.org/pypi/zc.buildout/
Note, that not only our current RPM implementation supports buildout but it allows one to extend and define its own custom application, the buildout way, within another RPM, that would then be able to leverage the Plone base one in term of core Plone version dependencies but as well as framework to build the application and RPM (We have such examples of this already and are distributing customer's packages this way very successfully)
In fact, let's say one would install both Zenoss and Plone on the same server or a version of Plone3 and Plone4 (which is very common) : both application would be using different Zope, Python dependencies etc...
It would mean:
1. Impossibility to install several Python based applications. Say we have both a Plone3 and Plone4 instance using 2 different versions of the zope.component egg (that according to your suggestion should be packaged as an RPM) How would you deal with different RPMs of the same component at OS level in this case?
2. Assuming we can work around #1, we are talking about a lot of RPMs here. Say you have both Plone3 and Plone4 installed it means you would reach approximately 500 RPMs. (a significant percentage if the overall system's RPMs just for 2 Python applications)
Just to make sure we are talking about the same thing here:
Plone4 egg dependencies:
http://dist.plone.org/release/4.0/versions.cfg
Plone3 egg dependencies:
http://dist.plone.org/release/3.3.5/versions.cfg
Zope 2.12.10 egg dependencies:
http://download.zope.org/Zope2/index/2.12.7/versions.cfg
For instance, why would I maintain an RPM for 'plone.app.redirector egg' outside of the Plone one when this one only makes sense inside the Plone framework?
To sum up:
1. We don't believe it makes sense to package hundreds of application level eggs as RPMs
2. Having one RPM for Zope and having the Plone RPM defining it as a dependency would be something we could discuss (although, we think it doesn't add value but complexity for something not obviously beneficial.)
3. Please tell us if having an RPM for an egg is really compulsory. If so, then it will be a deal killer for us and we will not move forward with this on our side.
Let me know if you have any questions or if I am missing something obvious here.
Thank you.
J.
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@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.
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 #9 from Julien Anguenot julien@enfoldsystems.com 2010-09-24 14:51:40 EDT --- Hey,
I do not see any questions or feedback after my 2 previous comments. Does it mean there is no interest in discussing this on your side?
Let me know.
Thank you.
J.
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 #10 from Robin Lee robinlee.sysu@gmail.com 2010-09-25 01:19:10 EDT --- We welcome you to the python-devel mailing list[1] of Fedora, and let's talk there. We must come up to higher level of agreement, if we are deploying a packaging approach significantly different from other Python packages in Fedora.
I think we all have a wish to make Zope/Plone available in Fedora repository.
[1] https://admin.fedoraproject.org/mailman/listinfo/python-devel
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 #11 from Robin Lee robinlee.sysu@gmail.com 2010-09-25 04:06:10 EDT --- I would prefer to talk about Plone 4 at first.
I agree that it would be hard to maintain if we make a RPM for each application level eggs. But if we build an all-in-one RPM for Plone, and a user want to deploy a Zope configuration without Plone, then, shall we build another all-in-one RPM for Zope or tell him to install the all-in-one Plone instead?
So, all-in-one bundles may be not acceptable. At this time, I may suggest to separate that all-in-one RPM for Plone into several parts:
- ZTK Packages in the ZTK collection is packaged RPMs per egg.
- ZODB We have a RPM for the egg of ZODB3.
- Zope A bundled RPM contains the eggs of Zope2 and all its dependencies other than ZTK, ZODB and existing packages(like Paste).
- Plone A bundled RPM contains, you know, others.
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 #12 from Robin Lee robinlee.sysu@gmail.com 2010-09-25 04:18:21 EDT --- We should have some general principles:
- All the sources packages specified in Source*: lines should come from the actual upstreams other than third parties.
- We should not make duplications of existing packages.
- We should try our best to make all the RPMs parallelly installable.
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 #13 from Julien Anguenot julien@enfoldsystems.com 2010-10-12 08:43:49 EDT --- Hey Robin,
(In reply to comment #11)
I would prefer to talk about Plone 4 at first.
We can talk about Plone4 first. Please note that this is very critical for us to be able to move forward with Plone3 at the same time though.
I agree that it would be hard to maintain if we make a RPM for each application level eggs. But if we build an all-in-one RPM for Plone, and a user want to deploy a Zope configuration without Plone, then, shall we build another all-in-one RPM for Zope or tell him to install the all-in-one Plone instead?
You are right, we do not want to force a user to install a all-in-one Plone bundle and we believe having a ZTK, Zope, ZODB and Plone RPMs is reasonable.
So, all-in-one bundles may be not acceptable. At this time, I may suggest to separate that all-in-one RPM for Plone into several parts:
- ZTK
Packages in the ZTK collection is packaged RPMs per egg.
- ZODB
We have a RPM for the egg of ZODB3.
- Zope
A bundled RPM contains the eggs of Zope2 and all its dependencies other than ZTK, ZODB and existing packages(like Paste).
- Plone
A bundled RPM contains, you know, others.
We would be fine with this approach on our side for Plone4. For Plone3.3.5, the ZTK is out of the picture but the principle remains the same.
We can move forward and generate these RPMs and update the Plone3 RPMs to depends on these new ones as well as package Plone4. Let me know if you believe we should move forward with this on our side? As I said, we are committed to maintain these on the long term as this is critical for some of our customers.
Would you would like to continue this discussion on this ticket or on the actual python-devel mailing list?
Let me know please.
Thank you.
J.
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 #14 from Robin Lee robinlee.sysu@gmail.com 2010-10-12 09:43:45 EDT --- The python-devel mailing list is preferred. You should first make a post, otherwise I don't know whether you have been listening to the list.
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 #15 from Julien Anguenot julien@enfoldsystems.com 2010-10-12 13:53:36 EDT --- (In reply to comment #14)
The python-devel mailing list is preferred. You should first make a post, otherwise I don't know whether you have been listening to the list.
Will do Robin.
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
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard| |NotReady
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
Matthias Runge mrunge@matthias-runge.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrunge@matthias-runge.de
--- Comment #16 from Matthias Runge mrunge@matthias-runge.de 2012-02-27 09:27:21 EST --- is there any progress here?
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
Matthias Runge mrunge@matthias-runge.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status Whiteboard|NotReady |NotReady, StalledSubmitter
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
Matthias Runge mrunge@matthias-runge.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |INSUFFICIENT_DATA Last Closed| |2012-03-24 14:24:12
package-review@lists.fedoraproject.org