[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
On Tue, 05 May 2009 16:57:21 +0200, 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. Since I finally found out about this and catched up on this thread, I wanted to give my +1 to a Plone 4 with a reduced scope from the current trunk. Regards, Florian Schulze ___ 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
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
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
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: The new Plone 4.0, was Re: Plone 3.5
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: The new Plone 4.0, was Re: Plone 3.5
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] Re: The new Plone 4.0, was Re: Plone 3.5
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
[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
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
[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
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
[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5
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
