Todays FWT meeting canceled

Looks like that todays security patch caused more work than supposed -
we were only three: Andrew, Ross and I.

We canceled the meeting. I suppose to hold the next one next week:
Tuesday, 25th June, again 19:00 UTC.

I'll chair the next one again. The next one after the next one should be
chaired by someone else.

Please review, vote, do the championing work, encourage, read, code,
relax.

Best,
Johannes

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Looks like that todays security patch caused more work than supposed -
we were only three: Andrew, Ross and I.

We canceled the meeting. I suppose to hold the next one next week:
Tuesday, 25th June, again 19:00 UTC.

reminder for our meeting tomorrow

Dear people of the Framework Team!

This is just a friendly reminder for our meeting tomorrow, 17th June
2013 at 21:00 CET (19:00 UTC).

Despite the security team also postponed the upcoming Plone hotfix
release for tomorrow and the postponement of our meeting last week was a
bit pointless, I propose to have the meeting tomorrow as planned to
follow up our FWT work - unless a fair amount of votes against the
meeting is given.

Have a nice day,
Johannes Raggam

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Dear people of the Framework Team!

This is just a friendly reminder for our meeting tomorrow, 17th June
2013 at 21:00 CET (19:00 UTC).

Despite the security team also postponed the upcoming Plone hotfix
release for tomorrow and the postponement of our meeting last week was a

Plone 5

<div>
<div>
                    <div>So, as you've likely noticed, we spent a lot time of talking about Plone 5 during the recent Plone Symposium Midwest. I think we've reached the point where can really start prioritizing concepts for a major release. Obviously, any changes need to go through the Framework Team for final approval, but I've got a bully pulpit and I'm not afraid to use it.&nbsp;</div>
<div><br></div>
<div>Here's how I'd like to see development focused over the near term:</div>
<div><br></div>
<div>&nbsp;* Plone 5 ships with Dexterity as its default content type story.&nbsp;</div>
<div>&nbsp; &nbsp; * Dexterity versions of plone.app.event and plone.app.collection</div>
<div>&nbsp; &nbsp; * Better set of widgets (plone.app.widgets)</div>
<div>&nbsp; &nbsp; * Products.Archetypes, Products.ATContentTypes, archetypes.schemaextender remain available as add-ons for older content</div>
<div>&nbsp; &nbsp; * Full multilingual story available (plone.app.multilingual)</div>
<div><br></div>
<div>* Plone 5's UI gets an extensive overhaul.</div>
<div>&nbsp; &nbsp; * Diazo becomes the default theming story</div>
<div>&nbsp; &nbsp; * Fewer CSS files makes finding and overriding easier</div>
<div>&nbsp; &nbsp; * No more !important in its CSS</div>
<div>&nbsp; &nbsp; * Editing interface is separated from content for easier styling (plone.app.toolbar)</div>
<div>&nbsp; &nbsp; * Accessible: WCAG- and ATAG-compliant</div>
<div>&nbsp; &nbsp; * Deco.gs is replaced with a more commonly-used grid system, responsive</div>
<div>&nbsp; &nbsp; * New folder contents UI with filtering and batch operations&nbsp;</div>
<div>&nbsp; &nbsp; * Improved, tested widgets</div>
<div>&nbsp; &nbsp; * TinyMCE gets upgraded to version 4.0, with a simplified integration making it easier for us to stay up-to-date</div>
<div><br></div>
<div>* Plone 5 ships with an empty portal_skins.</div>
<div>&nbsp; &nbsp; * Exists for add-ons</div>
<div>&nbsp; &nbsp; * Most content moved to browser views, z3c.form</div>
<div>&nbsp; &nbsp; * Login rewritten to use views, events. Simple, but pluggable for more complex use cases</div>
<div>&nbsp; &nbsp; * Pay attention to proper XSRF protection for our most common functionality</div>
<div><br></div>
<div>* Plone 5 has amazing test coverage.</div>
<div>&nbsp; &nbsp; * Migrating scripts from portal_skins to browser views allows more unit testing</div>
<div>&nbsp; &nbsp; * New JavaScript practices mean more unit tests for our interactive stuff</div>
<div><br></div>
<div>* Plone 5 is faster.</div>
<div>&nbsp; &nbsp; * Chameleon reduces rendering times by 30%</div>
<div>&nbsp; &nbsp; * Date formatting is handled on the client side</div>
<div><br></div>
<div>* Plone 5 is easier to learn.</div>
<div>&nbsp; &nbsp; * plone.api covers most common development tasks.</div>
<div>&nbsp; &nbsp; * Plone 5 eats its own dog food and sets an example for:</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; * Views</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; * z3c.form</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; * Dexterity</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; * Diazo</div>
<div>&nbsp; &nbsp; * JavaScript integration/development requires less knowledge of Plone&nbsp;</div>
<div>&nbsp; &nbsp; * Theming requires less knowledge of Plone, less fighting with the default setup</div>
<div><br></div>
<div>And most importantly...</div>
<div>* Plone 5 is achievable within the next 12 months.</div>
<div><br></div>
<div>There are, I'm sure, 30 other features that are in some stage of not-doneness, and while I'd like to see us do everything, we need to find some kind of scope. I think the above featureset gives us a nice range of features, a not-too-painful upgrade, and gives everyone plenty to do over the next year.</div>
<div><br></div>
<div>We've already begun approaching Plone companies to get buy in to the effort, asking for time, money or organizational support. Six Feet Up has pledged 5 hours per week of their QA team's time to test our work. Netsight is organizing a sprint to rework the login. AMP is pledging 5 hours a week toward deprecating portal_skins. Wildcard is taking on the folder contents revamp. If your group has a particular need, now is the time to make it happen.</div>
<div><br></div>
<div>In addition, we have plans to use the general community excitement that comes along with a major release to build some momentum in our non-code teams. If we can move this forward, I think Plone 5 will be a big step up for both Plone the software and Plone the community.</div>
<div><br></div>
<div>Eric</div>
                </div>
                <div></div>
