Re: [Framework-Team] Zope 2.13 PLIP ready for review
Do we expect Plone 4.1 / Zope 2.13 to be using Python 2.7 by default? (makes sense to me, but not sure if it has other implications that I'm unaware of) On Thu, Sep 9, 2010 at 6:03 AM, Hanno Schlichting ha...@hannosch.eu wrote: Hi. The Zope 2.13 PLIP (https://dev.plone.org/plone/ticket/10776) is ready for review. There's a PLIP buildout at https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10776-zope213.cfg including notes to use it via a local.cfg. There's also an accompanying text file with some comments about the current status in the same folder (plip10776-zope213.txt). I'd welcome a timely review, so I can either fix any upcoming suggestions or merge this in early. Thanks, Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://twitter.com/limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone roadmap
Just a note from the UI side of things here, since you're all doing a good job with the other bits: On Sun, Sep 5, 2010 at 11:10 AM, Hanno Schlichting ha...@hannosch.euwrote: On Sun, Sep 5, 2010 at 7:17 PM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: On 5 September 2010 15:29, Hanno Schlichting ha...@hannosch.eu wrote: This should get us out of the business of maintaining a web server, but will also likely mean the loss of FTP and WebDAV support. I don't think that's a good option. We may not need to support both, but supporting one is probably quite important. For one thing, it'd kill Enfold Desktop and similar integrations. WebDAV is also very useful for bulk movement of images and documents. I haven't ever seen an actual good and working WebDAV client for normal content editors. The WebDAV standard is dead and the big operating systems have no interest in fixing it or their implementations. FTP is even less user friendly and I've only seen WebFTP implementations that work for mortals. I think we should focus on better web-based upload and batch functionality and give up on those other protocols. As I said, there's some customers that want this, but it's a tiny minority and thus best served by an add-on. Just because FTP and WebDAV have been cool in 1998 doesn't mean we need to keep them in 2010. With HTML5 and AJAX UI's we have better answers to these use-cases now. Yes, at this point I personally think it's fair to consider anything that isn't part of the web as dead to us. In actual use, people are much more comfortable with doing everything through a web browser these days than they were in 1998, both because web browsers have become more capable, and because we have more and more users with less sophistication and capability to keep track of abstractions like a WebDAV/FTP representation of their content — it's bad enough in most systems that separate the admin interface from the actual content interface, adding another abstraction on top of this isn't going to work for the average content author. Besides, few people are willing to edit HTML by hand on the file system anymore, and people are increasingly moving away from blobby formats like .doc and are comfortable with doing editing through the web browser as long as we can supply proper formatting + layout support (via Deco) and a good autosave-to-draft implementation — and with the IndexedDB/localStorage options on the horizon for the web in the near future, we can even support offline editing in a proper, standards-based manner. I've been pretty bullish on dropping WebDAV and FTP for a while now, and I think it's time to get serious about it. It siphons away our focus on proper, TTW solutions when there's always the you can use WebDAV for batch operations option that isn't really maintained by anyone — no disrespect to Enfold et al, of course, this is a client-side WebDAV issue that is unlikely to be particularly good in any OS, ever. I think we should envision a future without WebDAV and FTP as core components of our stack. They never worked well in practice, and are unlikely to ever reach mainstream usage because of the extra steps, concept abstraction, and setup knowledge required. The browser should be our only deployment target on the client side. -- Alexander Limi · http://twitter.com/limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Access to archetypes repository
I'd also recommend keeping the AT repositories where they are until we no longer rely on them (and even then, keep them around). Breaking existing setups shouldn't be done unless we can't avoid it. :) On Sat, Jul 31, 2010 at 7:12 PM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: On 1 August 2010 09:50, Alex Clark acl...@aclark.net wrote: On 7/26/10 6:41 AM, in article 4c4d6662.7000...@bubblenet.be, Godefroid Chapelle got...@bubblenet.be wrote: Le 19/07/10 20:48, Geir Bækholt a écrit : On 19-07-2010 19.09, Dorneles Treméa wrote: +1, status quo I agree. Big +1 I received only +1s : Since July 2010, 26th, write access to Archetypes repository will be granted to each requester (as it is already the case for the collective repository). Since this is the case, does it make any sense to try and commbine the AT repo with the collective repo? That'd mean one less repo to manageŠ Only if you can keep all checkout URLs and revision numbers 100% the same, which I think is more or less impossible. Repository moves are painful for anyone working on the software. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone-developers] Upcoming Plone 4.0 releases
On Wed, May 26, 2010 at 12:09 PM, Hanno Schlichting ha...@hannosch.euwrote: Why wouldn't we want to migrate content by default? If we don't do it by default, only a few will figure out how to do it and people loose the major advantage that blobs give them. I haven't been involved in the PLIP discussions around this as much, but I thought this was a clear case of something that just wasn't done yet. If you have a specialized need, you can opt-out of this upgrade step by using the portal_setup upgrades screen and omitting this one step. But the default should be to migrate people. +1. Also, getting this change in as early as possible will give us more time to figure out whether there are migration issues. Having some data stored one way, and some data stored another (for the same type of content) just seems like it'll cause problems later. Is it a lot of work to enable? I assume the difficult part already exists, since we can manually trigger the migration? -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 5 - rough roadmap
On Wed, Mar 24, 2010 at 6:58 PM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: It's not *quite* that easy, though, because people will have things like collective.xdv in their buildouts. If an upgrade means installing something else, then in the worst case that something else could actively conflict with an old installation, and we're in trouble. Also keep in mind that package name doesn't have to be the product name. We're not called CMFPlone. ;) It's also not so easy because at least two books in print mention XDV, as do three or four tutorials on plone.org. I think we need a damned good reason to rename, more so than this name is cooler. I also think we should ask the broader community's reaction first. The community is tiny, tiny until it ships with a Plone release. Now is the time to do it. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 5 - rough roadmap
On Wed, Mar 24, 2010 at 12:45 PM, Steve McMahon st...@dcn.org wrote: How about Pastiche ? http://en.wikipedia.org/wiki/Pastiche Or the simpler http://en.wikipedia.org/wiki/Pastis — which seems appropriate. ;) (not being serious here, I also think pastiche is way too hard for most people to remember the spelling of :P ) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 5 - rough roadmap
+1 to xdv as long as it gets a decent new name. ;) Now that xdv supports CSS-style selectors, it's by far the most compelling choice. On Tue, Mar 23, 2010 at 2:29 AM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: Tom Gross wrote: On 03/12/2010 04:07 PM, Hanno Schlichting wrote: Hi there, ... On the future side we have: - Chameleon - Deco / Blocks - Dexterity - WSGI - xdv as the default theming story Is there still discussion space to choose between xdv and Deliverance. I'm not to deep in the subject but I have heard that Deliverance can be used with other web-applications, but xdv is Plone specific. If this is true, Deliverance would open Plone to a broader community. Where did you hear that? It's not correct. ;-) Deliverance is a Python-based implementation. It is used either as a standalone proxy or in a WSGI pipeline. As such, it may be attractive to people with a WSGI-oriented stack. It also has more client-side tools and is generally broader in scope than XDV. XDV is an XSLT-based implementation. You compile theme + rules into an XSLT, which is then deployed either in a WSGI pipeline step, or in a web server like nginx or Apache. As such, it is even broader in scope in the sense that it's not tied to Python. collective.xdv is a Plone control panel + hook to apply an XDV theme without the need for a fronting web server. This is a good solution for people with no further integration needs. However, the same theme + rules can be compiled and deployed as an XSLT if that's desirable. Probably the most important deciding factor is that XDV is more lightweight, overlaps less with existing tools, should be faster, and - crucially - has more uptake in the community. With Plone 3 and Plone 4 at least it's also easier to set up and deploy than Deliverance, which ether requires a standalone process that proxies to Zope, or adoptation of repoze.zope2 to get a WSGI stack in Zope. 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 -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv http://ejohn.org/blog/html5-shiv/ for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv http://ejohn.org/blog/html5-shiv/ for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.netwrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv http://ejohn.org/blog/html5-shiv/ for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- *Veda Williams* Web Developer Groundwire 206.286.1235x23 v...@groundwire.org [image: Groundwire]http://groundwire.org?utm_source=Groundwire.org-emailutm_medium=Emailutm_campaign=email-signature;utm_content=Logo -- ONE/Northwest is now Groundwire! Read all about our new namehttp://groundwire.org/about/our-new-name?utm_source=Groundwire.org-emailutm_medium=Emailutm_content=Read%2Ball%20about%20our%20new%20nameutm_campaign=email-signature . -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
The way it works is that you can use the XHTML spelling (ie. closing your tags), but you serve it up as normal HTML. http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F There's no Strict or similar thing in HTML5, AFAIK. (There is also something informally referred to as XHTML5 which is serving it as XML, which isn't what we want to do) On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe l...@lrowe.co.uk wrote: By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
Right, I don't see a reason to do that, though — it doesn't buy us anything. The reason the HTML5 doctype is simply: !DOCTYPE html …is that it's the shortest possible string that will trigger strict/standards parsing (ie. not quirks mode) in all browsers, including IE6. On Tue, Mar 16, 2010 at 3:34 PM, Laurence Rowe l...@lrowe.co.uk wrote: It is listed as an obsolete permitted doctype string http://dev.w3.org/html5/spec/Overview.html#obsolete-permitted-doctype-string - i.e. we can lie about the doctype. I'm not sure why xhtml 1.0 transitional is not allowed. Laurence On 16 March 2010 22:18, Alexander Limi l...@plone.org wrote: The way it works is that you can use the XHTML spelling (ie. closing your tags), but you serve it up as normal HTML. http://wiki.whatwg.org/wiki/FAQ#Should_I_close_empty_elements_with_.2F.3E_or_.3E.3F There's no Strict or similar thing in HTML5, AFAIK. (There is also something informally referred to as XHTML5 which is serving it as XML, which isn't what we want to do) On Tue, Mar 16, 2010 at 3:06 PM, Laurence Rowe l...@lrowe.co.uk wrote: By my reading of the html 5 draft, it would seem conformant with the (html5) spec to serve a document with a text/html Content-Type but an XHTML Strict doctype. On 16 March 2010 20:14, Alexander Limi l...@plone.org wrote: What does transitional doctype have to do with geolocation? (and XHTML STRICT is a problem, since it implies serving with XML MIME type, which IE doesn't handle, so that's unlikely to happen) On Tue, Mar 16, 2010 at 12:48 PM, Veda Williams v...@groundwire.org wrote: This brings up the question of when we're moving away from Transitional DOCTYPE. Do we have a sense of when this will happen? I'm particularly keen on knowing, as it opens up the door for us in terms of geolocation in the next year or so. Thanks, - Veda On Mar 16, 2010, at 12:40 PM, Alexander Limi wrote: On Tue, Mar 16, 2010 at 4:45 AM, Wichert Akkerman wich...@wiggy.net wrote: I'ld like to see a list of pros and cons of using HTML 5 as well. I am quite worried by the lack of proper support in existing browsers. None of them implement any of the existing HTML standards properly, and I fear that switching to the still unfinished HTML5 would be a several steps too far at this point in time. What parts in particular do you find are not working? Browsers that don't have dedicated support for HTML5 will just treat those tags similar to div elements (given an HTML5 shiv for styling to apply in IE), and most of the new form-related enhancements are additive in nature. In general, HTML5 renders even on IE6, there isn't much magic here (but of course it doesn't get any of the advantages either). HTML5 is mostly about standardizing edge case behaviors and adding new abilities that will gracefully degrade in older browsers — and then a few new tags like video/audio (that are also relatively easy to make degrade) and structural elements like article/footer, etc. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team Veda Williams Web Developer Groundwire 206.286.1235x23 v...@groundwire.org ONE/Northwest is now Groundwire! Read all about our new name. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Alexander Limi · http://limi.net -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Beta 1 is (essentially) out! FWT, your job is done.
2010/3/12 Ross Patterson m...@rpatterson.net FWIW, if it's not *undesirable* to have FWT members stay on, I'd very much like to continue as a FWT member. Having existing members stay around is desirable — we just think it's fair to give people a way to say that they don't have time (etc) anymore. It's a natural point to allow some reshuffling, and the focus in minor releases is slightly different, so some people might not find that particular type of projects as compelling. (Writing this offline, I'm sure others have said the same already, but just in case ;) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 5 - rough roadmap
2010/3/12 Hanno Schlichting ha...@hannosch.eu On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe l...@lrowe.co.uk wrote: On 12 March 2010 15:07, Hanno Schlichting ha...@hannosch.eu wrote: Currently listed for Plone 4.x are things like: ... - Well formed, valid XHTML (as a foundation for easier theming via xdv) That's really good to hear. Though I think semantic HTML or sensible ids/classes to identify elements in pages is what I had in mind with this point. Well besides the valid XHTML which is a requirement for Chameleon as well. It's also likely that we'll transition to using HTML5 (the XHTML-compatible phrasing, ie. HTML5, but close your tags), and Deco as a layout engine will be much happier if we do a revamp of the existing HTML structure. It's quite messy in parts from the 8+ years in production, and while it has held up well, it's time to adjust to how the web has evolved since then, especially with focus on our upcoming theming capabilities. Also, while on the subject of release management, it would be possible to split up these major new technologies in smaller releases, but we'd have to look at which things should land together. E.g. xdv and Deco should likely be in the same release —but don't *have* to — whereas Dexterity might be a requirement for tiles/blocks. (I'm inventing dependencies here, so no need to point out that any of these assumptions aren't correct ;) We could also take a page from how Firefox is looking to change their release management strategy, ie. landing stuff that has only infrastructural impact in a 4.x release (out-of-process plugins in FF's example, which will land in the 3.6 series, for Plone 4.x, it could be something like WSGI). Of course, that's what we're already doing, but pushing the less risky parts that were previously considered only for Plone 5 might be a good approach, and reduce risk. Landing too much at once in Plone 5 is definitely a real risk, as is a too-long release cycle for Plone 5. So evaluating each of the things we land in Plone 5 for possible inclusion in a future 4.x release is probably a good tactic. I'd love to see a shorter release cycle for Plone 5, but as usual, it's hard to determine, and I don't think the currently suggested estimates are unreasonable. I think an increased focus on Tech Preview releases (ie. what alpha used to mean :P ) could provide useful checkpoints for people to rally around when it comes to development. We shouldn't underestimate the power of self-imposed deadlines, I think it was used well in the Plone 4 release cycle, and even if Plone 5 is a release with a longer release cycle, we should try to do several checkpoints along the way to avoid landing too much at once, and get stuff out there for people to test in carefully managed projects, similar to what Jarn and others have been doing for Plone 4. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: A suggestion to egg on add-on product authors
On Thu, Mar 11, 2010 at 4:24 PM, Eric Steele ems...@psu.edu wrote: On Mar 11, 2010, at 8:00 PM, Eric Steele wrote: Thanks, Jon! I'll take care of this tonight. :) Eric On second thought, I'll hold off on this until we have installers available. Good move. Nothing is more frustrating to people than not having installers. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Plone 4 - holidays are over :)
On Mon, Jan 4, 2010 at 6:36 PM, Eric Steele ems...@psu.edu wrote: 2) We *really* need to move away from this whole limi's theme thing where Alex is the point-of-failure for anything template/design related. Agreed. Denys has been picking up this, but anyone should feel free to help out. My main concern at the moment is the state of TinyMCE, I'll see if we can get some traction on this over the weekend with Rob and Sisi. I have been useless over the past week since I'm home sick, but And on points 2 and 4...what does the UI team do these days, do we still have one? I've been silently trying to bootstrap a new one (mostly for Plone 5), and I have rallied them to get Plone 4 beta in shape. Currently my list is Rob, Denys, Sisi — other suggestions welcome. Spare time and follow-through more important than skills (which can be learned ;). -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP9311 and plone 4.1 release
I don't think a PLIP is automatically accepted into 4.1, since we allow wider-ranging changes in a dot-zero release than we do in the minor releases. In this particular case, I don't think it'll be a problem, since the PLIP is pretty small — but I think the PLIPs will probably go through the usual rounds of review anyway. I don't think we have a timeline for 4.1 yet. -- Alexander Limi · http://limi.net On Tue, Dec 22, 2009 at 10:35 AM, Kim Chee leong le...@goldmund-wyldebeast-wunderliebe.com wrote: Hi, For the 4.0 release my PLIP 9311 was rejected in the last voting round. I have a few questions about it: - Is there any date schedule available for PLIPs in 4.1. I would like to know the deadlines so I can do a bit of work scheduling. - Is it correct that this PLIP is accepted for 4.1 (because it was accepted for 4.0) and I can continue working on it. Cheers, Kim Chee -- Goldmund, Wyldebeast Wunderliebe www : http://www.gw20e.com/ ___ 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] Re: Death to the roadmap page?
On Mon, Sep 28, 2009 at 7:34 PM, Eric Steele ems...@psu.edu wrote: Alex and I will be doing a bit of sprinting on Friday to get this up to snuff. Personally, I'm all in favor of having some of the marketing folks have a go at what we come up with -- I'm told I'm not a particularly sunny individual. It might just be a requirement for (or caused by? ;) being the release manager. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Death to the roadmap page?
I definitely agree, but at the moment we don't do a particularly good job at covering our basic needs on the marketing front — and the roadmap isn't the most important part of what we do for marketing. The stuff outlined in the marketing plan (standardized marketing/conference material, feature comparisons, etc) should have priority. Of course, these aren't mutually exclusive, so if anyone wants to own this piece and make it kick ass — go for it! In the meantime, we can at least get the technical bits right, so our developers and already-using-Plone users can get better information. :) -- Alexander Limi · http://limi.net On Mon, Sep 28, 2009 at 7:00 AM, Nate Aune na...@jazkarta.com wrote: I think pointing newbies to the list of PLIPs is not a wise move from a marketing standpoint. You can certainly have the link to the PLIP page from the roadmap page, but I think there needs to be a more accessible and human friendly page showing what's coming in Plone 4/5. The list of PLIPs will just scare all but the most technical people away. Compare the descriptions of Plone with the Joomla and Drupal description on this page: http://guide.conecta.it/index.php/Content_management_systems Which of those CMSes (if you were completely new to CMSes) would be most attractive to you? The Drupal and Joomla descriptions tell you *what* you can actually do with the CMS. I think we need to boil it down for people and tell them that Plone can do all of those things as well, and show them examples of where it is done. The roadmap page is probably the first thing I would look at if I were choosing a technology on which to build my future website. It would need to be have a clear vision of what major changes will impact me, how they benefit me, and why they are important. It should be written in a non-jargony tone, but have links to more technical descriptions if I want to read the nitty gritty details. The roadmap page should get me excited about the future of Plone, preferably with screenshots and screencasts demonstrating these new features that will be included. It should instill trust that the Plone software project is moving forward and there is a unified vision for where it is going. Nate On Mon, Sep 28, 2009 at 2:51 AM, Alexander Limi l...@plone.org wrote: On Fri, 25 Sep 2009 12:29:08 -0700, Steve McMahon st...@dcn.org wrote: Unfortunately, the situation is *much worse* than Marie indicates, as the roadmap page is completely obsolete and outdated since we switched to trac. It's more than a bit embarrassing that we link to it from the home page. We should have something better, but meanwhile, what should we do with the old roadmap page? It may be useful to some as a historical artifact. The idea (at least for now) is to point it to the Trac roadmap page, and do a bit better job with the release descriptions there. Eric Steele and Yours Truly have volunteered for this task, but we didn't want to do it until 3.3 was out. Now it is, and the old roadmap page can be retired. I don't think we need to involve Mark and others in this particular case — they have much more important things they could be spending their time on — but we can definitely do much better than we're doing right now. If nothing has happened by the end of this week, feel free to call us out on it. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Nate Aune - na...@jazkarta.com http://www.jazkarta.com http://card.ly/natea +1 (617) 517-4953 ** Learn best practices for deploying your Plone sites at our upcoming Plone Deployment Training in Budapest ** http://plonedeployment-natesig.eventbrite.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] Framework Team: Time is short, we need your reviews.
Boo! Hiss! :) (this message was brought to you by the inventor of embarrassment-driven developmenthttp://www.blueskyonmars.com/2009/03/02/embarrassment-driven-development/ ) -- Alexander Limi · http://limi.net On Tue, Sep 8, 2009 at 1:18 PM, Eric Steele ems...@psu.edu wrote: 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 Patterson 0 of 8 Raphael Ritz0 of 0 Erik Rose 3 of 7 Laurence Rowe 1 of 2 Matthew Wilkes 0 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). 9214Support logins using e-mail address instead of user id Erik Rose 9249Add TinyMCE as the default visual editor David Glick 9263GenericSetup syntax for importing Sharing page roles Calvin HP 9283A more lightweight backend for collections Alec Mitchell 9288Improved commenting infrastructure Laurence Rowe 9305Use real names instead of usernames Ross Patteson 9309Better search for East Asian (multi-byte) languages. Matthew Wilkes 9310User registration process more flexibleRoss Patterson 9311Clean up of user related actions UI Matthew Wilkes 9321Reimplement the search form with an eye on usability Erik Rose 9330Add ability to choose role when adding new site members Eric Steele 9352Search results improvements Calvin HP In conclusion: Shame. Eric -- 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 ___ Plone-developers mailing list plone-develop...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plone-developers ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 9315 — New Theme, review feedback
On Wed, Aug 26, 2009 at 10:14 AM, Laurence Rowe l...@lrowe.co.uk wrote: The default portlet assignments should be thought through with respect to the new theme. To my eyes the new portal tabs style along with portlets in the left hand column, makes the page seem unbalanced. Placing those portlets on the right made it all look a lot better to me. Agreed, it looks better with portlets on the right. What we're doing with the standard setup is to put some elements on the left side, some on the right — to teach people that they can do both, and that the layouts adapt based on how you allocate the portlets. Until we have proper layouts with Plone 5, this is unfortunately the best we can do. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Status of PLIP 9315 — New theme for Plone 4
You're a bit late, seeing as the initial deadline was last week. ;) But feel free to check out the current version and give feedback on what's there — it's unlikely to change significantly in the general approach and design, but more eyes are always better. Let me know if you find issues in addition to the ones listed in the review notes. I spent quite a lot of time fixing bugs and adding print/mobile CSS etc this weekend, and will continue improving it in the coming weeks. Thanks for getting involved and helping with testing it! -- Alexander Limi · http://limi.net On Fri, Aug 21, 2009 at 5:45 AM, Francesco Ciriaci francesco.ciri...@gmail.com wrote: Hi Alex, you know I've always been interested in the default theme of Plone. I'm really curious about the new refresh of Plone. If you need some help for the visual design I'd glad to give some of my time. There is also a couple of people in Reflab/Mediatria that are willing to contribute: Antonio, who works mostly on UI and JS and Giulio who's a visual designer and skinner. Also consider that the work we did back in old days of Plone 3 (October 2007) with Capri and other themes were precisely aimed into refreshing the Plone default theme with: 1) updated logo (had been officially announced a couple of days before the sprint) 2) updated (and extended) icon theme 3) accessibility (contrasts/colors included) 4) have a base theme for skinning 5) recongnizable / keeping Plone visual identity 6) nice use of typography 7) new use of colors for user actions and portlets 8) grid (fixed width) I'm glad to see that many of these elements plus some new one fluid, HTML5, etc. are in the PLIP: nice work! I'm not sure how the review/PLIP process works for the visual design but I'd also bring the new design to the attention of the Plone evangelism team, just for a feedback. Then, once the PLIP is approved, it would be interesting to *promote* the new visual design and especially it's implementation. Let us know what we can do. Cheers, Francesco. Il giorno 19/ago/09, alle ore 09:02, Alexander Limi ha scritto: The first cut of the theme is checked in, with related buildout.cfg and review notes. To address some of the questions brought up in the thread: *Why are you not supporting base_properties?* It doesn't make a lot of sense, since there are only two properties that are adjustable, and that is easier to do by pulling them out and putting them first in the CSS. The upside of having standard CSS files that can be fed to CSS editors and other tools outweighs the dynamicism that variables for these would give us. And for a person new to Plone theming, DTML and the ZMI is a lot more intimidating than two hex values in a well-known and predictable format. * Is this another version of **plonetheme.netsightintranet? *Nope, it was just used for inspiration, sorry about not being specific enough with my explanation. As you can see, the Sunburst theme looks slightly different. Hopefully everything else is addressed by the review notes, but if you have additional questions, let me know. I'll be refining the theme further over the next few days, start testing in IE, etc. -- Alexander Limi · http://limi.net On Sun, Aug 16, 2009 at 9:52 PM, Alexander Limi l...@plone.org wrote: I ran into unexpected problems today while trying to wrap up my PLIP for the review today — in short, there doesn't seem to be any (!) way to get any version of Plone running on OS X 10.6 (Snow Leopard) at the moment: The Unified Installers fail, buildout-based install fails, and any combination of MacPorts Python (current release, trunk from their SVN), binary Python and GCC (4.0, 4.2) versions fail while compiling parts of Zope. I spent 6 hours today with the help of messieurs Glick, Steele and McMahon today trying to make it work, but there's something very weird going on (for example, the Acquisition egg compiles properly, but after reporting that it's successfully compiled, can't be found — if you're interested, here's the output http://pastebin.com/m6df313f). (And if you know what's going on here, it would be great if you can help out, since we also need to solve this — preferrably before Snow Leopard is released, which may be as soon as end of this month.) Since I have fully migrated to Snow Leopard on my work laptop as part of testing Firefox on 10.6 (and that happened just before my vacation), I need to locate a computer that runs OS 10.5 before I can put together the running version of the theme product. Here's what I put together before I went on vacation, and that I have on my laptop at the moment: - An updated main_template that uses HTML5 (XHTML variant) that adds various structural elements like sidebar and various other cleanups. No changes to class/ID structure so far, though — so existing themes should work. (the only exception is if they do stuff like table.* in CSS, ie. depend
[Framework-Team] Status of PLIP 9315 — New th eme for Plone 4
I ran into unexpected problems today while trying to wrap up my PLIP for the review today — in short, there doesn't seem to be any (!) way to get any version of Plone running on OS X 10.6 (Snow Leopard) at the moment: The Unified Installers fail, buildout-based install fails, and any combination of MacPorts Python (current release, trunk from their SVN), binary Python and GCC (4.0, 4.2) versions fail while compiling parts of Zope. I spent 6 hours today with the help of messieurs Glick, Steele and McMahon today trying to make it work, but there's something very weird going on (for example, the Acquisition egg compiles properly, but after reporting that it's successfully compiled, can't be found — if you're interested, here's the output http://pastebin.com/m6df313f). (And if you know what's going on here, it would be great if you can help out, since we also need to solve this — preferrably before Snow Leopard is released, which may be as soon as end of this month.) Since I have fully migrated to Snow Leopard on my work laptop as part of testing Firefox on 10.6 (and that happened just before my vacation), I need to locate a computer that runs OS 10.5 before I can put together the running version of the theme product. Here's what I put together before I went on vacation, and that I have on my laptop at the moment: - An updated main_template that uses HTML5 (XHTML variant) that adds various structural elements like sidebar and various other cleanups. No changes to class/ID structure so far, though — so existing themes should work. (the only exception is if they do stuff like table.* in CSS, ie. depend on the tag instead of the class/ID name). HTML5 renders fine in all browsers, btw — they just don't style the new elements, which we aren't putting visual styles on anyway. - A tested, robust grid system (the same as I have shown at Plone Symposium East, and that we'll use for Plone 5) that supports both fixed and fluid widths. No tables in the layout anymore. Works in IE6 too. - A new design from Iain (screenshothttp://dev.plone.org/plone/attachment/ticket/9315/plone%204%20theme.png) that I have implemented as a static HTML version on top of the Plone markup (with the main_template changes. Note that the typography and pull-down menu will be different — closer to what you see on plone.org right now. - A new CSS that implement's Iain's layout with the changes discussed in the ticket. Still missing are things like print CSS and (if I get the time) a mobile/iPhone stylesheet using the @media selector. - CSS doesn't use base_properties, but is color-neutral except for a couple of properties (e.g. link color) that are pulled out separately to the top of the CSS file, so they are easy to override, should you need to. No DTML magic. - Three-column layout approach is intact for Plone 4, we'll move to a freer layout as part of Plone 5, so no change here either. - A theme skeleton — plonetheme.sunbursthttps://svn.plone.org/svn/plone/plonetheme.sunburst/trunk/— that Denys checked in for me while I was flying across the Atlantic. Unfortunately this is just a blank skeleton still, since I can't get Plone running at the moment. What's missing was to pull these together on top of the current Plone 4 checkout, which should take 4-6 hours including basic testing to have something ready for the first review deadline. I completed the core of the work before I went on vacation, and knew that I would only have one day when returning from vacation to put together the package, so I had the entire day reserved to complete the actual theme product. Unfortunately, there seems to be no way I can get Plone running on my current laptop, so I have to find another computer to do it on. I'm going to humbly (and embarrassingly) ask for your permission to submit my PLIP for review late — I have access to a computer running OS X 10.5 tomorrow, so I will most likely have it ready by the end of Monday/Tuesday. I assume you have enough to do the first 24 hours of the PLIP submission deadline that it won't feel like you're lacking things to do in the meantime. :) It sucks, and I'm sorry — I really didn't expect this to be an issue at all. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Board] Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
2009/7/29 Martin Aspeli optil...@gmail.com 2009/7/29 Jon Stahl jonst...@gmail.com: So, my question is: what qualifies as explicit agreement? Does it have to be on the permanent record in some manner? In our business, an email that you keep tends to be enough. I would: - Ask the relevant people by email - Ask them to reply by email giving explicit consent - Store those emails forever - Make a note in a CONTRIBUTORS.txt or similar that these people consented on a particular date If that's ever in dispute, you can go back to those emails. I don't see a reason for any kind of wet signature so long as they've signed the contributor agreement. We're not *trying* to be difficult. :) +1. One thing that SFLC taught us is that any lawyer will always advice you to have their name signed in blood etc, to make *really* sure that nothing goes wrong. In practice, as long as you can show reasonable intent (and an email should be plenty, if there's forgery going on, that's a different issue), so I think this should be good enough. Keeping the dates in a text file is also convenient. FWIW, Mozilla runs their entire project without a contributor agreement — so we are already way ahead of what most large open source projects do on this front. :) — Alexander ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Plone 4 FWT meeting summary 2009-06-23
On Tue, 23 Jun 2009 20:02:02 -0700, Alec Mitchell ap...@columbia.edu wrote: The idea is to ensure everyone on the team who wants can get threaded updates on PLIP comments delivered. Does Trac's RSS allow this? RSS isn't threaded, of course. But is it needed? :) (if you already have the mailing list up and running, nevermind — just wanted to point to a quick and working solution :) -- Alexander Limi · http://limi.net ___ 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
On Tue, 23 Jun 2009 13:17:57 -0700, Eric Steele ems...@psu.edu wrote: * We have 57 PLIPs to evaluate, more than any previous version of Plone (we're told), with less time than any other major release. #$@! I will just observe that: a) This is an awesome problem to have b) I think this validates somewhat that the Trac route vs. PSC proposals leads to more submissions. Even subtracting the garbage PLIPs, this is an impressive collection of features. :) * Would be helpful to be automatically CC'ed on all PLIP changes. Would be too much noise for the FWT list, let's create a new one. Ross will try to get that set up. Why not use the Trac RSS feed instead? Seems like a perfect fit for a short-term feed like this. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
On Sat, 20 Jun 2009 21:32:19 -0700, Martin Aspeli optilude+li...@gmail.com wrote: - We use this PLIP review cycle to start assigning PLIPs to 4.1. There's no reason we can't and shouldn't start planning for that now. So, if a PLIP looks like it'll take longer to do, we can still vote +1 in principle, but target it for a 4.1 release that can come not too long after 4.0 is out. I agree strongly on this. A process note, I see we have created 4.1, 4.2 milestones — would it be better to create a 4.x milestone like we did on 3.x, so we can say it'll be in one of the 4.x releases instead of tying it to a specific release until we actually know which release it'll make it into? -- Alexander Limi · http://limi.net ___ 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
On Sat, 20 Jun 2009 21:38:28 -0700, Martin Aspeli optilude+li...@gmail.com wrote: 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 can potentially walk people through how to build these using Amberjack too: http://dev.plone.org/plone/ticket/9324 -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: [Plone-developers] The new Plone 4.0
On Sun, 10 May 2009 23:36:41 -0700, Raphael Ritz raphael.r...@incf.org wrote: Or, even easier: use our underlying technologies theming capabilities and simply ship with two themes. ;-) Good point. :) Make the new one the default for new sites but leave existing ones alone. Exactly. Then we can remove it in Plone 5. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] The new Plone 4.0
On Tue, 05 May 2009 15:56:36 -0700, Ricardo Alves r...@eurotux.com 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. This would make 4.0 seem fresh out of the box, make it look like an application from 2009, and let us ship with considerably more efficient/smaller CSS files. The risk would be that we need to do some IE6 testing on it, but that might not be a bad thing, since we know much more about IE6 workarounds at this point than we did when the original CSS was written. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] The new Plone 4.0
On Sat, 09 May 2009 05:09:07 -0700, Martin Aspeli optilude+li...@gmail.com wrote: I'd support this, *if* it follows the usual PLIP process and we actively encourage outside review from the get-go. That process may mean the theme change gets a thumbs-down. Of course. We'd also need to find a way to not break all existing themes. It will break (ie. slightly change) themes that reuse parts of the original Plone CSS as part of their theme. Luckily, the fix is easy: make a copy of the old CSS in your product. Few themes do this anymore though — it's mostly for the editing/authoring bits, which would still work (although they will change slightly too). Again, very easy to copy the old CSS into your theme if you want to keep the old style. It's a x.0 release, so slight breakage like this shouldn't be a big issue. A small visual refresh would be welcome, though. Plone is looking a bit last millenium. :-/ Yup. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Plone Messaging
On Tue, 05 May 2009 23:41:55 -0700, Matt Hamilton ma...@netsight.co.uk wrote: Now I know that Alex is often (and I hope you don't mind me saying this Alex) quite ambitious in his visions for Plone in some of these talks, but I think that is a good thing. :) That's spot on, my role isn't always to be correct, it's to show what potential we can realize if we do certain things, and why we want to do it. I know very well that a lot of the stuff we talk about ends up landing in a later release — but I have stopped worrying about scheduling. We've been at this for 8+ years, we have some of the best people in the business working on our product, and a healthy, fun community. That's what counts, and why I'm not worried. How that will now relate to the release manager type role I'm not sure. Ie. I think Hanno would be in a much better position to say what is or isn't upcoming. But I think Alex does a very good spokesperson (dare I say BDFL?) type role. I'm probably the de facto BDFL these days, backed up by Hanno, Martin, Laurence et al on the technical front, which I think is a good solution too. The vision for the product and the user experience is something that lends itself to a small group, technical leadership within a certain domain is easier to distribute. And I certainly think the structure we have now with release manager (with veto powers ;) + framework team is a really good solution. Even Mozilla is interested in how we do these things, and whether there's something they can learn from it. Alex is doing something at the Plone Symposium East for this: http://weblion.psu.edu/news/alexander-limi-to-open-plone-symposium-east-2009 And Geir is doing a similar talk at the European Symposium. It will also be the main focus of the Plone Conference 2009 talk, so it's good that we have these events a few months earlier to refine and update the message. I think this is a great avenue for communicating the message to the community on where Plone is going. One thing we could probably do better is to communicate this outwards. There's been a resurgence of interest from the press in Plone lately, so I'm hoping to get this stuff published in publications outside of just the Ploniverse too. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP process in Trac for Plone 4 onwards
Hi all, Just wanted to summarize how I think we'll using Trac for the PLIPs for Plone 4 onwards: - PLIPs are added as tickets with the PLIP type. - PLIPs show up in http://dev.plone.org/plone/report/24 - If you propose for a particular release, you assign it to that release's milestone. - Idea PLIPs are put in the Future milestone. - That the ticket is accepted reflects FWT vote - When the ticket is resolved, it means that it has been merged. I have added this to the description on the Trac report, let me know if anything should be added or changed. We probably want to add the state of the ticket to that report, so we can keep track of the resolved/accepted states. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP process in Trac for Plone 4 onwards
On Thu, Apr 2, 2009 at 5:39 PM, Sidnei da Silva sidnei.da.si...@gmail.comwrote: That sounds a lot like Blueprints in Launchpad. Just sayin! :) Of course it does. :) If we were using Launchpad for our issue tracking, we'd use the blueprints. They are all the same, but it makes sense to track them in the same system as you track the bugs/feature suggestions. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: NuPlone and Plone 3.2
On Mon, 05 Jan 2009 10:21:29 -0800, Tom Lazar li...@tomster.org wrote: i can't remember which version but wasn't there a plone version that skipped a minor version and went straight to the next higher one? at any rate i'd say this would be the most straight forward way to deal with this issue. I think 3.0 had a false start, so 3.0.1 was the real release here. I might remember wrong, too lazy / bandwidth-constrained to check right now. But yes, it has definitely happened earlier. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Multiple workflows (Was: PLIP lifecycle)
On Fri, 02 Jan 2009 11:50:34 -0800, Martin Aspeli optil...@gmx.net wrote: Tres Seaver wrote: You can actually have multiple workflows for a given type. I may be the only person who has ever actually used the feature, but it is truly helpful at times. I'd be interested to hear what kind of situations it's useful for? Another example is when you want to track translation state for documents — when a document has been changed, a notify (with diff) for the translators go out, then they change it back to mark the translation as updated once they are done. This may be independent of the publishing state. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: [plone4] Release process
On Sun, 28 Dec 2008 15:15:16 -0800, David Glick davidgl...@onenw.org wrote: collective.transmogrifier already can load both AT-based content and non-Archetypes content, but is fully pluggable and only needs additional components to support more details as well as dumping. Is there a writeup anywhere of using collective.transmogrifier in a real-life scenario? The docs included in the package are clear, but an example of its use would help me wrap my head around how using it compares to other options, make it less abstract, and help clarify what missing plugins are needed. In the series of talks that were a damn shame that we didn't get at Plone Conference 2008 (for very understandable reasons, but a lot of people were excited about this talk :). -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
On Sun, 28 Dec 2008 09:10:29 -0800, Martin Aspeli optil...@gmx.net wrote: Please note that whilst this vision sounds more or less in line with what I hope will be possible and desirable soon, this is not something that's been decided. The 4.0 framework team and release manager will have the final say in whether this type of model is a good idea or not. Of course, FWT and release manager have the final say, as always. I'm just excited. ;) Dexterity is getting pretty close to a state where it's usable for real-world projects (the TTW UI and a few minor pieces of plumbing being the major stumbling blocks; the basic type story is pretty stable now), and it's developed in such a way that it can be used with 3.x right now. However, it needs to be proven in real life before we can say that it's the way. Absolutely. We might also choose to only support the new layout model with the new types, if this makes it easier to manage. We'll cross that bridge when we get there. I don't think this will be necessary. The layout model should be developed in such a way that it works regardless of type implementation. OK, great — just wanted to mention it, since we discussed this very early on in the project. I agree that we should support it if we can. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
On Sat, 27 Dec 2008 10:16:15 -0800, Ross Patterson m...@rpatterson.net wrote: So I would like to see something of a slight-of-hand here. Sleight. Just because I used to make the same mistake myself. ;) Speaking of Dexterity: Sleight, meaning dexterity or deceptiveness, comes from the Old Norse slœgð.[3] Sleight of hand is often mistakenly written as slight of hand. Slight descends from the Old Norse slettr, meaning plain, flat, even, smooth, level. Sorry for the aside, I found it amusing and somewhat relevant, with the Old Norse (Martin ;) behind Dexterity, etc. :) 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. Yup, the idea is to make AT *optional* (but still default), and to be able to supply a Dexterity-based alternative. Then we can work on the migration story from AT-Dexterity without that being a blocker for 4.0. In other words, if you start a new project, you'll probably want to look into Dexterity-based types — if you have an existing site running Archetypes, you'll probably want to keep that for the time being. This means that developers that know what they are doing and/or new users could go with Dexterity immediately, whereas the people that mostly care about keeping their existing site running could stick with AT. We might also choose to only support the new layout model with the new types, if this makes it easier to manage. We'll cross that bridge when we get there. 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. This would have to be named Plone 5.0. Replacing the default types approach is a huge undertaking, especially from the upgrade side. If Plone 5.0 was a release that only did this change, I'd still be happy with it. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: search function for plone.org and for Trac
On Sat, 27 Dec 2008 07:58:58 -0800, Graham Perrin g.j.per...@bton.ac.uk wrote: Might PloneTrac http://plone.org/products/plonetrac/ provide a useful foundation to any of this? From its January 2007 (alpha) description: No. ;) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP lifecycle
On Sat, 27 Dec 2008 09:56:23 -0800, Ross Patterson m...@rpatterson.net wrote: 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. This sounds like a good starting point. +1. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: A roadmap in a Trac
On Fri, 26 Dec 2008 13:48:42 -0800, David Glick davidgl...@onenw.org wrote: Looks pretty good. Would be nice to show the status of each PLIP there if it's not hard. Have we considered how we're going to handle the search function once plone.org and trac look the same visually? If we just use the separate search features of each product it's a bit non-ideal Yes, this is a known issue that I think we'll have to live with for a little while. It doesn't make things worse as such, but it certainly could be made better — and the fact that it will look like it's the same web site For now, we'll have to tolerate it, and see if we can do something nicer wrt. indexing when all the other bits are in place. collective.solr would be nice, but I don't want to put more moving parts on plone.org until we have sanitized what's already there. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Explaining Plone on launchpad
On Thu, 25 Dec 2008 13:41:24 -0800, Graham Perrin g.j.per...@bton.ac.uk wrote: Explanation should be simple (those currently found at http://dev.plone.org/plone/roadmap are ideal) and should clarify why we sometimes find more at Launchpad than at other locations. This is just a temporary situation, once Plone 3.2 ships, all installers will be based on the Unified Installer approach, and we have one installer for each platform — it seems we might even have a fat binary for Intel/PPC on the OS X side — haven't followed Steve's efforts here lately, but he was in the process of doing just that. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIPs for milestone 4 and beyond in Trac: occasional conversion from type 'Feature Request'?
On Tue, 23 Dec 2008 04:55:34 -0800, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: PLIPs have their own numbering and are currently stored exclusively on plone.org. Actually, for 4.0 and later, we're moving them all to Trac. That way, we can assign them to releases, track them separately, and use the update features as a progress log. With the new plone.org setup, the /development area will be Trac, and we'd like to have one roadmap page, not two. Trac is built for development and lightweight release management, so let's use it for what it's good at. :) but I'd not be adverse to moving to trac if we had a smooth migration plan. Migration plan is: Everything in 3.x stays the way it has been (at least for now), for 4.0 — and possibly later releases in the 3.x series — we put PLIPs in Trac. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: FWT trac user for CC's that will post trac activity to this list
On Wed, 24 Dec 2008 06:20:34 -0800, Martijn Pieters m...@zopatista.com wrote: It's a pity Trac doesn't support ticket detail changes; there is a plugin for Trac 0.11 that supports this (see http://trac-hacks.org/wiki/DetailedRssFeedPlugin) but dev.plone.org still runs on 0.10. Hopefully not for much longer. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: [plone4] - Initial PLIP drafts coming in
On Tue, 23 Dec 2008 06:40:34 -0800, Ricardo Alves r...@eurotux.com wrote: 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? There has been some informal discussion here and there, and with Hanno in agreement, we just did it. If there's any opposition to it, I'm happy to have that discussion too — we just moved ahead with it since it was already happening. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] - Initial PLIP drafts coming in
On Sat, 20 Dec 2008 12:06:38 -0800, Hanno Schlichting hanno...@hannosch.eu 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 (we should probably add component in the table too, but my SQL-fu is weak ;) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Kicking off Plone 4: Release Manager candidate
On Mon, Oct 27, 2008 at 3:25 PM, Steve McMahon [EMAIL PROTECTED] wrote: Shall I draft a call announcement for discussion? Yes, please! :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Kicking off Plone 4: Release Manager candidate
Hi team, There's been a lot of activity and excitement about Plone 4 after the Plone Conference, and I'd like for us to start moving on the development for it. Hanno Schlichting has said that he'd like to be the release manager for Plone 4, and I'd like to formally propose him as a candidate for this role. Martin Aspeli has indicated that he'd like to help Hanno in a developer communication role, so Hanno can focus on his job of the release manager, and Martin will help communicate what's going on to our core developers and add-on product developers. So, if anyone else is interested in being the release manager for Plone 4, let us know! Also, if the official nomination for the Plone 4 release manager has to wait until there is a Framework Team for 4.0, we should: a) Start identifying these people ASAP. b) Possibly accept Hanno as an interim release manager until the team can make an official recommendation based on the available candidates. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP 246: View for rendering events as an iCalendar file
Hi Framework Team, On behalf of Andreas Zeidler, I'd like to offer up the following PLIP for your consideration for Plone 3.3: http://plone.org/products/plone/roadmap/246 It's a pretty trivial PLIP that adds a new view that is capable of rendering events as an iCalendar file, so people can subscribe to Plone events in various calendaring software like iCal, Google Calendar, Outlook, Sunbird, etc. The view is added to ATContentTypes, and is currently implemented on a branch (and includes tests). PS: Andreas is fully responsible for the implementation here, I'm only helping out by writing a short PLIP for him. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: What is Plone 3.3?
On Sat, 11 Oct 2008 08:47:51 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: Right now, the things that concern me are: - Adding a new way to add content (the add sibling proposal) - Moving the contextual manage portlets link somewhere else - Removing the display menu and putting the behaviour on the fieldset (the last one is doubly bad, because it would require any add-on product that used this menu to be updated in a possibly backwards-incompatible way, to add a field to replicate this, and we'd need a unique solution for non-AT content). +1, I don't think any of these should land in 3.x. Especially since a lot of them should hopefully be moot in the next major release anyway — but in the meantime, let's not change UI behaviour in a minor release. It's bad form, and while I'm usually tending towards this, I have changed my approach after seeing the confusion it can cause. Luckily, there's a workaround. :) All of these changes could be provided with easy-to-install add-on products. These could be tested on real users and used by those who want different behaviour. This is the way to go if you want your pet UI peeve addressed in the 3.x series. Thanks for raising this, Martin. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: random thought: identify the components that lack owners
Thanks to you both for lots of great writing, this is really helpful. I'm pretty much in 100% agreement on what you've written so far — so don't take my silence as anything but consent at the moment. Battling US immigration authorities in Brazil to try to get back to the US, so my time is limited at the moment. :) Wanted to comment on one particular subject that was mentioned: On Sun, 28 Sep 2008 09:10:23 -0300, Wichert Akkerman [EMAIL PROTECTED] wrote: I feel we need better sprints: fewer people, smaller focus, try harder to get people with the right experience and long-term availability in and make sure we get people with outside expertise in. I agree, and I think we should also arrange more sprints that are less of the travel somewhere and see the world type. Local sprints (see SuperHappyDevHouse etc for inspiration) are really valuable, and there are several natural pockets of Plone developers around the world — San Francisco, Amsterdam, Oslo (well, Tønsberg ;) and more. A local 1-2 day event — during the week or the weekend — can go far in getting some real work done, and I'm planning to do one with Steve McMahon and Joel Burton (or at least one of them) and others here in San Francisco as soon as possible. Related, World Plone Day might offer some useful insights on these pockets and the potential for local sprints. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Plone 3.2 and 3.3 planning
On Thu, 11 Sep 2008 00:50:44 -0700, Andreas Zeidler [EMAIL PROTECTED] wrote: so personally i'm still undecided and would like to hear some more opinions. spontaneously i think i'd rather leave the window open, but i'd like to contemplate about it a bit more... Please leave the window for PLIPs open until after the conference. Most of our best thinking happens at conference sprints, and that's the part that you can't replicate anywhere else — once the PLIP is written, you can pretty much work on it anywhere, you don't need a sprint for that (although it does help with blocking out time). I know that I personally won't have time to work on PLIPs until the Plone Conference — especially since I'm preparing both for PyCon Brazil and the Plone Conference, and my mind will be in that space until the conference sprints start. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.2 and 3.3 planning
On Sun, 07 Sep 2008 03:34:58 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: That's a good idea. On the other hand, I wonder if it would be nice to give people a chance to come up with and work on PLIPs during the post-conference sprint. In the past, we've seen a spike in PLIPs around sprints as people focus on one thing or another. +1. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: Framework Team Page Needs Updating
On Wed, 20 Aug 2008 15:12:53 -0700, Andreas Zeidler [EMAIL PROTECTED] wrote: hmm, i guess i must have somehow missed the discussion that lead to that consensus (this is not meant to sound cynical or anything, btw). there was some talk right after 3.1, and of course there were plans to write things down in order to improve the process for the future. i might very well have missed parts of any more recent discussion, but as a member of the (currently still active) 3.1 team, i'm wondering why i don't really seem to know about this consensus. or was it just an effective one, i.e. one that sort of came up because the discussion was never really finished? That's what consensus means, at least in casual English. To be more precise, there wasn't a we will do it this way, period decision, but most people seemed to think it was a good idea, and I didn't see anyone express strong opinions otherwise. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Framework Team Page Needs Updating
On Tue, Aug 19, 2008 at 12:49 AM, Raphael Ritz [EMAIL PROTECTED]wrote: To me, this looks just fine. Are there only 5 members? I thought there were more. If not, ignore me. :) PS: maybe it's about time to think about a new team for Plone 4 (or Plone 3.3 even) though. I think the general consensus is to keep the 3.0 team for Plone 3.3 (for continuity), and elect a new FWT for 4.0 — and some overlap would be good, to make sure the lessons learned from the 3.x releases will be carried over. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Framework Team Page Needs Updating
On Mon, 18 Aug 2008 12:35:35 -0700, Martijn Pieters [EMAIL PROTECTED] wrote: In your specific case, that'd be for Plone 3.3. Current Plone trunk will be version 4.0. I'd keep it on the list and not canvas us directly though. His point still stands — the team list is outdated. If you send me a list of the missing members, I'm happy to update the group. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Testing for PLIP 209: Unified Installer Plus Buildout
On Mon, 18 Feb 2008 00:21:18 -0800, Tom Lazar [EMAIL PROTECTED] wrote: i downloaded this and everything worked fine from then on. i created a zeo setup with its own python and libjpeg(!). this is great stuff. i shall be using this for my own client work from now on Another happy customer! :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.1 planning update
On Sun, 17 Feb 2008 07:05:36 -0800, Wichert Akkerman [EMAIL PROTECTED] wrote: Since the framework team needed more time to do a proper, thorough review of all the PLIP implementations we needed to adjust the time line for the Plone 3.1 release. This is the updated time line: This looks good, except for one minor detail: there's 3 days between releasing the RC and tagging the final. This means that the RC is released on a Monday, and the final is tagged on a Friday, which seems a bit drastic. At least leave a weekend between them, so people have the opportunity to help test the RC? Calendar representation here: http://www.google.com/calendar/hosted/plone.org/embed?src=plone.org_bolka8qqqgvg6sop823vapl970%40group.calendar.google.comctz=Europe/Rome I'd like to suggest the following minor change: - 2008-03-17 : 3.1 release candidate with installers released Keep everything up to and including this date. - 2008-03-21 : 3.1 final tagged Move to: - 2008-03-28 : 3.1 final tagged - 2008-03-24 : 3.1 final with installers released Move to: - 2008-03-31 : 3.1 final with installers released This leaves a weekend to between releasing the 3.1 RC installers and tagging the final release. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] scope of reviews was: Re: Updated PLIP review deadline
On Fri, 15 Feb 2008 15:57:54 -0800, Andreas Zeidler [EMAIL PROTECTED] wrote: that stuff can amount to some serious time, i can tell you. indeed, mine took me something between two and four or maybe even five hours each. That would be a great things to have written down and communicated to the next Framework Team. Setting expectations is important. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Translation effort for Plone 3.1
On Mon, 04 Feb 2008 10:09:59 -0800, Hanno Schlichting [EMAIL PROTECTED] wrote: I did cost me only two hours to do so and this work is finished and available on PloneTranslation trunk. An overall of 205 messages are gone. We now have a total of 2070 messages in all pot files combined for Plone 3.x. Awesome! So in addition to there being 10% less messages (10%!), most of the ridiculously long and hard to translate messages are gone, in particular the ones dealing with browser-specific troubleshooting for cookies etc. Hopefully we'll have time to audit the messages in the plone.* namespace, where there is a lot of redundancy right now. We should be able to bring it even further down. This is a great start for the 40-language translation push. :) Thanks! -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Translation effort for Plone 3.1
Hi, This isn't strictly a framework team subject, but thought I'd give a little heads-up on something Hanno and myself have been discussing: For Plone 3.1, I want to do a big translation push. Our goal is to get the 40 languages that cover more than 99% of the world's online population as complete as possible. However, Plone 3.0 ships with translation files that contain strings for both 2.5 and 3.0. We did a major cleanup in 3.0, killing off a lot of happytalk, and as a result, there's less fluff to translate. You probably see where I'm going with this, but: I'd like to ship 3.1 with a set of .po files that do not contain the strings from Plone 2.5. Hanno said it would take him a couple of hours to weed out the stuff that is 2.5-specific, and agrees that it would be a good thing to do. It will make Plone easier to translate, and increase our participation and success rate with the upcoming translation push. Comments? -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIPs 208 and 217 Ready for Review
On Fri, 18 Jan 2008 10:01:42 -0800, Alec Mitchell [EMAIL PROTECTED] wrote: I've got a buildout for the local roles PLIP (208) ready: https://svn.plone.org/svn/plone/review/plip208-localroles Just a general question here, while I remember it: When things like this happen, shouldn't packages be renamed to plone.localrole instead of borg.localrole? The reason I'm asking is that it seems to me that it'll be very confusing once we have 20 different prefixes for things that are considered Plone Core. :) There is some precedent already for this, IIRC — we renamed the Iterate packages from Kapil that were included in 3.0 (I believe they had a or.* namespace). -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Kupu PLIP for 3.1
Hi guys, Just a quick email to say that I have been traveling (and without internet connection :( ) since before the PLIP deadline. The one I want in 3.1 isn't really a core thing as such — it's in Kupu — but I think it should have a PLIP to make it follow the process anyway. It's detailed in this issue: http://dev.plone.org/plone/ticket/6882 (Duncan has already made Kupu work with the latest Webkit/Safari builds, so half the PLIP is already done) I won't have internet connnection until Monday, so I hope it's OK that I get the PLIP in then. Since this is more about the acceptance of the idea than delivering the implementation at this point, I assume the above ticket has enough info for you to make a decision for now. Sorry about the delay! -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: proposed plone 3.1 timeframe
On Thu, 22 Nov 2007 01:59:23 -0800, Martijn Pieters [EMAIL PROTECTED] wrote: I see both sides of the coin here, Wichert is correct in insisting on shorter release cycles, Martin is correct that December is not the month to do this. I won't have much time to review bundles over New Year for example, not with a move coming up at the end of January as well. Can we add just 2 weeks or so to Wichert's schedule? +1 for adding a couple of weeks since Christmas throws things off by that much. I agree with the other sentiments here that it's not about the time since 3.0, it's about the time from announcement of the deadlines until the actual deadline. 1.5 months is way too short, particularly with Christmas in there. I agree with Wichert's goals, but I still think there should be some more wiggle room the first time around. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] wicked stuff
On Wed, 25 Jul 2007 13:52:49 -0700, whit [EMAIL PROTECTED] wrote: got a dual pattern filtering working locally yesterday. will release for rc2. Go Whit! -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Terminology change: migration - upgrade
On Sat, 21 Jul 2007 01:16:42 -0700, Raphael Ritz [EMAIL PROTECTED] wrote: Alexander Limi wrote: [..] Any objections? no, not from me - as long as you don't break any code ;-) Checked in: http://dev.plone.org/plone/changeset/16131 -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone-developers] wicked stuff
On Wed, 18 Jul 2007 08:33:04 -0700, whit [EMAIL PROTECTED] wrote: Martijn Pieters wrote: I am assuming the current UI uses a radio select (format a *or* format b). You could change this to a set of checkboxes. Replacing the subscriber with one that runs either filter based on those selection boxes would get you the same effect, no? iirc, the whole point of this was so limi could have an interface where one could turn on or off wiki linking(no other choices). I assume after this is solved, thats' what will happen. Yeah, it has spiralled a bit out of control discussion-wise, although I do appreciate your efforts very much. :) Essentially, I just want to be able to have an on/off switch on types that enables wiki markup, and that works with both the MediaWiki-style [[link]] notation as well as the more internationally friendly ((link)) syntax. If the implementation supports limiting to just one of them, that's fine — but I don't think that's necessary in basic Plone. I'm actually fine with the current way it works too, I had no idea it would be this complex to support both syntaxes in the same paragraph. That case is unlikely to come up in anything but synthetic testing anyway. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked stuff
On Tue, 10 Jul 2007 12:12:13 -0700, whit [EMAIL PROTECTED] wrote: I also added multiple pattern support( ie [[]] or (()) ). Whichever pattern matches first is used for the whole block of text. I'm not sure this is the preferred behavior, but it was much faster to implement(and the code is easier to read than the regexes). Perhaps someone knows an alternating regex that will work with the existing code. This confused me at first, since one of the formats was working, but not the other — and until I read your post, I didn't understand why. I guess it's unlikely to come up in real-life, but people on plone-dev (CCed) know a regexp that would match on both. :) I also tried slimming down the markup and making it consistent with how other wikis work, as well as the Plone link class standard (non-existant pages are red, add links have the entire link clickable, but with a superscript + etc). The one thing I'd like to know is whether the ID hashes are actually used for anything, or whether they can be removed, example: span id=text-158e812d9c8a44b0f659186cd9825cdf a class=link-wiki href=contact-the-plone-teamcontact the Plone Team/a /span I'd like to get rid of the stray span tag, so either putting the id on the link tag itself — or remove it altogether if it isn't used — any comments on whether this would break anything? -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: wicked stuff
On Sun, 15 Jul 2007 18:40:48 -0700, Alexander Limi
[EMAIL PROTECTED] wrote:
I also tried slimming down the markup and making it consistent with how
other wikis work, as well as the Plone link class standard (non-existant
pages are red, add links have the entire link clickable, but with a
superscript + etc).
Related, I hope I didn't break any doctests by cleaning up the markup, I
was unable to run the tests — here's the output I got when I tried:
$ bin/zopectl test -s plone.app.wicked
Running tests via: /opt/local/bin/python
/Users/limi/Projects/Zope/2.10/bin/test.py -v --config-file
/Users/limi/Projects/Plone/3.0/etc/zope.conf -s plone.app.wicked
Parsing /Users/limi/Projects/Plone/3.0/etc/zope.conf
Running tests at level 1
Traceback (most recent call last):
File /Users/limi/Projects/Zope/2.10/bin/test.py, line 117, in ?
sys.exit(testrunner.run(defaults))
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 271, in run
failed = not run_with_options(options)
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 380, in run_with_options
tests_by_layer_name = find_tests(options, found_suites)
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 1048, in find_tests
for suite in found_suites:
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 1087, in find_suites
for fpath, package in find_test_files(options):
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 1153, in find_test_files
for f, package in find_test_files_(options):
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 1181, in find_test_files_
for (p, package) in test_dirs(options, {}):
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 1235, in test_dirs
p = import_name(p)
File
/Users/limi/Projects/Zope/2.10/lib/python/zope/testing/testrunner.py,
line 1251, in import_name
__import__(name)
ImportError: No module named wicked
--
Alexander Limi · http://limi.net
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Move footer.pt and colophon.pt to viewlets?
On Wed, 06 Jun 2007 17:18:23 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: This is a bit late in the game, but I'd like to offer for consideration whether we should move footer.pt and colophon.pt to viewlets? Why? Because custom skins very often want to hide these. With the (incredibly cool) new viewlet manager from fschulze, we could make this very easy. As it stands, you still need to customise both of these (and/or main_template) to remove/change them. Thoughts? I thought this was already the case, but you're right — it's not, I just checked. Right now, there is a viewlet manager showing a footer viewlet, but the footer isn't actually inside of it. I'd consider this a bug, not a new feature. :) Related, I'm also rethinking how to do the document actions to make sure it's possible to have a product that works and looks right on both 2.5 and 3.0. At the moment, you will get duplication and/or the new document actions in the wrong location, depending on how you look at it. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Remove community_workflow?
On Mon, 04 Jun 2007 16:23:34 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: In reference to https://dev.plone.org/plone/ticket/6501, I *think* it would be safe and sensible to remove community_workflow and community_folder_workflow from the standard Plone 3 install, and re-title the plone_workflow and plone_default_workflow to be called Community site workflow and Community site folder workflow or some such. That is, the new community_workflow's are more or less identical to the old (but updated/sanitised) plone_workflow's. We can't remove the plone_* ones since too many things depend on them, but that's just a matter of the id anyway. Objections? Not from me, I believe this is the only sane way to do it. Keeps backwards compatibility while introducing the new workflows. As long as we have titles, nobody cares about IDs. :) …and if we're lucky, we'll have descriptions in DCWorkflows in 2.1 final too (thanks, Jens!): http://www.zope.org/Collectors/CMF/480 -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Moving Collection settings to ZMI
On Wed, 16 May 2007 12:33:50 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: I would agree that the current Collections control panel sticks out like a sore thumb and induces a large amount of huh in the users I've observed trying to use it, in light of the other control panels we now have in Plone 3 (which really is a whole other ball-game than what we have in 2.x). Indeed. I don't think we'll radically improve this in time for 3.0. I don't think we'll radically improve it ever, because fundamentally the abstractions it affords are very low level. Ultimately, it requires a pretty deep understanding of catalogs and indexes and criteria to make any sense to anyone. We wouldn't put the portal_catalog UI in the Plone control panel either. So, +1 for making this a link from somewhere in the ZMI. atct_tool maybe? Yup, I believe that was what Alec was suggesting when I spoke to him about it earlier. It's a stop-gap measure, maybe we need a more clearly defined advanced options that's more in-Plone. But whatever, we don't need to solve that right now and the ZMI largely (possibly badly) serves that function already. I kind of doubt many people are using this control panel right now anyway, or that it will be missed by those not happy to go into the ZMI. If it has more general bits I'm not remembering, we should move those to a more friendly control panel. I had a look at it, and there's nothing that I would interpret as general bits. It's all about index and metadata control. We'd need to make sure wiggy was happy with such a change at this point, though. Obviously. Technically speaking it's pretty much a no-risk change, though. It's not changing any APIs or other assumptions that the beta 3 release message communicates. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Moving Collection settings to ZMI (was: The big 3.0)
a secondary settings panel to me. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] portlet portletCalendar
http://dev.plone.org/plone/changeset/14760 I can't see why this test would fail. The portlet calendar has the class portlet in addition to portletCalendar. In fact, I fixed this a while back in: http://dev.plone.org/plone/ticket/6438 (I just checked with Firebug on a current SVN checkout, the portlet class does indeed show up in the markup of the standard calendar) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re-tagging 3.0 beta2?
Hi, Any chance we could re-tag beta2 with the one checkin that Wichert did to fix the user search? http://dev.plone.org/plone/changeset/14790 Since user search is broken, people can't test sharing page, groups, the new Contributor/Editor/Viewer roles or anything else that requires you to find a user. Which excludes a lot of new functionality that really needs to be tested a bit. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: The big 3.0 ;)
On Mon, 09 Apr 2007 11:32:25 -0700, Rob Miller [EMAIL PROTECTED] wrote: Alexander Limi wrote: On Tue, 03 Apr 2007 03:45:56 -0700, Wichert Akkerman [EMAIL PROTECTED] wrote: - Members folder gets created even though it's turned off? Bug, should be fixed. Still present. i worked on this w/ thomas during the bug day at the sorrento sprint. the fix was easy (just remove the folder declaration from the 'structure' area of the GS profile), but PortalTestCase depends on the Members folder being there for setting up self.folder in the test case class, so all hell breaks loose with the tests. Just to make sure we are all on the same page, we discussed this on IRC, and I believe we agreed to keep the current Members folder around until 3.5 since we're cleaning up a lot of users/groups/teams stuff (and portal_memberdata ;) then. I have renamed the title to Users to match the rest of the terminology used in Plone. The ID is still Members for test reasons, if people think this can be renamed to users instead without a lot of problems, feel free — but this is as far as I dare go in changing it. ;) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list [EMAIL PROTECTED] http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] NuPlone updated
Hi, I updated NuPlone this weekend, and while it's still not entirely finished, it should pretty much be feature complete in all browsers that are not IE6 (haven't tested IE7, but it's likely to have some issues too). It works well in Safari, WebKit, Opera, Firefox at the moment. Kupu issues are fixed, and it's now at the point where I use it as the default when I test things and fix bugs. There are still some spacing that looks a bit off here and there, the prefs portlet[1], some of the new features like the portlet management, and a few of the widgets — but in general, this update fixes most of the major issues I could find. If you stumble over any other major issues, file bugs in the tracker and assign them to me. Enjoy! [1] It is actually caused by Plone being silly about how that template is rendered (insane fill-slots etc), but I will look into that shortly. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: The big 3.0 ;)
On Tue, 03 Apr 2007 12:47:35 -0700, whit [EMAIL PROTECTED] wrote: Alec Mitchell wrote: I don't see why this should be considered any better/worse than the content add menu which uses the exact same links and will be shown on all such pages as well. From a spiders point of view, it's not different, AFAIK. Not that this isn't an important issue, but we've lived with it for a long time. Forget the spidering comment, that was just an additional concern. The real issue here is that people get dead content objects since it doesn't use portal_factory. It's Plone 1.0/2.0 all over again. this is like 3-4 line fix unless you wanted to create a proper add view (ie less effort than has been expended in writing emails about it). might have time this weekend to do it. Why not just link to the same adding method as Plone uses instead of the old-style adding method? That way, portal_factory is used, and everyone is happy. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Tue, 03 Apr 2007 03:45:56 -0700, Wichert Akkerman [EMAIL PROTECTED] wrote: - Members folder gets created even though it's turned off? Bug, should be fixed. Still present. - Put back autofocus behaviour now that we have ondomload (make sure tabindex is correct) Already done I think Halfway, the iterator still emits tabindex=0, which is wrong, so the JS is commented out for now. But shouldn't be hard to fix, and I asked Florian if he could have a look today. - Move sendto/print/whatever to bottom of page, use text representation Needs to happen soon or becomes 3.5 material. Done. Better styling is coming. - Fix up Table-of-Contents styling - Fix up presentation mode styling Needs to happen soon or becomes 3.5 material. Part of my work scheduled for tomorrow. It depends on getting some help with sanitizing the JS since it emits invalid HTML right now. - Search: only in this section checkbox Needs to happen soon or becomes 3.5 material. Added. - Fix in 3.0.x releases - Incremental KSS UI improvements, examples: - Login should be in-place (digg.com for an example) - Adding comments should give you a textfield inline - etc... 3.0.x minor are for bug and security fixes, not feature changes. So in 9 months, we can add comments without reloading the page, great... -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: NuPlone and Plone 3.0
On Tue, 03 Apr 2007 03:30:52 -0700, Wichert Akkerman [EMAIL PROTECTED] wrote: I'm wearing my release manager hat today and was looking at NuPlone. At the moment there are still a lot things that do not work or look bad in NuPlone (IE support, form styling and control panel styling are easy to find examples). That means that it is currently not in a state where I want it to even ship with Plone 3. The plan is still the same as outlined earlier: - Get NuPlone feature complete by beta2 - Work on IE6/7 issues towards the RCs - Decide based on how ready it seems to be whether it should be the default in the RCs. I have set off tomorrow evening to work on NuPlone. - Danny has a made a fair number of improvements on the Informaat NuPlone-based intranet design, which might be mergable into NuPlone directly. But he has no time to work on that. If he sends those changes to me, I'm happy to merge them and sanitize. I have asked him several times, but no response yet. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Thu, 22 Mar 2007 23:43:13 -0700, Alexander Limi [EMAIL PROTECTED] wrote: - There's something strange going on with enabling comments, it only works on the initial view of the page after saving, possibly related This actually seems to be related to the KSS inline loading of the content area too. When I add a comment, then switch to the edit tab, and then back to the view tab, the comment is gone. It comes back if I force-refresh the page. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Fri, 23 Mar 2007 17:49:50 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: Martin Aspeli wrote: - Only show the Display/Add/WF pulldowns on the View screen - Possibly remove the border on initial creation forms (ie. keep the actual green border, but remove everything clickable on it, since it causes errors) +1 We already do this with formlib-based add forms from plone.app.form. Done both of these: no border/tabs on the add form with portal factory or formlib, and no drop-downs except on the View tab. The former is done with a check in base_edit; the latter is done with a content provider registration: the menu is registered for view = IViewView, whilst there is a fallback one for IBrowserView that is just empty. Great! It has one bug, though: I just created a new site after doing svn up, and on the front page (which is a default view in the portal), you don't get any menus, so it's hard to add anything. In fact, since that's the only page (and the menus are missing from folder_contents), you can't really add anything anymore, which is unfortunate. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Sat, 24 Mar 2007 07:19:32 -0700, Martin Aspeli [EMAIL PROTECTED] wrote: This should now be fixed, svn up plone.app.layout. Note that with KSS inline tab reloading and inline content view switching, you'll need to reload the page manually, because KSS doesn't yet refresh the menu as well as the thing inside the border. See https://dev.plone.org/plone/ticket/6272 I thought we stopped doing that because of the URL/history breakage, but I guess that was just a side effect of KSS being broken for a while. Chalk up another good reason to not do the dynamic replacement of the content area. It's also extremely confusing when you do History comparisons, since the standard pattern is to: - Go to the history page - Compare two revisions - Discover that it was the wrong revision, hit the back button to check a different revision - Suddenly you are back at the view page *of the previous object* you looked at Very bad indeed. Again, I strongly recommend that we disable this *unless* the KSS people have time (and willingness) to spend fixing history+URL injection. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Sat, 24 Mar 2007 13:26:43 -0700, Alexander Limi [EMAIL PROTECTED] wrote: Again, I strongly recommend that we disable this *unless* the KSS people have time (and willingness) to spend fixing history+URL injection. That sentence was missing a for now. :) I'm happy to reintroduce it in a later version once we know that it works properly, but right now I don't think it's ready. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Sat, 24 Mar 2007 03:04:50 -0700, Geir Bækholt · Plone Solutions [EMAIL PROTECTED] wrote: Yes. of course the :default must be supplied or the checkbox will not be noticed by html. I somehow took this for granted and didn't mention it (sorry. my oversight), but i see now in boolean.pt widget template in AT that it is not included. Zope has its own built-in form typecast for this: input type=checkbox name=foobar:boolean value=True / input type=hidden name=foobar:boolean:default value= / Works for all cases i can find. I don't have the 10 minutes i need to actually check it into AT and test that it works TTW right now, but i'll try to get it done tonight unless someone beats me to it. Old-skool Zope power ;) Geir just checked in the fix, and it seems to work for everything I was able to test. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Sat, 24 Mar 2007 05:00:05 -0700, Daniel Nouri [EMAIL PROTECTED] wrote: I know that the difference between ZMI and Plone configuration has traditionally been: If you need to do more than that, go to the ZMI, even if more by accident than by anything else. I don't see why we should cling to this distinction. Because now it's by design, not by accident. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PloneErrorReporting
Hi, Could we please remove PloneErrorReporting from Plone 3.0? - Everybody ends up installing it in their sites, meaning their users get pages and pages of error messages. - Sending people to the Plone issue tracker when something goes wrong on random site XYZ.com is not very useful. - It's another thing to keep track of and update/release. - It was never proposed in a proper manner, it suddenly showed up in a release somewhere along the line, and nobody took it out. Related, I want to do the following to minimize the information disclosure and potential security problems, as well as making the error page friendlier: http://dev.plone.org/plone/ticket/6277 Should be a very straightforward sprint task for the people there this week. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Fri, 23 Mar 2007 05:03:58 -0700, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Daniel Nouri wrote: Who removed JS from checkboxes when? I did that, it worked correctly for me (and the old javascript did not work with in-place edit iirc). I haven't tested why it doesn't work for alex. Actually, it doesn't work for anyone, here's how to reproduce: 1. Edit the front page 2. On the Settings tab, uncheck Exclude from navigation, save 3. Edit again, notice how EfN is checked (as it should be) 4. Uncheck it again, click save 5. Edit again, notice how the unchecking didn't stick, and it's impossible to get the item to not be Excluded from Navigation now. What does this mean? It means people need to get of their ass and switch to GS profiles. Not supporting something like title.txt only encourages that imho. Heh. I agree. [Collection Control Panel I'd suggest an advanced section in the control panel. I don't like the idea of moving this back to the ZMI because it's too complex for the typical user. +1 Even Alec (who built it) agrees that the control panel is too much like portal_types, it was just put there for convenience. The general principle behind the Plone control panels is to expose the things *most* people want to tweak (and 3.0 is awesome in that regard), and let the things that very few want to tweak reside in the ZMI settings. It's not about having full settings coverage, then you end up with the ZMI with prettier colors. ;) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Fri, 23 Mar 2007 06:29:01 -0700, Florian Schulze [EMAIL PROTECTED] wrote: On Fri, 23 Mar 2007 07:43:13 +0100, Alexander Limi [EMAIL PROTECTED] wrote: - Fieldsets - Do we still support fieldsets that require something on fieldset #1 to be filled out before you can access fieldset #4? You mean the wizard style like before? You have to use a marker interface for this, then the fieldset stuff isn't used for that type. Yes, I didn't know whether that marker interface was there or not. If you can tell me how this is done, I'll make sure it makes it into the product upgrade docs. - Fieldset code: if more than N (N=6?) fieldsets, turn into pulldown You mean a select pulldown? Yes. Like the Types control panel. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: The big 3.0 ;)
On Fri, 23 Mar 2007 05:00:45 -0700, Daniel Nouri [EMAIL PROTECTED] wrote: Do you want to tell (core) add-on developers to not make use of the niceties of plone.app.controlpanel because their thing is too complex? Uhm, if people can't use zope.formlib anywhere else than in plone.app.controlpanel, then this is a totally different problem. Let me turn it on its head: Do you want developers to expose every single setting in the Plone control panels because it's easier than doing it in other locations? Now, *that's* wrong, if you ask me. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: The big 3.0 ;)
On Fri, 23 Mar 2007 14:40:46 -0700, Geir Bækholt · Plone Solutions [EMAIL PROTECTED] wrote: On 23. mar. 2007, at 13.03, Wichert Akkerman wrote: Who removed JS from checkboxes when? I did that, it worked correctly for me (and the old javascript did not work with in-place edit iirc). I haven't tested why it doesn't work for alex. I believe this is just a matter of adding hooks for the zope-typecasting syntax :boolean and it'll work again. That's what we thought too (and I believe that was what was done), and it doesn't work. If you can prove otherwise, please do. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] The big 3.0 ;)
container, go here. - It looks like you can reorder items in Large Folders, which you can't - WF history and versioning history should be shown in the same table - We need a way to ping us (image with some info about OS, version etc) when you install Plone — checkbox on install screen - Fix up Table-of-Contents styling - Fix up presentation mode styling - Search: only in this section checkbox - Fix in 3.0.x releases - Incremental KSS UI improvements, examples: - Login should be in-place (digg.com for an example) - Adding comments should give you a textfield inline - etc... -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: beta1 release timing
On Fri, 09 Mar 2007 17:42:21 -0800, George Lee [EMAIL PROTECTED] wrote: Alexander Limi [EMAIL PROTECTED] writes: Might be a good time to create that product-developers list we have been considering for a while, too. +1. =) (Are you talking about an e-mail list?) Yes. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: beta1 release timing
On Thu, 08 Mar 2007 15:02:01 -0800, whit [EMAIL PROTECTED] wrote: +100 and someone should blog or write a tutorial about these changes and how to utilize them. I'm collecting stuff for the how to update your product for Plone 3 part of the migration manual that we will send product authors to. Might be a good time to create that product-developers list we have been considering for a while, too. -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Base tag
On Mon, 05 Mar 2007 15:48:46 -0800, Martin Aspeli [EMAIL PROTECTED] wrote: According to the ticket, there is at least an easy fix for the select-all-in-IE issue. See also the note from Geir and my attempt at summarising the problem. Right, the reason I don't want to have a base tag is actually not related to the IE bug, but rather the fact that it breaks HTML anchors, something we have started to use a lot lately (and Kupu now has support for). -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] A short update on performance
Hi, Did some additional profiling today - comparing 3.0 to 2.5, testing Rocky's fix for the issue we found at the optimization sprint, etc. All timings are for 10 calls. Notable findings: - Rocky's fix to Zope 2.10 fixes the worst of the performance penalty, but calling contentmenu.pt still takes 0.76s with his changes — the threadlocal cache in TypesTool got it down to 0.27s (with 2.10.2's broken code, it took a ridiculous 6.38s). - Plone 3 is a tiny bit faster than 2.5 for rendering the document view (3.07s vs 3.47s). We should be able to do better than this. ;) - Rendering the edit page is slower in 3.0 — predictably, since it does a lot more now. It takes 6.29s to render it after the optimizations Hanno co did (8.96s before). As a comparison, Plone 2.5 took 4.54s, but only rendered a small subset of the widgets that are there now. Targets for optimization: - column.pt (the view needs to be profiled properly to see if there's scary stuff going on). It takes about 0.8s to call it right now, although none of the time is spent in the template itself. - TypesTool in CMFCore - adding the threadlocal cache makes that part close to three times as fast, even after the recent Zope 2.10 fix. I think we should do this, as we already subclass TypesTool, and adding the optimization cache here is a quick win. - plone_view/globalize in views is the most expensive call we do by an order of magnitude. On the average view template, globalize takes up 0.52s, and the next most expensive call is mtool.getMemberInfo(user.getId()), which takes 0.04 seconds (ie. not worth optimizing). If we can make globalize faster, everyone wins. :) -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: branching moment
+1 on keeping it until the release (or the RCs at the very least) On Mon, 26 Feb 2007 07:54:07 -0800, Martin Aspeli [EMAIL PROTECTED] wrote: I'd say even wait until the release is out. We don't really want to have an svn switch frenzy with things going into the wrong places when people are fixing last-minute issues with the RCs. I *believe* this is how it's been done in the past (branch on release date), but I may be wrong. Martin On 2/26/07, Wichert Akkerman [EMAIL PROTECTED] wrote: With beta1 coming out soon I am wondering what the best moment would be to branch off Plone 3.0 and open a new trunk. At the moment my preference is to hold off until rc1 to make sure all attention stays on 3.0. I would love some other opinions though. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] 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 -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: latest wicked
On Sun, 25 Feb 2007 22:55:49 -0800, whit [EMAIL PROTECTED] wrote: http://cheeseshop.python.org/pypi?:action=displayname=wickedversion=1.1.1 fixed the on-save/registration issue limi observed Updating and testing now, thanks! -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Re: wicked merged
On Sat, 27 Jan 2007 19:57:50 -0800, whit [EMAIL PROTECTED] wrote: aq is a dependency mainly to avoid multiple catalog calls. now that dieter is a zope foundation contributer I'm going to email him and see if he'd be interested in adding it zope2 proper. OK. Ask about ManagedQuery at the same time? I believe both of these are very useful (but their release/maintenance/license state is a bit ambiguous). -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
