Hello, I think we need some sort of stering group (or person(s)). Without rules and decisions to follow we're going to end up like headless chicken running around in the kitchen. Noone knows the direction.
Yes sometimes radical changes are good. We're also carrying a lot of old baggage around with Zope3. It is lurking around the corner. Like Shane's zope.pipeline, repoze stuff, etc. BUT at the same we have projects that have to be kept running (and migrated, possibly smoothly) Keeping our packages together at least with a KGS is a must in my opinion. Unless you want yourself to find a working set between the permutations of all required packages versions. Someone releases a new package version and your project just break the next day. That's a nightmare. Monday, March 2, 2009, 6:11:59 PM, you wrote: CM> I'm pretty sure a steering group and a rebranding of existing software is not CM> going to make us more effective. Here's what I believe would make us more CM> effective: CM> - encouraging radical change for experimentation purposes, releasing folks from CM> various constraints (backwards compatibility, style policing, historical CM> ownership) CM> - discourage the contribution of stop energy (discourage CM> the utterances of "don't", "stop", "this is wrong", CM> "stop talking about this"). CM> - focusing on externalizing software; each egg should stand on its own as CM> something that a non-Zope person would be able to understand and use CM> in isolation. This means documentation for each thing, as well as CM> a sane dependency graph. This is *less* about giving this collection CM> of software a group name ("the zope framework") and more about CM> making people *forget* that it is a part of some larger thing. When CM> a piece of software does not have a purpose in isolation but still CM> lives in its own egg, kill it off and merge it back into whatever CM> thing its most closely related to. CM> - Stop trying to version control and treat all this software in some CM> overall release. Let each piece of software have its own life. Likewise CM> if a piece of software does not have its own life, kill it. CM> - C CM> _______________________________________________ CM> Zope-Dev maillist - Zope-Dev@zope.org CM> http://mail.zope.org/mailman/listinfo/zope-dev CM> ** No cross posts or HTML encoding! ** CM> (Related lists - CM> http://mail.zope.org/mailman/listinfo/zope-announce CM> http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZER mailto:agros...@gmail.com -- Quote of the day: There is no remedy for sex but more sex. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )