Re: [Framework-Team] Plone 3.5
I'm leaning towards naming the new intermediate release Plone 4 rather than Plone 3.5, and change what we previously thought of as Plone 4 to Plone 5 or Plone Future (until it becomes close enough in time to give it a version number). Plone 3 has been stable and a safe choice, and jumping to 3.5 with bigger changes can only confuse people. -- ___ Helge Tesdal · Senior Developer, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support ___ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Plone-developers] [Framework-Team] Plone 3.5
On 5. mai. 2009, at 22:26, Alec Mitchell wrote: I'd like to stand up for my release a little, since people seem to be implying it was some sort of expectations/compatibility disaster. I don't consider it a disaster. To me it's more about the community learning from mistakes, identifying areas of improvement and getting better by each release. If we were more happy with Plone 2.5 than 3, we would have a real problem. :) -- ___ Helge Tesdal · Senior Developer, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support ___ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.2 Release Manager
On 24. jun. 2008, at 22:45, Spanky wrote: Before I make my case, the reason I didn't simply say I'll do it! is because I'd like to know a little bit more about the job. This is what I was really asking for. I certainly don't want to volunteer for something I cannot do :) So, I asked what the job entails. Is it very code-centric or more process-oriented? To me, it seems this job is about making sure that the appropriate parties are providing the pieces required for the release (cutting releases/ making eggs), compiling everything, running tests, communicating with everyone on this and other teams, tagging releases, managing changelogs, building consensus about versions/features/direction, etc. Basically managing the release. Maybe I'm totally off- base. Either way, I'd like to learn. Saying no to people trying to get new features into bugfix releases, even though it's unpopular decisions, and even if it's limi who really wants to. ;) -- ___ Helge Tesdal · Senior Developer, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support ___ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Suggestion for more a better streamlined process?
On 18. feb. 2008, at 13:41, Tom Lazar wrote: On 18.02.2008, at 11:41, Martin Aspeli wrote: There have been various good ideas about how to improve the process. I +1 me, too. i also want to definitley stay on for 3.2, as well, which will then have a much more streamlined process. How about always keeping half or a third of the previous team on the next team. Unless we're doing that already. :) -- ___ Helge Tesdal · Senior Developer, Jarn · www.jarn.com Plone Solutions, Development, Hosting and Support ___ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP145 Locking - Review
On Tue, 26 Sep 2006 11:13:30 +0200, Raphael Ritz [EMAIL PROTECTED] wrote: 2. Test setup = I wasn't actually able to test the review bundle now with Zope 2.10 from SVN, so I'm basing this review on the demonstration during Archipelago sprint and looking at code. I wasn't able to test it either, but I looked at the code extensively. Because we screwed up the bundle or because of lack of time? Most likely because I was using Zope 2.10 SVN and this was an older, incompatible branch of CMFPlone. When trying to select a Plone Site from the ZMI add dropdown, I got a message about profiles not being available, preventing me from getting to the Add Plone Site screen. I didn't have time to check with prior versions of Zope 2.10. You really need two simultaneous browser sessions with different users authenticaed for this to become visible. The sprint demonstration was very good, which is why I chose to base the review partly on that demo and not testing it for myself in the browser. BTW: if shipping with CMFEditions/iterate: did we already decide whether to enable versioning/staging per default or whether we leave this as an option to the site admin? In case of the latter the TTW locking might need to support and provide different policies wrt lock setting and removing. I'm not aware of any discussion about what should be enabled by default and what should be available for install. It might be a good idea to see how the integration goes and what the UI will look like before deciding. 6. Recommendation = Sure. Do we have an event that gets fired the moment an editing process starts? (rendering an edit form or the user choosing to start some in-line editing process)? If so, we are done. If not, we should introduce and fire such an event. (suggestions on who to actually do this are welcome!) Again, at the time we've considered AT to be the framework. But I agree with Alec that we should aim for a more generic solution. However, I'd be surprised if the team that created this code wouldn't be willing and capable of decoupling it from AT. Correct ;-) I don't consider the discussion here as criticism of the original implementation nor the developers who did it, but more as a discussion about improvements in light of how the framework and our knowledge has evolved since the sprint. Events handling in Archetypes is a different and bigger issue than just this PLIP, and will have to be done regardless of what we think of this PLIP. We need to continue the good discussion about the details and challenges here, just keep in mind that this isn't personal in any way. One problem I see is that it might not be clear about what we're voting about. Are we voting on a merge of the current implementation as is, or are we voting on the PLIP and functionality, and considering the current implementation more as a prototype to be reimplemented (which is feasible in this case due to the limited amount of code)? My reasoning has been closer to the latter, but I could probably have been more explicit about it. -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP8 CMFEditions - Review
1. Overview === PLIP8 Versioning finally gives Plone a versioning story. http://plone.org/products/plone/roadmap/8 2. Test setup = This was tested with Zope 2.10 from SVN and the review bundle. svn co https://svn.plone.org/svn/plone/review/plip8-versioning-bundle Products cd Products ./getZVC.sh 3. How does it work === UI wise, the user can add versions explicitly using the versions tab, or use the checkmark on the edit form to add a new version on save. If you assign diffs to content types in the diff tool, you can even diff between versions of content. The doc/DevelDoc.txt and the README explains more about how it works under the hood, and I'm trying to give a short summary below: portal_repository/IRepository.py implemented by CopyModifyMergeRepositoryTool.py Main API. Implementation depends on the applications use cases/policies. portal_archivist/IArchivist.py implemented by ArchivistTool.py The Archivist knows _how_ to clone/copy a python object. It needs the help of the portal_modifier to find the boundaries of an object. portal_modifier/IModifier.py implemented by ModifierRegistryTool.py Registry for modifier plug ins. Modifiers know how to handle different aspects of objects during the versioning process - knows _what_ to clone. portal_historiesstorage/IStorage.py implemented by ZVCStorage.py Storage layer for storing the versions. Does not have to care about references as that is handled already. purge - can be used for purging very old data. This is a fairly new feature. 4. State of code CMFEditions has a lot of history (pun intended), going all the way back to 2003, with the main development push happening in 2004 and 2005 (sponsored by Oxfam). By now, I believe it is well proven and battle hardened. There also seems to be quite a bit of code. A bit like Plone itself. There are interfaces with good descriptions, and a lot of time has obviously gone into the architecture design. Although there is a lot of code, there is not a lot of bit rot compared to other components of similar age and complexity. 5. Suggested improvements = It would probably make sense to introduce some Z3 tech, like triggering an event when creating a new version for example. I don't see any showstoppers, and inclusion in Plone 3 will hopefully lead to increased development activity. 6. Recommendation = CMFEditions adds significant complexity to Plone. There is a lot of code, and several new tools. I'm not going to pretend I full understand all aspects of the code yet, but what I have seen is confidence inspiring. Versioning is an important feature, and this seems to be the best alternative around. +1 to including this in Plone 3. -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP168 Iterate - Review
1. Overview === PLIP168 Iterate provides in-place staging in Plone for improved editing of published content. http://plone.org/products/plone/roadmap/168 2. Test setup = This was tested with Zope 2.10 from SVN and the review bundle. svn co https://svn.plone.org/svn/plone/review/plip-168-iterate Products 3. How does it work === The action menu has a 'check out' option, to create a copy of the published content. On checkout, an event is fired, and a reference linking the copy to the original is added. The copy has 'check in' and 'cancel checkout' actions. When checking in, an event is fired, and the published content is replaced by the edited copy. 4. State of code Great. Cleanly laid out, customizable by adapters and events. Very confidence inspiring. 5. Suggested improvements = When I tried to view the locked front page I had made a copy of, I got an error and was unable to view the page until I checked in the copy. Didn't look into it - assuming it's a minor issue, but has to be fixed before merge. There are a couple of items in the todo list that will hopefully get some more attention if iterate is included in Plone 3, but iterate is useful in Plone 3 even without those items. 6. Recommendation = +1 to including this in Plone 3. -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP145 Locking - Review
1. Overview === PLIP145 Locking http://plone.org/products/plone/roadmap/145 2. Test setup = I wasn't actually able to test the review bundle now with Zope 2.10 from SVN, so I'm basing this review on the demonstration during Archipelago sprint and looking at code. 3. How does it work === When editing content, an event is fired, and an event handler sets a WebDAV lock to prevent concurrent editing. When editing ends or is cancelled, an event is fired, and an event handler removes the WebDAV lock. I believe you can also remove stale locks. 4. State of code Implemented using view, events and event handlers. Not a lot of code (or I missed some code), fairly easy to get an overview of and modify. 5. Suggested improvements = This needs to be made compatible and aware of iterate. Event naming conventions has to be harmonized with iterate. Furthermore, it should not be possible to easily remove the lock set by iterate on the published content (or locks set by any other applications for that matter). Check the comments section of the PLIP page for specifics. 6. Recommendation = +1 to including this in Plone 3 - provided the suggested improvements are done. -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] review status
On Tue, 19 Sep 2006 15:34:43 +0200, Wichert Akkerman [EMAIL PROTECTED] wrote: If someone is not able to make the deadline please say so so we can try to rearrange the workload. I might not be able to make the deadline. If anyone have spare time, don't hesitate to look into the versioning/iterate/locking bundles. -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] My review bundles (versioning etc)
Just a heads up to let you know that I won't be able to look into the review bundles I'm responsible for until Friday evening or the weekend. Where did we put the list of bundles and people responsible anyway? -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: hard dependency on PIL?
On 3:12 pm 09/12/06 Martin Aspeli [EMAIL PROTECTED] wrote: I think a dependency is probably OK, even though it would annoy me to have to do it for all development instances. The swinger for me is the recent security problems that we've had to use PIL to get around. Is it possible to disable member portraits if PIL is not installed? ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Now what do we do?
On Wed, 30 Aug 2006 20:31:19 +0200, Martin Aspeli [EMAIL PROTECTED] wrote: Glad you feel that way, I don't want to be seen to tell people what to do! Personally, though, I prefer to get a bit of a nudge rather than have to do all the leg work myself (and I was in need of a distraction). Nudge is good. Do we keep the list somewhere else than in mails? Like on plone.org or in SVN? -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.0 shouldn't just be about the user facing UI
On Mon, 13 Mar 2006 20:08:11 +0100, whit [EMAIL PROTECTED] wrote: Helge Tesdal wrote: On Mon, 13 Mar 2006 18:18:20 +0100, whit [EMAIL PROTECTED] wrote: My personal feeling(somewhat reinforced by what I saw at the symposium) is that our ui layer is on a crash course with it's self. At best, this offers an opportunity to rethink how we want to work with UI as developers, designers, integrators, etc before stumbling into a system shaped by the assumptions of the old one. I tend to prefer the complete rethink, so I'd like a discussion on how we're doing UI and how we want to do UI. :) this is what I'm advocating, the discussion that I think needs to happen. What I meant to write was: +eleventybillion -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone core developer manual
On Mon, 13 Feb 2006 19:52:56 +0100, Martin Aspeli [EMAIL PROTECTED] wrote: Raphael Ritz [EMAIL PROTECTED] writes: Again, I propose Martin for this, if he is available. at Martin: would you be willing to do this? If there's one thing I do, it's yap on a lot. I'm happy to take on this role if people want me to do it. +1 -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone core developer manual
On Mon, 13 Feb 2006 21:43:10 +0100, whit [EMAIL PROTECTED] wrote: vds, helge? I already voted (Mon, 13 Feb 2006 20:12:45 +0100) +1 -- Helge Tesdal Plone Solutions ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
