Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy ele...@umich.edu wrote: Feel free to respond over email or just edit the document: http://dev.plone.org/plone/wiki/PlipProcess Great work! In general, I'd like to give the fixed release schedule a 6 month test drive. If it sucks we can go back to status quo or move forward with the latest and greatest. I cannot remember any Plone releases that only took 6 months - even when we tried hard. I'd usually expect a 50% overrun from any stated timeline, so while aiming for 6 months we can manage to do a release after 9 months. We'd have to aim for a 3-4 months cycle to actually be able to do two releases in a year. And I wouldn't really want to do more than two releases per year, or we risk getting too fragmented, diverging code bases and very short support lifecycles for each release (only the last 4.x release gets bugfixes at any given time according to our current policy). I think we could aim for a spring and an autumn release, expecting most people to be busy in summer vacations and around x-mas/new year. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Hi. Thanks for pushing out those thoughts to the mailing list. I'm not much on IRC lately, so I likely missed a lot of the discussions leading up to this. On Fri, Jan 14, 2011 at 10:24 PM, Elizabeth Leddy ele...@umich.edu wrote: In general, let's move away from the fixed timeline of announcing, gathering, reviewing plips and towards a continuous integration of new features. I very much like this. I think our deadline approach doesn't work out that well for us. It currently seems that no deadline we set is actually taking seriously and we happen to postpone the real ones for months afterwards. So I'm not all too motivated anymore to actually do things for a fake deadline anymore. It currently looks to me like we aren't able to ship the actual finished work for 4.1, because we are waiting and waiting for some work that isn't quite ready yet. I'd rather have earlier, faster and smaller releases for the 4.x series again. The minor feature releases ideally should be more time based than feature based. For the major releases like 4.0 and 5.0 we need to handle them differently, as certain types of features can only land in them for backwards compatibility concerns. Having a feature almost ready and then postponing it to the next major release means not shipping it for two to three years. That's a lot different from not shipping some small feature for another minor release and six months. Your notes on the actual process sound good to me in general, I trust the FWT to organize themselves ;) Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Alec's review of PLIP 10877: Separate Products.CMFPlone from the Plone egg and its optional dependencies
On Mon, Sep 13, 2010 at 8:28 PM, Laurence Rowe l...@lrowe.co.uk wrote: This is because Plone requires PIL but does not specify it as a dependency. Dependencies only work for setuptools compatible distributions, which the standard PIL currently isn't. Therefor you cannot just pull it in as an egg dependency. Anyone doing this relies on having first installed a repackaged PIL distribution into their site-packages or having it in their egg cache. There's other issues with it, like having to have lots of C libraries installed and having to have a C compiler as well. I'm hopeful that this can change in the future - I got a positive response to http://mail.python.org/pipermail/image-sig/2010-August/006480.html by private email. It's really good to hear you got a positive response on this. I assume the response was from Fredrik Lundh? Given the frequency of PIL releases we'll get this in a PIL 1.1.8 in 2011 or 2012 I'd guess ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Zope 2.13 PLIP ready for review
On Mon, Sep 13, 2010 at 9:58 AM, Raphael Ritz r.r...@biologie.hu-berlin.de wrote: Just clarifying: this means we have code that runs on 2.6 but breaks on 2.7. I'm not sure if we have code in the core that breaks in a hard way. I'm aware of issues in some recipes like iw.recipe.template, collective.recipe.hudson, collective.recipe.solrinstance that all break with Python 2.7. I know we had to do some minor fixes in all of ZODB, ZTK and Zope2 to fix small issues. Therefor my general impression is that we'll need some time to test the support in practice and real projects to figure out if any popular add-ons are affected as well. There is also one major issue to figure out around testing. In Python 2.7 deprecation warnings are silenced by default. We agreed in the Zope community that this is ok for production code, but we'd like to enable the warnings in tests by default, as you'll otherwise never notice them. We haven't actually implemented that behavior yet, though. This has also lead to most of the ZTK having passing tests under Python 2.7 but actually emit tons of deprecation warnings once you enable them - for example all self.fail* methods in tests got deprecated in favor of their self.assert* spelling to just name one. Before we can claim real proper Python 2.7 support we need to make sure our own stack runs without deprecation warnings. @Hanno: any gut feeling already how many issues/idioms we are looking at? Should we start collecting those and let people know how to become future proof? (or do have that anywhere already and I simply missed it?) Apart from the deprecation warning business I'm not aware of any other major issues. But you can only reasonably make code compatible with Python 2.7 once you have moved it to Python 2.6 without emitting any warnings. Going straight from Python 2.4 to 2.7 is going to be a bit painful as you'll loose all the helpful deprecation messages and just get straight exceptions on some issues. Once Plone 4.1 is released we stop providing bug fixes for the Plone 3.x line. At that point I'd expect many add-on maintainers to be ok with supporting only Plone 4 and requiring Python 2.6. Once that has happened it should be much easier to move forward to Python 2.7 support. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Zope 2.13 PLIP ready for review
Hi. The Zope 2.13 PLIP (https://dev.plone.org/plone/ticket/10776) is ready for review. There's a PLIP buildout at https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10776-zope213.cfg including notes to use it via a local.cfg. There's also an accompanying text file with some comments about the current status in the same folder (plip10776-zope213.txt). I'd welcome a timely review, so I can either fix any upcoming suggestions or merge this in early. Thanks, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
On Sun, Sep 5, 2010 at 5:46 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2010-9-5 17:29, Hanno Schlichting wrote: PluggableAuthService -- There's tons of code based on this. I imagine we can first move the authentication API's into a WSGI middleware querying PAS as the backend. This sounds like the mistake repoze.who 1 made. It turns out that for almost every use case you want more control over handling login behaviour than WSGI middleware can provide. It is much simpler to have a simple API to an AAA service and use that than to try pushing this into middleware. Right, I'm aware of the repoze.who lessons. Authorization is always going to be a WSGI framework component (endware) and not an isolated middleware. But there should be some subpart of the API, which allows you to share the same authorization information across multiple WSGI applications. Or deal with some of the external authorization handling, when you offload things to Apache or other SSO approaches. But I'm not familiar enough with this topic to know what exact subpart this is. It might come down to just the userid. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meeting Minutes - Aug. 24, 2010
On Tue, Aug 24, 2010 at 9:57 PM, David Glick davidgl...@groundwire.org wrote: - Scheduling - Final PLIP submission deadline is next Friday, Aug. 30 - Six week PLIP implementation period beginning on the submission deadline and ending Sept. 11 - Would like to start reviewing sooner where possible. - PLIP authors should let the FWT know as soon as their PLIPs are ready for review. Could someone make sure to announce this schedule a bit more openly and to the wider community? At least I have currently no idea if any of my PLIP's are really accepted, when I should create a proper plip buildout config file and submit it for review or how much time I have afterwards to adjust things to any feedback I get. I have one PLIP I'm only going to get started at, once I got an ok on the general idea (the controlpanel / z3c.form stuff). It would be good to know when I should start doing any work on that ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4.1 Framework Team Meetin g Minutes– 17 August, 2010
Hi. On Thu, Aug 19, 2010 at 4:08 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 19 August 2010 09:52, Alec Mitchell ap...@columbia.edu wrote: Though I voted against the inclusion of the UUID PLIP on it's own, if the link-by-uuid PLIP makes good use of it, then it certainly could be worth including. I'd like to work with David to make sure that happens. It seems like an obvious win. Please be aware that the link-by-uid functionality is multi-lingual aware. As such it relies on looking up the translations of any UID target. If you change the behavior to use a different uid mechanism, it becomes more expensive to calculate those translations, as we'd have to convert from AT UID's to uuid's a number of times. I'd prefer if we kept all reference / link related functionality to use the AT functionality for now. Once we have plone.uuid as part of core Plone, I'm planning to rewrite LinguaPlone to make use of this instead of the AT uid's. At that point we can more easily switch features over to the new mechanism. So far as I was hoping to see the plone.uuid feature to make it into 4.1, which would give me enough time to finish the LinguaPlone move for 4.2. I can only work on this if we do get plone.uuid into 4.1 though. Requiring the complete uuid installation as part of a LinguaPlone upgrade is too much to ask from users. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] z3c.form PLIP?
On Mon, Aug 9, 2010 at 12:45 PM, Laurence Rowe l...@lrowe.co.uk wrote: On 9 August 2010 01:52, Martin Aspeli optilude+li...@gmail.com wrote: I can own this, although I'm not quite sure what a PLIP should look like? The actual work is in rewriting the control panel forms. The only thing the PLIP would say is ship with p.a.z3cform + dependencies as a dependency of PLIP 10359. We already have: Include z3c.form - https://dev.plone.org/plone/ticket/9473 Thanks, I was referring to that one and the points it lists. I think the code for this one is basically done. But it needs a code review, needs a review from the UI team on usability of the widgets and the generated markup. There's also translation and documentation to be updated. Someone knowing the code needs to act as a contact person for these things. I would also love to see someone bring some stability into the plone.z3cform and plone.app.z3cform packages and release proper 1.0 releases. All the last minor have been backwards incompatible with changes in the form wrapping approach (plone.app.discussion has been one victim of this, always having to pin versions to one exact combination at a time). We cannot do that any longer when these things are part of Plone. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] z3c.form PLIP?
Hi. My controlpanel PLIP 10359 (http://dev.plone.org/plone/ticket/10359) depends on someone else doing the base work of getting z3c.form into 4.1. There's a PLIP at http://dev.plone.org/plone/ticket/9473 for this, but currently nobody stepped forward to actually own it for 4.1. Are there any volunteers? Otherwise I'll have to withdraw my own PLIP. I'm not familiar enough with z3c.form and its Plone integration layers to own this base part. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Using plone.testing / plone.app.testing in Plone 4.1
Hi. On Sun, Aug 1, 2010 at 4:50 PM, Martin Aspeli optilude+li...@gmail.com wrote: When writing them, I wanted to use the new plone.testing / plone.app.testing packages. [...] So, we can either: 1) Stay with the status quo, and hope that plone.testing/plone.app.testing become the standard for Plone 5. In the meantime, people can use it in non-core packages only. 2) Use them as test dependencies, and let people choose how to set up their own tests 3) Write a separate PLIP for the inclusion of these two packages into our KGS (but not for the porting of all existing PTC tests, since that'd be a pretty big task) I would go for option three. Formally this should still be a PLIP, as it is introducing new dependencies. I think another pair of eyes during a framework team review wouldn't hurt the codebase either. But I'd be happy to see the PLIP limited to adding the two packages to 4.1 and allowing people to use it. Converting existing tests can be outside of the scope. For non-trivial projects based on Plone 4, I already have to resort to collective.testcaselayer which snuck in without a dedicated review in 4.0. It's just plain impossible to get a test setup working with pure PloneTestCase once you have a more complicated setup. We have an open meta-bug from Wichert on this issue, where he also noted a plethora of changes and problems with PloneTestCase. So I think we need to move forward and adopt the new kid and fix any issues we run into. PloneTestCase is just not usable anymore and we need to offer a good testing story. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Two PLIP's for 4.1
Hi. While the deadline is still a good bit away, I'd already like to submit two PLIP's for 4.1. Update to Zope 2.13 (http://dev.plone.org/plone/ticket/10776) and Convert control panels to use z3c.form (http://dev.plone.org/plone/ticket/10359) Looking forward for your feedback :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone-developers] Upcoming Plone 4.0 releases
On Thu, May 27, 2010 at 10:03 AM, Raphael Ritz raphael.r...@incf.org wrote: The only other concern I recall is the potential breakage of backup routines. If someone just rsyncs/copies Data.fs via cron (or the like) it will miss the binary data after the upgrade. We are migrating the types to use blobs in any case. So any new images or files he adds are going to go into blobstorage and would be missed. This is only about existing content. People have to change to a completely new zeoserver recipe, which creates a blobstorage by default. So the risk of having no blobstorage and getting an error is fairly low. Maybe there can be better documentation in the upgrade guide for the backup related changes, but those are needed in all cases. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone-developers] Upcoming Plone 4.0 releases
On Wed, May 26, 2010 at 8:22 PM, Andreas Zeidler a...@zitc.de wrote: i haven't looked at the changeset itself ((In [36715]) Add upgrade step to convert all files and images to blobs.), but it sounds like the automatic blob-migration we didn't want to enforce. existing file and image content should remain untouched and migration to blobs optional. cheers, Why wouldn't we want to migrate content by default? If we don't do it by default, only a few will figure out how to do it and people loose the major advantage that blobs give them. I haven't been involved in the PLIP discussions around this as much, but I thought this was a clear case of something that just wasn't done yet. If you have a specialized need, you can opt-out of this upgrade step by using the portal_setup upgrades screen and omitting this one step. But the default should be to migrate people. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone-developers] Upcoming Plone 4.0 releases
On Sun, May 23, 2010 at 4:09 PM, Hanno Schlichting ha...@hannosch.eu wrote:
#10365 / #10366 - @@blob-file-migration fails on migrated site
#10549 - Uncaught NotFound exception in plone.app.linkintegrity when page
contains some @@{view} links
I fixed both of these today - but they are in desperate need of
testing on real world data sets :)
Gah, bad quoting. I fixed #10365 / #10366. David fixed #10549.
Hanno
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Improving the process -- PLIP UI and Documentation
On Sat, May 22, 2010 at 5:09 AM, Martin Aspeli optilude+li...@gmail.com wrote: 2010/5/22 Eric Steele ems...@psu.edu: FWT! I want to introduce two additions to the PLIP process that I'd like us to add into the Plone 4.1 process. +1 to both +1 as well Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Improving the process -- PLIP UI and Documentation
On Sat, May 22, 2010 at 11:48 PM, Alex Clark acl...@aclark.net wrote: how about documenting and publishing the FWT process? (E.g. Something like http://admin.plone.org/) I've heard rumblings that Hanno was going to do this… I started this, it's ongoing work, but currently getting 4.0 to final has higher priority for me. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Upcoming Plone 4.0 releases
On Fri, May 14, 2010 at 4:00 AM, Eric Steele ems...@psu.edu wrote: So here's where we stand, from my viewpoint... 1) Plone 4.0 is feeling like a nearly-finished product (Great job, everyone!) Indeed, much kudos to our tireless release manager! 2) Everyone is getting sick of working on it Right, we all want to work *with it* now :) In the interim, I'd like to drop a beta 4 next Wednesday (19 May). This one isn't going to be substantially different from b3, but I think we have enough changes in there to make it worthwhile. I'll make a new Zope 2.12.6 release in time. The ZODB 3.9.5 upgrade required some changes to anything creating ZEO instances (the script was moved to an external package) and I've updated all our buildout recipes now. I'll be spending time over the next few days digging through our remaining tickets to consider what gets pushed off until 4.x and what should rightly be considered a blocker. Looking at Trac and from my memory, I'd consider these things to be blockers for a release candidate: #10360 - Incomplete migration: site_properties and portal_controlpanel #10124 - should remove Large Plone Folder type and expose the folder ordering setting in the schema #10365 / #10366 - @@blob-file-migration fails on migrated site These are all migration related. I'd hate to see any large new upgrade steps being introduced during the release candidates. From what I can tell the blob issue is a real blocker, as we currently don't upgrade existing content to blobs during the upgrade. But the upgrade to 4.0 final is exactly the one time where people expect to spent time on such a large and long taking issue. If we don't do this upgrade automatically most people will never run it and miss out on one of the biggest improvements we have. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Documenting the process
2010/4/26 Israel Saeta Pérez dukeb...@gmail.com: Any progress here? It would be very, very helpful for GSoC... :) Not much. I started by copying over the bits from various sources into one place, so all we had written down somewhere is now at http://dev.plone.org/plone/wiki/Development. The core developer manual from plone.org is gone as well. The next step is to reorganize the information into one structure and then update it. I'll continue to work on that :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Zope 2 is alive
Hi there, for those not following the zope-dev mailing list, see https://mail.zope.org/pipermail/zope-dev/2010-March/039880.html I've taken it on me to serve as Zope 2.12's and 2.13's release manager. I'm planning to make a new Zope 2.12.4 release on Easter monday in time for our next 4.0 beta. Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Documenting the process
Hi. 2010/3/24 Israel Saeta Pérez dukeb...@gmail.com: http://plone.org/documentation/manual/plone-core-developer-reference is the place for this kind of documentation. I'd prefer to keep all documentation in the same place instead of spreading it over plone.org and the Trac wiki. I talked briefly to Eric and Israel about this. I'll start working on this over the weekend / next week and we'll move everything into the Trac wiki to have all development of Plone information in one place. Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 5 - rough roadmap
On Wed, Mar 24, 2010 at 5:58 PM, Jon Stahl jonst...@gmail.com wrote: On Wed, Mar 24, 2010 at 2:38 AM, Martin Aspeli optilude+li...@gmail.com wrote: If someone has a really great name, I'd consider it, but I think the ship may've sailed. Renaming now is likely to cause a lot of confusion. How about something very simple like Theme Builder? (collective.themebuilder). Short, says what it does, sounds approachable. We can pretty easily refer to it as Theme Builder (formerly XDV) for a little while. I'd suggest that it keeps a name that has nothing to do with the Plone (or collective) brand. The technology isn't Plone specific, which is one of its selling points. A Plone integration package like the current collective.xdv can have a Plone specific name, though. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On Mon, Mar 22, 2010 at 1:32 AM, Martin Aspeli optilude+li...@gmail.com wrote: David Glick wrote: So I guess it's not clear to me that there is one best practice, or at least not one that is best in all circumstances. To me at least, the idea that we pick an arbitrary context (the Plone site root) and then write a one-off adapter from that to some schema interface that happens to represent the fields we want (the schema is almost always form-specific, since we want to control fields, ordering, fieldset grouping etc), register it in the CA (even though it's going to be used only for the form) and then let the form framework look it up on a field-by-field basis seems entirely like CA abuse. It's also quite difficult to understand if you're reading the code. Ok, so there doesn't seem to be one obvious way to do it :( Once I get to actually coding this, I'll try both approaches and make an arbitrary decision based on what looks better ;-) Thanks for the input, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Documenting the process
On Tue, Mar 23, 2010 at 2:37 AM, Eric Steele ems...@psu.edu wrote: I'm finding that I'm consistently wrong about how I think whole Plone thing works. Every assumption I had coming into this job has been met with some sort of No, we have a process. It's just not documented. Let's fix that. Yeah! The process has changed over time and has been documented as part of mailing list discussion, IRC meetings and real life meetings, like the Strategic Planning Summit or the framework team meeting at the Plone conference in Washington D.C. The only two websites I can find that have any information are: http://dev.plone.org/plone/wiki/FrameworkTeam http://plone.org/documentation/manual/plone-core-developer-reference/overview/release-process Both of which contain some valuable and some outdated information. The information should probably be linked from: http://dev.plone.org/plone/wiki/Development I'm looking for some help in actually writing down the process of how a major release of Plone comes together. Rough list of necessary parts would be: * Choosing a FWT * Choosing a release manager * The role of the FWT * The role of the Release Manager * PLIP review process * By what standards is a PLIP judged? * By what standards is a PLIP implementation judged? * Creating the release Suggestions for missing sections? Anyone willing to help me write this? I can help. There's a good deal of our processes that emerge naturally or that are driven by interested and influential community members, like for example the whole general major roadmap planning. But it'll probably help to make it clear where mysterious things happen and where we have formalized processes that are actually followed. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On Sun, Mar 21, 2010 at 2:26 PM, Martin Aspeli optilude+li...@gmail.com wrote: I suggest we use the dict context (implement getContent() and return a dict) instead of all those adapters to get/set values as we do presently. Ok. I'll have a look at that. Those adapters only exist, as the context of the form is the plone site root, but the settings come from many different places. Some of the forms redefine self.context, some of them use some property helpers to deal with portal_properties and value conversions. So there needs to be some form of intermediate layer in between, but I don't care what it is. Also, use trunk of z3c.form, plone.z3cform and plone.app.z3cform for the time being - important cleanups have happened. That's what I thought. This PLIP is dependent on someone owning the general z3c.form / Plone integration PLIP (http://dev.plone.org/plone/ticket/9473) - I hope someone will be up to that task :) I can at least help, though I'll need to see closer to the actual deadline where I can own it. Ah, you didn't fall for the obvious trap ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
On Sun, Mar 21, 2010 at 8:15 PM, David Glick davidgl...@groundwire.org wrote: On 3/21/10 7:40 AM, Hanno Schlichting wrote: On Sun, Mar 21, 2010 at 2:26 PM, Martin Aspeli optilude+li...@gmail.com wrote: I suggest we use the dict context (implement getContent() and return a dict) instead of all those adapters to get/set values as we do presently. Ok. I'll have a look at that. Those adapters only exist, as the context of the form is the plone site root, but the settings come from many different places. Some of the forms redefine self.context, some of them use some property helpers to deal with portal_properties and value conversions. So there needs to be some form of intermediate layer in between, but I don't care what it is. -1 on this, which feels like change just for change's sake -- unless it's really clear it makes the code more readable. Is that a -1 on Martin's dict context / getContent() suggestion? I'd like to have those forms be good examples of using z3c.form, so I'd like to use whatever is considered to be best practice. The use-case is having standalone forms which pull their data from a different place. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 10359 for Plone 4.1 - Convert control panels to use z3c.form
Hi there, I've written a new PLIP that I'll hope to submit for Plone 4.1 Convert control panels to use z3c.form available at http://dev.plone.org/plone/ticket/10359. I'll start the work on the PLIP shortly, so if anyone sees any major problems with it or has other suggestions, I'd welcome any early feedback. This PLIP is dependent on someone owning the general z3c.form / Plone integration PLIP (http://dev.plone.org/plone/ticket/9473) - I hope someone will be up to that task :) Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Tue, Mar 16, 2010 at 12:45 PM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. We'll discuss the pros/cons of switching once we get a full PLIP for this in time for Plone 5 in a year or so from now. From what I can tell today, we'll still need to support IE 7+ at that point, which puts clear limits on what we can do. I can see us using a lot of the new input elements which degrade nicely in older browsers for example. But switching the doctype won't be anything our default theme can do. Everyone is free to build a new theme himself experimenting with HTML5, but I don't see that as part of the core. Our default will have to be conservative, aiming for maximum compatibility. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Mon, Mar 15, 2010 at 10:13 AM, Alexander Limi l...@plone.org wrote: We could also take a page from how Firefox is looking to change their release management strategy, ie. landing stuff that has only infrastructural impact in a 4.x release (out-of-process plugins in FF's example, which will land in the 3.6 series, for Plone 4.x, it could be something like WSGI). I think we can introduce some technologies already in 4.x releases, but make them opt-in. For example shipping Chameleon but disabling it by default. We will only get WSGI with a new Zope 2 release, which will bring a number of other changes with it, among those another basket full of updated Zope Toolkit packages. It's yet too early to say what these changes will be. Maybe we can upgrade to Zope 2.13, but that depends a lot on how Zope 2 maintenance and development will proceed and how the ZTK will play out. One thing to be aware of, is that in contrast to Firefox nobody uses a bare-bone Plone, but we are highly dependent on our add-ons. And that's not just two dozen most often used ones. We have therefor been careful not to break any add-ons during a major release cycle. Unfortunately all our major framework level changes have a tendency to just do that. Of course, that's what we're already doing, but pushing the less risky parts that were previously considered only for Plone 5 might be a good approach, and reduce risk. Landing too much at once in Plone 5 is definitely a real risk, as is a too-long release cycle for Plone 5. So evaluating each of the things we land in Plone 5 for possible inclusion in a future 4.x release is probably a good tactic. Sure. We can split some of these up. But I don't think we can include either Deco/Blocks, xdv or Dexterity as a whole into any 4.x release. Changing the default story for any of those areas is too much a change. That's why I like them to follow Dexterity's lead and push down parts of them into 4.x releases. Stuff that makes their life outside the core easier. And both Deco/Blocks and xdv still have to prove themselves in real production projects outside the core. Dexterity has yet to work out its evolution story for Archetypes based add-ons and content. I'd love to see a shorter release cycle for Plone 5, but as usual, it's hard to determine, and I don't think the currently suggested estimates are unreasonable. Oh yeah, my schedule is realistic, but not inspiring or visionary in any way ;) I think an increased focus on Tech Preview releases (ie. what alpha used to mean :P ) could provide useful checkpoints for people to rally around when it comes to development. We shouldn't underestimate the power of self-imposed deadlines, I think it was used well in the Plone 4 release cycle, and even if Plone 5 is a release with a longer release cycle, we should try to do several checkpoints along the way to avoid landing too much at once, and get stuff out there for people to test in carefully managed projects, similar to what Jarn and others have been doing for Plone 4. I had some idea about doing some more longer running agile process initially for my Plone release. But it turned out that this doesn't work with any of our processes or how volunteers can pledge their time. We are going to have one PLIP review cycle for Plone 5.0. Once that process starts, we have a couple of months to go, until we hit a feature freeze and some more weeks or months until we have fixed all the bugs. But that means that any major PLIP needs to be ready before we start the PLIP process. Another thing I learned from all my experimental changes, is that we can only merge things to trunk, once they are really finished or some of the more unstable changes can bring the entire release to a halt. So if we want to ensure that some of those big changes make it into Plone 5, the only variable we have, is to start the PLIP process at an appropriate time. Once that process starts, it's going to be all time based and we'll release whatever is ready by the end of the PLIP process. So my timeline tries to give those major changes a chance of making it into Plone 5. But that means we aren't going to work on the official Plone 5 release at all for the next 12 months. There won't be any code for the official Plone 5 for a long time. All interesting work will have to be made in add-ons outside the core. And the process for that work needs to be driven by interested people on their own terms. Just my take on this, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Mon, Mar 15, 2010 at 4:58 PM, Nate Aune na...@jazkarta.com wrote: On Fri, Mar 12, 2010 at 11:07 AM, Hanno Schlichting ha...@hannosch.eu wrote: - ... tons of new or better features What about Amberjack for self-guided tours/help? http://dev.plone.org/plone/ticket/9324 The entire list is at http://dev.plone.org/plone/report/24. I didn't feel like repeating all 26 items, but subsumed lots of them in my ... line. Is that still on the roadmap for landing in Plone 4.1? At some point there will be a new PLIP deadline for 4.1. If someone champions the PLIP, makes sure it gets implemented and has a plan to ensure the help texts will get continuous updates in the future ... then it will get into 4.1. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Beta 1 is (essentially) out! FWT, your job is done.
On Fri, Mar 12, 2010 at 11:14 AM, Laurence Rowe l...@lrowe.co.uk wrote: What happened in the 3.x series, I thought the 3.0 team stayed on. No. One member of the team stayed on from the 3.0 team for the 3.1 team. The 3.1 team then stayed the same for the 3.2 and 3.3 releases. The main idea here was that the x.0 release requires a huge time investment and we don't want to stretch the same persons too much. We've also had some drop-outs from overworked members late in the process, so we cannot just take the existing team. For the official process, the secret society of emeritus framework team members would now put out a call for new applications for the 4.1 team. This same group will then select the new team. As a formality the new framework team would then confirm the release manager or suggest a new one to the Foundation Board. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 5 - rough roadmap
Hi there, with Plone 4 beta 1 out the door and the 4.0 framework team having done its job, it's time to look ahead into the future a bit. Eric has started the discussion around Plone 4.1 already, I'll let him drive that process :) But I had a look at the PLIP's we have seen and feature discussion we had in the past. Currently listed for Plone 4.x are things like: - Include plone.app.registry - Include z3c.form - Improved commenting infrastructure - Improving the event type with recurrence, etc. - New roles : Webmaster/site administrator and novice users - Unified interface for lists of content - New collections UI - Well formed, valid XHTML (as a foundation for easier theming via xdv) - ... tons of new or better features I think there's lots of good stuff in there. I think with Plone 4.0 as a new technical basis we need some time to make Plone the product better again. Image and media handling, better usability, better support for common tasks, more content lifecycle management, ... there's a lot we can and should do here. Figuring out what exactly should be part of Plone Core won't be easy, but I have a feeling our feature set is lacking behind the competition in various ways now. On the future side we have: - Chameleon - Deco / Blocks - Dexterity - WSGI - xdv as the default theming story - deprecate portal_skins - ... I don't want to go into the details of any one of those, but my general feeling is that none of these are anywhere ready to be shipped as part of Plone Core. My current idea would therefor be to aim for a Plone 5.0 release roughly 18 to 24 months after Plone 4.0 final is released. We could aim for 18 months if we only do a 4.1 release, but I assume we are going to do a 4.2 release as well (both taking about 9 months from experience). At that point 24 months is more realistic. That means these technologies and projects will need to evolve outside the core for some time. I'd hope they could bring up some PLIP's for 4.1 and 4.2 which will make their life easier - much like Dexterity has already done with CMF 2.2 and Plone 4.0. Sometimes these might just be events, interfaces and some more adapters to make things independent of Archetypes. Does this kind of roadmap has general agreement? Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: On 12 March 2010 15:07, Hanno Schlichting ha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) Just to note that xdv uses the HTMLParser which is really very tolerant of badly formed markup (an earlier problem with the Nginx implementation running plone.org is now fixed). The output is wellformed and forced into the xhtml namespace, though no validation is performed. The only downside to the HTMLParser is that inline elements in other namespace (e.g. esi, svg) are not allowed in the content or template, though they may be included in the rules. That's really good to hear. Though I think semantic HTML or sensible ids/classes to identify elements in pages is what I had in mind with this point. Well besides the valid XHTML which is a requirement for Chameleon as well. Denys did a heroic job at this already for Plone 4.0. But I expect there's much more to do and especially many more add-ons to fix. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Beta 1 is (essentially) out! FWT, your job is done.
On Tue, Mar 9, 2010 at 3:50 AM, Eric Steele ems...@psu.edu wrote: I've just finished getting the last bits of 4.0b1 to wherever they need to be. I'll give it another 24 hours of soft-release before handing it over to the installers folks to make sure everything is there. If I understand this whole Plone process correctly (and I'm not at all sure I do), this means it's the end of the line for the 4.0 Framework Team. I want to thank all of you; you've done an amazing job. You took what was supposed to be a very boring release and turned it into something that everyone is excited about. We gave you heavy workloads and horrible deadlines and and you came through. Well done, all! Thank you Eric for managing the impossible! Thank you Alec, Calvin, David, Erik, Laurence, Matthew, Raphael and Ross for being an outstanding framework team! Thank you all guest reviewers, thank you PLIP authors and implementers, thank you community at large! There's so many people involved in this, it's amazing. Totally excited about Plone 4, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Body class
On Sun, Jan 17, 2010 at 9:19 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2010-1-17 16:52, Hanno Schlichting wrote: mark_view have_portlets hide_columns renderBase bodyClass is_view_template or whatever it is that manages IViewView. We've found it to be very painful to manage IViewView now. In particular it appears to be impossible to set when you render a template from a browser view. mark_view actually sets the IViewView interface. The main_template does: view nocall:view | nocall: plone_view; dummy python: plone_view.mark_view(view); which you should be able to do in any template that doesn't use main_template. Otherwise it should work just fine to add implements(IViewView) to your browser view class. But maybe I'm missing what exactly you want to do. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Body class
On Sun, Jan 17, 2010 at 9:38 PM, Wichert Akkerman wich...@wiggy.net wrote: class MyView(BrowserView): def __call__(self): return aq_inner(self.context).some_template() and make sure that IViewView is set when some_template is rendered. Currently that is impossible since mark_view does checks that are impossible to influence from the outside, and there is nothing MyView could set IViewView on itself. Right. I have to admit that I don't fully understand IViewView. It currently suggests that for any published url, there's one view representing this url and it can be marked as the view of an object. But our pages are composed of many views, with skins there aren't any underlying views, though we somehow try to treat the ploneview as a surrogate. Once you turn main_template into a browser page it becomes even less clear what the view object is. And as you noticed it's impossible to get to that one mysterious view from somewhere in the layout stack. The only things you can access from all places are context and request. I think we might want to add a marker to the request instead or in addition to the current approach, similar to how disable editable border and hide columns work. I had a similar use-case recently, where I needed to make some of the content menus conditional on whether or not you are on the folder contents page. In the end I had to go down to something like alsoProvides(request, IContentsPage) and check that in code in the menus. The view just isn't accessible anywhere outside the one template it is driving. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 - holidays are over :)
On Wed, Jan 6, 2010 at 1:52 PM, Laurence Rowe l...@lrowe.co.uk wrote: 2010/1/6 Alex Clark acl...@aclark.net: So are they the same or not? If so, then we can stop feeling like idiots for missing 'bin/instance console' and continuing to use runzope ;-) I'm getting the impression 'bin/instance console' is just a convenience. In the end both of them prepare an OS environment and execute Zope2/Startup/run.py. The main difference is that bin/instance is easier to type and is a Python script. sh parts/instance/runzope is a Unix shell script, so it's not available on all platforms. And in the zope2instance version used for Plone 4 runzope does no longer exist. Since plone.recipe.zope2instance puts the egg paths in the instance zope.conf, parts/instance/bin/runzope should be equivalent I think. Not quite. The recipe used to construct a Python path and put it into runzope ;-) But luckily we don't have to do that anymore, as buildout takes care of all that script generation stuff and constructing the right sys.path for us. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 4 - holidays are over :)
Heya. Some of us have been busy over the holiday season and worked a bit more on Plone 4. The next question now is: What is missing for a beta release? I'll allow myself to give my opinion on that. Eric feel free to disagree, it's your call :) In general I think Plone 4 is in good overall shape. But there's some blockers and critical issues noted in the bug tracker, which we need to address. I cleaned up Trac, so the 4.0 milestone only has tickets which are new to Plone 4.0 and should *all* be resolved before a release candidate. But here's the list of things that we need to tackle, before we can label a release beta in my opinion: Unified folders #9912, #9791 This comes down to: What to do with the Large Plone Folder during upgrades. To actually unify folders, we need to migrate all existing large folders to the new unified type. From what I understand that type should have an option in its schema, that allows to turn on/off the orderability. When migrating large folders, orderability should be turned off. Currently the large folders are left as is and we don't have such an option in the schema. TinyMCE vs. Kupu #9945, #9783, #9877, #9949, #9956, #9976, #9637, #9958 Overall we always have many issues with our visual editor. Kupu is far from being problem-free, so we cannot expect TinyMCE to suddenly be all perfect. So I wouldn't call all of the listed tickets critical. But one really critical problems is, that TinyMCE doesn't work well enough in Safari/Chrome to give it to normal users. The proposed solution is to install both Kupu and TinyMCE by default and force Kupu for all Safari/Chrome users. Kupu has such a browser detection logic, as it also didn't work with Safari for a long time. It did a fallback on a plain textarea, but we can do better today having two editors with different browser coverage. Sunburst (or themes in general) There's quite a number of open tickets in the Templates/CSS component. For some parts of the UI, there's currently no styling information. While we can fix some of those during the beta cycle, I think we should fix everything that requires changes to main_template or needs new viewlet managers and the like before a beta release. Noteworthy are #9278, #9995 and #8805 (don't ship with NuPlone anymore). JS dialogs #9805, #9806, #9921, #9693, #9957, #9964, #9977 All of these essentially mean that an operation done in a pop-up doesn't redirect and reload a new page. So any kind of feedback (positive, reconfirmation and failures) is lost. The other problem is that the original page (shown in the background of the dialog) might show information that is changing as a result of the dialog action. For example publishing an object in a dialog, needs to refresh the page, as its workflow state needs to be reflected, the item might now show up in the navigation tree, a calendar or any other type of portlet. It's a bit sad to see these problems, as we have already encountered all of them, when first applying AJAX/KSS in the early Plone 3 stages. We ended up reverting to a non-AJAX UI for most things, as almost all of our UI actions can have arbitrary effects. I'm afraid that we need to re-evaluate all actions that use the new dialogs and discuss them. We haven't had a PLIP review of the individual dialogs. I think we have missed to pass on the hard earned knowledge learned from the early Plone 3.0 days, but luckily it's not too late. User / Group handling #9789, #9966, #5548, #9743, #9898, #9777, #9710, #9732, #9955, #9960, #9742, #9748 There's a ton of problems with the various new user and groups templates and related password handling functionality. If we want to claim that we improved anything in this regard (as our PLIP's claim) we need to fix this stuff. Not all of this needs to be fixed before a beta, but we need to get some good progress on these or they'll never be done. Otherwise we have some issues related to the installers. I just refactored a large part of the zope2instance recipe, which might have broken things in the installers. I didn't test the new changes on Windows yet, so the current recipe trunk quite definitely some issues. I'll fix these during this week. Finally there is one open PLIP (https://dev.plone.org/plone/ticket/9314) about the Developer Pack for the installers. I have no idea what the status on this one is. Personally I disagree with some of the choices mentioned in the PLIP (like shipping the unmaintained Clouseau, using eggtractor where buildout covers the same use-case today, turning on debug-mode in zope.conf, which should only be done via bin/instance fg vs. bin/instance console). It would be good to get an idea what the current status of this is and how it is implemented. Looking at this there's still a ton to do. I'll leave it to Eric to figure out whom to encourage to get these things done ;-) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org
[Framework-Team] Re: Plone 4 - holidays are over :)
A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. Eh, how do you guys start an instance without the forced debug mode of fg? You don't use start for that, do you? Since when have we had that? Since we use buildout or to be more precise, April 2008. Let me quote the PyPi page: 1.8 (2008-04-05) Added console command to the instance script, which is equivalent to fg but does not implicitly turn on debug mode but respects the zope.conf setting. [hannosch] One month later we changed it not to fork a process internally, so this is what we've been using for supervisord configurations for years. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIPs and plone.pot
On Sun, Sep 20, 2009 at 11:00 PM, Steve McMahon st...@dcn.org wrote: It looks like I'd need to branch collective/PloneTranslations, then branch plone.app.locales in order to make the externals point to the new collective/PloneTranslations branch. But, I don't see a sign that anyone's ever done it that way before. So, I suspect I'm on the wrong track That would be the only technical way to make a branch indeed. Anybody got a handle on the right way to add to the .pot for a PLIP? The right way is not to care about updating the pot files before PLIP's are merged. All messages are extracted automatically anyways and should only be exposed to the translators once the corresponding PLIP is approved and merged. You can run the i18ndude extract on your branches and see if they pick up all messages correctly - just don't commit it. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Minutes: 8 August 2009
On Wed, Aug 5, 2009 at 10:00 PM, Erik Rosepsuc...@grinchcentral.com wrote: * All the globalization in templates is gone now, and Plone's templates have been updated to not use it. This originated in the 5.x branch as a speed optimization, but does it deliver? It's going to break a lot of products. MatthewWilkes will talk to Hanno about this and see if it really did help performance. The FWT is concerned about breaking every product if it turns our we're just replacing one very slow thing with many less-slow things. This change is not only and maybe not even primarily a speed optimization. When running performance tests against current Plone 4 for typical full-fledged pages like a document view, edit screens or folder contents views, there is hardly any performance difference between Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate performance gain for those kind of pages, but neither is there any increased cost. One thing where you should be able to measure a significant difference is on classic portlets. These used to set up all the globalize stuff again for the separate expression context of the classic template, making them quite a bit slower. Executing the globalize hack twice or even many times was certainly quite a bit of a difference. The reasons why I'm very much in favor of removing the globalize hack are different ones: Obviously the way it is done is an utter hack. Walking up stack frames to inject things into a higher global scope is very evil. Second the globalized names are today a random set of shortcuts, which have little to do with the typical need inside templates. They started out a point where access to a set of tools was essentially the whole Plone API, but this isn't the case anymore. Now they just make it harder to understand template code as there is no way to find the actual code path from for example the syntool name inside a template to the actual implementation. They obscure templates for little to no benefit, as most often the real call is a one-liner itself and context/portal_syndication gives a much better searchable term. Another point is that they make templates rely on execution order of the whole macros system. They only work when called after the globalize hack has been executed but not in isolation. This also leads to problems when trying to move templates into more reusable packages as it becomes very hard to see the actual dependencies of the template. What looks like locally defined shortcuts turn out to be oh and btw. I need those other ten packages-type dependencies. It would have been much harder to understand and disentangle dependencies between packages on trunk, if those hacked in names still would have been in place. If we want to make things optional to get people a more speedy and less memory hungry Plone, having a central place that binds them all doesn't work. And last removing these calls from a centralized place makes both profiling of what actually contributes to the slowness of Plone much easier and allows for easier deprecation of some of the so far globalized names. For example many of the actual performance improvements on trunk result from changes to the way actions are looked up. To make these work, all of the actions, keyed_actions, user_actions, workflow_actions, folder_actions, global_actions names of todays globalize thing need to be deprecated and replaced. Instead of always having these defined everywhere, they need to be turned into a pattern where only the viewlet / macro that actually shows the particular action category also calls and evaluates those actions. For example hiding the personal bar in the UI today doesn't make a difference since all the actions in that category are still evaluated and their conditions checked. Even though nobody will ever show any of them. Maybe I forgot other reasons why this particular hack is considered one ;-) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Minutes: 8 August 2009
On Thu, Aug 6, 2009 at 3:23 AM, Tres Seavertsea...@palladion.com wrote: Alec Mitchell wrote: Perhaps we could find some clever way to deprecate access to the globalized attributes (e.g. make them all lazy lookups and issue a warning on first access)? There is an example of this pattern in the 'ursine_globals' view on the CMF trunk: http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/ursa.py?view=markup Which doesn't help here. If the Plone version would be of the form someview_called_globals/utool it's quite easy to do something on attribute lookup from that someview_called_globals object. Unfortunately the Plone version uses setGlobal on each and every attribute of that globalize view. So in the template there's no intermediate object anymore but magically utool is available in the scope. This would need some kind of very clever lazy proxy object which would introduce a hook in between the lookup and the actual code. Since the TAL machinery itself checks the scope for availability of names in some ways, that proxy couldn't just defer everything. This also gets somewhat more complex with the two TAL implementations we have now. It might be possible to do this, but its certainly not easy. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
On Wed, Jul 29, 2009 at 9:47 AM, Martin Aspelioptilude+li...@gmail.com wrote: Wichert Akkerman wrote: The whole point of the agreement and the conservatory is that we have a solid legal basis. I would really like to see an informed legal opinion on the requirements for moving existing code to foundation ownership. Without that I fear we may be on dangerous ground and risk making the separate repository useless. +100 For what I know we needed to explicitly state what code we had written and wanted to donate to the Foundation for work done prior to the agreement. We do need some kind of document (whatever constitutes a legal document in Delaware) that states who transfers what code to the Foundation. Just because I signed the agreement to transfer the my rights in the stuff now in the Plone repo, doesn't mean I automatically transfer the copyright in anything else. But don't let it stop or discourage people from doing what's right. The Contributor Agreement is pretty clear reading, especially the front page matter: http://plone.org/foundation/contributors-agreement/agreement.pdf The first thing you learn about the legal system is that the written text of any agreement or contract is just a tiny little piece of what actually is the case. What is written might be clearly illegal, it might not match current law practice as exercised by courts anymore or the text might look like it's stating something whereas the legal language makes it something else. Legal language and English only seem to be the same for some degree, but they aren't really. People get far too worked up over the What Would A Layer Do question, probably in the belief that there is in fact a black-and-white answer that they're just not qualified to know. I can understand it coming from Americans. They probably have wristbands with that written on them. Less so from the Dutch. :) There's never a black-and-white answer. But with American case law you have no clue whatsoever what could be the case without studying a lot of law. Since we have pro-bono legal council, we better make use of it for important legal concerns. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] today's meeting
On Wed, Jul 29, 2009 at 6:26 PM, David Glickdavidgl...@onenw.org wrote: A couple things I'd like to talk about: * Upgrade policy. Currently Plone 3 supports migrations from Plone = 2.0.5. I was hoping to be able to do that for Plone 4 as well, but there is a tradeoff. Plone 4 no longer has any runtime dependency on GroupUserFolder, so I was hoping we wouldn't need to depend on it any longer. However, it is still needed in order to migrate Plone sites from before we used PAS (e.g., Plone 2.5). I think we have 2 options: Thoughts on which is preferable? 3. What about supporting upgrades from Plone 2.5 final and later? These sites all have PAS installed already. Since 2.5 is considered a major version, we would still support the upgrade from the last two major versions of Plone instead of one. 2.5 also introduced GenericSetup, and with an upgrade machinery depending on GS it is easier to have that in place before any upgrade. * wicked / AdvancedQuery. See https://dev.plone.org/plone/ticket/9398 ...Does removing this dependency make sense? Is someone willing to volunteer to make the needed change in wicked? I think the change makes sense. AdvancedQuery was only accidentally included as a dependency of wicked and never got a proper risk analysis. With Dieter Maurer now essentially gone and as far as I know no longer doing any Zope development, we don't have any chance of updating AdvancedQuery to silence all the deprecation warnings for 2.12. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone 4] Zope 2.12 status
On Thu, Jul 2, 2009 at 12:25 AM, Andreas Zeidlera...@zitc.de wrote: On Jul 1, 2009, at 9:22 PM, David Glick wrote: On Jul 1, 2009, at 12:13 PM, Hanno Schlichting wrote: - sort out image traversal stuff / linkintegrity (image scales are now found via an IPublishTraverse adapter rather than __bobo_traverse__, which doesn't work during non-publish traversal, so linkintegrity fails to detect that images are linked in a document) Huh? I thought that change was only part of Archetypes trunk and not in the scope of Plone 4. This should have read: Not in the scope of David's PLIP. I haven't given a lot of attention to Archetypes yet. We can (and probably should) exclude that change. otoh, `plone.app.imaging` also introduces that adapter, and as it was mainly created as a support package for adding image support to `plone.app.blob` (did you think anyone wanted those configurable image scales? :)). that's because the latter overrides the original adapter with an implementation based on zodb blobs. so i'm gonna argue for it's inclusion into plone 4, thereby bringing back the `IPublishTraverse` adapter. of course, limi simply converted that old PSPS ticket (#7822) into a PLIP and i didn't think of adding a reference to that dependency, so the fwt will have a point in turning this down. i should mention, though, that not being able to rely on `plone.app.imaging` would set back image support quite a bit and thereby reduce the chances of wrapping up blob support in time. also, i think the configurable image scales have been a popular request by some (b1 had 500+ downloads in 1.5 month ;)). anyway, and stopping the shameless advertising here, i think back-porting the traversal adapter might make sense, and since both `plone.app.imaging` (being a potential candidate needing this) and `plone.app.linkintegrity` happen to be packages i'm familiar with, i'd volunteer to help fixing the issue. how's that? :) Sounds good. I'm just trying to stop David from doing too much, so he actually has a chance of finishing the main big task of getting Plone 4 onto Zope 2.12 ;-) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone 4] Working out a timeline
On Mon, Jun 22, 2009 at 6:18 AM, Eric Steeleems...@psu.edu wrote: Ok, so I promised a draft timeline before our meeting on Tuesday. Here's what I've got: - Aug 16 initial implementation - Aug 30 first review due - Sept 13 revisions due - Sept 27 review of revisions / vote - Oct 4 Alpha 1 release - Oct 25 Beta 1 Release (or directly after the conference?) - Dec 1 Final Release This seems to be a typical roadmap derived from the end date and then everything else filled in. History tells us this won't actually work ;) Don't get me wrong, such a plan is good to have to get some common understanding, but usually none of the later dates in the timeline will be met in practice. For the later Plone 3.x releases Wichert adopted a style of only committing to the next two milestones on the plan as hard targets. Once these where reached or missed by some days or weeks, plan for the next dates. I'd encourage you to be flexible along those lines. In the end what matters more than a nailed down target of December first is what features and what quality we ship. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2
On Sat, Jun 20, 2009 at 12:17 PM, Martin Aspelioptilude+li...@gmail.com wrote: - c20188, c20190, c23197 — removal of PloneFolder (hannosch) — need to double check whether this requires a migration for any persistent objects, and write that if necessary +0 to remove. There's no persistent stuff based on that particular class since Plone 2.1. What is still left is the OrderedContainer implementation inside the PloneFolder module, as this is used by the PloneSite object itself. This ought to be cleaned up since OFS has almost the same implementation, but this is a different task. The temporary folder used for the FactoryTool was based on this as well, but can use the PortalFolder from CMF instead. It's just faking some more rich environment to create a new content object in and luckily never persisted. - c20337, c20338, c22979, c22981, c22988 - switch the control panel to be based on normal actions in a new action category, rather than using a special control panel tool (hannosch) — see also http://dev.plone.org/old/plone/ticket/8804 +0 - we need to make sure the existing controlpanel.xml import step continues to work. There's an extra PLIP for this for Plone 5. Especially since I figured out that actions in their current form are the most critical performance bottleneck we have by a large margin, I don't want to move anything to actions at all anymore. I'd leave these changes out until we have figured out what to do with actions in general instead. Moving more actions to the actions tool will make things slower if we don't include some of the workarounds and hacks I did to the actions machinery all over. - c22831, c22832, c22891, c22951 — remove external editor (hannosch) — see http://dev.plone.org/old/plone/ticket/8592 -0 - people do use this. what's the cost of keeping it? See the ticket for details. It has an extra ticket and needs discussion, so better leave it out for now. The main argument is that it's unmaintained for ages and not used by many. It's a perfect add-on candidate. - c22847 — remove wicked from core (hannosch) — see http://dev.plone.org/old/plone/ticket/8593 (but note that as of this week Carsten Senger has been doing some maintenance...yay!) +0 to make this an add on people can install if they need it, but we should endeavour to make it work for migrated sites This has an extra ticket as well and I'd leave it out of the other changes. There's at least documentation to be done here if we remove it from the core. - c23193 — turning default_error_message into a browser view (hannosch) — seems like a decent idea to me, but as implemented here it removes the redirector and content search features +0 - I think ideally plone.app.redirector should just override this view and do nothing if not explicitly installed. I'm not sure we have time to do that properly, though. I wouldn't touch this. The main reason for these changes are, that the old way of doing things doesn't work in the repoze.zope2 / WSGI world. Exception views, standard_error_message, the error_log and all that stuff simply doesn't work at all. So the whole of p.a.redirector needs to be changed quite a bit to be made to work in that new world. Since WSGI is out of the scope for 4.0, I'd leave these things out for now. - c23198, c23199 — removal of portal_interface tool (hannosch) — if we remove this then we lose the way to check for marker interfaces from action expressions, for instance. also, it's missing a migration +0 to remove. Doesn't plone.app.layout.globals have something for this that's based on a view rather than a tool? I'd leave this in place, but then it needs to be changed to work with zope.interface interfaces instead of Interface stuff. Removing this was made under the assumption that there's no skin templates / scripts left in default Plone that would need this. This won't be the aim for Plone 4.0, so this thing might still have some legitimate use. - c23226, c23233 — moving migrations to plone.app.upgrade and using all GS without the migration tool (hannosch) — -0 from me...I think moving these to a separate package may actually make it harder to keep migrations in sync with the Plone release they belong too, simply from the standpoint of reviewing svn history +1 to move to all GS, at least. I don't have a strong feeling about the package location. Maybe Hanno does? The initial driver for making this into its own package, was that the upgrade steps tend to have dependencies on quite a number of add-ons, like CMFEditions, KSS, portlets, ... for interfaces or to call into code to make some changes. If the Plone distribution itself contains the migration code, it gets all these dependencies pulled in and makes it quite hard to create a minimal base distribution. The way I attacked the unclutter dependencies / base distribution problem is based on the assumption that the Plone distribution itself turns into a no-code, policy distribution of some
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On Sat, Jun 20, 2009 at 8:38 PM, Tres Seavertsea...@palladion.com wrote: Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. We have a bit of a mismatch between the big plan and what just happened over the last weeks. The way Plone 4 has been schemed out, was indeed to be short-hop release, largely taking already completed work and packaging it up, so we could deliver something to our integrators and end-users while waiting for Plone trunk. What has been done so far, seemed to be largely in the way of baseline technology features, like Zope 2.12, Python 2.6 but also blob support, plone.folder and the various performance improvements in the content creation space. Now I take some blame and credit for the overall plan and I seem to have missed out one important point: our community. It seemed like we had an ever diminishing interest from our community to advance Plone itself over the course of the Plone 3.x timeline. The working assumption that I and others had, was that the current technological complexity of Plone, would cause this decline for a number of months or years. The hope was that after we refurbished some of our underlying technology to become less complicated, we would see a new rise in contributions. Given that idea, I think we have missed to ask our community at large for contributions and didn't give us a clear way to suggest these. Some of the ideas we have seen since the PLIP deadline has been opened are quite unfinished. However what completely positively surprised me was the amount of ideas and people that contributed already. It seems the Plone developer community is still much more alive and kicking than what at least I imagined. The tough call that is on the release manager and the framework team to make now, is how to best serve our community interest and come up with a roadmap that allows us to integrate all the exciting things that people suggested. One thing to remember is that continuously planning the road ahead is much more important than the plans we already made. Personally I'd be in favor of extending the scope of Plone 4.0 to some degree and making a clear commitment to allow quite a number of the suggested features to be done in the scope of Plone 4.1, 4.2, ... releases. Much of the work that makes up Plone trunk (5.0?) today is going to take even more time than we had planned for and is all pretty invasive changes. If our developer community is still so much alive based on our current set of technologies, we can allow ourselves to take some more time to refurbish our backend. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] update on supporting Python 2.6 / Zope 2.12 / CMF 2.2
On Sat, Jun 20, 2009 at 6:47 AM, David Glickdavidgl...@onenw.org wrote: - The current situation with regard to PlacelessTranslationService needs to be reviewed to make sure that our language negotiator and product i18n dirs are still getting registered properly following simplification/removal of Five's Zope2 i18n integration layer. Hanno said he could probably take a look at this. I looked at this now and adjusted the simple missing stuff. A quick test showed that switching the Plone site language to German works correctly and all the UI renders accordingly. There might be some minor issues somewhere, but by and large it just works (tm). This uses PTS trunk which doesn't have a persistent representation in the ZMI Control_Panel anymore, but hooks directly into zope.i18n and registers all po files independent of their location in locales or i18n folders as zope.i18n message catalogs. The nice thing about this is, that no add-on product needs to be changed. - I switched back to Zope 2.12.0b1 for now because with Zope 2.12.0b2 there is an issue preventing the Unauthorized error when you first try to access the ZMI from getting propagated into an HTTP authentication request. I haven't had time to dig into this yet although I did check a non-Plone Zope 2.12.0b2 and it didn't seem to be an issue there. I looked at this as well and hopefully found and fixed the bug in Zope2 itself. Pending David's confirmation :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIPs in Trac
On Fri, Jun 19, 2009 at 2:03 AM, Maurits van Reesmaur...@vanrees.org wrote: I do not really mind either way. But I talked with Jean-Paul Ladage about this today and he is right in saying that end users wanting to know the future of Plone will look at the roadmap on plone.org and they will not be impressed: http://plone.org/products/plone/roadmap The old roadmap is obviously supposed to be replaced by the Trac one from http://dev.plone.org/plone/roadmap. This was supposed to happen shortly after 3.3 is released. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 dependencies
David Glick wrote: We'll also have to consider what happens with the version numbers of the various plone.* packages which Hanno has been calling 2.x for use with Plone trunk...in most cases the changes are probably fine for Plone 4 and we can just keep using 2.x, but if there is a package with some changes on trunk that we don't want, we'll have to make a 2.x branch without the undesirable change and move that package's trunk up to 3.x) My main reason to call all these trunk version 2.x was to allow for many more minor-feature-upgrades aka. 1.2, 1.3, ... to happen for these packages before the grand-overhaul-breaking-backwards-compatibility thing. I think we should branch of the last 1.x branch of a package to a new 1.x+1 branch for the packages where we need to do this. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 dependencies
Matthew Wilkes wrote: Perhaps the question we should be asking is, What do we want the new features for Plone 5 to be?. I think moving to browser views for default templates would be useful, if not just so it unifies our customisation story. On the concrete example given, quite high-up on my list of wishlist features for Plone 4 would be ditching portal_skins and having a layer-aware analogue for browser views, with an exporter. TTW editing is sorely missing in 3.x, and I think it's a pain point. +1 for it being a pain point. But ;) I think we can move all the admin-UI stuff like preference screens, folder_copy, object_rename and author pages and the like from CMFPlone to browser views in Plone 4, as these tend not to be customized that often. I wouldn't want to see document_view, folder_listing and the more commonly customized templates to be changed in Plone 4, though. Changing these will break lots of customizations out there and I only want to do that once we have figured out the complete story for TTW editing and new-style default theming. As long as we have Archetypes and any AT-based add-on, we won't be able to ditch portal_skins anyways. It's whole widget machinery and base_* are too tightly based on nested skin layers and lots of magic. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone Messaging
Matt Hamilton wrote: On 6 May 2009, at 01:44, Ross Patterson wrote: These kind of messages are not largely or exclusively technically, marketing, or user oriented. They require a cohesion of all concerns. Maybe I'm trying to be structural about something that shouldn't be addressed that way. It does seem, however, that this is a significant challenge for our communities. No? I see what you are getting at here. I think one event that does do a lot for this is the Plone Conference keynote by Alan and Alex. Or the 'what coming up in release X' talks that Alex usually does. These generally focus on what is coming up feature-wise and I think do a lot to set expectations of what is coming up. Now I know that Alex is often (and I hope you don't mind me saying this Alex) quite ambitious in his visions for Plone in some of these talks, but I think that is a good thing. I have been sitting with a big smile in my face in all keynotes I attended, knowing that half of what our founders where talking about was not to be taken too seriously ;) I think we do have two types of messaging going on here. One is the real marketing messaging to our customers. These better only promise features and directions that are based on some good ground, as in whatever is actually released or in late beta / release candidates. The other one is part of the community conversation about where we are headed. It's trying to build consensus or set expectations on where we should go. The keynotes do have a bit of both, but a talk from Alexander about the Future of the Plone UI is pretty much completely in the later scope. Another aspect of these internal conversations is also to attract people to the idea. If you have an idea that you cannot technically or time-wise implement, you need to market the idea to the community, so it is on the one side accepted as something we should do but on the other hand you also need to attract someone who wants to do it for you. Thanks to our open discussion nature we do have the conversation about what to do next in the same open way as everything else. If an outsider mistakes these as factual promises on some deliverables he has a bit more to learn about Open Source. What you can count on is what is released in a final version. This holds true for commercial vendors in the same way, which might remove a feature from a late beta release. The added value you get in Open Source is that you can see the debates about the future direction, which in many commercial solutions will be hidden behind the doors of some meetings. And you can even engage and try to change these directions. The abstraction-loving German in me sometimes wants to structure these things and appoint people, get clear responsibilities. But so far I failed to see any way that could be done or would be useful for this particular challenge. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] The new Plone 4.0, was Re: Plone 3.5
Hi. To summarize the feedback from the European time zone, I think that the proposal in general meets the favor of everyone. The controversial issue is the exact version number to use for the release. There seems to be broad support for freeing the current Plone trunk from a version designator and release a 4.0 release with the envisioned scope of this proposal instead. If I do not get a strong signal or message otherwise, consider this proposal changed in this regard. Hanno Hanno Schlichting wrote: Hi. While everyone is waiting for Plone 4 and its rather long timeline, some people have been thinking about how to bridge the gap between the current stable 3.x releases and the future. The general idea that seems to have met some consensus is to go for a Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5 that is similar in spirit to the Plone 2.5 release. It tries to both refresh some of our technical underpinnings in addition to some more intrusive feature changes we didn't allow ourselves in the 3.x series so far. In order to frame the scope of such a release I made a listing of some of the potential features for such a release at http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list is both non-exclusive and non-binding in the recommendations. The envisioned timeline for a Plone 3.5 release would be to aim for a final release either by the time of the conference or by the end of this year, giving us six months or a bit more for it. By aiming for an after-summer beta deadline we will have a chance of leveraging some Google Summer of Code contributions for such a release. When it comes to the official personal involved in such a new major release, I'd like to suggest a slight deviation on our process. As many to all of the features changes in question for the 3.5 release have so far been in the scope of the 4.0 release, I'd suggest to appoint the entire 4.0 framework team to be the official team for 3.5 as well. This forces them to get involved with the process in a more defined and clear way now. On the side of the release manager, Wichert has signaled that his workload as a freelancer will not allow him to take over the shepherding of a new major release. We do however have with Eric Steele of PSU fame a well-known interested candidate for the position. This is only a proposal that needs community feedback and encouragement at this point to make it into an official roadmap. The next steps are to have an open discussion about this for the next one to two weeks. If it meets general favor, we will appoint the new/old framework team and let them recommend a release manager to the Foundation board for official nomination. Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Quick team meeting
Hi Calvin. Thanks for taking the initiative here. I'll not gonna make it to todays tune-up nor the conf call, though :( Calvin Hendryx-Parker wrote: The next one is this Friday and I'd suggest that we meet at 17:00 GMT. I'll send out Yugma conference info so we can share desktops if needed. Their service supports skype so make sure to download the Yugma SE plugin for skype if you want to skype into the call. https://www.yugma.com/share_skype.php For the first meeting I'd like to suggest: * That everyone checkout Plone 4 locally so we can talk at a very high level about the roadmap for this release * Better documentation for developers and the PLIP process and how it has changed What we have in terms of documentation for the release so far is: 1. A mailing list discussion about the high-level goals and process: http://thread.gmane.org/gmane.comp.web.zope.plone.teams.framework/2274 of which various parts are outdated already. 2. A number of PLIP's at http://dev.plone.org/plone/milestone/4.0 which are reasonably up-to-date. I tried to take the initiative back in January to incorporate the changed process from the Plone 3.x framework team and required adjustments for the 4.0 process into our official process documentation. The discussion hasn't been very fruitful and ended without a clear result. I'd welcome it if the 4.0 framework team would take the lead in this matter and started clarifying the PLIP process for 4.0 as required from the framework teams point of view. In my dual role of release manager and major code contributer I have payed too little attention on communicating the changes and ideas for the 4.0 release. I'd welcome suggestions on how to improve this situation and ways of turning Hanno's playground called trunk back into a managed collaborative environment. Cheers, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Quick team meeting
Ross Patterson wrote: Hanno Schlichting hanno...@hannosch.eu writes: Four of us (calvinhp, ErikRose, ErikRose, zenwryly) made it to the meeting and came up with a few things to act on. I'll briefly describe them here so we can discuss. Awesome! Some of the discussion centered around possible changes or clarifications to the PLIP process. This begged the question, where is PLIP procedure documented? The two current main sources of written documentation are: https://dev.plone.org/plone/wiki/FrameworkTeam and hidden in http://plone.org/documentation/manual/plone-developer-reference/overview/referencemanual-all-pages it would be good if the relevant bits from the latter could be incorporated into the wiki. The general idea is to have all development of type information inside the Trac wiki. As hanno said: I tried to take the initiative back in January to incorporate the changed process from the Plone 3.x framework team and required adjustments for the 4.0 process into our official process documentation. The discussion hasn't been very fruitful and ended without a clear result. So we need to determine the official home for the PLIP process documentation and evaluate the status of that which calvinhp said he'd take the lead on. See above. I think the process for the 3.x release and 4.0 release should be somewhat different. 4.0 is supposed to make many more interconnected and radical changes, as we ever do in a single 3.x release. The process needs to reflect this in some way. But I would appreciate it if Calvin could indeed take the lead on this and I'll be happy to comment and give my feedback. Since the Americans refused to distinguish themselves with clearly recognizable accents :) , I'm not sure whether it was calvinhp or ErikRose who suggested that we start sort of public presentation of changes happening in Plone 4. The main goal is to reduce surprises. We agreed that an informal process of blogging in more widely accessible language about what makes it into the ChangeLog would be good. This could also be a way to collect feedback as well. Discussion through blog comments may become a problem but we'll tackle that if it comes to Pass. ErikRose said he'd take the lead on this. This sounds like an excellent idea. I tried to write up something in less technical terms inside those Trac PLIP's which hopefully go into the direction of this. They haven't seen too widespread exposure yet, from what I know. Is this the kind of information you are looking for? There is even some more high-level roadmap information that isn't written down at any point but has only been communicated in informal conversations. I'd be happy to try to bring some of those to the public in form of blog posts or any other form people find valuable. So far, much of the Plone 4 work has happened in narrower circles to free it up for prototyping, visioning, and imagining new approaches. This has been in part to isolate such a process from the paralysis that can come from discussion of edge cases or disagreements which are more proper and valuable at a later stage. I raised a concern that as we start presenting this work more publicly, we should think about communicating and setting expectations for the impact of the backwards incompatible changes. I proposed adding an explicit, formalized part of the PLIP procedure for community impact assessments. I'd love a better name, but the idea is a place to communicate to the various parts of Plone communities (developers, integrators, themers, users, etc.), Here's what you need to know to update your code/skills. Here's where to find documentation. I offered to take the lead on this. Sounds good. I think this is a logical extension of the Documentation Impact section we added to the 3.3 PLIP process. One of the things I'd like to have a more important role in the PLIP process is the upgrade guide we have on plone.org. I think taking the What's New documentation from Python (http://docs.python.org/whatsnew/2.6.html) as an example could be valuable here. I tried to introduce this to Zope2 at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html with the chapters written about Acquisition and IContainer changes. This kind of information is probably best written by a combination of the documentation team as we've done it for Plone 3.3 with more involvement of the PLIP authors themselves. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Fwd: Doodle: Link for poll Framework Team Meeting
Matthew Wilkes wrote: I've tried to include all the relevant possible times in this, let me know if there's another I should add. I'll be at PyCon in that week and have no idea what my time schedule is going to be. I'll try to join on whatever time others agree. In general I'll be on vacation from April 1st until April 13th with limited internet access. From April 14th until end of June I'm going to work on-site at a customer in Copenhagen. My internet access and availability might be reduced at the start and exact work times are still a bit unclear. I won't be available on IRC or for immediate comments through-out the workday in those months. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Fwd: Doodle: Link for poll Framework Team Meeting
Matthew Wilkes wrote: On 13 Mar 2009, at 19:30, Hanno Schlichting wrote: Matthew Wilkes wrote: I've tried to include all the relevant possible times in this, let me know if there's another I should add. I'll be at PyCon in that week and have no idea what my time schedule is going to be. I'll try to join on whatever time others agree. To be clear, that week was chosen as it's around the right time and is after DST starts in Europe so it is repeatable. Please sign up when you're USUALLY available, even if you're not on that particular day. Ah ok, others please follow this advice :) As noted in my other comments, I have no idea yet what my availability will be after that week. Anything usual ends for me again next Tuesday and I'll yet have to find out what my new usual will be. Once I'm in Copenhagen after Easter and things have settled a bit I can update this :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.3 PLIP merges
Wichert Akkerman wrote: In prepraration for the merges I have created a 3.3 plonenext branch; please use that to merge your work and test the results. Hanno Schlichting - PLIP 237: Minor i18n upgrades PLIP 237 is merged. New releases of PLT and PTS are made and plonenext is updated with new versions and branch locations. Finally I updated the PLIP page on plone.org (http://plone.org/products/plone/roadmap/237) and included the documentation I wrote for the review bundle. PLIP status was moved the Merged :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.3 PLIP merges
Wichert Akkerman wrote: On 2/19/09 8:59 AM, Raphael Ritz wrote: Wichert Akkerman wrote: Now that the final reviews are in it's time to start merging. I disagree with the framework team results on one item: PLIP 243 is not ready for merging. It still suffers from a problematic unicode decore error that I have not been able to fix, and which must be solved before it can be merged. (shameless request: I need help with that one! Sorry for not catching that one :-( Can you give more details maybe? I don't see anything reported on http://dev.plone.org/plone/browser/review/plip243-content-history/README.txt#25 I tried to look into this, but I wasn't able to provoke any error or see any obvious place where one could occur. Can you give me some concrete steps to follow to provoke the error? Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Final review report
Andreas Zeidler wrote: On Feb 5, 2009, at 9:48 PM, Andreas Zeidler wrote: This however, resulted in a 404. It turned out, that the view was only registered for IATFolder and IPloneSiteRoot, but not for `Large Plone Folder` a.ka. IATBTreeFolder. I took the liberty of `fixing this myself`__ ;-) and it worked as expected. yep, that was indeed a rather silly oversight on my behalf. thanks for fixing it. I haven't looked at the code, but why restrict this to those container interfaces alone? Isn't some IContainer or OFS-level interface all that is required? Once the Plone site root is supported, the code likely doesn't rely on any of the AT-semantics. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 237 ready for review
Andreas Zeidler wrote: On Jan 18, 2009, at 2:44 PM, Hanno Schlichting wrote: I'm somewhat late with creating the review buildout for PLIP 237 (Minor i18n upgrades) at: https://svn.plone.org/svn/plone/review/plip237-minor-i18n-upgrades/ The review notes and detailed explanation is found in the review buildout's README.txt. i've added notes in http://dev.plone.org/plone/changeset/24772 in short: i'm +1 for merging, but PLT has an error which needs to be fixed before the next release. it's not related to the changes, though. Can you add a ticket for the bug you encountered? From the review notes alone, I wasn't able to understand what the problem really is. Thanks! Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 237 ready for review
Hi. I'm somewhat late with creating the review buildout for PLIP 237 (Minor i18n upgrades) at: https://svn.plone.org/svn/plone/review/plip237-minor-i18n-upgrades/ The review notes and detailed explanation is found in the review buildout's README.txt. The PLIP text at http://plone.org/products/plone/roadmap/237 is somewhat outdated and will be updated with the detailed information if I get a go-ahead. Thanks, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: NuPlone and Plone 3.2
Martin Aspeli wrote: Martin Aspeli wrote: Hi, Why on earth is Products.NuPlone not in the Plone 3.2 egg? Is this in purpose or just a gross oversight? Ok, I've released Products.NuPlone 1.0b3. This one should be compatible with 3.2. You can use it straight away by adding Products.NuPlone to your eggs. The question now is how we deal with the release. We could: - Add Products.NuPlone as a dependency of the Plone egg. This would mean 'Plone' always comes with NuPlone, but there's no reason overt for the dependency. +1. Plone 3 ships with NuPlone in the same way it does with CMFEditions or any other package, we shouldn't change this in the 3.x series. Please introduce no special handling of it. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: NuPlone and Plone 3.2
Martin Aspeli wrote: Wichert - I'm assuming you've been away for the weekend, but once you get this, could you at least grant a few people, including me, PyPI access to Products.NuPlone? We then also need to make the 3.2.1 release that includes NuPlone ASAP. I just spoke to Wichert. He's on vacation in a far remote place. He'll be back next week to follow up. From what I can tell we just need to wait with a re-release until then. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP's for 3.x releases in Trac???
Wichert Akkerman wrote: Previously Matthew Wilkes wrote: On 25 Dec 2008, at 17:39, Hanno Schlichting wrote: we just decided to move all PLIP's to Trac for Plone 4 and no longer use plone.org/products/plone for it. Incidentally, I missed this, where was it discussed? Are we going to have a new workflow for PLIPs? I was wondering the same thing. It very much looks like the framework team selection process somehow always invented a new PLIP process behind closed doors. I'm not sure where you got the impression. Moving the PLIP's to Trac has been discussed many month back and I effectively put this into practice two month back when adding the first PLIP for Plone 4 to Trac. This has nothing to do with the framework team selection process. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
Tres Seaver wrote: Hanno Schlichting wrote: - Plone 4 will have a documented upgrade story A migration from Plone 3 to 4 does not need to be possible in an almost fully automated fashion. We need to ensure we have an easy to follow and understandable documented upgrade story. If we for example change API's or rearrange code, we can document the new places in writing and with error references for the most commonly used parts. If you need to change your buildout configuration, a document explaining the changes is fine, we don't need to build an upgrade machinery for configuration files. Can I persuade you and the FWT to forego an upgrade-in-place strategy for moving from P3 to P4, and instead to have a well-tested ad documented dump-and-reload story? I'd love to have this story. I think it is even a prerequisite for changing the default content types story. If someone wants to champion bringing transmogrifier and GSXML up to a point where they are a fully-featured export and import story for all aspects of typical Plone content types, that'd be awesome. As long as we don't have a champion for this, I won't make this a blocker for a release. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] - Initial PLIP drafts coming in
Jens W. Klein wrote: In your PLIPs you wrote i.e. here https://dev.plone.org/plone/ticket/8593 to remove parts out of Plone the Product. I fully agree to remove features from the core! But I think if we do so, there should be a set of Managed Plone Products. Important add-ons like LinguaPlone or the removed parts should get in a managed by the Plone [Foundation|Team X] state. [...] If current teams structure is not sufficient for this task, we could introduce a new Add-On Team. I think none of the current teams or structures we have is able to do the job of maintaining a list of recommended / proven / better / whatever list. There have been numerous discussions around this topic and various ideas on how to solve this (community rating, automatic metrics, self-certified criteria, ...) but so far there is neither a consensus nor someone dedicated to own the task. I'd very much welcome if someone would step up for this, but I'm not willing to have this block the removal of unmaintained code anymore ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] [plone4] - Initial PLIP drafts coming in
Hi. I've started to write up initial PLIP drafts for the major changes that have already been implemented on SVN trunk and that I want to do for 4.0. They can be found in Trac and are associated with the 4.0 milestone. They aren't supposed to be complete yet, but serve as a reminder to keep track of the changes we need to properly document and that should get a framework team review. Just because I already implemented them and merged them to trunk, doesn't mean they don't need to go through some review and discussion process. If you are missing PLIP's for changes that have already happened, please tell me and I'll try to add them. The actual content of the PLIP's isn't ready for review yet. I only want to make sure we have PLIP's in place for all changes that need them. Once we have defined the review process for Plone 4 and the structure and information to be included in PLIP's, I can flesh them out more, to cover all the required topics. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: 4.x team nomination
Hi. Would it be a good idea to collect the nominations in some place like the dev.plone.org/plone Wiki? I fear we might loose track of the nominations, when they come in over a couple of weeks. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Kicking off Plone 4: Release Manager candidate
Hi. Alexander Limi wrote: Hanno Schlichting has said that he'd like to be the release manager for Plone 4, and I'd like to formally propose him as a candidate for this role. Over the last couple of months, I have been considering to step up for the release manager job and have gotten positive feedback from various community members to the idea. I have not made this public for a long time, as I wanted to get an understanding about out shared community vision for what Plone 4 should actually be, before stepping up as a manager for it. Culminating in the conference I think I have gotten an understanding of what direction the community wants to go into and I can identify myself with that direction. I'll try to summarize some broad ideas about this direction and the general roadmap for Plone 4 from my point of view soon. Martin Aspeli has indicated that he'd like to help Hanno in a developer communication role, so Hanno can focus on his job of the release manager, and Martin will help communicate what's going on to our core developers and add-on product developers. I asked Martin to help in the communication effort, as I know my German communication-style can easily be misunderstood by some people, who don't know me in person ;) Giving Martin an official title should make his role unambigous and let him do, what he is so good at, with an official blessing :) So, if anyone else is interested in being the release manager for Plone 4, let us know! Please do step up, if you want to take on this role. I don't have an exclusive right of any kind to get the job. Also, if the official nomination for the Plone 4 release manager has to wait until there is a Framework Team for 4.0, we should: a) Start identifying these people ASAP. b) Possibly accept Hanno as an interim release manager until the team can make an official recommendation based on the available candidates. As we agreed in Washington to give the framework team the role of finding and suggesting the release manager to the foundation board, we cannot make a final decision about it, as long as we don't have a new team. I'd be happy to serve as an interim manager and renew my application to the new framework team once it is in place. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: random thought: identify the components that lack owners
Martin Aspeli wrote: Tres Seaver wrote: It seems to me that not having continuity of architectural vision across releases, including the ability to remove broken / abandoned components, is a really dangerous place for Plone to be. I think there is architectural vision in Plone, but it tends to be established through a process of discourse and consensus building, more so than through one man's iron fist. The problem I have with the current state is that we have been exceedingly bad at looking at maintenance cost of new technology we use and features we include. Consensus building so far has most of the time meant, that we do include new features all the time. There's no clear voice that says STOP. The other problem I see is that we have an insanely complex set of dependencies and code base. Few people are able to understand large parts of it. Our learning curve is insane. There's a reason why Plone developers aren't available anywhere on the market and the training cost to get them up to speed is huge. If we don't get a roadmap that is able to reduce the complexity of the system from a developers point of view by a huge factor, Plone will not be able to survive. We are eight years old by now, where do we need to be in another two to four years? I know that various people in the community tend to think in the same direction, but we need clear visible steps to get there. For example we took a huge risk to embrace Zope 3 technologies via Five. After the explosion of Zope 3 into separate packages it has become obvious that only a few core packages like zope.component and zope.i18n are actually maintained. Large parts of zope.app do not have any community to support them, neither has Five itself. What do we make of that? We used zope.formlib but most other people ditched it by now. Can we get a consensus on discouraging its use and making sure we don't use it in the core anymore? That's not to say we shouldn't rip out a bunch of code. In fact, I'm going to lend my voice (and hopefully a little bit of authority) to that argument in two weeks' time. :-) Yes! How many components do we have that are completely unmaintained? For example stuff like different storage layers in Archetypes, wicked, NuPlone, ExternalEditor, iterate, ... to name a random number. We cannot simply remove everything that is unmaintained, but I think we need to make some of those hard decisions about what to remove from the core very soon. Hanno P.S. Maybe my perspective from a bug tracker manager is always a bit more depressing than for other people ;) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: random thought: identify the components that lack owners
Jon Stahl wrote: I'm wondering why this would be a task for the framework team? I'm open for suggestions about who else might take it on. I'd say the general development community. I think we have a bit of a problem in that we have no formally-designated leadership team for the codebase of this project. The FWT seems like the closest thing we have in general, and on this topic, they (including you, Wichert) seem like the folks with the most relevant knowledge. The people with the general knowledge might indeed be the ones, that follow this particular mailing list. I'd be very reluctant to make the framework team into a general code leadership team, though. That's explicitly *not* what it has been designed for and the way it is elected and the people are recruited doesn't give them a lot of authority for this matter. It's also not what they signed up for. In my opinion we do not have an official leader or leadership team for matters of general code and development related topics. This has been the case since Alan stopped doing this job. If the community feels like we should get such an authority back, we need to communicate this and find a way of establishing such a team. This is too important to just be assigned as an additional duty to an existing entity. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: random thought: identify the components that lack owners
Hi Jon. Jon Stahl wrote: However, there's really no definitive list of these that we can use to recruit more talent. I've just given you Trac admin rights, so you can have a look at https://dev.plone.org/plone/admin/ticket/components which is probably the best we have. I'm not quite sure what to make of that list. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Framework Team Page Needs Updating
Alexander Limi wrote: On Tue, Aug 19, 2008 at 12:49 AM, Raphael Ritz [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: To me, this looks just fine. Are there only 5 members? I thought there were more. If not, ignore me. :) They are only five members in the current active team. It is only those five who have done an incredbible job at getting Plone 3.1 reviewed ;) They have been lots of members who served on former teams, though. PS: maybe it's about time to think about a new team for Plone 4 (or Plone 3.3 even) though. I think the general consensus is to keep the 3.0 team for Plone 3.3 (for continuity), and elect a new FWT for 4.0 — and some overlap would be good, to make sure the lessons learned from the 3.x releases will be carried over. I think the consensus has indeed been to keep the same team for the 3.x releases, unless someone wants to step down for any reason. For 4.0 we do indeed need a new team. I for one would be happy to serve on that team again :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.2 plans
Wichert Akkerman wrote: Previously Martin Aspeli wrote: Wichert Akkerman wrote: The packaging goal we want to achieve is to move to a fully eggified release. Great! What isn't eggified yet? The products currently still in the 3.2 ploneout are: CMFActionIcons CMFCalendar, CMFDefault, CMFDiffTool, CMFEditions, CMFPlacefulWorkflow, CMFTopic, CMFUid, DCWorkflow, GroupUserFolder and PloneTranslations. I expect that we'll be able to have eggified versions of these in a week as well. A week was a bit pessimistic here, products are gone from the 3.2 branch! Also - what about Zope itself? I know Andreas is kean to move Zope 2 to all eggs soon (and make use of Zope 3.4, which is all eggs). It may make sense to co-ordinate here, since a fully eggified CMF/Plone is really only half the picture. This will be a topic for the black forest sprint in August. I eggification of Zope to be a goal for Zope 2.12, which means we won't be able to benefit of that for some time. In the meantime we should use the fake-zope-eggs option of plone.recipe.zope2install. I have just signed up for helping out on Zope 2 eggification on that sprint as well. I'm sure we can get there for Zope 2.12. If we are able to make a Zope 2.11 release as an egg, is yet to be decided. 2.10 is definitely not going to see an official egg release anymore. I think we're due a new features process. Perhaps we could start soliciting PLIPs for 3.3 and get the review process organised at the same time that we package up 3.2. I presume 3.2 won't have any PLIPs to review (well, maybe one or two package related ones) in any case. For 3.2 I only want to look at PLIPs that deal with installers. There are two PLIPs listed for 3.2 at the moment. 229 is purely an installer extension and should be easily doable, especially since I already implemented almost the same thing for the Jarn Plone hosting environment. 230 is borderline but I'm willing to look at it if it is done in the form of an optional new package. 3.2: I gave my comments on plone.org on the two PLIP's in question. 3.3: I should probably start writing my own PLIP's soon :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Testing for PLIP 209: Unified Installer Plus Buildout
Florian Schulze wrote: On Thu, 14 Feb 2008 16:23:41 +0100, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Florian Schulze wrote: On Thu, 14 Feb 2008 13:38:56 +0100, Raphael Ritz [EMAIL PROTECTED] wrote: (i) when describing start/stop/status we might want to add 'fg' (foreground) as a simple means to start in debug mode without changing the configuration AFAIK this doesn't work for some reason in buildouts. It has bitten me many times now, but I didn't get to look into it yet. I use 'bin/instance fg' a lot. In fact I use it 99% of the time when doing development. So I'm quite sure it works fine in buildouts. It runs, yes, but it doesn't switch to debug mode. This was fixed in the recent 1.2 release (early January) of the zope2instance recipe. Before that it foreground wouldn't go into debug mode automatically. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Testing for PLIP 209: Unified Installer Plus Buildout
Sidnei da Silva wrote: On Thu, Feb 14, 2008 at 1:23 PM, Raphael Ritz [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008 13:38:56 +0100, Raphael Ritz [EMAIL PROTECTED] wrote: (i) when describing start/stop/status we might want to add 'fg' (foreground) as a simple means to start in debug mode without changing the configuration It works on Windows, but when you hit CTRL-C you get into a weird state where you're asked if you want to exit the batch file or some such, and then you have to hit 'y' once or twice. Pretty odd as if the output or the input was in a separate thread. Yep, I haven't been able to figure out why exactly that happens. I usually just hit Ctrl-C twice. There is probably some problem with the way the subprocess is started, which behaves differently on Windows compared to *nix. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Translation effort for Plone 3.1
Hi. Alexander Limi wrote: However, Plone 3.0 ships with translation files that contain strings for both 2.5 and 3.0. We did a major cleanup in 3.0, killing off a lot of happytalk, and as a result, there's less fluff to translate. You probably see where I'm going with this, but: I'd like to ship 3.1 with a set of .po files that do not contain the strings from Plone 2.5. Hanno said it would take him a couple of hours to weed out the stuff that is 2.5-specific, and agrees that it would be a good thing to do. I did cost me only two hours to do so and this work is finished and available on PloneTranslation trunk. An overall of 205 messages are gone. We now have a total of 2070 messages in all pot files combined for Plone 3.x. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 195 implementation ready for review
Raphael Ritz wrote: Wichert Akkerman wrote: 2. Not sure it's the best possible UI to completely hide a product if a dependency is missing. [...] I'ld like some input from Hanno on that. What I did was update the isInstallable method in the quickinstaller tool, which seemed the logical place to put it and makes sure all the standard APIs and code paths do the right thing. QI has never had a user interface or API that communicates why a product is not installable and I'm not sure what the best way to add this is. Well, for testing purposes I just deliberately introduced a typo in the PloneLanguageTool (of Plone 2.5.4 to demonstrate that this is not new; removed a colon in line 60) and in 'prefs_install_products_form' I get: Broken products Some products were found to have errors when compiling the install file. * PloneLanguageTool Error Type exceptions.SyntaxError Error Value invalid syntax (Install.py, line 60) That's what I meant. Along the same line we could just list products with broken dependencies here as well as they are checked anyway. This seems like a good approach for me right now. I do have some plans to do a major update to the installation logic for Plone 3.2 so a better UI can probably wait until then. Right now the dependency support is the most frequently asked for feature, so lets get that out to people :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Suggestion for adding Usecase information
Danny Bloemendaal wrote: After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 219: New site search implementation
Tom Lazar wrote: On 17.12.2007, at 09:47, Raphael Ritz wrote: Wichert Akkerman wrote: I want to propose PLIP 219: New site search implementation http://plone.org/products/plone/roadmap/219 Given the risk of breaking customizations which I consider significant (as search often gets customized from what I can tell) I'm -1 for Plone 3.1 same here, unless you can work something out (perhaps together with hanno) along the lines of the 'optional' migration steps that hanno has mentioned. i.e. folks could choose to include this update in 3.1 if they know they haven't customized search. any ideas on that? hanno? wiggy? I won't have time to do any work for the 3.1 deadline. Hopefully I'll have more time again for 3.2, but I cannot commit to anything here right now. Given an optional migration strategy is available this could be 3.x material in my non-voting opinion ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP #212: Use jQuery Javascript Library
Wichert Akkerman wrote: Previously Martijn Pieters wrote: On Dec 13, 2007 5:13 PM, Andreas Zeidler [EMAIL PROTECTED] wrote: so, +1 from me, provided we're gonna have the wrapper for cssQuery and an easy way to switch back to the old implementation and the original cssQuery in case anybody needs those... again something for the migration docs, i suppose. cssQuery will be moved to the deprecated skin layer and disabled in the js tool, so it can be re-enabled quite easily. -1 Moving it to deprecated is fine, but please do not disable it on migration. Not enabling it for new sites is fine, but disabling it on migration has a too big risk of breaking things. We can and should add text to the release notes that say that cssQuery is now deprecated and admins can try to disable it on their site to reduce their page size. Better safe than sorry. A bit unrelated, but should we maybe try to enhance our upgrade story in a way that we list required and optional steps in it and provide the user with a way to select/deselect the optional steps? So disabling cssQuery would go into an optional step and get a description explaining why we want to remove it from the site. For cssQuery that won't work as we don't have that infrastructure yet and it's past plip deadline for 3.1, so keeping it enabled on upgrade is probably better. I'd be interested to improve our upgrade story eventually for 3.2, though ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: transforms
Thierry Benita wrote: Hi, A remark about transforms in Plone. atReal did a piece of work about transforms, with AROfficeTransforms, the last PastisSprint and some work in progress. We also work close to Hanno on the transform engine since the sprint. We are adding transforms to plone.transforms, but it looks like there is a licence issue at some point because we sometime need to include some code that is published under free licence (mostly GPL) but we don't own the code, and it is therefore impossible to give that code to the Foundation. It is perfectly fine to add code to the Plone SVN repository which is owned by somebody else as long as it is clearly marked as such. We are doing this in CMFPlone itself (where we have separated it slightly in form of an svn:external reference for JavaScript libraries for example) but other places with direct inclusions as well. This is especially true for openoffice xslt transforms (that rely on a modified xslt sheet from opendocumentfellowship) and windows transforms that need to embeed binaries if we want them to be easy to install. From what I can tell plone.opendocument includes those xslt transforms as well. I'd rather like to see one implementation of openoffice support for Plone. Joscha just told me he'll be coming to the Plone conference and he's determined keep working on plone.opendocument for a while, so I'd rather see his work being supported by others. For the external binaries I think we need to rethink the way we do our development environments, distributions and installers for the next major Plone version anyways. We already started discussion around this on the plone-devel list (zc.buildout-based installers?) and I'm sure we will come up with something new here. The way in which we provide those binaries to further enhance the OOTB experience of Plone is a bit dependent on that discussion. My proposal is to embeed AROfficeTransforms in the Plone bundle or package. We may change the name if it is an issue. This would provide a full solution for indexing and previews (other proposal) out of the box without licence issue. I'm not sure what exactly AROfficeTransforms provides here. For the actual transforms I hope we will have all of them covered in or based on plone.transforms in a short time. The preview feature is something which in my opinion should either be included directly into Archetypes (if it is just a tiny bit of code and some changes needed in AT itself anyways) or made available as a new archetypes.preview package. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PloneErrorReporting
Hello. Alec Mitchell wrote: On 3/25/07, Hanno Schlichting [EMAIL PROTECTED] wrote: Alexander Limi wrote: Could we please remove PloneErrorReporting from Plone 3.0? +1, as the current official maintainer I took the liberty to remove it from the release and the bundle. One stupid thing less to take care of :) I thought you were the one that added it to 2.5 on the grounds that it had been in some past releases. I think getting rid of it is a fine idea. As far as I can remember I only added it to the products bundle and fixed it because it had been in the dist_plone scripts and thus the releases forever. I just looked at the independent.py scripts and it seems to me that we have included it at least since Plone 2.0.0 :) But it outlived its purpose which was to help people in reporting errors to our trackers for a long time now. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] plone products leaders (v2)
Hi, Tom Lazar wrote: On Mar 17, 2007, at 8:35 AM, Thierry Benita wrote: What do you think of this idea ? Do you think that it is possible/affordable ? + 100 and thanks for the nice writeup, i think this initiative comes at a very good time, because on the one hand we definitely need to lighten the load of responsibility that currently is divided among the very few shoulders of our 'rock stars'. Personally I would love to divide some of the load on more shoulders. Especially mine are getting busier with other responsibilities and I want to avoid to become a bottleneck... take hanno's `statusmessages` product for instance, a super small product all in itself. just yesterday i found a bug in it and given the fact, that the entire functionality is just a few lines of (isoltaed) code i was (surprisingly) easily able to come up with a patch. however, now that i'm fairly familiar with this product's inner workings i already would feel confident taking over maintainership of it, while hannosch still remains 'mentor' of it. Consider yourself the new official maintainer of it ;) I'll do one last release tomorrow so you start with a clean state :) so, perhaps, to ease the transition the current de facto maintainer of a package could offer 'mentorship' (i.e. provide support for the maintainer, as opposed to everybody). I'm willing to do that for all the packages I'm currently maintaining. There are some where I don't understand enough about the inner workings to mentor anybody though, but I shouldn't maintain those in the first place... one example being ATReferenceBrowserWidget which constantly breaks due to the sheer amount of configuration options in conjunction with exactly zero tests. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] wicked - lxml dependency?
Heya. I noticed that a lot of tests in wicked fail on my machine, as I don't have lxml installed. Is lxml a real dependency for the functionality we use in Plone or is it optional or only required to run the tests? Hanno P.S. I tried to install lxml via easy_install and while it claims to install fine, I get Bus errors during test runs of wicked then :( ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked - lxml dependency?
whit wrote: Hanno Schlichting wrote: Is lxml a real dependency for the functionality we use in Plone or is it optional or only required to run the tests? it's used in the tests (to strip whitespace). iirc, any working version of libxml2 should work(both for the test and lxml, though lxml needs to be rather current). lxml or libxml is not needed for any of wicked's functionality. Ah ok, great. I got lxml running on Windows (as there's a pre-built binary release) and all tests did indeed pass. Thx for the clarification, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Martin Aspeli wrote: I'm obviously for ploneenv/workingenv. I'm obviously a bit biased towards the buildout based approach since I worked on it, but I worked on it because I was never very happy with the way workingenv-in-instances worked. ploneenv makes that better and slicker, actually, and I quite like it. I'm not really for or against anything here. My main reason to work on ploneout has been that our current general approach of handling eggs in Zope instances (which is not to use them at all, but use a plone3-libs bundle) annoyed me, especially since I saw that Whit already had some nice code in wicked relying on entry-points but had to remove it again, as we have no advertised way that makes it easy to setup an instance with properly installed eggs. As I already knew how to handle workingenv, I thought I'd bring zc.buildout to the table and realized that we would only be able to discuss about it for real, if it would be able to actually build us a working Plone 3 environment, hence ploneout was born... One reason why I like ploneout is that my MacBook's monitor is partially damaged and I'll have to live without it for some weeks once I send it into repair. For those weeks I'll use a different (Windows) machine at work and need a way to get my development environment up and running, preferably in the same way I'm already used to and would prefer it not having to spent too much time on it. I'd guess this is not a good argument in general ;) Ultimately, I think we are arguing preferences and taste. The main lever for all of this is eggs (which we all love, of course :-)) and both approaches basically depend on eggs and setuptools as much as possible. Yep, for instance I never liked the way a Zope instance currently looks like and so in return have no problems to get used to a different layout, others may have different preferences here. After all I think we are making very good progress in exploring different kinds of setting up our development environments. The one thing we can probably agree on, is that we need something better than the current plone3-libs bundle ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Daniel Nouri wrote: Hanno Schlichting wrote: Nope. Windows support for zopectl is a lot harder then just some path fiddling. But the real issue with it is not really something that is an argument for ploneout, I just took the time to implement it in it, it could be a separate package as well. The basic problem with it is, that it relies on Unix-specific thread handling for the start/stop/restart/debug/status options, but it calls the internal status command at every start of the script, so on Windows it fails before you can do anything with it. I adjusted the internal status handling, so it doesn't look for the Unix specific stuff but should look if a Windows service of the instance is installed and running. Ideally this could move into Zope itself. I have seen that somebody implemented something alike for instancemanager... I looked at the Zope 2 recipe briefly and thought it only fiddlest with PYTHONPATH in bin/runzope.bat. I don't really understand the other issue with Unix specific threading that you mention. Lucky you, basically the current state is: zopectl doesn't work on Windows! But I found out that it's not that hard to enhance it in a way so it does work on Windows... all you need to do is to look into the internals of zopectl and zdaemon combined with how configuration files are parsed at Zope startup... and add some platform specific conditional code. Now after a refreshing my memory it fails on socket handling in zdctl.py in zdaemon on the line (sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)) where socket.AF_UNIX is not defined on Windows. Basically the way Zope is started in non-foreground mode on Unix is different from Windows, where you need to install a service which you can start/stop/restart... First off, I think ploneenv would need to modify the runzope.bat script so that it calls the activate script before startup. Wouldn't it be enough to adjust the PYTHONPATH to look into the workingenv directory first? I thought that's the only thing that's really necessary to activate a workingenv? Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked integration w/ plone 3
Martin Aspeli wrote: whit wrote: does anyone have a good formlib example for a controlpanel that *doesn't* edit a cmf tool? plone.app.controlpanel has none? There are examples of formlib in plone.app.contentrules and plone.app.portlets.portlets, and Rocky has a formlib tutorial. Otherwise, Hanno may have light to shed. :) The approach I have taken in plone.app.controlpanel is to introduce a middleware-adapter for the IPloneSiteRoot that will act as the context for the formlib form. Read the full story in http://dev.plone.org/plone/browser/plone.app.controlpanel/trunk/README.txt This approach allows you to do any kind of work in the adapter. If you look at the types control panel you won't see any CMF tools usage inside there ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: plip 149 (better markup support) request for merge
Hi Tom, Tom Lazar wrote: hi everybody, as of http://dev.plone.org/plone/changeset/11748 the last functional 'show stopper' for the markup plip has been removed IMHO and i have since been looking into re-implementing its control panel as a view. it seems that hannosch has already created quite some infrastructure for controlpanels in plone.app.controlpanel, which i'm eager to tap into (browsertests, yay!) I have also added a long-overdue README explaining the approach taken in far more detail, that should help you (and others) to understand what I have been up to ;) The browsertests only make sure all the actual control panels work, but do not explicitly test any of the infrastructure, so they might not be that helpful. however, before i go ahead and create what will be the sixth(!) branch for my bundle i'd like to request for the branches of this plip to be merged into trunk, so i can continue with working on trunk directly, since all that is left to do (http://dev.plone.org/plone/browser/review/plip-149-markup-support/plip149-todo.txt?rev=11748) are really just 'cosmetics'. all tests pass (or rather cmfplone and archetypes fail in my branch with the identical errors that they do with in trunk...) +1 on merging it (I don't want you to loose any time again on handling branches ;) having said that, however, i only have time to work on this during the next three days... if merging should take significantly longer than one day, please let me know, and in that case i'll continue on my own branch of plone.app.controlpanel in order to get things finished before new year. As long as you don't break anything, you can just work on the trunk of plone.app.controlpanel ;) It's not yet in any releasable state anyways. Yours, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP125 (link integrity) part II - redirect-on-move ready for merge
Hi, Martin Aspeli wrote: Hi guys, I've spent the past two days piecing together RedirectionTool and Whit's topp.rose product into something that meets the second half of PLIP125. Yeah, you rock as you always do! The first half is what Andreas is working on - warning when you're about to delete things that will break links. The second half is about offering automatic redirects or, if not possible, useful guesses instead of a dumb 404 page when an object has been moved or renamed. For the record, I love this functionality :) While I like this too, I'm a bit concerned about the performance penalty. Is there an easy way to turn this behavior off? Like a switch in some control panel? I'd like to merge this now, unless people have objections. There's no bundle, but the code is here: http://dev.plone.org/plone/browser/plone.app.redirector/trunk http://dev.plone.org/plone/browser/CMFPlone/branches/plip125-redirector The only thing that seems a bit dubious to me is the IGNORE_IDS constant in browser.py. I think this is a policy decision that should be easier to customize. The simplest solution here would be to turn this into a simple global utility with just one method that would return this list. This way people who really wanted to customize it could add their own local utility to return something different (for instance ignore all aliases registered on any content type + all dynamic view templates + ...). Also, unlike RedirectionTool, there is no form for making your own redirects (mainly because there's no good selection widget for me to use). This would work just fine (add things to the IRedirectionStorage utility), but since we have automatic redirects for anything moved or renamed, I think it's much less useful... in any case, it can be added later. Is there any way to clean up some old redirects, like a 'delete all redirects' option somewhere? I imagine that people might need this after a while. I'd like to merge before trunk moves too far away from my branch. :) +1 in general Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Revisited: Some preliminary Plone 3.0 profiling results
Hi again. Martin Aspeli wrote: Hanno Schlichting wrote: Just as a small update. I did some changes to the way the date/time formatting works and some more optimizations in PTS and PloneTranslations. You should remove all the catalogs in the PTS Control Panel once, to get the whole performance gain. While I have some more ideas, how to speed up some of the code in PTS, my current simple benchmark number is now at 5.7 requests/sec :) I worked a bit on my ideas on how to make PTS even faster and this resulted amongst other things in using the memoize_contextless decorator from plone.memoize.view for some functions in PTS. While I had to trick a bit as the PTS object is of course not a view, but an Acquisition-wrapped object, it was pretty simple in the end. Especially as there already has been quite some caching code that stored things in the request. /me cheers Hanno's dedication We need to paint a go-faster stripe on it. That'll speed it up! Martin, going for 6 requests/second (w00t, speed of thought!) While we have seen some performance decrease by the merges of some recent bundles, I have been able to make Martin's dream come true nonetheless and we are now at 6.2 requests/sec :) Hanno, who still has some more ideas about how to speed things up ;) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Revisited: Some preliminary Plone 3.0 profiling results
Hi all. Hanno Schlichting wrote: Martin Aspeli wrote: Hanno Schlichting wrote: My simple benchmark shows a boost in performance from 4.0 requests/sec to 5.2 requests/sec for a newly created site, which is now finally a tad bit faster then the Plone 2.5 branch. Wasn't it 6 requests/sec before? Yes, but that was as I removed the recent, review and most importantly calendar portlets altogether. The calendar portlet is still quite resource intense, even if there's nothing to show. Once I remove the calendar portlet now, I get about 6.2 requests/sec. The recent and review portlets don't make any noticeable difference. Just as a small update. I did some changes to the way the date/time formatting works and some more optimizations in PTS and PloneTranslations. You should remove all the catalogs in the PTS Control Panel once, to get the whole performance gain. While I have some more ideas, how to speed up some of the code in PTS, my current simple benchmark number is now at 5.7 requests/sec :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Revisited: Some preliminary Plone 3.0 profiling results
Martin Aspeli wrote: Hanno Schlichting wrote: My simple benchmark shows a boost in performance from 4.0 requests/sec to 5.2 requests/sec for a newly created site, which is now finally a tad bit faster then the Plone 2.5 branch. Wasn't it 6 requests/sec before? Yes, but that was as I removed the recent, review and most importantly calendar portlets altogether. The calendar portlet is still quite resource intense, even if there's nothing to show. Once I remove the calendar portlet now, I get about 6.2 requests/sec. The recent and review portlets don't make any noticeable difference. Hanno P.S. In Plone 3.0 the calendar portlet usually cost about 1 to 1.5 requests/sec, so it's bad but better now ;) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Can I merge plone.memoize and plone.app.layout?
Alexander Limi wrote: On Mon, 04 Dec 2006 10:47:37 -0800, Martin Aspeli [EMAIL PROTECTED] wrote: Perhaps we should move it to plone.app.controlpanel, though? I'm a bit worried about CMFPlone.browser becoming as big as CMFPlone/skins +1. The control panel stuff deserves its own space, and will hopefully be expanded a lot in the near future (the goal is that site admins should never have to visit the ZMI unless they want to do very esoteric things). Ok, done. It has it's own package now. All of you are welcome to review this (as it's my first time using formlib) and more importantly add more control panels ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Can I merge plone.memoize and plone.app.layout?
Hi. Hanno Schlichting wrote: Plone 2.5 branch - 5 requests/sec Plone 3.0 some days ago - 3.5 requests/sec Plone 3.0 right now - 4.0 requests/sec Plone 3.0 without old-style portlets - 6.0 requests/sec And as another reference: Plone 2.1 branch - 5.7 requests/sec Hanno P.S. I used ab -n 100 http://127.0.0.1/plonesite; to get all those numbers. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Can I merge plone.memoize and plone.app.layout?
Martin Aspeli wrote: Hanno Schlichting wrote: So right now one easy way of getting some more performance is to turn the remaining old-style portlets into new-style ones. This will happen, it's mostly just manual work. The only hard one remaining is the calendar one, plus I want to make some new portlets altogether, like a Document renderer and a Smart Folder renderer. The only annoying one left of the old ones is the Calendar portlet. I started to work on that one this morning on my train ride, as I already have a quite intimate relationship to that code ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: merging florian's icon work
Wichert Akkerman wrote: Are there any objections to merging the updated icon handling? The changes are quite small and they bring us a lot more flexibility. +1 for merging ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
