[Framework-Team] Re: PLIP lifecycle
Hanno Schlichting hanno...@hannosch.eu writes: The exact way to involve the UI and documentation team needs to be defined. I think we should write up the process first and then sent it for comments to the two others team. We can incorporate their feedback in terms of when and how they like to be involved. It seems like it's important that this part be both structural and lightweight. By structural I mean there should be more than just a we should think about docs when discussing the PLIP gesture. We could define this either through procedure alone or through the tools. Could we include reviews by the other teams in the Trac workflow for PLIPs? That would remove any requirement that someone on the FwT *remember* to check for the external team reviews. :) One way to keep these cross-checks lightweight might be to start with a statement of impact. There are code changes, for example, that have no UI impact. In such cases, it would be fast and more painless if a PLIP champion noted this. Someone from the UI team could then corroborate that the PLIP entails no UI impact and that would be the end of it. If there is an impact, then the PLIP champion would need to include full UI consideration for the impact in the PLIP. The UI team could then review both the statement of impact for accuracy and the UI consideration for sufficiency and completeness. The same would largely be true for the doc team with the exception that, IMO, all changes have a documentation impact even if it's only for developers and so there should be no option to declare no impact. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
Hanno Schlichting hanno...@hannosch.eu writes: - Plone 4 will be primarily a feature based release, not time-based ... - Plone 4 will be released based on an agile approach +1 I like this approach a lot. I've been worrying about how to be ambitious while still ensuring that Plone 4.0 is something more than perpetual pie-in-the-sky. The proposed approach seems to strike an ideal balance. We need to address various major problems with Plone of which some will block a new release from my point of view. For example noticeably increased performance, unifying similar concepts (portal skins vs. Zope3, viewlets vs. macros vs. portlets), a better page composition story (no more folder_listings, display menu) and a leap in our technical base (Python 2.6 and WSGI). +1 There are a lot of issues I think need urgent improvement in Plone, but I also agree it's important to be as conservative as we can in terms of what issues we allow to block Plone 4. This list is pretty much exactly what I'd restrict myself to were it left to me. The possibility to easily use a non-Archetypes based content type story is blocking a new release for me as well. Switching to a new default story is something I don't consider possible in the next year right now, but might be convinced otherwise. +1 I think it would be a mistake to switch to a non-AT based story as the default story before 4.5. My reasons are largely psychological and anthropological. I think many in the integrator community and the accidental-technologist-turned-developer community are dealing in part with a sense that Plone is too much of a moving target. OTOH, many in the developer community, such as myself are having less fun coding with Plone because of all the history represented in the code base. Many in the consultant community are also having more pain from projects that find the learning curve and rabbit holes that stem from keeping history alongside new technology. It seems that we have fairly widespread agreement that getting this balance right is one of the most important things we need to fix with Plone 4. So I would like to see something of a slight-of-hand here. I'd like to get us to the point where there is a new content type/schema definition story that will make developers happy again. I'd also like to ensure, however, that small Plone deployments with a few custom AT content types don't have a psychological assault when they *read* that AT is no longer the The Way in Plone 4. I'd prefer a carrot to a stick. Your AT content types should be fairly easily portable to Plone 4! BTW, if you want your content types to perform better, take a look at dexterity (or whatever)! I think it's also important, however, that there be a *flavor* of Plone that uses *only* the next generation of content type/schema definition for those developers like myself that are eager to just move on. Fortunately, this seems easily doable in a setuptools world. Of course this raises the concern of yet again running two different technologies side-by-side. To mitigate this, I'd be in favor of moving very quickly to a 4.5 that completely removes AT as a part of Plone-the-product at the very least. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
Tres Seaver tsea...@palladion.com writes: Ross Patterson wrote: Tres Seaver tsea...@palladion.com writes: Hanno Schlichting wrote: - Plone 4 will have a documented upgrade story A migration from Plone 3 to 4 does not need to be possible in an almost fully automated fashion. We need to ensure we have an easy to follow and understandable documented upgrade story. If we for example change API's or rearrange code, we can document the new places in writing and with error references for the most commonly used parts. If you need to change your buildout configuration, a document explaining the changes is fine, we don't need to build an upgrade machinery for configuration files. Can I persuade you and the FWT to forego an upgrade-in-place strategy for moving from P3 to P4, and instead to have a well-tested ad documented dump-and-reload story? I've never actually understood how a dump-and-reload approach would be inherently more maintainable or otherwise more trouble-free. I know this has been discussed before, but I missed those discussions. Can anyone shortcut the research for me and give me some links or pointers to previous discussions? The short answer is that in-place migrations lead to ordering-dependent arrangements of crufty bits in the site: it gets particularly bad when the representation format of the data changes. If the programmer is both careful and lucky, she can often mitigate the problem with clever defaults, properties, etc., but the downside is that the BBB-driven code has to stay around *forever*. Thanks, that's exactly what I wanted to hear. So it's not so much about being inherently easier to implement as it is about enabling the removal of code. In that case, I'm +1 on this but I have other concerns. Dumping the content out to a neutral format and loading it into a clean site loses the crufty bits, and leaves the code in the new software free of nasty BBB stuff. It also gives people a migration target (for moving content into Plone, or even out of it), as well as a non-ZODB-specific backup representation of the site (e.g., to populate a staging / testing server). It seems like this this dump format will likely become a point of hackability in our software ecosystem. People out there will find interesting things to do with it aside from dump-and-reload. This would be a good thing except we're *expecting* the format to be unstable and change rapidly. It seems possible that there would be some ruffled feathers out there amongst those who come to depend on such hacks and then find that their favorite hack is quickly broken by the next release. As such, it seems like it would be a good idea to dress up the dump format in flashing red lights and loud alarms to discourage at least the adoption of such hacks if not their creation. It also seems like the complexity of this dump format is easily underestimated. I'm a little concerned that we'll adopt a solution that is more accidental in nature, such as an extension to the current GS handlers. I suspect that later we'd find some structural inadequacies in such an approach but having already build our upgrade machinery around it we'll have yet another painful change to make as we change to something better designed. OTOH, perfect is the enemy of good enough. I suggest we start with a *minimal* design discussion about how to architect a dump-and-reload strategy with the future in mind. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Patterson wrote: Tres Seaver tsea...@palladion.com writes: Ross Patterson wrote: Tres Seaver tsea...@palladion.com writes: Hanno Schlichting wrote: - Plone 4 will have a documented upgrade story A migration from Plone 3 to 4 does not need to be possible in an almost fully automated fashion. We need to ensure we have an easy to follow and understandable documented upgrade story. If we for example change API's or rearrange code, we can document the new places in writing and with error references for the most commonly used parts. If you need to change your buildout configuration, a document explaining the changes is fine, we don't need to build an upgrade machinery for configuration files. Can I persuade you and the FWT to forego an upgrade-in-place strategy for moving from P3 to P4, and instead to have a well-tested ad documented dump-and-reload story? I've never actually understood how a dump-and-reload approach would be inherently more maintainable or otherwise more trouble-free. I know this has been discussed before, but I missed those discussions. Can anyone shortcut the research for me and give me some links or pointers to previous discussions? The short answer is that in-place migrations lead to ordering-dependent arrangements of crufty bits in the site: it gets particularly bad when the representation format of the data changes. If the programmer is both careful and lucky, she can often mitigate the problem with clever defaults, properties, etc., but the downside is that the BBB-driven code has to stay around *forever*. Thanks, that's exactly what I wanted to hear. So it's not so much about being inherently easier to implement as it is about enabling the removal of code. In that case, I'm +1 on this but I have other concerns. Dumping the content out to a neutral format and loading it into a clean site loses the crufty bits, and leaves the code in the new software free of nasty BBB stuff. It also gives people a migration target (for moving content into Plone, or even out of it), as well as a non-ZODB-specific backup representation of the site (e.g., to populate a staging / testing server). It seems like this this dump format will likely become a point of hackability in our software ecosystem. People out there will find interesting things to do with it aside from dump-and-reload. This would be a good thing except we're *expecting* the format to be unstable and change rapidly. It seems possible that there would be some ruffled feathers out there amongst those who come to depend on such hacks and then find that their favorite hack is quickly broken by the next release. As such, it seems like it would be a good idea to dress up the dump format in flashing red lights and loud alarms to discourage at least the adoption of such hacks if not their creation. It also seems like the complexity of this dump format is easily underestimated. I'm a little concerned that we'll adopt a solution that is more accidental in nature, such as an extension to the current GS handlers. I suspect that later we'd find some structural inadequacies in such an approach but having already build our upgrade machinery around it we'll have yet another painful change to make as we change to something better designed. OTOH, perfect is the enemy of good enough. I suggest we start with a *minimal* design discussion about how to architect a dump-and-reload strategy with the future in mind. I have code in hand which I have used successfully for two different customer projects: one was using mostly stock Plone content types, while the other used entirely custom versions; both were based o AT. This format has allowed: - Exporting content from a large production site (50k content items), without taking the site down. - Merging content from multiple Plone sites into a single site, by running automated transforms of the exported formats. The basic assumption of the design is that *every* content object maps onto a directory: - Each directory contains a file which exports the item's properties in an INI format - BLOBish property values are mapped as separate files. - References are mapped as sequeces of UIDs in the properties file. - Containers have a file enumerating their subobjects. - Security settings are caputred in a separate INI file. - Workflow history would map onto a separate file (but neither project wanted to preserve the history, so it remains unimplemented). The format is built around GenericSetup's adapters, which makes it possible to extend the framework (e.g., to capture unforeseen values), or to replace implementations (e.g., to accomodate non-AT content schemas). It does not use XML at all, which means it will run even in environments where building lxml is problematic. Tres. - -- === Tres Seaver
[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
