[Framework-Team] Re: Plone Messaging

[Ross Patterson]

JoAnna Springsteen 
writes:

>> So could a team be formed or delegated with the responsibility of
>> reviewing Plone messaging?  Would such an institution be a slippery
>> slope to too much dogma or other stifling restriction?  What might be
>> some other ways to improve messaging in Plone communities?  Is this an
>> issue we're already addressing sufficiently and we just need to give it
>> time?  Is there a value to enshrining this process even if it's already
>> happening?  Is this not an issue?  :)
>
> I believe that this is already being addressed with the work
> Gabrielle, Mark, et. al. have been doing. It's slowly becoming more
> and more visible (15 Questions, organized representation at events
> like NTEN & World Internet Expo, etc). While I'm not sure exactly who
> all is involved on the team, from what I've heard, there is a plan
> taking shape. I'm sure, like most of our teams, they probably need
> more help.
>
> Personally, I think one of the things that would help is a formal
> PR/Marketing/Evangelism contact so that any journalists looking to
> write about Plone or any press releases put out always have a
> representative to go to. Establishing a relationship with the such
> people can be very valuable when it comes to promoting events like
> World Plone Day or the Conference. Telling people to contact a mailing
> list just isn't enough (tho I think it should still be done so we have
> a record of such messages/inquiries).
> Establishing a leadership team for the doc team has helped us get
> organized and we operate much like the framework team. Having a
> recognized leadership for all of Plone's working groups might benefit
> from a guiding team?

I meant messaging in a sense larger than just marketing.  I think we
need to better communicate with and educate our communities of
consultants, developers, and users regarding subjects other than just
marketing and press.

For example, what expectations should consultants communicate to
technically minded clients about features in the next release?  When a
sysadmin and sometimes hacker at a non-profit gets excited about Plone
and starts advocating for its usage internally, what will she have read
that helped her set expectations that will guide her towards success?
What will a consultant have read by the time they decide to start taking
on Plone jobs to help guide ethical and successful consulting?  If any
of these people started or joined discussions on IRC, on the mailing
lists, or at a conference, will the community members participating in
those discussions have encountered enough queues about appropriate
messaging?

These kind of messages are not largely or exclusively technically,
marketing, or user oriented.  They require a cohesion of all concerns.

Maybe I'm trying to be structural about something that shouldn't be
addressed that way.  It does seem, however, that this is a significant
challenge for our communities.  No?

Ross


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

[Framework-Team] Re: [Evangelism] Plone Messaging (was: How would you position Plone?)

[JoAnna Springsteen]

> So could a team be formed or delegated with the responsibility of
> reviewing Plone messaging?  Would such an institution be a slippery
> slope to too much dogma or other stifling restriction?  What might be
> some other ways to improve messaging in Plone communities?  Is this an
> issue we're already addressing sufficiently and we just need to give it
> time?  Is there a value to enshrining this process even if it's already
> happening?  Is this not an issue?  :)

I believe that this is already being addressed with the work
Gabrielle, Mark, et. al. have been doing. It's slowly becoming more
and more visible (15 Questions, organized representation at events
like NTEN & World Internet Expo, etc). While I'm not sure exactly who
all is involved on the team, from what I've heard, there is a plan
taking shape. I'm sure, like most of our teams, they probably need
more help.

Personally, I think one of the things that would help is a formal
PR/Marketing/Evangelism contact so that any journalists looking to
write about Plone or any press releases put out always have a
representative to go to. Establishing a relationship with the such
people can be very valuable when it comes to promoting events like
World Plone Day or the Conference. Telling people to contact a mailing
list just isn't enough (tho I think it should still be done so we have
a record of such messages/inquiries).
Establishing a leadership team for the doc team has helped us get
organized and we operate much like the framework team. Having a
recognized leadership for all of Plone's working groups might benefit
from a guiding team?

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

Re: [Framework-Team] Re: [Plone-developers] The new Plone 4.0, was Re: Plone 3.5

[Ricardo Alves]

Steve McMahon wrote:

My only concern about calling Hanno's incremental change list 4.0 is
that we don't suffer from big-number expectation syndrome.


This is the biggest risk I guess, a major release with just a minor set 
of visible (UI) improvements, will bring bad publicity.




If we start thinking that 4.0 "has to be big enough" to justify the
numbering jump, and start expanding too much on the "yes" list, we
won't get this out in 2009. And, it won't serve the purpose of
delivering enough new stuff to keep folks excited while waiting for
the big UI items.

So, a couple of questions for us all:

1) If we call it Plone 4.0, can we restrict ourselves to a modest list
of improvements that will actually get coded this summer and tested
this fall?

2) If we call it Plone 4.0, can we resist ourselves to changes that
will not break existing theme products or well-constructed Plone 3 add
ons?


Isn't that already the promise of the 3.x series? I mean, to be keep 
backward compatibility with Plone 3.0 addons? I still think that some of 
these improvements should be included in one or more 3.x releases.




Ricardo



On Tue, May 5, 2009 at 2:20 PM, Ross Patterson  wrote:

Lennart Regebro 
writes:


On Tue, May 5, 2009 at 22:05, Ross Patterson  wrote:

Sorry if I'm resurrecting an already fairly resolved debate.  None of
the concerns I raise here are enough to vote -1 one calling it
4.0.  But if enough people feel as I do here, maybe we should discuss
a little further.  What about plone 3.9?

3.0.x was very buggy, and I think that has been somewhat saved by the
upgrades to 3.1 and 3.2 being so painless. I think it would be, for
that reason, a big mistake to introduce bigger changes in 3.X unless
we can make sure the upgrade is quite painless and the changes are
*very* stable.

Yeah, I guess trying to have a release line that can grow is trying to
have it both ways.  I'm very concerned about the expectations we've been
developing about Plone 4 and the impact that will have on perceptions
when we say, "Yeah, that's plone 5 now" or worse yet the even less
confidence inducing "Yeah, that's plone trunk now."  But I guess the
right response to that issue is to be more disciplined in our messaging
in the future and *not* talk about release numbers before the release
process has had a chance to weigh in.  IOW, any perceptual/expectation
problems we have from this may be our just desserts.  :)

+1 to calling it 4.0.  +1 to constraining ourselves to not include
additional disruptive changes in the newly established 4.0 line and thus
to only include them in subsequent major versions.  +100 to not talking
about version 5 until the 5 FWT has actually done enough of it's process
to have some formal establishment of expectations.

Then I'll just have to buck up and tell people that a better skinning
story will *not* being Plone 4 afterall and that I can't tell them it
will be in Plone 5 and that somehow they shouldn't be discouraged by
that.  :(

Ross


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Plone-developers mailing list
plone-develop...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-developers







--
Ricardo Alves 
Eurotux  



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

[Framework-Team] Plone Messaging (was: How would you position Plone?)

[Ross Patterson]

It seems that a lot of the things we can improve on in our community can
trace their origins back to messaging.  Witness Chris Calloway's
observations regarding damage to our reputation from consultants trying
to solve any and every problem with Plone and poor expectations
regarding how much adopters should expect to have to engage the services
of consultants.  Witness the confusion regarding whether Plone's sweet
spot is an enterprise CMS or a small organization CMS (I think it may be
both, but we're not good a communicating how that is).  Witness the oft
cited expectations problems with the 2.5 release and the pain I now feel
about the surrendering already established expectations about the 4.0
release.  Witness the framework vs product debate.  We're now targeting
the notion of Plone Base and Plone the Product and a Plone API but are
we going to do enough to communicate what that means to the far reaches
of Plone communities?  I know that I and others appreciate the openness,
democracy, and introspection in Plone communities that allows us to be
honest about how the glass is half empty but regret that more isn't done
to share and express how the glass is half full.  It also seems that our
marketing story could be significantly improved with a better shared
understanding of the various different messages we'd like to get out
there.

To be sure, I like the decentralized and democratic character of Plone
communities and I don't in any way suggest we sacrifice that.  I do
think, however, that there's a lot we can do in the way of instilling
sufficient messaging discipline without sacrificing those qualities.
Bringing good release discipline by canonizing a release manager, for
example, has been a huge win for Plone user experience without
sacrificing the openness of Plone development.  I think appointing a
"Messaging manager" would be a bad idea, I only cite that as an example
of how discipline can be improved without sacrificing openness.

I know the PSPS did a lot to address messaging in the Plone world.  I
wonder, however, if recently we're not once more drifting too far from
sufficient messaging discipline.  It seems likely such drift is bound to
recur without some sort of somewhat central institution concerned with
discipline.

I don't think control is necessary here.  This is one of the great
things about Plone communities.  We respond well to a sense of shared
mission.  The value here would not be in policing, but rather in
ensuring that we have a continuous dedication of resources to the matter
of messaging.  The mission might be merely to start the discussions that
need to happen but aren't and to take the messages that come out of all
relevant discussions and ensure their wide dissemination to the far
reaches of Plone communities.  It would also have to be a broad, rather
than narrow, team with strong technical, marketing, and user voices to
ensure integral messaging.  Messaging like this can have a subtle effect
that may become very powerful when compounded through shared
understanding and repetition.

So could a team be formed or delegated with the responsibility of
reviewing Plone messaging?  Would such an institution be a slippery
slope to too much dogma or other stifling restriction?  What might be
some other ways to improve messaging in Plone communities?  Is this an
issue we're already addressing sufficiently and we just need to give it
time?  Is there a value to enshrining this process even if it's already
happening?  Is this not an issue?  :)

Ross


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

[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Ross Patterson]

Andreas Zeidler  writes:

> On May 5, 2009, at 11:11 PM, Ross Patterson wrote:
>> I should clarify my question here.  Is there an issue with making sure
>> that the backed up BLOB directory is consistent with a particular
>> backed
>> up state of the Data.fs via repozo.
>
> no.  the only important bit is to not pack the zodb before the blob
> storage backup has finished.  so what you do is:
>
> 1. backup data.fs via repozo
> 2. backup blob storage (for example via rsync)
> 3. optionally pack the zodb
>
> you might end up with some extra blobs created at a time after or
> during the repozo backup, but other than taking up space they won't
> hurt.  otherwise blobs will never change and only get removed during
> packing.
>
>> I'm just saying we'd need to be able to make some
>> promise about repozo backups of Data.fs and backups of BLOB directory
>> being consistent.
>
> we can.

Yay!  +1

Ross


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

Re: [Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Andreas Zeidler]

On May 5, 2009, at 11:11 PM, Ross Patterson wrote:

I should clarify my question here.  Is there an issue with making sure
that the backed up BLOB directory is consistent with a particular  
backed

up state of the Data.fs via repozo.


no.  the only important bit is to not pack the zodb before the blob  
storage backup has finished.  so what you do is:


1. backup data.fs via repozo
2. backup blob storage (for example via rsync)
3. optionally pack the zodb

you might end up with some extra blobs created at a time after or  
during the repozo backup, but other than taking up space they won't  
hurt.  otherwise blobs will never change and only get removed during  
packing.



I'm just saying we'd need to be able to make some
promise about repozo backups of Data.fs and backups of BLOB directory
being consistent.


we can.


andi

--
zeidler it consulting - http://zitc.de/ - i...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.2.2 released! -- http://plone.org/products/plone/



PGP.sig
Description: This is a digitally signed message part
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Laurence Rowe]

Ross Patterson wrote:

Andreas Zeidler  writes:


On May 5, 2009, at 10:05 PM, Ross Patterson wrote:

BLOBs: Has the backups/repozo story been sufficiently worked out?

this will need a good backup story, but it won't be via repozo.
repozo was meant to backup a single data.fs, but not your entire
zodb.  the blob storage will tend to be big and might live on some
media with other backup strategies (think SAN or S3).  there should be
some recipe or something that provides a single script to backup both
for the standard use-case of having the blob storage live on the same
filesystem, but that shouldn't be repozo.


I should clarify my question here.  Is there an issue with making sure
that the backed up BLOB directory is consistent with a particular backed
up state of the Data.fs via repozo.  IOW, can we say something like "so
long as you restore your BLOB directory to a state as it was in the same
moment or after the repozo process started then it is guataneed to be
consistent"?  I'm not saying that the above statement is correct cause I
don't know.  :) I'm just saying we'd need to be able to make some
promise about repozo backups of Data.fs and backups of BLOB directory
being consistent.


No problem here, you just take the copy of your BLOB directory after you 
take the copy of your Data.fs. The dangling blobs in the backup (those 
created since your backup of the Data.fs) are not an issue.


Creating a consistent backup of two filestorages (e.g. Catalog.fs and 
Data.fs) is more tricky.


Laurence


___
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, was Re: Plone 3.5

[Steve McMahon]

My only concern about calling Hanno's incremental change list 4.0 is
that we don't suffer from big-number expectation syndrome.

If we start thinking that 4.0 "has to be big enough" to justify the
numbering jump, and start expanding too much on the "yes" list, we
won't get this out in 2009. And, it won't serve the purpose of
delivering enough new stuff to keep folks excited while waiting for
the big UI items.

So, a couple of questions for us all:

1) If we call it Plone 4.0, can we restrict ourselves to a modest list
of improvements that will actually get coded this summer and tested
this fall?

2) If we call it Plone 4.0, can we resist ourselves to changes that
will not break existing theme products or well-constructed Plone 3 add
ons?

If we can agree to that and task Eric with enforcing it, I'm all for
calling "it" 4.0. In any case, Hanno's and collaborators have set us
on a great course.

Steve



On Tue, May 5, 2009 at 2:20 PM, Ross Patterson  wrote:
> Lennart Regebro 
> writes:
>
>> On Tue, May 5, 2009 at 22:05, Ross Patterson  wrote:
>>> Sorry if I'm resurrecting an already fairly resolved debate.  None of
>>> the concerns I raise here are enough to vote -1 one calling it
>>> 4.0.  But if enough people feel as I do here, maybe we should discuss
>>> a little further.  What about plone 3.9?
>>
>> 3.0.x was very buggy, and I think that has been somewhat saved by the
>> upgrades to 3.1 and 3.2 being so painless. I think it would be, for
>> that reason, a big mistake to introduce bigger changes in 3.X unless
>> we can make sure the upgrade is quite painless and the changes are
>> *very* stable.
>
> Yeah, I guess trying to have a release line that can grow is trying to
> have it both ways.  I'm very concerned about the expectations we've been
> developing about Plone 4 and the impact that will have on perceptions
> when we say, "Yeah, that's plone 5 now" or worse yet the even less
> confidence inducing "Yeah, that's plone trunk now."  But I guess the
> right response to that issue is to be more disciplined in our messaging
> in the future and *not* talk about release numbers before the release
> process has had a chance to weigh in.  IOW, any perceptual/expectation
> problems we have from this may be our just desserts.  :)
>
> +1 to calling it 4.0.  +1 to constraining ourselves to not include
> additional disruptive changes in the newly established 4.0 line and thus
> to only include them in subsequent major versions.  +100 to not talking
> about version 5 until the 5 FWT has actually done enough of it's process
> to have some formal establishment of expectations.
>
> Then I'll just have to buck up and tell people that a better skinning
> story will *not* being Plone 4 afterall and that I can't tell them it
> will be in Plone 5 and that somehow they shouldn't be discouraged by
> that.  :(
>
> Ross
>
>
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> ___
> Plone-developers mailing list
> plone-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>



-- 

Steve McMahon
Reid-McMahon, LLC
st...@reidmcmahon.com
st...@dcn.org

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

[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Ross Patterson]

Lennart Regebro 
writes:

> On Tue, May 5, 2009 at 22:05, Ross Patterson  wrote:
>> Sorry if I'm resurrecting an already fairly resolved debate.  None of
>> the concerns I raise here are enough to vote -1 one calling it
>> 4.0.  But if enough people feel as I do here, maybe we should discuss
>> a little further.  What about plone 3.9?
>
> 3.0.x was very buggy, and I think that has been somewhat saved by the
> upgrades to 3.1 and 3.2 being so painless. I think it would be, for
> that reason, a big mistake to introduce bigger changes in 3.X unless
> we can make sure the upgrade is quite painless and the changes are
> *very* stable.

Yeah, I guess trying to have a release line that can grow is trying to
have it both ways.  I'm very concerned about the expectations we've been
developing about Plone 4 and the impact that will have on perceptions
when we say, "Yeah, that's plone 5 now" or worse yet the even less
confidence inducing "Yeah, that's plone trunk now."  But I guess the
right response to that issue is to be more disciplined in our messaging
in the future and *not* talk about release numbers before the release
process has had a chance to weigh in.  IOW, any perceptual/expectation
problems we have from this may be our just desserts.  :)

+1 to calling it 4.0.  +1 to constraining ourselves to not include
additional disruptive changes in the newly established 4.0 line and thus
to only include them in subsequent major versions.  +100 to not talking
about version 5 until the 5 FWT has actually done enough of it's process
to have some formal establishment of expectations.

Then I'll just have to buck up and tell people that a better skinning
story will *not* being Plone 4 afterall and that I can't tell them it
will be in Plone 5 and that somehow they shouldn't be discouraged by
that.  :(

Ross


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

[Framework-Team] Re: blob backups (was: Re: The new Plone 4.0, was Re: Plone 3.5)

[David Glick]

On May 5, 2009, at 2:04 PM, Andreas Zeidler wrote:

On May 5, 2009, at 10:05 PM, Ross Patterson wrote:

BLOBs: Has the backups/repozo story been sufficiently worked out?


this will need a good backup story, but it won't be via repozo.   
repozo was meant to backup a single data.fs, but not your entire  
zodb.  the blob storage will tend to be big and might live on some  
media with other backup strategies (think SAN or S3).  there should  
be some recipe or something that provides a single script to backup  
both for the standard use-case of having the blob storage live on  
the same filesystem, but that shouldn't be repozo.



I was looking into this last week and found this thread enlightening: 
http://www.nabble.com/Backing-up-Data.fs-and-blob-directory-td19291251.html#a19293438

From that, it sounds like doing a repozo backup followed by an rsync  
of the blobstorage dir probably isn't insane, at least in some setups.


I agree that it would be nice to have some more pre-baked scripts for  
this though.


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: The new Plone 4.0, was Re: Plone 3.5

[Ross Patterson]

Andreas Zeidler  writes:

> On May 5, 2009, at 10:05 PM, Ross Patterson wrote:
>> BLOBs: Has the backups/repozo story been sufficiently worked out?
>
> this will need a good backup story, but it won't be via repozo.
> repozo was meant to backup a single data.fs, but not your entire
> zodb.  the blob storage will tend to be big and might live on some
> media with other backup strategies (think SAN or S3).  there should be
> some recipe or something that provides a single script to backup both
> for the standard use-case of having the blob storage live on the same
> filesystem, but that shouldn't be repozo.

I should clarify my question here.  Is there an issue with making sure
that the backed up BLOB directory is consistent with a particular backed
up state of the Data.fs via repozo.  IOW, can we say something like "so
long as you restore your BLOB directory to a state as it was in the same
moment or after the repozo process started then it is guataneed to be
consistent"?  I'm not saying that the above statement is correct cause I
don't know.  :) I'm just saying we'd need to be able to make some
promise about repozo backups of Data.fs and backups of BLOB directory
being consistent.

Ross


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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[David Glick]

On May 5, 2009, at 1:53 PM, Andreas Zeidler wrote:

On May 5, 2009, at 9:51 PM, Matthew Wilkes wrote:
FTR, one of the things I'd considered working on at the Balloon  
Sprint was the portal_skins/browser_layer/browser resources  
differences.  Andi, would you be interested in that?


interested for sure, but i'm afraid i'm gonna have enough on my  
plate finishing up blobs and unified folders around that time... :)



FWIW, this is still something I'm hoping to tackle (and have lots of  
plans for that I need to actually capture in a document somewhere).   
Hard to find enough time for it these days though, it seems...


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: The new Plone 4.0, was Re: Plone 3.5

[Andreas Zeidler]

On May 5, 2009, at 10:05 PM, Ross Patterson wrote:

BLOBs: Has the backups/repozo story been sufficiently worked out?


this will need a good backup story, but it won't be via repozo.   
repozo was meant to backup a single data.fs, but not your entire  
zodb.  the blob storage will tend to be big and might live on some  
media with other backup strategies (think SAN or S3).  there should be  
some recipe or something that provides a single script to backup both  
for the standard use-case of having the blob storage live on the same  
filesystem, but that shouldn't be repozo.



plone.folder: +10.


going back to keep working on it now... ;)


andi

--
zeidler it consulting - http://zitc.de/ - i...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.2.2 released! -- http://plone.org/products/plone/



PGP.sig
Description: This is a digitally signed message part
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Andreas Zeidler]

On May 5, 2009, at 9:51 PM, Matthew Wilkes wrote:

On 5 May 2009, at 20:42, Andreas Zeidler wrote:
i agree.  perhaps we could try to aim just a little bit higher.   
"Unify portal_skins and browser resources" and "Make pages  
folderish" don't sound all too exciting, for example, but i think  
they'd help solving two pretty important/annoying problems both on  
the developer/integrator and the user end.


FTR, one of the things I'd considered working on at the Balloon  
Sprint was the portal_skins/browser_layer/browser resources  
differences.  Andi, would you be interested in that?


interested for sure, but i'm afraid i'm gonna have enough on my plate  
finishing up blobs and unified folders around that time... :)



andi

--
zeidler it consulting - http://zitc.de/ - i...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.2.2 released! -- http://plone.org/products/plone/



PGP.sig
Description: This is a digitally signed message part
___
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

[Helge Tesdal]

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: [Plone-developers] [Framework-Team] Plone 3.5

[Alec Mitchell]

I agree with what appears to be majority opinion here – that this
release should be called Plone 4.0.  Whatever expectations people
might already have regarding Plone 4.0 can be easily managed.

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.
Plone 2.5 introduced some new infrastructure and officially deprecated
a number of old APIs, scripts and templates, but it maintained
compatibility for all of those.  The only exception that I'm aware of
is the introduction of PlonePAS, which theoretically offered API
compatibility but failed in that regard with some 3rd-party add-ons.
The scope of 2.5 was well defined, and highly constrained (in fact,
Plone's official deprecation/compatibility policy was established as a
part of the 2.5 release). The numbering jump may not have been ideal,
but calling that release 3.0, when there were almost no outwardly
visible changes (aside from deprecation warnings in your logs), would
have also been a blunder, IMO.

If you want to pinpoint a release that broke expectations with regard
to compatibility, Plone 2.1 is a far better example.  There were a
huge number of incompatibilities and migration issues between 2.0 and
2.1.  The transition to ATCT alone was worth a major revision, never
mind the numerous API and UI changes and configuration options
removed/disabled (some of which were thankfully put back in place in
2.5).  If anything, Plone 2.5 began to establish a contract of major
release compatibility that had been entirely destroyed with the 2.0 ->
2.1 transition.  Plone 2.5 wasn't perfect, but I find it hard to
imagine it as the expectations nightmare people are portraying here.

Alec

On Tue, May 5, 2009 at 5:23 AM, Matthew Wilkes  wrote:
> On 5 May 2009, at 12:44, Hanno Schlichting wrote:
>
>> The general idea that seems to have met some consensus is to go for a
>> Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
>> that is similar in spirit to the Plone 2.5 release. It tries to both
>> refresh some of our technical underpinnings in addition to some more
>> intrusive feature changes we didn't allow ourselves in the 3.x
>> series so
>> far.
>
> Why skip 3.4?  That Plone 2.5 was a special-case major release was
> quite nasty, it confused people about what was a major release and
> what isn't.  Also, we've made a commitment to 3.x being stable, I
> think we should keep to it.  However, it would be good to open the new
> features to a wider audience ASAP.
>
> I'd be -1 if it hurts our users by discontinuing a stable platform in
> favour of a half-way house.  If we keep Plone 3.x as fully supported
> and this being something for early adopters and dare-devils, then I'd
> be +0.  I'd be +1 if this was distinction was made explicit in the name.
>
> Matt
>
>
> --
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> ___
> Plone-developers mailing list
> plone-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

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

[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Ross Patterson]

In general, +1.  More below.

Hanno Schlichting 
writes:

> To summarize the feedback from the European time zone, I think that the
> proposal in general meets the favor of everyone.
>
> The controversial issue is the exact version number to use for the
> release. There seems to be broad support for freeing the current Plone
> trunk from a version designator and release a 4.0 release with the
> envisioned scope of this proposal instead.

I really agree with the concern about 3.5 but I also agree with the
problem of the expectations we've developed about what Plone 4 will be.
I also *really* like the idea of having a release series where we can
introduce changes of a level of risk *in between* that which is
appropriate for a stable release and that which is appropriate for a
major release.

IOW, I like the idea of a set of Plone releases that will grow towards
"the feature set formerly known as Plone 4" in incremental, somewhat
disruptive releases that are still appropriate for wide usage.  Consider
that we release all the "yes" items from Hanno's spreadsheet as Plone 4.
Can we then add the "maybe"'s in 4.1?  Or will those changes then be
considered too unstable for inclusion in an already released major
version?

Sorry if I'm resurrecting an already fairly resolved debate.  None of
the concerns I raise here are enough to vote -1 one calling it 4.0.  But
if enough people feel as I do here, maybe we should discuss a little
further.  What about plone 3.9?

> If I do not get a strong signal or message otherwise, consider this
> proposal changed in this regard.

> Hanno Schlichting wrote:
>> Hi.
>> 
>> While everyone is waiting for Plone 4 and its rather long timeline, some
>> people have been thinking about how to bridge the gap between the
>> current stable 3.x releases and the future.
>> 
>> The general idea that seems to have met some consensus is to go for a
>> Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
>> that is similar in spirit to the Plone 2.5 release. It tries to both
>> refresh some of our technical underpinnings in addition to some more
>> intrusive feature changes we didn't allow ourselves in the 3.x series so
>> far.
>> 
>> In order to frame the scope of such a release I made a listing of some
>> of the potential features for such a release at
>> http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list
>> is both non-exclusive and non-binding in the recommendations.
>> 
>> The envisioned timeline for a Plone 3.5 release would be to aim for a
>> final release either by the time of the conference or by the end of this
>> year, giving us six months or a bit more for it. By aiming for an
>> after-summer beta deadline we will have a chance of leveraging some
>> Google Summer of Code contributions for such a release.
>> 
>> When it comes to the official personal involved in such a new major
>> release, I'd like to suggest a slight deviation on our process. As many
>> to all of the features changes in question for the 3.5 release have so
>> far been in the scope of the 4.0 release, I'd suggest to appoint the
>> entire 4.0 framework team to be the official team for 3.5 as well. This
>> forces them to get involved with the process in a more defined and clear
>> way now.

I'm willing.

>> On the side of the release manager, Wichert has signaled that his
>> workload as a freelancer will not allow him to take over the shepherding
>> of a new major release. We do however have with Eric Steele of PSU fame
>> a well-known interested candidate for the position.
>> 
>> This is only a proposal that needs community feedback and encouragement
>> at this point to make it into an official roadmap. The next steps are to
>> have an open discussion about this for the next one to two weeks. If it
>> meets general favor, we will appoint the new/old framework team and let
>> them recommend a release manager to the Foundation board for official
>> nomination.

BLOBs: Has the backups/repozo story been sufficiently worked out?

Python 2.5: I'd like to see this one in 3.5.  Being "stuck" on "such an
old version" of Python seems to have psychological/perceptual effects in
the community and to those looking at Plone from the outside.  Moving to
2.5 now might help with that issue while at the same time priming the
pump for the development community to begin updating their code to more
modern Pythonisms while still being less painful than 2.6/2.7.  IOW, I
think it's a good stepping stone.

Quickinstaller: I think ripping it out in 3.5 would be a bad idea, to
disruptive in the larger add-on ecosystem.  I know I have several
clients for whom this would mean I couldn't upgrade them to 3.5 since
they still depend on add-ons that use Extensions/install.py.  How about
instead switching to a new GS based UI and officially deprecating the QI
thus paving the way for full removal in 4?

plone.folder: +10.  Many of my clients have been bitten by poor ordered
folder scaling.  In fact, I've gotten more

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Matthew Wilkes]

On 5 May 2009, at 20:42, Andreas Zeidler wrote:

i agree.  perhaps we could try to aim just a little bit higher.   
"Unify portal_skins and browser resources" and "Make pages  
folderish" don't sound all too exciting, for example, but i think  
they'd help solving two pretty important/annoying problems both on  
the developer/integrator and the user end.


FTR, one of the things I'd considered working on at the Balloon Sprint  
was the portal_skins/browser_layer/browser resources differences.   
Andi, would you be interested in that?


Matt

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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Andreas Zeidler]

On May 5, 2009, at 8:24 PM, David Glick wrote:
+1 on the modified proposal of aiming for a "less risky" release  
called Plone 4.0, with the caveats that:
- The release needs to offer improvements of significant value to  
justify the effort in upgrading (Hanno's spreadsheet of proposed  
changes and where they might land looks good to me overall)


i agree.  perhaps we could try to aim just a little bit higher.   
"Unify portal_skins and browser resources" and "Make pages folderish"  
don't sound all too exciting, for example, but i think they'd help  
solving two pretty important/annoying problems both on the developer/ 
integrator and the user end.



- We need to nail the upgrade story and documentation of changes.


+1!


andi

--
zeidler it consulting - http://zitc.de/ - i...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.2.2 released! -- http://plone.org/products/plone/



PGP.sig
Description: This is a digitally signed message part
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Jens W. Klein]

Am Tue, 05 May 2009 16:57:21 +0200 schrieb Hanno Schlichting:

> Hi.
> 
> To summarize the feedback from the European time zone, I think that the
> proposal in general meets the favor of everyone.
> 
> The controversial issue is the exact version number to use for the
> release. There seems to be broad support for freeing the current Plone
> trunk from a version designator and release a 4.0 release with the
> envisioned scope of this proposal instead.
> 
> If I do not get a strong signal or message otherwise, consider this
> proposal changed in this regard.

A big +1. Perfect! Thanks Hanno for pushing this forward!

Jens
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance


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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[David Glick]

Just catching up here on the west coast of the US...

+1 on the modified proposal of aiming for a "less risky" release  
called Plone 4.0, with the caveats that:
- The release needs to offer improvements of significant value to  
justify the effort in upgrading (Hanno's spreadsheet of proposed  
changes and where they might land looks good to me overall)

- We need to nail the upgrade story and documentation of changes.

+1 for Eric Steele as release manager for 4.0 (with Hanno continuing  
to oversee Plone trunk)


David

On May 5, 2009, at 7:57 AM, Hanno Schlichting wrote:


Hi.

To summarize the feedback from the European time zone, I think that  
the

proposal in general meets the favor of everyone.

The controversial issue is the exact version number to use for the
release. There seems to be broad support for freeing the current Plone
trunk from a version designator and release a 4.0 release with the
envisioned scope of this proposal instead.

If I do not get a strong signal or message otherwise, consider this
proposal changed in this regard.

Hanno

Hanno Schlichting wrote:

Hi.

While everyone is waiting for Plone 4 and its rather long timeline,  
some

people have been thinking about how to bridge the gap between the
current stable 3.x releases and the future.

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x  
series so

far.

In order to frame the scope of such a release I made a listing of  
some

of the potential features for such a release at
http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The  
list

is both non-exclusive and non-binding in the recommendations.

The envisioned timeline for a Plone 3.5 release would be to aim for a
final release either by the time of the conference or by the end of  
this

year, giving us six months or a bit more for it. By aiming for an
after-summer beta deadline we will have a chance of leveraging some
Google Summer of Code contributions for such a release.

When it comes to the official personal involved in such a new major
release, I'd like to suggest a slight deviation on our process. As  
many
to all of the features changes in question for the 3.5 release have  
so

far been in the scope of the 4.0 release, I'd suggest to appoint the
entire 4.0 framework team to be the official team for 3.5 as well.  
This
forces them to get involved with the process in a more defined and  
clear

way now.

On the side of the release manager, Wichert has signaled that his
workload as a freelancer will not allow him to take over the  
shepherding
of a new major release. We do however have with Eric Steele of PSU  
fame

a well-known interested candidate for the position.

This is only a proposal that needs community feedback and  
encouragement
at this point to make it into an official roadmap. The next steps  
are to
have an open discussion about this for the next one to two weeks.  
If it
meets general favor, we will appoint the new/old framework team and  
let

them recommend a release manager to the Foundation board for official
nomination.

Cheers,
Hanno




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


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] The new Plone 4.0, was Re: Plone 3.5

[Erik Rose]

1) Everyone is for a near-future release of the less risky work  
being done in trunk
2) Calling it 3.5 breaks the dot release contract. Go with "Plone 4"  
instead.


+1

I'd also be okay with (and in fact in favor of, if it didn't create  
too much additional work) releasing another round of Plone 3.x  
containing nondisruptive changes.


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

[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

[Carsten Senger]

Hanno Schlichting schrieb:

Hi.

To summarize the feedback from the European time zone, I think that the
proposal in general meets the favor of everyone.

The controversial issue is the exact version number to use for the
release. There seems to be broad support for freeing the current Plone
trunk from a version designator and release a 4.0 release with the
envisioned scope of this proposal instead.

If I do not get a strong signal or message otherwise, consider this
proposal changed in this regard.


Also +1 for a Plone 4 release.

..Carsten


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

[Framework-Team] Re: [Plone-docs] Plone 3.5

[Veda Williams]

Hello, 

FWIW, Darci Hanning is rewriting the chapter for Practical Plone 3 to
address this change.

Cheers,

- Veda


On 5/5/09 5:21 AM, "Raphael Ritz"  wrote:


> 
> Just for the record: we (the Plone 3 framework team) even got some
> critic from the doc team for allowing
> 
>http://plone.org/products/plone/roadmap/243
> 
> into Plone 3.3 as this had somewhat of an impact on the
> forthcoming manual. (not to mention all the printed books
> that appeared recently and that are going to appear soon)
> 


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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Martijn Pieters]

(Re-post to framework-team with different sender to make it through)

On Tue, May 5, 2009 at 16:57, Hanno Schlichting  wrote:
> To summarize the feedback from the European time zone, I think that the
> proposal in general meets the favor of everyone.
>
> The controversial issue is the exact version number to use for the
> release. There seems to be broad support for freeing the current Plone
> trunk from a version designator and release a 4.0 release with the
> envisioned scope of this proposal instead.
>
> If I do not get a strong signal or message otherwise, consider this
> proposal changed in this regard.

Having read the discussion on the bus, I can say I concur. +1 on this proposal.

-- 
Martijn Pieters

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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Eric Steele]

On May 5, 2009, at 10:57 AM, Hanno Schlichting wrote:


Hi.

To summarize the feedback from the European time zone, I think that  
the

proposal in general meets the favor of everyone.

The controversial issue is the exact version number to use for the
release. There seems to be broad support for freeing the current Plone
trunk from a version designator and release a 4.0 release with the
envisioned scope of this proposal instead.

If I do not get a strong signal or message otherwise, consider this
proposal changed in this regard.

Hanno



I'm glad I've not been the point of contention on this issue. ;) It's  
an honor to be... I guess at this point it's "nominated".


A quick survey of our integrators on campus shows an agreement with  
the current state of this discussion:
1) Everyone is for a near-future release of the less risky work being  
done in trunk
2) Calling it 3.5 breaks the dot release contract. Go with "Plone 4"  
instead.


Eric

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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Martijn Pieters]

On Tue, May 5, 2009 at 16:57, Hanno Schlichting  wrote:
> To summarize the feedback from the European time zone, I think that the
> proposal in general meets the favor of everyone.
>
> The controversial issue is the exact version number to use for the
> release. There seems to be broad support for freeing the current Plone
> trunk from a version designator and release a 4.0 release with the
> envisioned scope of this proposal instead.
>
> If I do not get a strong signal or message otherwise, consider this
> proposal changed in this regard.

Having read the discussion on the bus, I can say I concur. +1 on this proposal.

-- 
Martijn Pieters

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

Re: [Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Calvin Hendryx-Parker]

On May 5, 2009, at 10:57 AM, Hanno Schlichting wrote:

The controversial issue is the exact version number to use for the
release. There seems to be broad support for freeing the current Plone
trunk from a version designator and release a 4.0 release with the
envisioned scope of this proposal instead.

If I do not get a strong signal or message otherwise, consider this
proposal changed in this regard.



+1

--  
S i x  F e e t  U p ,  I n c .  |  http://www.sixfeetup.com

Phone: +1 (317) 861-5948 x602
cal...@sixfeetup.com
ANNOUNCING the first Plone Immersive Training Experience | Sept.  
10-11-12, 2009

http://sixfeetup.com/immerse




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

[Framework-Team] The new Plone 4.0, was Re: Plone 3.5

[Hanno Schlichting]

Hi.

To summarize the feedback from the European time zone, I think that the
proposal in general meets the favor of everyone.

The controversial issue is the exact version number to use for the
release. There seems to be broad support for freeing the current Plone
trunk from a version designator and release a 4.0 release with the
envisioned scope of this proposal instead.

If I do not get a strong signal or message otherwise, consider this
proposal changed in this regard.

Hanno

Hanno Schlichting wrote:
> Hi.
> 
> While everyone is waiting for Plone 4 and its rather long timeline, some
> people have been thinking about how to bridge the gap between the
> current stable 3.x releases and the future.
> 
> The general idea that seems to have met some consensus is to go for a
> Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
> that is similar in spirit to the Plone 2.5 release. It tries to both
> refresh some of our technical underpinnings in addition to some more
> intrusive feature changes we didn't allow ourselves in the 3.x series so
> far.
> 
> In order to frame the scope of such a release I made a listing of some
> of the potential features for such a release at
> http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list
> is both non-exclusive and non-binding in the recommendations.
> 
> The envisioned timeline for a Plone 3.5 release would be to aim for a
> final release either by the time of the conference or by the end of this
> year, giving us six months or a bit more for it. By aiming for an
> after-summer beta deadline we will have a chance of leveraging some
> Google Summer of Code contributions for such a release.
> 
> When it comes to the official personal involved in such a new major
> release, I'd like to suggest a slight deviation on our process. As many
> to all of the features changes in question for the 3.5 release have so
> far been in the scope of the 4.0 release, I'd suggest to appoint the
> entire 4.0 framework team to be the official team for 3.5 as well. This
> forces them to get involved with the process in a more defined and clear
> way now.
> 
> On the side of the release manager, Wichert has signaled that his
> workload as a freelancer will not allow him to take over the shepherding
> of a new major release. We do however have with Eric Steele of PSU fame
> a well-known interested candidate for the position.
> 
> This is only a proposal that needs community feedback and encouragement
> at this point to make it into an official roadmap. The next steps are to
> have an open discussion about this for the next one to two weeks. If it
> meets general favor, we will appoint the new/old framework team and let
> them recommend a release manager to the Foundation board for official
> nomination.
> 
> Cheers,
> Hanno
> 


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

Re: [Framework-Team] Plone 3.5

[Raphael Ritz]

[Do we really need to discuss this on three lists?]

Martin Aspeli wrote:

JoAnna Springsteen wrote:

The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.

What's the significance of 3.5? Why can't this catch up be done in
increments? 3.4 then 3.5 then 3.6?


Because upgrading Zope versions and some of the other changes are too 
big for the Plone 3.x stability promise.


Do we know that for sure already?
Do we know how far we could get with some temporary
module aliases to take care of stuff that has been
moved around?



My worry here is that catching up will mean a repeat of 2.5. 


What does that mean?



That we confused people to now end ...


As I understand the current discussion the general idea
is most welcome. People are concerned of staying in line
with our long-term promises and it seems to me that this
almost exclusively boils down to a naming issue.

Frankly speaking I would have no problem calling the proposed
intermediate release Plone 4 and not to assign a version number
to current trunk at all. AFAICS the current co-notation of
Plone 4 being the all-new, all-shiny next generation of Plone
is merely a project internal that we can redefine without
much of a problem but doing it the other way around because
we consider sneaking in a major release before the next major
release that some got used to think of being Plone 4
carries the risk of creating confusion and distrust where we
can't control it.

Raphael


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

[Framework-Team] Re: Plone 3.5

[Jens W. Klein]

Am Tue, 05 May 2009 22:08:14 +0800 schrieb Martin Aspeli:

> Jens W. Klein wrote:
> 
>> I just can say here: I agree to delay features and make the next major
>> 4.0 and not 3.5. Dont make the same mistakes again (looking at 2.5).
> 
> Who said anything about delaying features?

sorry - my bad english, what i mean is to put risky features proposed for 
4.0 on a 5 (6,7...) release number. Then make what now is discussed as 
3.5 the 4.0 release.

Ths communicates clearly the stability and serves the needs of the Plone-
integrators and developers.
 
> This proposal suggests a feature set that is incremental to the 3.x
> series, way less than what we've been tabling for 4.0 so far, but still
> a bit too much for a 3.x under the current stability packt.

right, and for this reason i'd name it 4.0 and not 3.5.

> Or did you mean to vote against the proposal wholesale, and have no
> half-way between 3.x and 4.0?

I would just not be so stingy with major release-numbers.

Jens
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance


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

Re: [Framework-Team] Plone 3.5

[Ricardo Alves]

Hanno Schlichting wrote:

Hi.

While everyone is waiting for Plone 4 and its rather long timeline, some
people have been thinking about how to bridge the gap between the
current stable 3.x releases and the future.

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x series so
far.


-1 on skipping 3.4. It will mostly bring more confusion. People will ask 
why, and most, manly newbies and outsiders who don't understand the 
complexity of the Plone stack, won't understand the rationale behind it. 
Also people will expect a 3.5 release to keep the promise of stability 
of the 3.x series.




In order to frame the scope of such a release I made a listing of some
of the potential features for such a release at
http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list
is both non-exclusive and non-binding in the recommendations.


It would be great to have such improvements before Plone 4. But I think 
most of these features, specially the ones tagged as "low risc" can, and 
should, be included in the 3.x series (3.4, 3.5, ...), without breaking 
backwards compatibility. Although, some may need special attention in 
regard to bbb.


I don't think there is a good solution here, but it will be less painful 
if we don't mess up with version numbering.



Just my 2 cents :)


Ricardo

--
Ricardo Alves 
Eurotux  



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

[Framework-Team] Re: Plone 3.5

[Martin Aspeli]

Jens W. Klein wrote:

I just can say here: I agree to delay features and make the next major 
4.0 and not 3.5. Dont make the same mistakes again (looking at 2.5).


Who said anything about delaying features?

This proposal suggests a feature set that is incremental to the 3.x 
series, way less than what we've been tabling for 4.0 so far, but still 
a bit too much for a 3.x under the current stability packt.


Or did you mean to vote against the proposal wholesale, and have no 
half-way between 3.x and 4.0?


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: Plone 3.5

[Jens W. Klein]

Am Tue, 05 May 2009 15:37:55 +0200 schrieb Wichert Akkerman:

> Previously Andreas Zeidler wrote:
>> Andreas Zeidler wrote:
>> >Hanno Schlichting wrote:
>> >>The general idea that seems to have met some consensus is to go for a
>> >>Plone 3.5 release up next.
>> >
>> >sounds good to me, +1.
>> 
>> actually, i think it should still be plone 4.0 (with the remaining
>> features deferred to 5.0 or later).  otherwise i think it's a good idea
>> in the sense of "release early, release often".
> 
> +1
> 
> In hindsight I feel it was a mistake to assign a version number to Plone
> trunk. It might end up being Plone 5, 6, 7 or 3000. Using Plone 4
> instead of 3.5 means that we will not break  our promise to never break
> stability in the 3.x, something I feel quite strongly about.

I just can say here: I agree to delay features and make the next major 
4.0 and not 3.5. Dont make the same mistakes again (looking at 2.5).

regards Jens
-- 
Jens W. Klein - Klein & Partner KEG - BlueDynamics Alliance


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

Re: [Framework-Team] Plone 3.5

[Helge Tesdal]

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: [Framework-Team] Re: Plone 3.5

[Matthew Wilkes]

On 5 May 2009, at 13:20, Martin Aspeli wrote:





Yes, I agree with all of these, and do think they're needed.

So, 3.5 is a compromise. The skipping of 3.4 actually helps back the  
story up. We could try something else, like Plone 2009, but I'm  
pretty sure we'd regret that in 2010 for one reason or another. And  
PyPI wouldn't like it.


That's true, I am very nervous about the Plone 3.x compatibility  
becoming >=3.0,<3.5-dev though - it is a change in policy to what  
we've previously said and I do think it would catch people out.


I had some issues with mails bouncing as I'm subscribed with different  
addresses to different lists, so, to reiterate, if we keep Plone 3.3  
supported and make it clear that there's a significant difference  
between 3.3 and 3.5, then I'm +0.  I'd only be +1 if we could make  
that explicit in the name.  This is not because of the proposal, I'm  
very much in favour of the proposal in principle, it's just the fact  
we lose our easy-to-understand compatibility promise by making a  
decision very much like the one we made in Plone 2.5.



Yeah, thanks for helping. :p


There may well not be a name that would satisfy me.  I can't think of  
one, you can't think of one, there may just not be one.



I think that'd be the case under the "two supported versions" policy.



But that would mean that when 4.0 comes out 3.<5 becomes unsupported  
completely.  Is that desirable?


I'm not trying to be an arse here Martin, really, I'm just concerned  
about 3.x users.  We've managed to remove a lot of fear from upgrades  
in the 3.x series, I don't want to lose that.


Matt

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

[Framework-Team] Re: Plone 3.5

[Carsten Senger]

Hanno Schlichting schrieb:

While everyone is waiting for Plone 4 and its rather long timeline, some
people have been thinking about how to bridge the gap between the
current stable 3.x releases and the future.

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x series so
far.


[...]


This is only a proposal that needs community feedback and encouragement
at this point to make it into an official roadmap. The next steps are to
have an open discussion about this for the next one to two weeks. If it
meets general favor, we will appoint the new/old framework team and let
them recommend a release manager to the Foundation board for official
nomination.


Improving Plone and cleaning up things is always a good thing. But a 3.5 
major release will break the users expectations to have a stable 
backward compatible 3.x release cycle. It's also confusing to name a 
major version x.5 with all the consequences like incompatible 3.x 
Add-Ons. The naming of Plone 2.5 was a rather unfortunate thing. The 
proper naming for a backward incompatible release should be 4.0. I think 
nobody wants a short living 4.0 release and rename the current Plone 4 
to Plone 5.


I'm in favour to put as much changes into a 3.4 that are backward 
compatible. I think it's ok to change some defaults for new Sites that 
can be easily changed by an administrator like TinyMCE/optional 
packages/Additional Roles that can. Thus I don't now what consequences 
this would have for our documentation team.
Changes that bring other than really minor incompatibilities for 3.x 
add-ons are a no-go for a 3.x release imho.



..Carsten


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

Re: [Framework-Team] Re: Plone 3.5

[Wichert Akkerman]

Previously Andreas Zeidler wrote:
> Andreas Zeidler wrote:
> >Hanno Schlichting wrote:
> >>The general idea that seems to have met some consensus is to go for a
> >>Plone 3.5 release up next.
> >
> >sounds good to me, +1.
> 
> actually, i think it should still be plone 4.0 (with the remaining 
> features deferred to 5.0 or later).  otherwise i think it's a good idea 
> in the sense of "release early, release often".

+1

In hindsight I feel it was a mistake to assign a version number to Plone
trunk. It might end up being Plone 5, 6, 7 or 3000. Using Plone 4
instead of 3.5 means that we will not break  our promise to never break
stability in the 3.x, something I feel quite strongly about.

Wichert.

-- 
Wichert Akkerman 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

[Framework-Team] Re: Plone 3.5

[Andreas Zeidler]

Andreas Zeidler wrote:

Hanno Schlichting wrote:

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next.


sounds good to me, +1.


actually, i think it should still be plone 4.0 (with the remaining 
features deferred to 5.0 or later).  otherwise i think it's a good idea 
in the sense of "release early, release often".




andi


--
zeidler it consulting - http://zitc.de/ - i...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.2.2 released! -- http://plone.org/products/plone/


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

[Plone-docs] [Framework-Team] Plone 3.5

[JoAnna Springsteen]

(sorry if you get this twice)

> The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
> we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.

What's the significance of 3.5? Why can't this catch up be done in
increments? 3.4 then 3.5 then 3.6?

My worry here is that catching up will mean a repeat of 2.5. Not to
mention if we are changing this much stuff on a platform level that it
won't get documented. The framework team would have to be responsible
for documenting these changes as the documentation team just does not
have the man power. Sure, we made the 3.3 release w/ documentation and
that was relatively small stuff. If you go for a bigger release under
the 3.x series we're going to end up back where we startedNew
technologies and no documentation. This will further the idea that
being a Plone developer is only for elite code jockeys. That's not
really something we want to reinforce, is it?

I gotta tell ya, this idea makes me really really nervous. I thought
the whole point of 3.x was to be stable and not repeat past mistakes?
I'm all for getting closer to 4.x but we need to do it in bite sized
steps, not all at once.

J.

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

[Framework-Team] Re: Plone 3.5

[Raphael Ritz]

Hanno Schlichting wrote:

Hi.

While everyone is waiting for Plone 4 and its rather long timeline, some
people have been thinking about how to bridge the gap between the
current stable 3.x releases and the future.

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x series so
far.


While I like the idea in general I would be very careful not to break
our promise of Plone 3.x being stable, maintained, backwards compatible,
not breaking 3rd-party add-ons etc. until Plone 4 is out for a while.

Just for the record: we (the Plone 3 framework team) even got some
critic from the doc team for allowing

  http://plone.org/products/plone/roadmap/243

into Plone 3.3 as this had somewhat of an impact on the
forthcoming manual. (not to mention all the printed books
that appeared recently and that are going to appear soon)