</div>

Shared Folder on PAM

<div><div dir="ltr">Hey FWT,<div><br></div>
<div>There is a use case on multilingual that I can't find a clean solution and all implementation I do I feel like they are really hacky.<br clear="all"><div><br></div>
<div>* Introduction *</div>
<div><br></div>
<div>There is a folder ( language root folder and navigation root ) for each language where the user stores the different content on each language.&nbsp;</div>
<div><br></div>
<div>The problem is on shared content. Content that is in a neutral language and needs to be seen on different language root folders. The desired solution should allow users to create content that is seen on different languages and when you see them it looks like you are still on the navigation root from the language you are browsing.</div>
<div><br></div>
<div>* Actual solution *</div>
<div><br></div>
<div>There is a 'shared' folder on the root that is set to neutral language. We patch the catalog to show it's content on the language root folders.</div>
<div><br></div>
<div>It leads a lot of problems, for example, we can't order the content on the shared folder. The patch is not nice to use ( we want to remove all portal catalog patches ). When we move to the shared content we need to patch again the catalog to see the language content.</div>
<div><br></div>
<div>* Possible solutions *</div>
<div><br></div>
<div>- Removing the shared folder, moving the shared content to the root of the plone site, using Acquisition to get the content on the place, patching catalog to show them, creating a IOrdering adapter for language root folders. Cons : patching catalog, we are using acquisition to get the content.</div>
<div><br></div>
<div>- Using something similar to collective.alias to create an alias inside the language root folder, they are alias to neutral content. The alias will be a 'shadow' copy of the real element with traversing inside and possible parameters mapping. Cons : collective.alias is old and a bit hacky to do it.</div>
<div><br></div>
<div>- Using language root folders to deliver the content that's on the root as it's himself. Overwriting the traversing functions on the container to get the neutral content inside the language root folder for the catalog, folder_listing, traversing,...</div>
<div><br></div>
<div>I know it's a complex problem without a clear solution but this use case is really common ( Members folders for example ) and I would like to find some clean solution to it.</div>
<div><br></div>
<div>
Thanks !</div>
<div><br></div>
<div>Ramon</div>
<div><br></div>-- <br>Ramon a.k.a bloodbare
</div>
</div></div>

Scheduled meeting on 11.6.2013 and CVE announcement

Hi FWT members,

We have a meeting scheduled on 11.6.2013, 21:00 CET, but on this day a
security vulnerability patch will be released at 2013-06-11, 15:00 UTC:
http://plone.org/products/plone/security/advisories/20130611-announcement

It's likely that some of us are busy updating their site. If that's the
case, we should consider to cancel the meeting and hold it 1, 2 weeks
later. What's your opinion?

Best, Johannes Raggam

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Hi FWT members,

We have a meeting scheduled on 11.6.2013, 21:00 CET, but on this day a
security vulnerability patch will be released at 2013-06-11, 15:00 UTC:
http://plone.org/products/plone/security/advisories/20130611-announcement

It's likely that some of us are busy updating their site. If that's the
case, we should consider to cancel the meeting and hold it 1, 2 weeks
later. What's your opinion?

Best, Johannes Raggam

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Today's meeting canceled

Hi framework team,
I canceled today's meeting because only Eric, Johannes, and I were 
there. (Ross tried but had technical difficulties.) For those of you who 
weren't present, can we change anything about how we are scheduling 
meetings to make it more possible for you to attend?

Please reply to this message with an update on the PLIPs you are 
currently championing or reviewing.

My update is that I did a review of the plone.app.widgets PLIP: 
https://dev.plone.org/ticket/13476#comment:14. It looks promising to me, 
but still needs some work on refactoring to be in the right places in 
core rather than an add-on, and on documentation. I am +1 on the concept 
of the PLIP but -1 on merging it until that work is done.

I unfortunately did not have time yet to do my other task, which is 
prototyping a more sane way to implement PLIP 13350 (define member 
properties TTW).

Also, a reminder to Nejc, Johannes, Matthew and Martijn that there are 
some PLIPs in the "Submitted" section of the google spreadsheet that you 
need to vote on.

best,
David

PLIPs and jenkins integration

Hi Timo!

