Re: [Framework-Team] Re: [plone4] Release process

[Erik Rose]

On Dec 27, 2008, at 13:31 , Ross Patterson wrote:


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.


Also, the format, if we go the dump-and-reload route, should be a  
tagged one so at least the *addition* of fields needn't scuttle  
dependents. Something XML-based might be a good choice, with my usual  
proviso that humans must never have to look at it. We could even throw  
a "version" attr into each tag in case we want to change the format of  
the data within. That would let dependents react more gracefully to  
format changes.


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [plone4] Release process

[Alexander Limi]

On Sun, 28 Dec 2008 09:10:29 -0800, Martin Aspeli  
 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

Re: [Framework-Team] Re: [plone4] Release process

[David Glick]

On Dec 28, 2008, at 5:37 PM, Martijn Pieters wrote:

On Fri, Dec 26, 2008 at 23:19, David Glick   
wrote:
I am definitely interested in seeing more work on filling out the  
holes in

GS support in core Plone.

If we include a tool for dump-and-reload content migration in Plone  
itself,
I think it needs to be pluggable enough to be useful with non- 
Archetypes

content as well as AT-based content.


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.


David Glick
Web Developer
ONE/Northwest

New tools and strategies for engaging people in protecting the  
environment


http://www.onenw.org
davidgl...@onenw.org
work: (206) 286-1235 x32
mobile: (206) 679-3833

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup





___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: [plone4] Release process

[Martijn Pieters]

On Fri, Dec 26, 2008 at 23:19, David Glick  wrote:
> I am definitely interested in seeing more work on filling out the holes in
> GS support in core Plone.
>
> If we include a tool for dump-and-reload content migration in Plone itself,
> I think it needs to be pluggable enough to be useful with non-Archetypes
> content as well as AT-based content.

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.

-- 
Martijn Pieters

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [plone4] Release process

[Martin Aspeli]

Hi Alex,

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.


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.


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".


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.


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

[Framework-Team] Re: [plone4] Release process

[Alexander Limi]

On Sat, 27 Dec 2008 10:16:15 -0800, Ross Patterson  
 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: [plone4] Release process

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ross Patterson wrote:
> Tres Seaver  writes:
> 
>> Ross Patterson wrote:
>>> Tres Seaver  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 l

[Framework-Team] Re: [plone4] Release process

[Ross Patterson]

Tres Seaver  writes:

> Ross Patterson wrote:
>> Tres Seaver  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

[Ross Patterson]

Hanno Schlichting 
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]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ross Patterson wrote:
> Tres Seaver  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*.

In SQL land, you can imagine altering tables to add columns, etc., with
out breaking anything (assuming that sensible defaults exist).  However,
if the original low-level partitioning / indexing algorithm changes,
etc., then dump-reload is the only sane way forward.  It is pretty much
standard practice to do dump-reload in enterprise-scale RDBMS
applications whenever upgrading the RDBMS software itself.

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).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJVmtM+gerLs4ltQ4RAg29AKChL3bYfEI7NbcISkA7rnfOoVJRoQCgiB92
fpUDM0LadK3U4++MvGd93Mw=
=UIzF
-END PGP SIGNATURE-


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [plone4] Release process

[Ross Patterson]

Tres Seaver  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?

Ross


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Re: [plone4] Release process

[David Glick]

On Dec 25, 2008, at 8:48 PM, Tres Seaver wrote:
If someone wants to champion bringing transmogrifier and GSXML up  
to a

point where they are a fully-featured export and import story for all
aspects of typical Plone content types, that'd be awesome.


I have on tap a non-XML serialization which I have used successfully  
for

a couple of client projects, migrating AT-based content including all
the Plone-specific security weirdness.  I plan to add this code to an
upcoming release of my 'plone_gs' product, but would be willing to
contribute it into the Plone core instead, along with the other code
from that product:

 http://svn.agendaless.com/Products.plone_gs/

There are still some Plone-specific tools and PAS plugins which don't
have full GS support, even with that product.  Finishing out that
support would be part of this effort, as well.