After quickly browsing through Hanno's list I don't see a
reason to break our pattern and to call this 3.5. At first
glance it seems perfectly feasible to me to introduce at least
most of the changes proposed here in Plone 3.4, 3.5, 3.6.

Having said that I'm not so sure this should be handled by the
Plone 4 FWT alone. Regarding the release manager on the other
hand I have nothing but a warm welcome and the best wishes for
Eric! Glad to see you getting more involved.

Of course I would have specific comments on some of those changes
but this is not the place and time to do into the details I guess.

Just my 2 cents,

Raphael


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

[Framework-Team] Re: Plone 3.5

[Martin Aspeli]

Matthew Wilkes wrote:

On 5 May 2009, at 12:44, Hanno Schlichting wrote:


The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x  
series so

far.


Why skip 3.4?  That Plone 2.5 was a major release was quite nasty, it  
confused people about what was a major release and what isn't.  We've  
made a commitment to 3.x being stable, I think we should keep to it.   
Releasing a Plone 3.5 would confuse the matter.


It's tricky, and we discussed this back and forth a few times before 
this proposal was formulated. I still think the version numbering is up 
for discussion.


The thinking is basically:

 - We'd like to move to ZODB 3.9 (blobs), Zope 2.11 (Zope 3.4), and 
possibly CMF 2.2 (trunk). Those changes are too big for the stability 
promise in 3.x.


Note that there's a certain imperative in this. In particular, I *hope* 
that we can get unofficial Python 2.5 support for Zope 2.11. Zope 3.3 is 
also becoming kind of painful as a platform. And blobs are way overdue.


 - We'd like to integrate some new features. Not critical stuff that 
couldn't be done with surgical add-ons, but nice-to-haves that will 
improve the experience for a lot of people.


 - However, to end users, this is still incremental stuff - not really 
enough for the kind of marketing push we'd like to attach to a 
'point-oh' release.


 - The term "Plone 4" is already out there meaning trunk, deco, 
deliverance, dexterity, unified types, tiles, and all that jazz. If we 
suddenly now start talking about a much more incremental "Plone 4", 
we'll cause a lot of confusion.


So, 3.5 is a compromise. The skipping of 3.4 actually helps back the 
story up. We could try something else, like Plone 2009, but I'm pretty 
sure we'd regret that in 2010 for one reason or another. And PyPI 
wouldn't like it.


However, it would be interesting to open the new features to a wider  
audience ASAP.  I'd be in favour of this if:


- It wasn't called Plone 3.x or 4.x (Dunno what though)


Yeah, thanks for helping. :p


- We maintained 3.x as officially supported


I think that'd be the case under the "two supported versions" policy.

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

Re: [Framework-Team] Plone 3.5

[Tom Lazar]

for the record, i think this is a great idea.

this will also take some weight off of the 4release, since some of its  
low-risk components will have had some real-world usage by then.


also, it should make migrations from 3.x to 4.x easier, i could imagine.

i'm also more than fine with eric as 3.5 release manager. thanks for  
volunteering, eric!


just my €0.02,

tom

On 05.05.2009, at 13:44, Hanno Schlichting wrote:


Hi.

While everyone is waiting for Plone 4 and its rather long timeline,  
some

people have been thinking about how to bridge the gap between the
current stable 3.x releases and the future.

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x  
series so

far.

In order to frame the scope of such a release I made a listing of some
of the potential features for such a release at
http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The  
list

is both non-exclusive and non-binding in the recommendations.

The envisioned timeline for a Plone 3.5 release would be to aim for a
final release either by the time of the conference or by the end of  
this

year, giving us six months or a bit more for it. By aiming for an
after-summer beta deadline we will have a chance of leveraging some
Google Summer of Code contributions for such a release.

When it comes to the official personal involved in such a new major
release, I'd like to suggest a slight deviation on our process. As  
many

to all of the features changes in question for the 3.5 release have so
far been in the scope of the 4.0 release, I'd suggest to appoint the
entire 4.0 framework team to be the official team for 3.5 as well.  
This
forces them to get involved with the process in a more defined and  
clear

way now.

On the side of the release manager, Wichert has signaled that his
workload as a freelancer will not allow him to take over the  
shepherding
of a new major release. We do however have with Eric Steele of PSU  
fame

a well-known interested candidate for the position.

This is only a proposal that needs community feedback and  
encouragement
at this point to make it into an official roadmap. The next steps  
are to
have an open discussion about this for the next one to two weeks. If  
it
meets general favor, we will appoint the new/old framework team and  
let

them recommend a release manager to the Foundation board for official
nomination.

Cheers,
Hanno


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

[Matthew Wilkes]

On 5 May 2009, at 12:44, Hanno Schlichting wrote:


The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x  
series so

far.


Why skip 3.4?  That Plone 2.5 was a major release was quite nasty, it  
confused people about what was a major release and what isn't.  We've  
made a commitment to 3.x being stable, I think we should keep to it.   
Releasing a Plone 3.5 would confuse the matter.


However, it would be interesting to open the new features to a wider  
audience ASAP.  I'd be in favour of this if:


- It wasn't called Plone 3.x or 4.x (Dunno what though)
- We maintained 3.x as officially supported

Matt

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

[Framework-Team] Re: Plone 3.5

[Andreas Zeidler]

Hanno Schlichting wrote:

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next.


sounds good to me, +1.


andi

--
zeidler it consulting - http://zitc.de/ - i...@zitc.de
friedelstraße 31 - 12047 berlin - telefon +49 30 25563779
pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/
plone 3.2.2 released! -- http://plone.org/products/plone/


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

[Framework-Team] Plone 3.5

[Hanno Schlichting]

Hi.

While everyone is waiting for Plone 4 and its rather long timeline, some
people have been thinking about how to bridge the gap between the
current stable 3.x releases and the future.

The general idea that seems to have met some consensus is to go for a
Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
that is similar in spirit to the Plone 2.5 release. It tries to both
refresh some of our technical underpinnings in addition to some more
intrusive feature changes we didn't allow ourselves in the 3.x series so
far.

In order to frame the scope of such a release I made a listing of some
of the potential features for such a release at
http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list
is both non-exclusive and non-binding in the recommendations.

The envisioned timeline for a Plone 3.5 release would be to aim for a
final release either by the time of the conference or by the end of this
year, giving us six months or a bit more for it. By aiming for an
after-summer beta deadline we will have a chance of leveraging some
Google Summer of Code contributions for such a release.

When it comes to the official personal involved in such a new major
release, I'd like to suggest a slight deviation on our process. As many
to all of the features changes in question for the 3.5 release have so
far been in the scope of the 4.0 release, I'd suggest to appoint the
entire 4.0 framework team to be the official team for 3.5 as well. This
forces them to get involved with the process in a more defined and clear
way now.

On the side of the release manager, Wichert has signaled that his
workload as a freelancer will not allow him to take over the shepherding
of a new major release. We do however have with Eric Steele of PSU fame
a well-known interested candidate for the position.

This is only a proposal that needs community feedback and encouragement
at this point to make it into an official roadmap. The next steps are to
have an open discussion about this for the next one to two weeks. If it
meets general favor, we will appoint the new/old framework team and let
them recommend a release manager to the Foundation board for official
nomination.

Cheers,
Hanno


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