At the last FWT meeting I brought up your request to get a viewpoint
from the Framework Team on having Jenkins integration for each PLIP.

We all think that this is a very good idea. You might have seen this
already in Eric's FWT meeting notes, but here again:

"""* Testing team working on Jenkins configuration for plips.
plone.app.contenttypes already working. Would we like these for all
plips? Absolutely.
    * We need to get some documentation in the coredev docs about how
PLIP implementers can get access to their builds.
"""

Please let me know if you need some more information from the FWT to
continue your work. And keep me updated about the progress.

Thanks a lot,
Johannes

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Hi Timo!

At the last FWT meeting I brought up your request to get a viewpoint
from the Framework Team on having Jenkins integration for each PLIP.

We all think that this is a very good idea. You might have seen this
already in Eric's FWT meeting notes, but here again:

"""* Testing team working on Jenkins configuration for plips.
plone.app.contenttypes already working. Would we like these for all
plips? Absolutely.
    * We need to get some documentation in the coredev docs about how
PLIP implementers can get access to their builds.
"""

Please let me know if you need some more information from the FWT to
continue your work. And keep me updated about the progress.

Thanks a lot,
Johannes

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Re: PLIP12344, plone.app.contenttypes ready to merge

Tnx for pointing me to this problem!

That was because of having P.PloneTestCase loaded plone.app.event also
for 4.3. Jenkins will tell, if this change fixed it:
https://github.com/plone/Products.PloneTestCase/commit/18b29a9b0007643cca74e6b797d6771720d46967

On Don, 2013-05-02 at 07:10 +0200, Timo Stollenwerk wrote:
> Am 02.05.2013 00:47, schrieb Johannes Raggam:
> > well, tests run again, with some failures which need to be fixed.
> 
> Seems like p.a.event somehow made it into the Plone 4.3 buildout as well:
> 
> http://jenkins.plone.org/job/plone-4.3-python-2.7/545/console
> 
> Many: "KeyError: 'profile-plone.app.event.at:default'"
> 
> Timo
> 

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Tnx for pointing me to this problem!

That was because of having P.PloneTestCase loaded plone.app.event also
for 4.3. Jenkins will tell, if this change fixed it:
https://github.com/plone/Products.PloneTestCase/commit/18b29a9b0007643cca74e6b797d6771720d46967

On Don, 2013-05-02 at 07:10 +0200, Timo Stollenwerk wrote:
> Am 02.05.2013 00:47, schrieb Johannes Raggam:
> > well, tests run again, with some failures which need to be fixed.
> 
> Seems like p.a.event somehow made it into the Plone 4.3 buildout as well:
> 
> http://jenkins.plone.org/job/plone-4.3-python-2.7/545/console
> 
> Many: "KeyError: 'profile-plone.app.event.at:default'"
> 
> Timo
> 

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

Reminder: Call tomorrow

<div>
<div>
                    We have our bi-weekly call tomorrow at 1900 GMT (http://everytimezone.com/#2013-4-29,1860,6bj)
                </div>
<div><br></div>
<div>https://www.google.com/calendar/render?gsessionid=Dp9GXhE7itL_ES8VyufSqA</div>
<div><br></div>
<div>Please check in on your PLIPs so we can discuss status.</div>
<div><br></div>
<div>Thanks,</div>
<div>Eric</div>
                <div></div>
</div>

PLIP12344, plone.app.contenttypes ready to merge

Dear FWT people,

I talked with Philip and Timo, and we think that
plone.app.contenttypes is ready to merge. Right, Philip and Timo?

That would also bring some benefit for the plone.app.event integration
process. As I mentioned in the other mail, I also have to adapt
 <at>  <at> plone-addsite and  <at>  <at> plone-upgrade.

Johannes

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com

plone.app.event integration issues

Dear FWT people,

I want to follow up the discussion from the last FWT meeting about
plone.app.event's integration issues.

Although plone.app.event is developed with least external dependencies
pointing to it and therefore it is de-installable, we should still
ship with an Event type installed by default for Plone 4.4. I think
this default Event type should still be the Archetypes based.

This could still be the ATContentTypes ATEvent, with an option to
install plone.app.event's ATEvent or the Dexterity Event instead.
Plone.app.event provides the "ploneintegration" profile for this. If
we want to go this way, we should revert the merges on Plone core
packages which werde done some weeks ago (CMFPlone, ATContentTypes and
plone.app.portlets).

The other option is to completly replace ATContentTypes ATEvent with
the plone.app.event one (which I prefer...). For this, we have to
migrate old ATEvent types to the new ones (a roughly tested migration
step is included) - mainly to add the timezone, wholeDay and
recurrence properties. I tend to favor this option, altough there
might be some risks involved, which I cannot see at the moment.

If we choose the second option, I would integrate plone.app.event in
the "Plone" package instead of Products.CMFPlone and create a profile
there (there isn't one at the moment). The Plone package was meant as
a default Plone distribution. If we put it there, people can still
build applications with Products.CMFPlone without having to depend on
plone.app.event, if they don't need it.

What's your opinion on this?

Thanks, Johannes

--

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: office@...
web:  http://programmatic.pro
      http://bluedynamics.com