[Zope-dev] the Zope Framework project

[Adam GROSZER]

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 at 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:agroszer at gmail.com
--
Quote of the day:
There is no remedy for sex but more sex.