Re: [Framework-Team] Zope 2.13 PLIP ready for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: There is also one major issue to figure out around testing. In Python 2.7 deprecation warnings are silenced by default. We agreed in the Zope community that this is ok for production code, but we'd like to enable the warnings in tests by default, as you'll otherwise never notice them. We haven't actually implemented that behavior yet, though. This has also lead to most of the ZTK having passing tests under Python 2.7 but actually emit tons of deprecation warnings once you enable them - for example all self.fail* methods in tests got deprecated in favor of their self.assert* spelling to just name one. +sys.maxint to ignoring that particular set of wank-off deprecations *forever*. No possible purity excuses introducing deprecations of long-established API aliases, which cause nobody any harm anywhere. Before we can claim real proper Python 2.7 support we need to make sure our own stack runs without deprecation warnings. +1, modulo that particular example. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyOo/oACgkQ+gerLs4ltQ7wegCfZWNW1b3tcqBVxSGoo6G4HE3f 7cUAoKuk9Qt4CtMJBe+qsR5C2RrazGhJ =aofZ -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Zope 2.13 PLIP ready for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Limi wrote: Do we expect Plone 4.1 / Zope 2.13 to be using Python 2.7 by default? (makes sense to me, but not sure if it has other implications that I'm unaware of) Both 2.6 and 2.7 are supported Python versions for the current Zope2 trunk -- see http://svn.zope.org/Zope/trunk/doc/INSTALL.rst?view=markup Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyNp0EACgkQ+gerLs4ltQ6mpwCgzDP87LI6lFSyBqXkCevUhTCl Fz0AniX+204y6jQh2sZP1kPgT5NVzIVQ =ey09 -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone-developers] Upcoming Plone 4.0 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Steele wrote: snip So let's move the b4 release to June 2, which should give us time to get the majority of these wrapped up (and provide me with the time to actually cut the release). At that point, I'll take another look at what's remaining and decide whether a June 16 release should be dubbed b5 or rc1. Sounds like a good call to me. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkv1rOsACgkQ+gerLs4ltQ6LGACgk9iCf915EQrHUV+qayxurXBk KM0AoJq6WEfCB9JZV/Ty5Iu5KrAWolC3 =vhON -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 5 - rough roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Limi wrote: On Wed, Mar 24, 2010 at 6:58 PM, Martin Aspeli optilude+li...@gmail.comoptilude%2blists-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: It's not *quite* that easy, though, because people will have things like collective.xdv in their buildouts. If an upgrade means installing something else, then in the worst case that something else could actively conflict with an old installation, and we're in trouble. Also keep in mind that package name doesn't have to be the product name. We're not called CMFPlone. ;) It's also not so easy because at least two books in print mention XDV, as do three or four tutorials on plone.org. I think we need a damned good reason to rename, more so than this name is cooler. I also think we should ask the broader community's reaction first. The community is tiny, tiny until it ships with a Plone release. Now is the time to do it. The decision is not really in this group's hands, though: XDV is a project which has its own life outside of Plone. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkusCY0ACgkQ+gerLs4ltQ6e6ACg2RFFb2shJRQ0ozPS7LoAuqNZ ZDkAn38JJ+Q8SceJ6JV46ls2ZCdYDGKO =ea7g -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 5 - rough roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tom Gross wrote: On 03/12/2010 04:07 PM, Hanno Schlichting wrote: Hi there, ... On the future side we have: - Chameleon - Deco / Blocks - Dexterity - WSGI - xdv as the default theming story Is there still discussion space to choose between xdv and Deliverance. I'm not to deep in the subject but I have heard that Deliverance can be used with other web-applications, but xdv is Plone specific. If this is true, Deliverance would open Plone to a broader community. Where did you hear that? It's not correct. ;-) Deliverance is a Python-based implementation. It is used either as a standalone proxy or in a WSGI pipeline. As such, it may be attractive to people with a WSGI-oriented stack. It also has more client-side tools and is generally broader in scope than XDV. XDV is an XSLT-based implementation. You compile theme + rules into an XSLT, which is then deployed either in a WSGI pipeline step, or in a web server like nginx or Apache. As such, it is even broader in scope in the sense that it's not tied to Python. collective.xdv is a Plone control panel + hook to apply an XDV theme without the need for a fronting web server. This is a good solution for people with no further integration needs. However, the same theme + rules can be compiled and deployed as an XSLT if that's desirable. Probably the most important deciding factor is that XDV is more lightweight, overlaps less with existing tools, should be faster, and - crucially - has more uptake in the community. With Plone 3 and Plone 4 at least it's also easier to set up and deploy than Deliverance, which ether requires a standalone process that proxies to Zope, or adoptation of repoze.zope2 to get a WSGI stack in Zope. /me notes 'Subject:' I am certain that Zope2's WSGI story will be hammered out long before Plone5 needs to freeze on a Zope2 version. repoze.zope2 will *not* be required to run Zope2 behind a WSGI server. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkupOD0ACgkQ+gerLs4ltQ72ngCgk/kZK4jrMQdFZIWHPIj2gnQx KacAnitpxxbnMlYqXCfGSROZuUsmdWne =Qspa -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: incorrect URL for repoze.xmliter?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Nate Aune wrote: I just tried running the Plone 4 coredev buildout (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: - repoze.xmliter= svn svn+ssh://rep...@svn.repoze.org/svn/repoze.xmliter/trunk http://rep...@svn.repoze.org/svn/repoze.xmliter/trunk + repoze.xmliter= svn http://svn.repoze.org/repoze.xmliter/trunk/ Also added to the plone-deco issue tracker on google code: http://code.google.com/p/plone-deco/issues/detail?id=15 This happens because you don't have commit privileges in the repoze svn. Leaving it with the public URL is better, though. Why depend on SVN checkouts, rather than working to get the package released? Martin, you are the last one to touch it, looks like. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktE8N8ACgkQ+gerLs4ltQ5MigCdEgyuq5kEJfdVXNPix/SqiR9n TpIAoKrtxuqbdMGmg3UhJXUWWGVX2S+X =Hyv/ -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: MailHost Improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Mitchell wrote: Hello, I've been working on making Plone use the standard Zope MailHost in place of the custom Products.SecureMailHost we've been using since Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this process I've run into a couple bugs in the MailHost implementation and I believe it is missing some essential functionality. The most significant issue is that if you call send() with a messageText containing just the message body, and that body has a ':' in it (e.g. a url) the body will be treated as a header and you'll send a nonsense message. The current implementation of send() also puts a fairly large burden on developers who want to generate simple, correctly encoded messages. Finally, send() relies heavily on the long deprecated 'rfc822' and 'mimetools' modules which have been removed from Python 3.0. I've attached a patch that updates MailHost to use the 'email' module for parsing and generating messages. In addition to fixing the issues that I ran across, and maintaining compatibility, it provides a number of new features: * send and sendTemplate accept an optional charset argument. Using this will set the content-type charset, as well as trigger appropriate encoding if needed. * send and sendTemplate accept an optional msg_type argument which will set the content type header for the message. * The messageText, mfrom, mto, and subject arguments may now be unicode or encoded non-ascii strings, provided a charset is given. Any unicode input will be automatically encoded to the provided charset (or the default charset). Headers will be further encoded in compliance with rfc2822. The message body will be further encoded using a transfer encoding determined by the email.Charset registry (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, base64 for most other encodings). * The messageText argument now accepts email.Message.Message objects directly. I'm attaching a patch that includes these changes as well as tests for all new functionality. I hope to integrate these changes into Zope 2.12 before final release, but would like to hear the opinions of Zope developers before committing. Though these are fairly significant changes, I believe they provide very useful functionality as well as at least one critical fix, while maintaining 100% compatibility. +1 for the approach in general (I haven't looked at the patch in detail). Assuming all tests pass, and that you have a test exercising the ':' bug you describe, I would just commit it on the trunk (I think such a change should be in the upcoming 2.12 beta). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKg4SS+gerLs4ltQ4RAgOuAJ0W2CNRCDQglY75s0HVKFnChOwbnwCfSEmu ph+wxAWDwjG3J8xZV1Cr6+U= =tZEF -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Minutes: 8 August 2009
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Mitchell wrote: I concur that the globalize stuff is a serious hack and should be removed at some point. However, I don't think 4.0 is the right time to remove it considering the huge impact it will have on 3rd-party products. If removing it doesn't result in a significant performance improvement (and apparently it does not), then I'd suggest we continue to live with it until the break-everything 5.0 release. We didn't have a PLIP for this and it would be a major disruption for 3rd party developers and integrators. Any 3rd party developers who want to find out whether their templates break without the globals can test them easily: just customize the main template under 3.3 and remove the following line: metal:block use-macro=here/global_defines/macros/defines / Any template which breaks without that line present can be trivially fixed by adding 'tal:defines' to pull in the names needed. No need for any black majyk here. Perhaps we could find some clever way to deprecate access to the globalized attributes (e.g. make them all lazy lookups and issue a warning on first access)? There is an example of this pattern in the 'ursine_globals' view on the CMF trunk: http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/ursa.py?view=markup Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKejCh+gerLs4ltQ4RAmKRAJ0ea+hImFlLqsc1N+YwYmGa2R8czQCeIifb jXSsBCCqIHnikyiytjg9ni8= =p6uU -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Burton wrote: Hello, Framework Team! I, myself, don't have any questions or issues about the PLIP deadline for 4.0. I'm not planning on submitting any PLIPs. Over the past two weeks, though, while chatting in IRC with various framework team members and other core Plone people, at least 5 have mentioned, without my prompting, that the deadline for 4.0 PLIPs seemed awfully fast in coming, and they wondered whether it may have been too aggressive. I don't know what the discussion was like in deciding on this date. It may still be the right decision to have it end now. I'm just suggesting that, if it seems that quite a few people may think that this is a slightly-too-soon date, that you may benefit from having that conversation (sometimes, groupthink kicks in and everyone might be assuming this is too soon, but I'm the only person who probably thinks that, so no point bringing it up.) Just want to make sure that's not what happens. In any event, have a wonderful PLIP season! I look forward to teaching what you invent. ;) Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKPSyl+gerLs4ltQ4RAoVzAJ99H2Gz9+bEt1bRcrUwtN2RPSuU3gCfdDx1 lCfOg4/RoNHxBl22WuPxU/c= =hwMz -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raphael Ritz wrote: Wichert Akkerman wrote: I seem to remember the plan was to target Plone 4 for CMF 2.2 and Zope 2.11, but as you can see below that does not appear to be possible. So that means Zope 2.12 instead, right? Do we have an estimate of what that implies on our side? Generally speaking, I'm a bit uncomfortable with jumping from Zope 2.10.x to 2.12.x as this will reduce the chances of reacting to deprecation warnings which is of particular importance for all our add-on developers. I'm afraid we'll see lots of broken add-ons without prior warnings. If there is nothing we can do about this (and it seems so) we could still consider to have Plone 3.x move to Zope 2.11 with 3.4 or 3.5. Just thinking out loud (and without knowing myself how much differences there are between Zope 2.10 and 12 that do affect us) ... An outsider's take: I would strongly urge that a release-by-year-end Plone4 use Zope 2.12. There is no compelling technical reason to hold off, and plenty of time to test and iron out any issues. Staying up-to-date gets you a migration path to a Python version (2.6) which will be supported for a reasonable time frame (2.4 is effectively out of support now; 2.5 is at the end of its support life). It will also allow Plone to use the fully eggified Zope, and rip out lots of workarounds (fake eggs, anyone). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKHaD0+gerLs4ltQ4RAphjAKCrWddVIMNgM1E9kLQfb8xe7lMdsgCgivEI QbaGWkFEAB44GxB43EN05hM= =goDC -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Multiple workflows (Was: PLIP lifecycle)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: You can actually have multiple workflows for a given type. I may be the only person who has ever actually used the feature, but it is truly helpful at times. I'd be interested to hear what kind of situations it's useful for? The canonical case is dealing with the lifecycle of content which has both drafts and revisions: - the draft part is governed by a submit-review-publish cycle, which results in the creation of a frozen revision. - revisions go through a lifecycle governed by their effective and expiration dates, using automatic transitions and some kind of background polling process. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJXoyu+gerLs4ltQ4RAqxPAJwJ7FGtZ65a+eCwKNGTSwNwRpiBCwCgmwyn EQjbTF/AXRqyMTmE2r+6Sgo= =35f9 -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [plone4] Release process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Patterson wrote: Tres Seaver tsea...@palladion.com writes: Ross Patterson wrote: Tres Seaver tsea...@palladion.com writes: Hanno Schlichting wrote: - Plone 4 will have a documented upgrade story A migration from Plone 3 to 4 does not need to be possible in an almost fully automated fashion. We need to ensure we have an easy to follow and understandable documented upgrade story. If we for example change API's or rearrange code, we can document the new places in writing and with error references for the most commonly used parts. If you need to change your buildout configuration, a document explaining the changes is fine, we don't need to build an upgrade machinery for configuration files. Can I persuade you and the FWT to forego an upgrade-in-place strategy for moving from P3 to P4, and instead to have a well-tested ad documented dump-and-reload story? I've never actually understood how a dump-and-reload approach would be inherently more maintainable or otherwise more trouble-free. I know this has been discussed before, but I missed those discussions. Can anyone shortcut the research for me and give me some links or pointers to previous discussions? The short answer is that in-place migrations lead to ordering-dependent arrangements of crufty bits in the site: it gets particularly bad when the representation format of the data changes. If the programmer is both careful and lucky, she can often mitigate the problem with clever defaults, properties, etc., but the downside is that the BBB-driven code has to stay around *forever*. Thanks, that's exactly what I wanted to hear. So it's not so much about being inherently easier to implement as it is about enabling the removal of code. In that case, I'm +1 on this but I have other concerns. Dumping the content out to a neutral format and loading it into a clean site loses the crufty bits, and leaves the code in the new software free of nasty BBB stuff. It also gives people a migration target (for moving content into Plone, or even out of it), as well as a non-ZODB-specific backup representation of the site (e.g., to populate a staging / testing server). It seems like this this dump format will likely become a point of hackability in our software ecosystem. People out there will find interesting things to do with it aside from dump-and-reload. This would be a good thing except we're *expecting* the format to be unstable and change rapidly. It seems possible that there would be some ruffled feathers out there amongst those who come to depend on such hacks and then find that their favorite hack is quickly broken by the next release. As such, it seems like it would be a good idea to dress up the dump format in flashing red lights and loud alarms to discourage at least the adoption of such hacks if not their creation. It also seems like the complexity of this dump format is easily underestimated. I'm a little concerned that we'll adopt a solution that is more accidental in nature, such as an extension to the current GS handlers. I suspect that later we'd find some structural inadequacies in such an approach but having already build our upgrade machinery around it we'll have yet another painful change to make as we change to something better designed. OTOH, perfect is the enemy of good enough. I suggest we start with a *minimal* design discussion about how to architect a dump-and-reload strategy with the future in mind. I have code in hand which I have used successfully for two different customer projects: one was using mostly stock Plone content types, while the other used entirely custom versions; both were based o AT. This format has allowed: - Exporting content from a large production site (50k content items), without taking the site down. - Merging content from multiple Plone sites into a single site, by running automated transforms of the exported formats. The basic assumption of the design is that *every* content object maps onto a directory: - Each directory contains a file which exports the item's properties in an INI format - BLOBish property values are mapped as separate files. - References are mapped as sequeces of UIDs in the properties file. - Containers have a file enumerating their subobjects. - Security settings are caputred in a separate INI file. - Workflow history would map onto a separate file (but neither project wanted to preserve the history, so it remains unimplemented). The format is built around GenericSetup's adapters, which makes it possible to extend the framework (e.g., to capture unforeseen values), or to replace implementations (e.g., to accomodate non-AT content schemas). It does not use XML at all, which means it will run even in environments where building lxml is problematic. Tres. - -- === Tres Seaver
[Framework-Team] Re: [plone4] Release process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: - Plone 4 will have a documented upgrade story A migration from Plone 3 to 4 does not need to be possible in an almost fully automated fashion. We need to ensure we have an easy to follow and understandable documented upgrade story. If we for example change API's or rearrange code, we can document the new places in writing and with error references for the most commonly used parts. If you need to change your buildout configuration, a document explaining the changes is fine, we don't need to build an upgrade machinery for configuration files. Can I persuade you and the FWT to forego an upgrade-in-place strategy for moving from P3 to P4, and instead to have a well-tested ad documented dump-and-reload story? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJVBDT+gerLs4ltQ4RAqb/AJ424SE/qqstfmRvQ/pJKDisbbvRvgCgjVYw E/XtFRo81n2SdHAU3m0ALnM= =+vuy -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: random thought: identify the components that lack owners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hanno Schlichting wrote: Tres Seaver wrote: Hmm, as an outsider, the FWT's job (reviewing and accepting PLIPs) is to do what a single BFDL would do in a project would have one. It might seem so from a certain point of view. That's however not how it has been intended and not quite what the current status is. Here's the current situation from my POV (German-style, as in: short and not meant to offend anyone, even if it sounds like it): In the early days we had two BDFL. One for code, one for UI. The one for code got busy growing his company and isn't involved in the core development anymore. We move on some years, get a terrible experience with the 2.1 release and we realize we need to do something. Folks sit down and create the framework team. It is intended to be a barrier for inclusion of bad and unfinished code into the core. What about such code, or abandoned code, which is already in the core, and which would therefore not be accepted today? The intended process of how growing Plone should work since the 2.1 release up until now is officially: - Someone writes a PLIP. - The community at discusses and generates consensus on whether or not a PLIP should be accepted and if it should be included in the core. - The submitter writes the code needed and submits it to the framework team for a particular release. - The framework team decides about the technical merit of the implementation and if the goals outlined in the PLIP are met. - The release manager for a release is appointed by the foundation board. He has a final say in rejecting or overruling the recommendation made by the framework team. That's the official story so far. The framework team does not have a mandate to decide about the general merit of a PLIP, but only on the technical one. It is currently a peer-review team. It is only elected for one release at a time and doesn't have any mandate to care about the long-term roadmap of Plone. What we are missing indeed these days is a technical long-term roadmap and an authoritative team to set it. I assumed from my outsider's viewpoint that the framework team had been given that responsibility. Right now various core developers, including me, Martin and Wichert to name a few of the most craziest contributers, push some parts into a direction at times. I'm officially abusing the lack of an established process for Plone SVN trunk to change it to my personal will right now. That is easy in the short term but not a good idea in the mid or long term. I think we need to address this issue and have an official story for Who inherits the role of Alan. History of open source projects have proven, that once a founder has stepped down from being a BDFL there is no way to go back to having a dictator again, so we need a team. But maybe this only my personal view of the current situation? It seems to me that not having continuity of architectural vision across releases, including the ability to remove broken / abandoned components, is a really dangerous place for Plone to be. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3TJF+gerLs4ltQ4RAkmdAJ9nsT0Fpg13h5Jv01SKw3ootTtjGACfWrdp ClFtMpkplqO0fNtlrNnxLd8= =7CRh -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 3.2 plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: What isn't eggified yet? The products currently still in the 3.2 ploneout are: CMFActionIcons CMFCalendar, CMFDefault, CMFDiffTool, CMFEditions, CMFPlacefulWorkflow, CMFTopic, CMFUid, DCWorkflow, GroupUserFolder and PloneTranslations. I eggified the actual CMF products in that list this morning: - CMFDefault - CMFTopic - CMFActionIcons - CMFCalendar - CMFUid - DCWorkflow Eggs for the 2.1.1 versions of those distributions are now available on PyPI. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIldos+gerLs4ltQ4RAh8oAJ9yGh25cSzmalb9konw++COEvjMJQCfYz74 Zj+F3pl7qIzwB98Q2SS8mx0= =GYmr -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
