Re: [Framework-Team] Fwd: Re: Request to join the framework team
Giacomo Spettoli giacomo.spett...@gmail.com writes: Forwarding this 'cause Ross replied to just me. Oops, thanks! Ross Original Message Subject: Re: Request to join the framework team Date: Wed, 26 Jun 2013 12:25:27 -0700 From: Ross Patterson m...@rpatterson.net To: Giacomo Spettoli public-giacomo.spettoli-Re5JQEeQqe8AvxtiuMwx3w-wOFGN7rlS /M9smdsby/k...@public.gmane.org Giacomo Spettoli giacomo.spettoli-re5jqeeqqe8avxtiumw...@public.gmane.org writes: name: Giacomo Spettoli email: giacomo.spettoli-re5jqeeqqe8avxtiumw...@public.gmane.org +1 myself. I'm aware I'm not the most experienced or known plonista out there, but I can bring a good mix of will to do and skills to do it. A mix of both experience and focus (docs, UX, IOW not just code) is something I think the FWT looks for and needs and we heartily encourage using the FWT as a way to get more involved. Thanks, Ross ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] [Plone-developers] Call for Plone 5 Framework Team Members
Elizabeth Leddy elizabeth.le...@gmail.com writes: 2 cents: being on the FWT was an amazing experience. If you are borderline or nervous, just make the jump and apply. I learned SO MUCH from working with the team and if you put just a small amount of effort in it will return itself 10 fold. No time for imposter syndrome… hope to see some new faces join in! This is really important to say and thanks for saying it. I hope whoever copies and pastes, I mean writes :-), the next call for members includes this in the post. Thanks, Ross On Tuesday, June 25, 2013 at 12:57 PM, Ross Patterson wrote: Hello Fellow Plone Developers, The current Plone Framework Team has decided that the next major Plone release will be Plone 5 (instead of 4.4). So it's time for some fresh blood on the Framework Team. We're seeking nominations for new members to help get an awesome Plone 5 out the door sooner rather than later. The framework team's mission is to guide the ongoing technical work on Plone in ways that promote code quality and that are aligned with the community's interests. Specific framework team responsibilities include: * Conducting in-depth reviews of Plone improvement proposals (PLIPs) * Encouraging contributors to submit needed PLIPs, and helping mentor them through the process * Meeting with the team for an hour every 2 weeks to work on moving PLIPs through the process See http://plone.org/community/teams/framework for more information about the framework team, and http://plone.org/community/processes/plips for more about the procedure for considering proposed improvements. Framework team members are expected to have made significant (code or non-code) contributions to Plone, to be familiar with current Plone code and/or UI best practices, to have plenty of experience with buildout and to possess a tolerance for awkward silence during conference calls. You're probably a good candidate if: * You follow discussion on plone-developers or Plone core commits on github * You're already active reviewing Plone-related pull requests * You have an opinion about the future of Plone, but are also someone respected for your ability to carefully consider opinions different from your own. If you or someone you know is interested in joining the team, please send a nomination email to the framework team list (framework-t...@lists.plone.org). Please include the name and email of the nominee as well as a note detailing experience with Plone and some reasons for wanting to join the team. Members will be selected by current and emeritus team members. Thanks, Ross Patterson Plone Framework Team --- --- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Plone-developers mailing list plone-develop...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plone-developers ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Support for pre-PSE sprint
Elizabeth Leddy elizabeth.le...@gmail.com writes: Hello Lads, The board needs some official communication that the FWT supports the pre-PSE sprint as a strategic sprint. The pre-PSE sprint will be focused on on ripping out CMFFormController. Any objections to supporting funding this? Otherwise a +1 will suffice. +1 and I'd like to participate though I can't commit yet. Thanks, Ross ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Framework Team Dinner in Arnhem
On Wed, Oct 10, 2012 at 3:06 AM, Martin Aspeli optil...@gmail.com wrote: Works for me. Can we bring the Roadmap team too? Absolutely, that sounds to me like a great improvement to the tradition of the annual FWT meeting. Ross On 10 Oct 2012, at 10:29, Ross Patterson m...@rpatterson.net wrote: Ross Patterson m...@rpatterson.net writes: I'm here sitting with Eric and Nathan and we're wondering when we'll do a FWT dinner here at Plone Conference 2012. So when and where shall we do the dinner? My thinking is that it might be best to wait until we hear more about night activities, other dinners, and any official parties before we decide. I'd missed it before, but it looks like the official dinner and party are both on Friday night. So I suggest we do the FWT dinner Thursday night after the lightning talks are over. So how about 6PM Thursday night? Anyone have any suggestions as to where? Ross ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Meetings...
Yiorgis Gozadinos ggo...@jarn.com writes: Hey! We did not manage to meet this time either and it's been a while since we had a meeting. Would it be possible to let people know ahead whether we are having the meeting or not? Say for instance Eric or someone else asking the day before? At the moment I have to wait for a few hours at the office to be present and it's frustrating when it's for nothing :) I believe eric canceled the FWT meetings indefinitely until we have PLIPs on this very list. :-) Ross ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] Today's meeting
Eric Steele ems...@psu.edu writes: On Sep 2, 2011, at 11:13 PM, Ross Patterson wrote: Eric Steele ems...@psu.edu writes: Does anyone have items of significance for today's FWT meeting? Otherwise, we can just cancel and wait for new PLIPs to look at. How long can we wait before we don't have enough time to help motivate enought PLIPs such that the next release is kinda meaningless? I guess I'd like to see the next meeting go forward so at the very least we can talk about what PLIPs or potential PLIPs we might be able to use our pulpit to advocate for. I think it's important that we don't start our new release schedule with a stall of inertia. It might take a little active involvement from the FWT as we transition to a more fluid schedule. Ross A reminder -- you'd committed to sending a hey, get your plips in! mail to the dev list. That'd be a good first step. ;) Right! :-) We discussed asking Mark Corum to draft something up so I sent that message to Mark 3 weeks ago. I never heard back and forgot to follow up. Sorry. I just poked Mark again and if I don't hear from him I'll just write and send it myself. Sorry again and thanks for the reminder, Ross ___ Framework-Team mailing list framework-t...@lists.plone.org https://lists.plone.org/mailman/listinfo/plone-framework-team
Re: [Framework-Team] FWT Meeting Notes: 8 March, 2011
Elizabeth Leddy ele...@umich.edu writes: How to do an initial PLIP review I'm not even sure where to start here. Ideas? - is it formatted correctly - what dependencies would it introduce - what backwards compatibility impacts will it have (different for minor vs major versions) - does this belong in plone core - do the deliverables include tests - ...? When an FWT member goes AWOL Lets actually talk about this at one of our next meetings. Its not so bad in the new process, we just need to have clear rules. Maybe something like Taking a break from the FWT Yeah, I think the rule should be, per the PLIP author's rights, when a champion flakes once, shame them, when they flake twice, mercifully grant them a leave of absence. Similarly, two missed meetings, shame, more, leave of absence. Ross ___ 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
Alec Mitchell ale...@gmail.com writes: On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting ha...@hannosch.eu wrote: 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! It seems likely that this process will require a also larger team for any given release (particularly given the historic attrition rate of team members over the course the review process), along with a reasonable mechanism for members to opt-out of a particular cycle if needed. Definitely. One of the larger motivations for this change is to be less impacted by FWT attrition. As we discussed it, the FWT would become more of a framework *pool* allowing members to get busy and then come back later. Have we spelled out the process for bringing in a new FWT member as needed? Ross ___ 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
Ross Patterson m...@rpatterson.net writes: Elizabeth Leddy ele...@umich.edu writes: Thanks for all the feedback guys! Curious what current team members think +1, though I expected to gather more contradicting perspectives before weighing in in. Ok, so Eric I think we're a go. Lets schedule another FWT meeting and hammer out the details. Liz, get ready! :-) Ross On Sun, Jan 16, 2011 at 11:44 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2011-1-16 22:46, Martin Aspeli wrote: I suspect they can be overcome by release managers setting target dates, asking people to contribute to a particular milestone date for a particular planned release, but not holding up a release if people slip. Many smaller deadlines can be better than fewer big ones. If you have many small deadlines they effectively become meaningless since people will just wait for the next one (to fly by). I've always tried to advocate a more continuous development pattern and I love Elizabeth's proposal. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org https://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Final decision on PLIP 9327 (Unified interface for lists of content)
Eric Steele ems...@psu.edu writes: I'd like to get a final consensus on whether or not PLIP 9327 will be included in 4.1. From discussion last week, several of you wanted to hold out until we knew whether collections and search results would be in. At this point, it looks like those two will be pushed off for 4.2. With 5 of 8 votes in, it stands at a +4 for inclusion. Are there any objections to my considering it approved? I'm a strong +1 for someone releasing this package to pypi so we can use it out in the world, but I'm -1 on including it with core Plone without those PLIPs that depend on it being included. I've updated my vote on the spreadsheet and that bring the total to +2. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Reworking the PLIP Lifecycle | discussion
Elizabeth Leddy ele...@umich.edu writes: Thanks for all the feedback guys! Curious what current team members think +1, though I expected to gather more contradicting perspectives before weighing in in. Ross On Sun, Jan 16, 2011 at 11:44 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2011-1-16 22:46, Martin Aspeli wrote: I suspect they can be overcome by release managers setting target dates, asking people to contribute to a particular milestone date for a particular planned release, but not holding up a release if people slip. Many smaller deadlines can be better than fewer big ones. If you have many small deadlines they effectively become meaningless since people will just wait for the next one (to fly by). I've always tried to advocate a more continuous development pattern and I love Elizabeth's proposal. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Fwd: Re: [Plone] #9288: Improved commenting infrastructure
Timo Stollenwerk li...@zmag.de writes: Hi, Elizabeth came across a problem with p.a.discussion during her PLIP review: Authenticated users are currently not able to post a comment, they need the Member role to do so. Do we also want authenticated users to be able to post comments? Shall we just check for the Reply to Item permission? I would like to hear other opinions before I start to refactor the code. Don't Open ID logins have only Authenticated and not Member? At any rate, I think it's generally a bad idea to check roles, one should always check permissions. So it should probably be protected with a permission that should be given to Authenticated by default. Ross What kind of message should users without the appropriate permission see? The log-in button is kind of silly if the user has a login, but not the appropriate permissions to post a comment. Cheers, timo Original-Nachricht Betreff: Re: [Plone] #9288: Improved commenting infrastructure Datum: Wed, 08 Dec 2010 04:30:48 - Von: Plone disc...@antiloop.plone.org Antwort an: disc...@antiloop.plone.org CC: plone-collec...@objectrealms.net #9288: Improved commenting infrastructure +--- Reporter: timo|Owner: timo Type: PLIP| Status: reopened Priority: minor |Milestone: 4.1 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by eleddy): Replying to [comment:50 timo]: Nice work! I am super gung ho about authenticated being able to comment. In default installs you will rarely see authenticated users who aren't members and in custom environments using the member role is unlikely. Curious what others think. Thanks! ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] FWT Meeting Tuesday
Eric Steele ems...@psu.edu writes: I'd like to have a quick meeting on Tuesday, Nov 9 to go over divvying up the submitted implementations, set a deadline, and discuss the merging of the Zope 2.13 and CMFPlone PLIPs. Sounds good, gonna send out another Calliflower invite? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PloneConf2010 FWT Dinner
Eric Steele ems...@psu.edu writes: Let's plan on Friday night for a Framework Team dinner. FWT alumni are invited, as well as whatever UI team members are here. I'd also like to have Israel, as our de facto docs team leader, join us. Any suggestions on a location? I'll be there. Also, I think it's about time for specifics. Can we at least set a time so I know what to plan for tonight? Thanks! Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Our next meeting – PLIP-a -thon part 1
Eric Steele ems...@psu.edu writes: We've got 30 PLIPs in for 4.1 already (http://dev.plone.org/plone/report/24), so it's time to get together and start talking. Can I assume that next Tuesday at 14:00 UTC will work, or should I set up another Doodle thing? If that's the same time as the last meeting, that works for me. The last meeting was at 10AM here on the pacific coast. The web sites I'm consulting to translate 14:00 UTC to my time, however, seem to indicate that's *way* too early in the morning. I apologize in advance for my time zone ignorance, but can someone tell me what time that is on the pacific coast? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Beta 1 is (essentially) out! FWT, your job is done.
Hanno Schlichting ha...@hannosch.eu writes: 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. FWIW, if it's not *undesirable* to have FWT members stay on, I'd very much like to continue as a FWT member. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Framework Team: Time is short, we need your reviews.
Eric Steele ems...@psu.edu writes: Framework Team, Friendly cajoling has not produced results, so the time has come for some public shaming. Your initial 2 week PLIP implementation review period came and went. We added another week. With 24 hours left on that new deadline, we're not much closer to being finished. Shame. Shme. We'd agreed that each of you would review a minimum of 6 PLIPs. Here's the breakdown of what you've done so far vs what you signed up for: David Glick 5 of 7 Calvin HP 0 of 6 Alec Mitchell 5 of 6 Ross Patterson0 of 8 Raphael Ritz 0 of 0 Erik Rose 3 of 7 Laurence Rowe 1 of 2 Matthew Wilkes0 of 6 In total: 14 of 42. Ugh. Half of the team hasn't completed even one review, which tells me that providing more time won't be at all productive. In order to have any sort of discussion, we're going to need at least one full review per submitted PLIP. To this end, I'm assigning you each 1-2 PLIPs to cover so that we can move on and stop delaying Plone 4. I've tried to account for relative complexity of each PLIP, the number you've completed so far, and the number I think you can realistically complete before tomorrow's FWT meeting (I'm leaving out Raphael because I haven't heard a peep from him in 6 weeks). 9214 Support logins using e-mail address instead of user id Erik Rose 9249 Add TinyMCE as the default visual editor David Glick 9263 GenericSetup syntax for importing Sharing page rolesCalvin HP 9283 A more lightweight backend for collections Alec Mitchell 9288 Improved commenting infrastructure Laurence Rowe 9305 Use real names instead of usernames Ross Patteson I'm working on this one now. Pretty much done and a pretty clear +1. 9309 Better search for East Asian (multi-byte) languages. Matthew Wilkes 9310 User registration process more flexible Ross Patterson Done, doesn't work for me, so -1 unless it can be fixed. 9311 Clean up of user related actions UI Matthew Wilkes 9321 Reimplement the search form with an eye on usability Erik Rose 9330 Add ability to choose role when adding new site members Eric Steele I'm signed up for this one. If I have time to get to a 3rd one, would this be the best one? 9352 Search results improvements Calvin HP In conclusion: Shame. Sooowwwy! :) Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Framework Team: Time is short, we need your reviews.
Takeshi Yamamoto t...@mac.com writes: Hi Ross, Hi! I really hope your PLIP gets a proper review. I had to turn it down because I know next to nothing about unicode/multi-byte. :( For PLIP9309, Any errorlog or traceback available? Actually, PLIP9309 is working well without sitecustomize.py on my OSX Leopard. See what you quoted below, I was replying to 9310, not 9309. :) Ross On Sep 10, 2009, at 1:20 AM, Ross Patterson wrote: 9309Better search for East Asian (multi-byte) languages. Matthew Wilkes 9310User registration process more flexible Ross Patterson Done, doesn't work for me, so -1 unless it can be fixed. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP load test reports available
You can find funkload load test benchmark reports and comparisons at: http://weblion.psu.edu/static/loadtesting/plone4.0/plips.html The buildout logs for the individual plips can be found with the same name as the *.cfg file substituting .log for .cfg in: http://weblion.psu.edu/static/loadtesting/plone4.0/ So if a PLIP looks like it has erroneous results take a look at the log and let me know if there's anything to be done to get valid results. Do this soon since the EC2 instance is costing me money so I will take it down soon and I won't want to set the whole thing up again once I take it down. You may also be interested in the following: - Plone 4.0 base against Python 2.4, 2.5, and 2.6 http://weblion.psu.edu/static/loadtesting/plone4.0/base.html - Plone 4.0 against Plone 2.5, 3.0, and 3.3 http://weblion.psu.edu/static/loadtesting/plone4.0/versions.html - Plone 3.3 write conflict error comparison http://weblion.psu.edu/static/loadtesting/plone4.0/threads-retries.html (interesting how well 1 ZEO client with 1 thread does against 2 ZEO clients with 1 thread each) Limi and I are working on adding some explanatory text and legends to these reports but for now this is all you get. :) Click through and around and if there's anything you still can't make sense of, ask and I'll see what I can do. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP load test reports available
Ross Patterson m...@rpatterson.net writes: Maurits van Rees maur...@vanrees.org writes: On Sun, Sep 06, 2009 at 05:52:52PM +0800, Martin Aspeli wrote: This is really good stuff! I must admit, I don't understand the graphs or the tables-of-graphs at all, though. Is there a quick explanation somewhere about how to read them? The reference bench results are for Plone4 without plips. The challenger bench results are for one of the plips. If the graph is mostly green, the plip has better performance. If the graph is mostly red, the plip has worse performance. Thanks for the documentation, very helpful! For each plip three tests have been done, showing performance for: - content creation - read only - heavy writes I don't know what is being tested exactly. See the tests package in collective.coreloadtests. Should be very readable: http://dev.plone.org/collective/browser/collective.coreloadtests/trunk/collective/coreloadtests/tests Also, using the funkload test recorder makes creating new tests pretty easy: http://funkload.nuxeo.org/#test-recorder On the front page of the tests at http://weblion.psu.edu/static/loadtesting/plone4.0/plips.htmlyou have per plip the following items: - label/name of the plip - for each of the three tests: - main graph, with link to detailed report of the plip - main difference graph between plip and plain plone, with link to detailed difference report Take the diffence page for plip 9310 showing heavy writes: http://bit.ly/vN9kJ The first graph has the requests per second. The blue line shows the results for B1 (bench 1, plain plain 4.0) The purple line shows the results for B2 (bench 2, plip 9310) The first part shows the difference between those lines as red, meaning that the plip is slightly slower; this part of the graph is for 1-3 concurrent users. To the right we have a green difference, meaning that the plip is faster, even up to 80% for 10 concurrent users. Actually, this is one of the invalid tests. If you look at the test data you see that it has 100% test failure. This is probably why the through put was so high. http://weblion.psu.edu/static/loadtesting/plone4.0/test_WriteHeavy-20090906T002920-plip9310-flexible-user-registration/index.html#test-stats So the things that should raise a flag are differential graphs with solid color (red or green) between the curve and the X axis, and individual test report graphs with a horizontal red line at the top of the bottom portion (the error portion, only present if there are hours), of the per-test report image. Another with problems: http://weblion.psu.edu/static/loadtesting/plone4.0/test_WriteHeavy-20090906T044758-plip9330-choose-member-role/index.html#test-stats Ross If results look too absurd, probably something went wrong in the tests. For example plip 8814, replacing secure mail host, looks totally red. Apparently with that plip we serve a whopping zero pages per second. :-) Exactly, and that's where the *.log files come in. Also, clicking through to the individual test report might also be informative. I hope that clears things up a bit. Greatly, I think. Thanks so much. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP load test reports available
Eric Steele ems...@psu.edu writes: Thanks so much for doing these Ross! These Plone 4 vs previous versions comparisons are going to be great for marketing. I'll put out a post touting our progress on Tuesday (was going to do it Friday, but didn't want to see it swallowed up by the holiday weekend here in the US). One thing we need to keep in mind with the PLIP comparisons is that many of them haven't merged in changes to CMFPlone and other packages since they did their initial branches so that may be one of the factors in their speed differences. Any chance we can get implementers to do this? I'll have to check with the guys at the office, but we may be able to spare a VM to do this sort of thing regularly. FYI, I've been doing these on a m1.large Amazon EC2 instance (2 cores, 8GB). Not ideal from a clean slate, predictable, consistent baseline perspective, but more so than anything else I have at my disposal. Ross On Sep 6, 2009, at 5:03 AM, Ross Patterson wrote: You can find funkload load test benchmark reports and comparisons at: http://weblion.psu.edu/static/loadtesting/plone4.0/plips.html The buildout logs for the individual plips can be found with the same name as the *.cfg file substituting .log for .cfg in: http://weblion.psu.edu/static/loadtesting/plone4.0/ So if a PLIP looks like it has erroneous results take a look at the log and let me know if there's anything to be done to get valid results. Do this soon since the EC2 instance is costing me money so I will take it down soon and I won't want to set the whole thing up again once I take it down. You may also be interested in the following: - Plone 4.0 base against Python 2.4, 2.5, and 2.6 http://weblion.psu.edu/static/loadtesting/plone4.0/base.html - Plone 4.0 against Plone 2.5, 3.0, and 3.3 http://weblion.psu.edu/static/loadtesting/plone4.0/versions.html - Plone 3.3 write conflict error comparison http://weblion.psu.edu/static/loadtesting/plone4.0/threads-retries.html (interesting how well 1 ZEO client with 1 thread does against 2 ZEO clients with 1 thread each) Limi and I are working on adding some explanatory text and legends to these reports but for now this is all you get. :) Click through and around and if there's anything you still can't make sense of, ask and I'll see what I can do. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
Wichert Akkerman wich...@wiggy.net writes: On 7/27/09 1:38 PM, Rob Gietema wrote: Hi, I'm currently working on TinyMCE for Plone 4 and would like some feedback on two issues: 1) The current code base is located in the Collective. Since TinyMCE will be the default editor in Plone 4 should I move (copy) the code base to Plone SVN? -0 I see no reason to move it. 2) I'm currently using the Products namespace for the package. Would it be better to switch to the plone(.app) namespace for Plone 4 (and keep the Products.TinyMCE for Plone 3)? -1 There is no benefit to moving, and this will make it harder to maintain Plone 3 and 4 trees in parallel. I'm -1 to both of these, potential disruption for no benefit I can see. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Please accept PLIP #9305 (Use real names instead of usernames)
Hi Laurens, Your PLIP #9305 (Use real names instead of usernames) has been accepted by the FWT and I volunteered to oversee this PLIP. Can you log into trac and accept the PLIP ticket there and comment to confirm that you intend to implement this PLIP? Thanks! Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Please accept PLIP #9214 (support logins using e-mail address instead of user id)
Hi Maurits, Your PLIP #9214 (support logins using e-mail address instead of user id) has been accepted by the FWT and I volunteered to oversee this PLIP. Can you log into trac and accept the PLIP ticket there and comment to confirm that you intend to implement this PLIP? Thanks! Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP activity list
Since there are some of us on the FWT that want to follow all PLIP activity and some of us who find that it's too much noise, we thought we might start a PLIP activity list. This list would be copied on all trac PLIP activity. Steve, can you set us up with a list? Plone admins, is there a more automatic way to get that list copied on PLIP activity than manually adding the list address to each PLIP's CC field. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 FWT meeting summary 2009-06-23
Eric Steele ems...@psu.edu writes: * Timing of call is somewhat inconvenient for some. We'll see if we can reschedule. New poll at http://www.doodle.com/zf9hkvyexzgi98tt,please fill out before next week. We'll meet weekly from now on. My availability is in there now. Thanks! Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2
Martin Aspeli optilude+li...@gmail.com writes: rant Well, I really hate having default content around, that I have to delete all the time and people use in tests that later on break if we change it. The initial content just won't make sense for many sites and people waste huge amount of times to try to get the initial content to match some form of uber-use-case. Has anyone looked at how much time people spent of fixing the nested past events collection? Except that everyone really thinks that nested collections are a bad idea in general and they actually don't really work? And then we have the infamous front-page which welcomes our users to Plone 3.0 with the exact same message up until today? We don't update these things and there's no one driving it. I'd just rather have something be part of the installers that welcomes new users and points to some section on plone.org for continuously updated information. An updated guide on plone.org about Your first steps with Plone - how to create content and a How to organize your content (simple information architecture) stuff would be more helpful and allow users to feel in charge of the content in their site. Right now first time users can't really tell, if those initial folders are content or part of the application logic and won't dare to change them. Not to mention that they create hard problems in multi-lingual settings, where you actually want to layout your site quite differently. So +1 one a welcome screen that isn't content in itself but a big -100 on any content in a new site. That's what demo.plone.org would be for. /rant That was a long paragraph. I think it's important that Plone has at least a welcome page when you install it. Staring at a blank folder_listing is going to put off new users. We can probably bet rid of the News and Events collections, though. I think I'd be opposed to removing the initial content, including the news and events collections, from the Plone installer. I think the batteries included story is very valuable and I love being able to tell prospective clients to just download the installer and start playing. Part of that is being able to add an event to their home folder, publish it, and see it in the listing. OTOH, I'd love to be able to write an client app package where I don't have to start my GS profile by *removing* that content. So I'm +1 for moving the initial content into a separate profile that is only installed by the installer and isn't installed by Add Plone Site. I'm -10 for removing the initial content if it isn't preserved in the installer. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Joel Burton j...@joelburton.com writes: I don't know what the discussion was like in deciding on this date. It may still be the right decision to have it end now. I'm just suggesting that, if it seems that quite a few people may think that this is a slightly-too-soon date, that you may benefit from having that conversation (sometimes, groupthink kicks in and everyone might be assuming this is too soon, but I'm the only person who probably thinks that, so no point bringing it up.) I've definitely been having some concern that valuable discussion might not have an opportunity to develop under the current deadline. Since I don't personally have a problem with this deadline, I haven't been saying much. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Matthew Wilkes matt...@matthewwilkes.co.uk writes: On 20 Jun 2009, at 19:38, Tres Seaver 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. Hmm, the way I see it is that the timeline is deliberately short as 4.0 is an intermediate release. Trunk is the innovative, new thing, 4.0 is incremental upgrades that go beyond a 3.x release. In fact, the release was almost called 3.5 or similar. I don't know how I feel about this, the period is awfully short, but I'm probably leaning towards short keeps things from getting too ambitious. To clarify, I'm definitely on board with the spirit of moving quickly. My concern is that in moving quickly we'll end up missing discussion that needed to happen and that without that discussion we'll end up with a release that is technically short-sighted, demonstrates poor consideration of impacts to the wider community, or any other negative that can result from moving too quickly. So maybe we should re-phrase the question. How fast is *too* fast? What *are* the minimum requirements for discussion of a backwards incompatible major release? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone 4] Framework team, let's talk...
Calvin Hendryx-Parker cal...@sixfeetup.com writes: Here is the link we used to start this process: http://www.doodle.com/ucb3w2fcqieken28 Based on the responses, generally folks are available Monday and Tuesday at 2:00PM US/Eastern time. This works for me, how about the rest? Good by me. Ross On Jun 4, 2009, at 10:21 PM, Eric Steele wrote: Alright folks... now that I'm officially official, it's time we sat down and talked. I'd like to get some sort of phone/iChat/Skype conference together. We're never going to get 11 geographically-diverse people together at the same time, but it'd be great to find something that works for the majority of us. Can I get a volunteer to get this organized? I know that the trunk team had a regular time they'd set up and only used once. Since, er... more than half...I think... of you are on that team as well, is that still an option? I definitely don't want to cut in on Hanno's time with you, but if it's there and not being used, I'm inclined to make a grab at it. ;) Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- S i x F e e t U p , I n c . | http://www.sixfeetup.comPhone: +1 (317) 861-5948 x602 cal...@sixfeetup.com ANNOUNCING the first Plone Immersive Training Experience | Sept. 10-11-12, 2009 http://sixfeetup.com/immerse ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 2009: Going from here
Raphael Ritz raphael.r...@incf.org writes: Eric Steele wrote: Since the new Plone 4 is looking like, essentially, a transitional release, another possibility would be to pull its framework team members from each of the currently-existing teams. I'm with Eric here and offer to participate from the Plone 3 FWT side. Ditto from the 4 side. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
Andreas Zeidler a...@zitc.de writes: On May 5, 2009, at 10:05 PM, Ross Patterson wrote: BLOBs: Has the backups/repozo story been sufficiently worked out? this will need a good backup story, but it won't be via repozo. repozo was meant to backup a single data.fs, but not your entire zodb. the blob storage will tend to be big and might live on some media with other backup strategies (think SAN or S3). there should be some recipe or something that provides a single script to backup both for the standard use-case of having the blob storage live on the same filesystem, but that shouldn't be repozo. I should clarify my question here. Is there an issue with making sure that the backed up BLOB directory is consistent with a particular backed up state of the Data.fs via repozo. IOW, can we say something like so long as you restore your BLOB directory to a state as it was in the same moment or after the repozo process started then it is guataneed to be consistent? I'm not saying that the above statement is correct cause I don't know. :) I'm just saying we'd need to be able to make some promise about repozo backups of Data.fs and backups of BLOB directory being consistent. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
Lennart Regebro rege...@gmail.com writes: On Tue, May 5, 2009 at 22:05, Ross Patterson m...@rpatterson.net wrote: Sorry if I'm resurrecting an already fairly resolved debate. None of the concerns I raise here are enough to vote -1 one calling it 4.0. But if enough people feel as I do here, maybe we should discuss a little further. What about plone 3.9? 3.0.x was very buggy, and I think that has been somewhat saved by the upgrades to 3.1 and 3.2 being so painless. I think it would be, for that reason, a big mistake to introduce bigger changes in 3.X unless we can make sure the upgrade is quite painless and the changes are *very* stable. Yeah, I guess trying to have a release line that can grow is trying to have it both ways. I'm very concerned about the expectations we've been developing about Plone 4 and the impact that will have on perceptions when we say, Yeah, that's plone 5 now or worse yet the even less confidence inducing Yeah, that's plone trunk now. But I guess the right response to that issue is to be more disciplined in our messaging in the future and *not* talk about release numbers before the release process has had a chance to weigh in. IOW, any perceptual/expectation problems we have from this may be our just desserts. :) +1 to calling it 4.0. +1 to constraining ourselves to not include additional disruptive changes in the newly established 4.0 line and thus to only include them in subsequent major versions. +100 to not talking about version 5 until the 5 FWT has actually done enough of it's process to have some formal establishment of expectations. Then I'll just have to buck up and tell people that a better skinning story will *not* being Plone 4 afterall and that I can't tell them it will be in Plone 5 and that somehow they shouldn't be discouraged by that. :( Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone Messaging
JoAnna Springsteen jluv...@gmail.com writes: So could a team be formed or delegated with the responsibility of reviewing Plone messaging? Would such an institution be a slippery slope to too much dogma or other stifling restriction? What might be some other ways to improve messaging in Plone communities? Is this an issue we're already addressing sufficiently and we just need to give it time? Is there a value to enshrining this process even if it's already happening? Is this not an issue? :) I believe that this is already being addressed with the work Gabrielle, Mark, et. al. have been doing. It's slowly becoming more and more visible (15 Questions, organized representation at events like NTEN World Internet Expo, etc). While I'm not sure exactly who all is involved on the team, from what I've heard, there is a plan taking shape. I'm sure, like most of our teams, they probably need more help. Personally, I think one of the things that would help is a formal PR/Marketing/Evangelism contact so that any journalists looking to write about Plone or any press releases put out always have a representative to go to. Establishing a relationship with the such people can be very valuable when it comes to promoting events like World Plone Day or the Conference. Telling people to contact a mailing list just isn't enough (tho I think it should still be done so we have a record of such messages/inquiries). Establishing a leadership team for the doc team has helped us get organized and we operate much like the framework team. Having a recognized leadership for all of Plone's working groups might benefit from a guiding team? I meant messaging in a sense larger than just marketing. I think we need to better communicate with and educate our communities of consultants, developers, and users regarding subjects other than just marketing and press. For example, what expectations should consultants communicate to technically minded clients about features in the next release? When a sysadmin and sometimes hacker at a non-profit gets excited about Plone and starts advocating for its usage internally, what will she have read that helped her set expectations that will guide her towards success? What will a consultant have read by the time they decide to start taking on Plone jobs to help guide ethical and successful consulting? If any of these people started or joined discussions on IRC, on the mailing lists, or at a conference, will the community members participating in those discussions have encountered enough queues about appropriate messaging? 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? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.3b1 tagged and uploaded
Wichert Akkerman wich...@wiggy.net writes: I have tagged and uploaded Plone 3.3b1. This is a first beta release, so please everyone: test the hell out of it! Unless any unexpected problems surface I intend to make a release candidate release in 3 weeks. I just wanted to draw attention to the following bug concerning PLIP #239: https://dev.plone.org/plone/ticket/9035 This bug is breaking nearly everything that still uses registerIndexableAttribute and that's keeping me from testing 3.3b1 much in the wild. Thanks! Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP Community Imapacts
Israel Saeta Pérez dukeb...@gmail.com writes: On Fri, Mar 13, 2009 at 7:16 PM, Ross Patterson m...@rpatterson.net wrote: Ross Patterson m...@rpatterson.net writes: 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. One of the hopes I have for this is that many times when a PLIP contributor goes to say Here's where to find documentation, they'll discover it doesn't yet exist and that these discoveries might be a part of substantially improving Plone documentation. At any rate, I'd like to open this up for discussion on this thread. We're already working on PLIPs' documentation and hope each Plone new version now comes with updated docs at plone.org reflecting improved and new features, so all the community will be able to benefit from them. :-) I guess what I'm proposing is either an additional documentation effort or a further clarification or honing of the intention of documentation efforts associated with PLIPs. Specifically, that some effort to address community impact should be a part of documentation efforts. Just to collect feedback, is your comment that you don't think this additional intention/focus doesn't bring additional value sufficient to formally include it in the PLIP process? Thanks! Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Quick team meeting
Hanno Schlichting hanno...@hannosch.eu writes: Thanks for taking the initiative here. I'll not gonna make it to todays tune-up nor the conf call, though :( 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. Some of the discussion centered around possible changes or clarifications to the PLIP process. This begged the question, where is PLIP procedure documented? 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. 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. 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. The last item concerned future meetings. When should we do this meeting in the future? Every other week or every third work? Thursday? Friday? Would all of the FWT members weigh in with both preferences and outright scheduling conflicts for future meetings. Then we can reconcile that information and schedule a regular meeting. Those present on the call can add details in response to this message and discussions can start from there. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Scheduling 4.0 FWT Meetings (was: Quick team meeting)
Ross Patterson m...@rpatterson.net writes: The last item concerned future meetings. When should we do this meeting in the future? Every other week or every third work? Thursday? Friday? Would all of the FWT members weigh in with both preferences and outright scheduling conflicts for future meetings. Then we can reconcile that information and schedule a regular meeting. I prefer any day in the middle of the week, Tues-Thurs, since I'm much more likely to have to miss meetings on Fridays or Mondays. calvinhp also raised a good point that people doing their 10% Plone on Fridays could use a Thursday meeting to inform their work on Friday. Similarly, I think later in the week is better than earlier in the week, such as Tuesday or Wednesday, because it can help inform work done over the weekend. My only preference for time is that it be after 10AM Pacific time. :) Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Quick team meeting
Hanno Schlichting hanno...@hannosch.eu writes: 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. Yeah, I'm now finding myself rethinking documentation. It might help focus to think of it as communication, where the problem being solved is communicating to the wider community. 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. That's an excellent point to tie into. If we do most of the work as a part of the PLIP, then that'll increase the likelihood of effective documentation making it into such an upgrade guide. 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. Yeah, I just want to make sure that it's *structurally* a part of the PLIP process. Ross ___ 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
Hanno Schlichting hanno...@hannosch.eu writes: 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. I think this is just meant as a *sample* week to be used to set the recurring meeting time for widest possible attendance so don't worry if you're gone *that particular* week. Right? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP Community Imapacts
Jon Stahl j...@onenw.org writes: Ross Patterson m...@rpatterson.net writes: 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 FWIW, Joel Burton raised some concerns along these lines as well when I spoke to him a couple of weeks ago. We hashed around the idea (which I've also spoken of with Alex) of actually doing some sort of in-person focus group style event, where the P4 FWT could present some of the work-in-progress on Plone 4 (e.g. deliverance, dexterity, deco) to a small panel of selected community members (e.g. trusted typical integrator types) to get feedback not only on what we need to improve/document better but also how we should go about best explaining/framing the changes so they don't cause undue alarm. I like that idea. We, as developers, may be liable to miss the target when trying to address community impact without such direction. I would be willing to do some work to help organize such an event, and I would not at all be surprised if the Foundation were willing to provide some underwriting (e.g. buy some plane tickets) but of course it is the participation/leadership of the FWT that would be the key to making it happen. I'd like to hear about how wide interest in this might be. Anyone? I could imagine this event, with fewer than 20 people, happening on the east coast USA sometime this summer (much depends on code readiness, I suppose). One might potentially define this as a spiritual successor to the 2008 PSPS event, but I would avoid using the terms strategic planning or summit to describe it. Maybe a Plone 4 Framing Workshop. ;-) East coast... summer... Ugh. :) The Californian, Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP Community Imapacts
Jon Stahl j...@onenw.org writes: East coast... summer... Ugh. :) East coast is significantly easier for the Europeans, both in travel time and intensity of jetlag. But all is open to discussion. They rallied to CA for the PSPS. :-) Just to be clear that was an utterly petty response about the location and should in no way be taken as feedback or comment. I won't even comment on the general European lack of fortitude. :) Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP lifecycle
Hanno Schlichting hanno...@hannosch.eu writes: The exact way to involve the UI and documentation team needs to be defined. I think we should write up the process first and then sent it for comments to the two others team. We can incorporate their feedback in terms of when and how they like to be involved. It seems like it's important that this part be both structural and lightweight. By structural I mean there should be more than just a we should think about docs when discussing the PLIP gesture. We could define this either through procedure alone or through the tools. Could we include reviews by the other teams in the Trac workflow for PLIPs? That would remove any requirement that someone on the FwT *remember* to check for the external team reviews. :) One way to keep these cross-checks lightweight might be to start with a statement of impact. There are code changes, for example, that have no UI impact. In such cases, it would be fast and more painless if a PLIP champion noted this. Someone from the UI team could then corroborate that the PLIP entails no UI impact and that would be the end of it. If there is an impact, then the PLIP champion would need to include full UI consideration for the impact in the PLIP. The UI team could then review both the statement of impact for accuracy and the UI consideration for sufficiency and completeness. The same would largely be true for the doc team with the exception that, IMO, all changes have a documentation impact even if it's only for developers and so there should be no option to declare no impact. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
Hanno Schlichting hanno...@hannosch.eu writes: - Plone 4 will be primarily a feature based release, not time-based ... - Plone 4 will be released based on an agile approach +1 I like this approach a lot. I've been worrying about how to be ambitious while still ensuring that Plone 4.0 is something more than perpetual pie-in-the-sky. The proposed approach seems to strike an ideal balance. We need to address various major problems with Plone of which some will block a new release from my point of view. For example noticeably increased performance, unifying similar concepts (portal skins vs. Zope3, viewlets vs. macros vs. portlets), a better page composition story (no more folder_listings, display menu) and a leap in our technical base (Python 2.6 and WSGI). +1 There are a lot of issues I think need urgent improvement in Plone, but I also agree it's important to be as conservative as we can in terms of what issues we allow to block Plone 4. This list is pretty much exactly what I'd restrict myself to were it left to me. The possibility to easily use a non-Archetypes based content type story is blocking a new release for me as well. Switching to a new default story is something I don't consider possible in the next year right now, but might be convinced otherwise. +1 I think it would be a mistake to switch to a non-AT based story as the default story before 4.5. My reasons are largely psychological and anthropological. I think many in the integrator community and the accidental-technologist-turned-developer community are dealing in part with a sense that Plone is too much of a moving target. OTOH, many in the developer community, such as myself are having less fun coding with Plone because of all the history represented in the code base. Many in the consultant community are also having more pain from projects that find the learning curve and rabbit holes that stem from keeping history alongside new technology. It seems that we have fairly widespread agreement that getting this balance right is one of the most important things we need to fix with Plone 4. So I would like to see something of a slight-of-hand here. I'd like to get us to the point where there is a new content type/schema definition story that will make developers happy again. I'd also like to ensure, however, that small Plone deployments with a few custom AT content types don't have a psychological assault when they *read* that AT is no longer the The Way in Plone 4. I'd prefer a carrot to a stick. Your AT content types should be fairly easily portable to Plone 4! BTW, if you want your content types to perform better, take a look at dexterity (or whatever)! I think it's also important, however, that there be a *flavor* of Plone that uses *only* the next generation of content type/schema definition for those developers like myself that are eager to just move on. Fortunately, this seems easily doable in a setuptools world. Of course this raises the concern of yet again running two different technologies side-by-side. To mitigate this, I'd be in favor of moving very quickly to a 4.5 that completely removes AT as a part of Plone-the-product at the very least. Ross ___ 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 tsea...@palladion.com writes: Ross Patterson wrote: Tres Seaver tsea...@palladion.com writes: 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've never actually understood how a dump-and-reload approach would be inherently more maintainable or otherwise more trouble-free. I know this has been discussed before, but I missed those discussions. Can anyone shortcut the research for me and give me some links or pointers to previous discussions? The short answer is that in-place migrations lead to ordering-dependent arrangements of crufty bits in the site: it gets particularly bad when the representation format of the data changes. If the programmer is both careful and lucky, she can often mitigate the problem with clever defaults, properties, etc., but the downside is that the BBB-driven code has to stay around *forever*. Thanks, that's exactly what I wanted to hear. So it's not so much about being inherently easier to implement as it is about enabling the removal of code. In that case, I'm +1 on this but I have other concerns. Dumping the content out to a neutral format and loading it into a clean site loses the crufty bits, and leaves the code in the new software free of nasty BBB stuff. It also gives people a migration target (for moving content into Plone, or even out of it), as well as a non-ZODB-specific backup representation of the site (e.g., to populate a staging / testing server). It seems like this this dump format will likely become a point of hackability in our software ecosystem. People out there will find interesting things to do with it aside from dump-and-reload. This would be a good thing except we're *expecting* the format to be unstable and change rapidly. It seems possible that there would be some ruffled feathers out there amongst those who come to depend on such hacks and then find that their favorite hack is quickly broken by the next release. As such, it seems like it would be a good idea to dress up the dump format in flashing red lights and loud alarms to discourage at least the adoption of such hacks if not their creation. It also seems like the complexity of this dump format is easily underestimated. I'm a little concerned that we'll adopt a solution that is more accidental in nature, such as an extension to the current GS handlers. I suspect that later we'd find some structural inadequacies in such an approach but having already build our upgrade machinery around it we'll have yet another painful change to make as we change to something better designed. OTOH, perfect is the enemy of good enough. I suggest we start with a *minimal* design discussion about how to architect a dump-and-reload strategy with the future in mind. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] Re: Plone 4 Framework Team Selection List
Tom Lazar li...@tomster.org writes: On 18.12.2008, at 11:48, Wichert Akkerman wrote: On 12/18/08 11:43 AM, Tom Lazar wrote: and therefore should be reflected in the membership of the group which makes decisions based on those factors. i think that conclusion is the only part where we disagree. can we agree at least on that? ;-) Not without a way to guarantee that user interface will be a full part of the process, which incudes the guarantee that everything will go through a proper user interface review done by people with the right skillset, and can be rejected even if just the user interface is not up to par. ... but perhaps we could make the 'UI impact component' a formal part of the evaluation of a PLIP, i.e. add it as a formal part of the structure of a PLIP (in addition to the current ones such as Deliverables, Participants etc.) that way the issue could never be missed (i imagine that many UI flaws come into existence because technical people didn't realize there *was* a UI perspective to the given issue). Also, it would make it easy to get an overview of the UI impact of all of the submitted PLIPs by simply focussing on those parts of the PLIPs. anybody care to add their $0.02? It seems clear that everyone agrees that UI concerns need to be included in the review process. There doesn't seem to be agreement on retracting the FWT selection. For my money, I think any sort of retraction or re-openning of the process would be a mistake. I also think that simply saying Don't worry, we'll consider UI could be inadequate to ensure UI is considered sufficiently. It is most certainly inadequate to redress the concerns of those who raise the complaint and agree with it. So I think it makes a lot of sense to find an alternate way to formalize the inclusion of UI concerns into the review process. As such I'm +1 on formalizing the 'UI impact component' part of the PLIP process. More specifically I think we should require that every PLIP have a UI expert weigh in on the estimation of UI considerations and if a PLIP has UI considerations then we should require that a UI expert fully reviews those UI impacts. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] Re: Plone 4 Framework Team Selection List
Ross Patterson m...@rpatterson.net writes: Tom Lazar li...@tomster.org writes: On 18.12.2008, at 11:48, Wichert Akkerman wrote: On 12/18/08 11:43 AM, Tom Lazar wrote: and therefore should be reflected in the membership of the group which makes decisions based on those factors. i think that conclusion is the only part where we disagree. can we agree at least on that? ;-) Not without a way to guarantee that user interface will be a full part of the process, which incudes the guarantee that everything will go through a proper user interface review done by people with the right skillset, and can be rejected even if just the user interface is not up to par. ... but perhaps we could make the 'UI impact component' a formal part of the evaluation of a PLIP, i.e. add it as a formal part of the structure of a PLIP (in addition to the current ones such as Deliverables, Participants etc.) that way the issue could never be missed (i imagine that many UI flaws come into existence because technical people didn't realize there *was* a UI perspective to the given issue). Also, it would make it easy to get an overview of the UI impact of all of the submitted PLIPs by simply focussing on those parts of the PLIPs. anybody care to add their $0.02? It seems clear that everyone agrees that UI concerns need to be included in the review process. There doesn't seem to be agreement on retracting the FWT selection. For my money, I think any sort of retraction or re-openning of the process would be a mistake. I also think that simply saying Don't worry, we'll consider UI could be inadequate to ensure UI is considered sufficiently. It is most certainly inadequate to redress the concerns of those who raise the complaint and agree with it. So I think it makes a lot of sense to find an alternate way to formalize the inclusion of UI concerns into the review process. As such I'm +1 on formalizing the 'UI impact component' part of the PLIP process. More specifically I think we should require that every PLIP have a UI expert weigh in on the estimation of UI considerations and if a PLIP has UI considerations then we should require that a UI expert fully reviews those UI impacts. Oh, BTW, I'm +10 for doing the same for Documentation. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: five.intid compatible with five.localsitemanager
Martin Aspeli [EMAIL PROTECTED] writes: As a general point, it's almost never necessary to cross-post to the plone-devel and plone-framework lists. The framework team uses the latter to discuss their business, and some of the more tactical how-to-we-manage-the-release-process discussions tend to go there, but I guarantee you every member of the framework team reads the plone-devel list as well. The framework team list is not a more important version of plone-devel (though I can understand how perhaps it may seem that way). plone-devel is still the place to discuss general issues concerning development of Plone itself. I posted to framework because it was one of the only places I found any previous discussion of five.intid. I will not post to the framework list again. Ross ___ Framework-Team mailing list [EMAIL PROTECTED] http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: five.intid compatible with five.localsitemanager
Martin Aspeli [EMAIL PROTECTED] writes: I posted to framework because it was one of the only places I found any previous discussion of five.intid. I will not post to the framework list again. I didn't say that. :) We don't mind non-framework-team members posting there, especially if it's something pertaining specifically to review bundles or important messages about getting things in shape for the release. However, general Plone core development discussion belongs on plone-devel. In fact, this question probably belong on plone-user or the Five lists, since five.intid is not a part of Plone core, but let's not quibble. The discussion in this thread is useful and important. I just fount it a bit annoying having every post in this thread show up three times in my newsreader. :) Ok, well I will be more careful in my posting then. :) Thanks, Ross ___ Framework-Team mailing list [EMAIL PROTECTED] http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: five.intid compatible with five.localsitemanager
whit [EMAIL PROTECTED] writes: Ross, let me know if there is anything I can do to help you with a release(or if you need me to make one). fiancé is out of town this weekend and I'm going to dedicate an evening or two to stuff like this. Firstly, I just want to reiterate that merging this branch as it currently is will *break* five.intid without five.localsitemanager and it looks like five.localsitemanager isn't compatible with Zope 2.10. So are you giving me the go ahead for that? Or are you giving me the go ahead to factor out the bits that are dependent and making them dependent on a conditional of successful import of five.localsitemanager? IOW, do you want to maintain Zope 2.9 compatibility? try: import five.localsitemanager except ImportError: USE_LSM = False else: USE_LSM = True ... if USE_LSM: make_objectmanager_site(...) else: enableLocalSiteHook(...) I'm not up to speed on eggs yet and don't have the time to get up to speed just now. So I'll do what I can to setup the egg dependency on five.localsitemanager but if you could test the egg specific bits for me, that would be great. Other than that I can cut a release myself once I get your final word. Thanks! Ross ___ Framework-Team mailing list [EMAIL PROTECTED] http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] five.intid compatible with five.localsitemanager
I need five.intid in Plone 3.0 so I started a branch that is compatible with five.localsitemanager as is used in Plone 3.0/Zope 2.10: http://svn.plone.org/svn/collective/five.intid/branch/localsitemanager/ Is there any interest in integrating this into five.intid/trunk? If so I'd be happy to factor out the necessary bits and make them conditional on successful import of five.localsitemanager falling back to the Zope 2.9/non-localsitemanager bits as appropriate. If not, can anyone reccomend an alternate approach that doesn't involve maintaining a separate branch? Ross ___ Framework-Team mailing list [EMAIL PROTECTED] http://lists.plone.org/mailman/listinfo/framework-team
