Re: [Framework-Team] PLIPs ready for review
Hi, I've just submitted for review plip #9286, and I'll be wrapping up PLIP #9329 until the end of the day. I hope it won't be too late to include it into the review process. Sorry for the delay :) Thanks, Ricardo Eric Steele wrote: The following 27 PLIPs have been indicated as being ready for review: 7822Make standard file content types use ZODB BLOB support 8801Move action icon support into actions, remove CMFActionIcons 8802Move our upgrade / migration infrastructure to GenericSetup 8808Require Python 2.5 or 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0 8814Replace SecureMailHost with a standard Zope mailhost 9186Set Image IDs from Title field 9214Support logins using e-mail address instead of user id 9249Add TinyMCE as the default visual editor 9250Add jQuery Tools to base install 9256Expand variable substitution in mailing action of plone.app.contentrules 9258Replace Products.ATReferenceBrowserWidget with archetypes.referencebrowserwidget 9259Group dashboards 9263GenericSetup syntax for importing Sharing page roles 9264Merge backport patches from plone.app.dexterity into Plone 9272Exposing and editing Dublin Core properties 9284Allow views to override skin layer elements easily 9285Show blocked portlets in management interface 9288Improved commenting infrastructure 9295Improved UI for collections (merged with 9283 for review: A more lightweight backend for collections) 9305Use real names instead of usernames 9309Better search for East Asian (multi-byte) languages. 9316Unify folder implementations 9321Reimplement the search form with an eye on usability 9327Unified interface for lists of content 9330Add ability to choose role when adding new site members 9352Search results improvements We also have 2 PLIPs that depend on the outcome of the theme PLIP and will require a later review: 8805Do not ship with NuPlone anymore 9300Well formed, valid XHTML And two that are installer options: 9314Plone "Developer Pack" option for installers 9322Ensure that Plone 4 can upgrade Zope on Windows and Mac OS X via binary eggs (See our spreadsheet for the full list of PLIPs http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw) If we stick with the 2 reviewers/PLIP that we'd discussed last week, that means at least 6 reviews per FWT member. I'm going to make the assumption that you'll want some help with these. I think there are some cases where we'd be best served having one FWT review and one external review for a PLIP. Hanno has offered to pitch in and I'd like to see him review David's backporting PLIPs. Some would benefit greatly from a UI team reviewer (do we need a UI review of the collections work since half of the UI team worked on it?) I've also asked accessibility evangelist Christian Vinten-Johansen here at WebLion to look at some of these for possible accessibility issues. If there are others you'd like to bring in, let me know and I'll make it happen. Our deadline for reviews is August 30. We can discuss the feasibility of that during Wednesday's call. Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIPs in Trac
Alec Mitchell wrote: I'm in agreement that the plone.org system is preferable; however I think it's probably a little late to change this. It does seem like the "PLIPs" submitted so far are mostly unstructured feature requests. Even the better ones are pretty minimal. I think the same, most of the PLIPs look like feature requests, and I'm not sure if everyone who submitted a PLIP is aware that it means they should be responsible for implementing/championing it... With PLIPs at plone.org there was also the permission "barrier": only people in the core developer team could submit PLIPs. Ricardo On Thu, Jun 18, 2009 at 3:48 PM, Matthew Wilkes wrote: Hi all, I'd like to open a public discussion on where tracs should be. As some of you may know, I'm very much against the PLIPs-in-trac system that has been implemented following out-of-band discussions last year. I think we need to make a proper decision, I'm not sure how that will happen, but if it'll stop me whinging either way. For Plone <4.0 we've put PLIPs on plone.org, this has the following advatanges: - Unique, relatively low number for each PLIP - Custom content type enforces PLIP structure - Workflow matches our process The disadvantage of it being on a different site has been raised, but I don't buy this. How often do you want to look at the bugs and PLIPs for a release at the same time? They have a completely different process. The current crop of PLIPs for 4.0 are very unstructured, only the ones copied verbatim from plone.org have seconders. We're having to bodge workflow by assigning different milestones. It's really suboptimal. Do others agree with me, or do you prefer trac? Despairingly yours, Matt ___ 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 -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIPs for portlet improvements
Hi Framework Team, I'm revisiting PLIP #244: "Site-wide portlets and portlet management improvements". The old PLIP description is at: http://plone.org/products/plone/roadmap/244 The page is showing some markup error... probably related to the recent upgrade. Anyway, based on the feedback I've got, I've updated it and splitted into different PLIPs so we can avoid some unnecessary confusion. These improvements are related, but they don't depend on each other, so even if one is not approved, the other can go ahead. - #9285: Show blocked portlets in management interface Improve the portlet management screen to show all portlets, including the ones that are blocked. This way users are be able to see what's going to be blocked with a whole category and also the ones that are being inherited. https://dev.plone.org/plone/ticket/9285 - #9286: Allow to show/hide portlets Allow the user to hide individual portlets using the portlet management interface with a single click. https://dev.plone.org/plone/ticket/9286 Considering that the other PLIP wasn't accepted due to some UI concerns, It would be great to get some feedback in time to adjust the PLIPs, since I believe these would be really valuable changes. Cheers, Ricardo -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone-developers] The new Plone 4.0
Alexander Limi wrote: On Tue, 05 May 2009 15:56:36 -0700, Ricardo Alves wrote: Steve McMahon wrote: My only concern about calling Hanno's incremental change list 4.0 is that we don't suffer from big-number expectation syndrome. This is the biggest risk I guess, a major release with just a minor set of visible (UI) improvements, will bring bad publicity. I agree — this is the biggest risk in terms of calling it 4.0 instead of 3.5. The consensus to call the 2009 release 4.0 makes sense to me — so +1 on that decision. One way to mitigate this — and make Plone seem a bit more modern along the way — could be to apply the new typography/theme that I'm currently applying to trunk. This is essentially the typography from the plone.org redesign along with a color-neutral design for the navigation and other UI elements. The goal is to make something that you can put the company logo on, and it looks relatively decent, no matter what your company colors are. +1. A refreshed visual theme plus several new features, like blob support or commenting improvements, have the potential to make 4.0 an appealing release. Ricardo -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone-developers] The new Plone 4.0, was Re: Plone 3.5
Steve McMahon wrote: My only concern about calling Hanno's incremental change list 4.0 is that we don't suffer from big-number expectation syndrome. This is the biggest risk I guess, a major release with just a minor set of visible (UI) improvements, will bring bad publicity. If we start thinking that 4.0 "has to be big enough" to justify the numbering jump, and start expanding too much on the "yes" list, we won't get this out in 2009. And, it won't serve the purpose of delivering enough new stuff to keep folks excited while waiting for the big UI items. So, a couple of questions for us all: 1) If we call it Plone 4.0, can we restrict ourselves to a modest list of improvements that will actually get coded this summer and tested this fall? 2) If we call it Plone 4.0, can we resist ourselves to changes that will not break existing theme products or well-constructed Plone 3 add ons? Isn't that already the promise of the 3.x series? I mean, to be keep backward compatibility with Plone 3.0 addons? I still think that some of these improvements should be included in one or more 3.x releases. Ricardo On Tue, May 5, 2009 at 2:20 PM, Ross Patterson wrote: Lennart Regebro writes: On Tue, May 5, 2009 at 22:05, Ross Patterson 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 -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Plone-developers mailing list plone-develop...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plone-developers -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 3.5
Hanno Schlichting wrote: Hi. While everyone is waiting for Plone 4 and its rather long timeline, some people have been thinking about how to bridge the gap between the current stable 3.x releases and the future. The general idea that seems to have met some consensus is to go for a Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5 that is similar in spirit to the Plone 2.5 release. It tries to both refresh some of our technical underpinnings in addition to some more intrusive feature changes we didn't allow ourselves in the 3.x series so far. -1 on skipping 3.4. It will mostly bring more confusion. People will ask why, and most, manly newbies and outsiders who don't understand the complexity of the Plone stack, won't understand the rationale behind it. Also people will expect a 3.5 release to keep the promise of stability of the 3.x series. In order to frame the scope of such a release I made a listing of some of the potential features for such a release at http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list is both non-exclusive and non-binding in the recommendations. It would be great to have such improvements before Plone 4. But I think most of these features, specially the ones tagged as "low risc" can, and should, be included in the 3.x series (3.4, 3.5, ...), without breaking backwards compatibility. Although, some may need special attention in regard to bbb. I don't think there is a good solution here, but it will be less painful if we don't mess up with version numbering. Just my 2 cents :) Ricardo -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #246 ready for review (pending review notes)
Andreas Zeidler wrote: hi ricardo, On Jan 18, 2009, at 1:44 AM, Ricardo Alves wrote: Andreas Zeidler wrote: as a heads-up, the review bundle for PLIP 246 (View for rendering events as an iCalendar file) is ready for review. you can get it from https://svn.plone.org/svn/plone/review/plip246-ical-feed/ I'm very interested in this PLIP, since I've being implementing such feature for several projects and would be great to have it shipped with Plone. From a first look at the review bundle, I have some suggestions: just as a heads-up: i've implemented most of your suggestions by now... actually, i've sneaked in some of the stuff that was discussed during the PLIP review last night after merging things, but don't tell wichert! ;) i didn't get around to do it during the review period (since i was busy reviewing i guess) and went on vacation right afterwards. but well, most of these were only bug-fixes anyway... Awesome :) - I'm not so sure about it, but shouldn't we also support vCalendar? It's still provided for single events. vcal support is still missing, though. while it should be easy enough to do, i considered it too much of a change to still add to the already accepted and reviewed PLIP. i reckon it'll make make a very easy PLIP for 3.4, though... ;) or maybe it could be considered a bug and go into 3.3.1, too. +1 to consider it a bug. Basically, it's about providing the same feature, but for software that still uses vCalendar, and since the individual events also provide it... - Are there any plans to add a new document action for this feature? well, yes. but nothing has been decided really. i asked some people (hint, hint! :)) who were gonna make a suggestion about it, and perhaps it would even still be possible to add it before releasing 3.3, but i'm not sure what wichert thinks about it. maybe we should take some time to finish the discussion and add it to the next minor version... IMHO, the best would be a document action for folders and topics, shown *if* there is something to download. It would be consistent with the current behavior for individual events. Without the action, I guess this will be an hidden feature. Ricardo -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #246 ready for review (pending review notes)
Andreas Zeidler wrote:
hi,
as a heads-up, the review bundle for PLIP 246 (View for rendering
events as an iCalendar file) is ready for review. you can get it from
https://svn.plone.org/svn/plone/review/plip246-ical-feed/
Hi,
I'm very interested in this PLIP, since I've being implementing such
feature for several projects and would be great to have it shipped with
Plone.
From a first look at the review bundle, I have some suggestions:
- We should also support this view in collections/topics. I think it
makes sense, since collections are a common way to list events from a
plone site.
- Change the view name to "ics_view", which is the same name used for a
single event. I find the current name ("calendar.ics") a bit confusing,
because I would expect it to be the downloaded file's name, but that
will be "[CONTEXT_ID].ics".
- I'm not so sure about it, but shouldn't we also support vCalendar?
It's still provided for single events.
- Are there any plans to add a new document action for this feature?
Thanks for working on this :) and please let know if you need any help.
Ricardo
--
Ricardo Alves
Eurotux <http://www.eurotux.com>
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [plone4] - Initial PLIP drafts coming in
Alexander Limi wrote: On Sat, 20 Dec 2008 12:06:38 -0800, Hanno Schlichting wrote: I've started to write up initial PLIP drafts for the major changes that have already been implemented on SVN trunk and that I want to do for 4.0. They can be found in Trac and are associated with the 4.0 milestone. And here's a first stab at a report to track these: http://dev.plone.org/plone/report/24 Sorry if I missed some discussion/decision on this, but the place for PLIP submission is now trac? Or are these just drafts that will eventually origin PLIP's at plone.org? Ricardo -- Ricardo Alves Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Comments on PLIP 244
Wichert Akkerman wrote: Previously Ricardo Alves wrote: Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... I disagree. Again you are just describing a special case of a more generic problem: the lack of ability to selective block (and perhaps unblock) portlets. I agree that per-portlet blocking would make it easier, and it shouldn't be that hard to implement. I can not think of a single situation where site portlets would make sense. The use case is almost the same, even with per-portlet blocking. I'll try to describe it. Say you have the following site structure: / (Site Root) /services (Folder) /services/network/ (Folder) - the site root has a portlet assignment (e.g. news portlet) - the folder "/services" blocks the news portlet - but you don't want to block the news portlet in folder "/services/network" - if using a site-wide portlet, folder "/services" would be the only one blocking it and it would be shown in "/services/network". Anyway, I do agree that this use case is not that common, and per-portlet blocking would do the trick for most use cases. So I guess the best is to start working on it :) Ricardo -- Ricardo Alves <[EMAIL PROTECTED]> Eurotux <http://www.eurotux.com> ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Comments on PLIP 244
Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... Let me also make it clear that the idea here is not to break with existing functionality, neither with any concept. The idea of marking categories as "not inherited by subfolders" would be extremely useful. Currently, you need to block inheritance in all subfolders. Anyway, I'll be happy to reformulate this PLIP, or even split it into smaller ones, after some more discussion. Thanks, Ricardo ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
