Re: [Framework-Team] Re: PLIPs in Trac
On Jun 18, 2009, at 11:09 PM, Martin Aspeli wrote: Hanno Schlichting wrote: ... I wrote a big reply to Matt, and ditched it. +100 to everything you said. :) I'd suggest that: a) We now formally ask PLIP authors to write to the plone-dev list (not this list!) announcing their PLIPs and asking for feedback. We can use a convention like prefixing the subject with [PLIP]. Anyone PLIPs that don't have this degree of commitments should be ignored straight away. b) At the same time, the FWT can go and unassign the milestone for any PLIP that is obviously a feature request or lacks detail. Just do that with a comment explaining why. If the PLIP gets fleshed out (maybe following a), we can always re-assign it. c) We communicate a deadline for PLIP evaluation. We'll need to leave a couple of weeks for this discussion/fleshing out to happen, I think. But not too long. Two or maybe three weeks max, I reckon. d) We get into the habit of sending reminders to plone-dev (and possibly planet.plone.org for the important ones) when deadlines are approaching. I think it needs to be part of the release manager's job to send a 2 week reminder, a 1 week reminder and a tomorrow reminder for each milestone date. I know this feels like baby sitting, but trust me - it'll save a lot of gnashing of teeth later. Finally, we *need* to be better to managing deadlines and dates. I for one have too many calendars and a short memory. It all gets very confusing. I would suggest that we set up one Plone Release calendar on Google Calendar and add every deadline and target release date to this. We then link to this prominently from dev.plone.org and in every FWT communique. Martin I have little to add to what Hanno and Martin have stated so well here. To me, what shortcomings the Trac-based approach may have are trivial enough for me to largely overlook and can be covered through some further integration work by the plone.org team and/or better documentation of the process. I've been getting a sense of frustration from new folks we've let into the system looking to help but are getting shot down with that's a feature request. While that may be the case, I really don't want to see these potential contributors feeling dismissed. Can we come up with some strong documentation on where the leap from feature request to PLIP lies? I'm sure you'll all get sick of hearing me say it, but this Plone has a very short timeline. While all major releases have had to find the fine balance of time between discussion, implementation, review, and releasing, it's even more of a struggle with this one. We currently have a 10 day window scheduled for PLIP discussion and voting. I'm inclined to stick to that, with a strong admonition to all involved that time required to complete the proposal is just as important a consideration as its technical merits. I'm not completely inflexible on that timeframe though. I already have a calendar started. I'll work on getting that filled out, published, and publicized ASAP. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: update on supporting Python 2.6 / Zope 2.12 / CMF 2.2
On Sat, Jun 20, 2009 at 12:17 PM, Martin Aspelioptilude+li...@gmail.com wrote: - c20188, c20190, c23197 — removal of PloneFolder (hannosch) — need to double check whether this requires a migration for any persistent objects, and write that if necessary +0 to remove. There's no persistent stuff based on that particular class since Plone 2.1. What is still left is the OrderedContainer implementation inside the PloneFolder module, as this is used by the PloneSite object itself. This ought to be cleaned up since OFS has almost the same implementation, but this is a different task. The temporary folder used for the FactoryTool was based on this as well, but can use the PortalFolder from CMF instead. It's just faking some more rich environment to create a new content object in and luckily never persisted. - c20337, c20338, c22979, c22981, c22988 - switch the control panel to be based on normal actions in a new action category, rather than using a special control panel tool (hannosch) — see also http://dev.plone.org/old/plone/ticket/8804 +0 - we need to make sure the existing controlpanel.xml import step continues to work. There's an extra PLIP for this for Plone 5. Especially since I figured out that actions in their current form are the most critical performance bottleneck we have by a large margin, I don't want to move anything to actions at all anymore. I'd leave these changes out until we have figured out what to do with actions in general instead. Moving more actions to the actions tool will make things slower if we don't include some of the workarounds and hacks I did to the actions machinery all over. - c22831, c22832, c22891, c22951 — remove external editor (hannosch) — see http://dev.plone.org/old/plone/ticket/8592 -0 - people do use this. what's the cost of keeping it? See the ticket for details. It has an extra ticket and needs discussion, so better leave it out for now. The main argument is that it's unmaintained for ages and not used by many. It's a perfect add-on candidate. - c22847 — remove wicked from core (hannosch) — see http://dev.plone.org/old/plone/ticket/8593 (but note that as of this week Carsten Senger has been doing some maintenance...yay!) +0 to make this an add on people can install if they need it, but we should endeavour to make it work for migrated sites This has an extra ticket as well and I'd leave it out of the other changes. There's at least documentation to be done here if we remove it from the core. - c23193 — turning default_error_message into a browser view (hannosch) — seems like a decent idea to me, but as implemented here it removes the redirector and content search features +0 - I think ideally plone.app.redirector should just override this view and do nothing if not explicitly installed. I'm not sure we have time to do that properly, though. I wouldn't touch this. The main reason for these changes are, that the old way of doing things doesn't work in the repoze.zope2 / WSGI world. Exception views, standard_error_message, the error_log and all that stuff simply doesn't work at all. So the whole of p.a.redirector needs to be changed quite a bit to be made to work in that new world. Since WSGI is out of the scope for 4.0, I'd leave these things out for now. - c23198, c23199 — removal of portal_interface tool (hannosch) — if we remove this then we lose the way to check for marker interfaces from action expressions, for instance. also, it's missing a migration +0 to remove. Doesn't plone.app.layout.globals have something for this that's based on a view rather than a tool? I'd leave this in place, but then it needs to be changed to work with zope.interface interfaces instead of Interface stuff. Removing this was made under the assumption that there's no skin templates / scripts left in default Plone that would need this. This won't be the aim for Plone 4.0, so this thing might still have some legitimate use. - c23226, c23233 — moving migrations to plone.app.upgrade and using all GS without the migration tool (hannosch) — -0 from me...I think moving these to a separate package may actually make it harder to keep migrations in sync with the Plone release they belong too, simply from the standpoint of reviewing svn history +1 to move to all GS, at least. I don't have a strong feeling about the package location. Maybe Hanno does? The initial driver for making this into its own package, was that the upgrade steps tend to have dependencies on quite a number of add-ons, like CMFEditions, KSS, portlets, ... for interfaces or to call into code to make some changes. If the Plone distribution itself contains the migration code, it gets all these dependencies pulled in and makes it quite hard to create a minimal base distribution. The way I attacked the unclutter dependencies / base distribution problem is based on the assumption that the Plone distribution itself turns into a no-code, policy distribution of some
[Framework-Team] [Plone 4] June 23, 2009 Framework Team Meeting
FWT! We have a conference call scheduled for Tuesday, June 23 at 2PM EST (1800 UTC). The Foundation Board has given me the go-ahead to try out some different international conference calling solutions in an attempt to avoid the Skype debacle that was our last meeting. I've set up a meeting using Calliflower. They should have localish numbers for most countries (http://apps.calliflower.com/account/call_in_numbers ). Call details are at http://apps.calliflower.com/conf/show/52681. If there are any big problems with this setup for anyone, please let me know and I'll see what else I can work out. At this point, I think we can assume this conference call will be a weekly event. Eric ___ 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Burton wrote: Hello, Framework Team! I, myself, don't have any questions or issues about the PLIP deadline for 4.0. I'm not planning on submitting any PLIPs. Over the past two weeks, though, while chatting in IRC with various framework team members and other core Plone people, at least 5 have mentioned, without my prompting, that the deadline for 4.0 PLIPs seemed awfully fast in coming, and they wondered whether it may have been too aggressive. 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.) Just want to make sure that's not what happens. In any event, have a wonderful PLIP season! I look forward to teaching what you invent. ;) 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. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKPSyl+gerLs4ltQ4RAoVzAJ99H2Gz9+bEt1bRcrUwtN2RPSuU3gCfdDx1 lCfOg4/RoNHxBl22WuPxU/c= =hwMz -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
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. Matt ___ 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
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On Sat, Jun 20, 2009 at 8:38 PM, Tres Seavertsea...@palladion.com wrote: Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. We have a bit of a mismatch between the big plan and what just happened over the last weeks. The way Plone 4 has been schemed out, was indeed to be short-hop release, largely taking already completed work and packaging it up, so we could deliver something to our integrators and end-users while waiting for Plone trunk. What has been done so far, seemed to be largely in the way of baseline technology features, like Zope 2.12, Python 2.6 but also blob support, plone.folder and the various performance improvements in the content creation space. Now I take some blame and credit for the overall plan and I seem to have missed out one important point: our community. It seemed like we had an ever diminishing interest from our community to advance Plone itself over the course of the Plone 3.x timeline. The working assumption that I and others had, was that the current technological complexity of Plone, would cause this decline for a number of months or years. The hope was that after we refurbished some of our underlying technology to become less complicated, we would see a new rise in contributions. Given that idea, I think we have missed to ask our community at large for contributions and didn't give us a clear way to suggest these. Some of the ideas we have seen since the PLIP deadline has been opened are quite unfinished. However what completely positively surprised me was the amount of ideas and people that contributed already. It seems the Plone developer community is still much more alive and kicking than what at least I imagined. The tough call that is on the release manager and the framework team to make now, is how to best serve our community interest and come up with a roadmap that allows us to integrate all the exciting things that people suggested. One thing to remember is that continuously planning the road ahead is much more important than the plans we already made. Personally I'd be in favor of extending the scope of Plone 4.0 to some degree and making a clear commitment to allow quite a number of the suggested features to be done in the scope of Plone 4.1, 4.2, ... releases. Much of the work that makes up Plone trunk (5.0?) today is going to take even more time than we had planned for and is all pretty invasive changes. If our developer community is still so much alive based on our current set of technologies, we can allow ourselves to take some more time to refurbish our backend. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Hanno Schlichting wrote: Personally I'd be in favor of extending the scope of Plone 4.0 to some degree and making a clear commitment to allow quite a number of the suggested features to be done in the scope of Plone 4.1, 4.2, ... releases. Much of the work that makes up Plone trunk (5.0?) today is going to take even more time than we had planned for and is all pretty invasive changes. If our developer community is still so much alive based on our current set of technologies, we can allow ourselves to take some more time to refurbish our backend. I think it's important to get 4.0 out the door quickly so we can start enjoying the benefits of Python 2.6, Zope 2.12 and CMF 2.2. With that in place we will be in a good position to add features in subsequent 4.x releases. So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1, you don't have to wait until 5.0. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On 20 Jun 2009, at 20:54, Laurence Rowe wrote: So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1 With the usual caveat that 4.x releases are as ambitious as 3.x releases. The reason we need a 4.0 release is so we can put the things Laurence mentions through. The place for ambitious changes is still trunk and PLIPs against 5. Matt ___ 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 wrote: On 20 Jun 2009, at 20:54, Laurence Rowe wrote: So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1 With the usual caveat that 4.x releases are as ambitious as 3.x releases. The reason we need a 4.0 release is so we can put the things Laurence mentions through. The place for ambitious changes is still trunk and PLIPs against 5. I want to avoid a mad dash for getting features included with 4.0, so I'd like us to say that any PLIP we would consider for 4.0 we would also consider for subsequent 4.x releases. 4.0 is far less radical than 3.0, so I think we can safely spread out features throughout the 4.x line and not be quite as conservative as the 3.x changes have been. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs in Trac
On Jun 20, 2009, at 5:04 PM, Eric Steele wrote: I already have a calendar started. I'll work on getting that filled out, published, and publicized ASAP. actually, PLIP #246 was meant to introduce the possibility to set up the plone calendar using plone.org itself: keeping all relevant dates in event content within the roadmap section[*] would make it easy to publish a release calendar. using the provided view higher up the hierarchy could additionally be used to include sprints etc or simply all plone events. cheers, andi [*] http://plone.org/products/plone/roadmap/ -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.2.2 released! -- http://plone.org/products/plone/ PGP.sig Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] update on supporting Python 2.6 / Zope 2.12 / CMF 2.2
On Sat, Jun 20, 2009 at 6:47 AM, David Glickdavidgl...@onenw.org wrote: - The current situation with regard to PlacelessTranslationService needs to be reviewed to make sure that our language negotiator and product i18n dirs are still getting registered properly following simplification/removal of Five's Zope2 i18n integration layer. Hanno said he could probably take a look at this. I looked at this now and adjusted the simple missing stuff. A quick test showed that switching the Plone site language to German works correctly and all the UI renders accordingly. There might be some minor issues somewhere, but by and large it just works (tm). This uses PTS trunk which doesn't have a persistent representation in the ZMI Control_Panel anymore, but hooks directly into zope.i18n and registers all po files independent of their location in locales or i18n folders as zope.i18n message catalogs. The nice thing about this is, that no add-on product needs to be changed. - I switched back to Zope 2.12.0b1 for now because with Zope 2.12.0b2 there is an issue preventing the Unauthorized error when you first try to access the ZMI from getting propagated into an HTTP authentication request. I haven't had time to dig into this yet although I did check a non-Plone Zope 2.12.0b2 and it didn't seem to be an issue there. I looked at this as well and hopefully found and fixed the bug in Zope2 itself. Pending David's confirmation :) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIPs in Trac
Eric Steele wrote: I have little to add to what Hanno and Martin have stated so well here. To me, what shortcomings the Trac-based approach may have are trivial enough for me to largely overlook and can be covered through some further integration work by the plone.org team and/or better documentation of the process. I've been getting a sense of frustration from new folks we've let into the system looking to help but are getting shot down with that's a feature request. While that may be the case, I really don't want to see these potential contributors feeling dismissed. Can we come up with some strong documentation on where the leap from feature request to PLIP lies? Eric, We've long lacked a process for average Plone users to make feature requests. But no longer! :-) I hope I've managed to document feature request vs. PLIP reasonably well now at: http://plone.org/documentation/faq/suggest-a-feature-for-plone Please feel free to suggest any ways to make this clearer, or to adapt anything from there onto the dev.plone.org/plone wiki space as needed. best, jon ___ 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
Hi Hanno, 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. We need an instance of some sort to have a place for the zope.conf and site.zcml and start/stop script for one. Since we want to support ZEO and the http port of the webserver is in the zope.conf file, we need the ability to have multiple instances. Since we will need to change quite a bit of that stuff when WSGI hits, I'd rather try to mimic the current behavior / layout as closely as possibly for 4.0, so we don't invalidate the documentation twice. Yeah, +1 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