I am definitely interested in seeing more work on filling out the  
holes in GS support in core Plone.


If we include a tool for dump-and-reload content migration in Plone  
itself, I think it needs to be pluggable enough to be useful with non- 
Archetypes content as well as AT-based content.



David Glick
Web Developer
ONE/Northwest

New tools and strategies for engaging people in protecting the  
environment


http://www.onenw.org
davidgl...@onenw.org
work: (206) 286-1235 x32
mobile: (206) 679-3833

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup





___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: [plone4] Release process: technology previews, inclusion and removal of trusted code

[Hanno Schlichting]

Graham Perrin wrote:
> On 25 Dec 2008, at 17:08, Hanno Schlichting wrote:
>> Comments? Anything else people want to know at this point?
> 
> One question and one suggestion. Responses -- from the Team, not
> necessarily from Hanno -- need not be 'at this point', January some time
> will be fine.

There is no deadline on comments. I'd like to get the process and
discussion started now. When we finish depends on the outcome of the
discussion.

> 
> Removal of a feature/code from a technology preview,
> removal of a feature/code from a Plone core release,
> trust in developers
> 
> 
> Recalling from the Evangelism forum a post
> 
> concerning (amongst other things) compatibility and breakage, I think
> the following phrase may require clarification:
> 
>> we can remove the feature again from the codebase. Inclusion into a
>> release can happen on the basis of trusting the developer who did the
>> change to follow up on it and maintain it. If he doesn't, we can
>> remove a feature again from the codebase.
> 
> * remove from the base during technology preview phase?

The statement was only meant to cover the technology preview phase. At
some point we will need to relabel technology previews as a beta release
from which point on stability will be more important. Removal and change
in general will happen less in a beta phase but will still be allowed if
there are very good reasons for it. When we reach a release candidate we
make a guarantee on stability up to the final release.

> * remove from the base following a release?

We only remove features at well-defined points of the Plone lifetime. So
far the policy is to only do this in major releases like 3.0 and 4.0.
During the 4.x minor release cycle we will add new features and might
deprecate existing features, but we will not remove anything.

Hanno


___
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]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hanno Schlichting wrote:
> 
> Tres Seaver wrote:
>> 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'd love to have this story. I think it is even a prerequisite for
> changing the default content types story.
> 
> If someone wants to champion bringing transmogrifier and GSXML up to a
> point where they are a fully-featured export and import story for all
> aspects of typical Plone content types, that'd be awesome.

I have on tap a non-XML serialization which I have used successfully for
a couple of client projects, migrating AT-based content including all
the Plone-specific security weirdness.  I plan to add this code to an
upcoming release of my 'plone_gs' product, but would be willing to
contribute it into the Plone core instead, along with the other code
from that product:

  http://svn.agendaless.com/Products.plone_gs/

There are still some Plone-specific tools and PAS plugins which don't
have full GS support, even with that product.  Finishing out that
support would be part of this effort, as well.

> As long as we don't have a champion for this, I won't make this a
> blocker for a release.

As a non-core developer for Plone, I am not really a "champion," but I'm
fine with helping advance the goal.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJVDft+gerLs4ltQ4RAl5dAKCo4U1eX/SL9CjFpXFZAsnJROZP5ACeMdLB
SPOJVvS5+RNAkJYR3Mp1KLk=
=52Xf
-END PGP SIGNATURE-


___
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]

Tres Seaver wrote:
> 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'd love to have this story. I think it is even a prerequisite for
changing the default content types story.

If someone wants to champion bringing transmogrifier and GSXML up to a
point where they are a fully-featured export and import story for all
aspects of typical Plone content types, that'd be awesome.

As long as we don't have a champion for this, I won't make this a
blocker for a release.

Hanno


___
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]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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?


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJVBDT+gerLs4ltQ4RAqb/AJ424SE/qqstfmRvQ/pJKDisbbvRvgCgjVYw
E/XtFRo81n2SdHAU3m0ALnM=
=+vuy
-END PGP SIGNATURE-


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team