Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > Martijn Faassen wrote at 2009-3-3 22:11 +0100: >> ... >>> backwards compatibility at all costs, >> I agree that have erred on the side of too much backwards compatibility. >> That increased the overhead of changes tremendously and blocked innovation. > > Large applications are built upon the framework. > > If the framework too often drifts away, the maintenance costs > for these applications gets too high -- and make the framework > unattractive. But if the framework is no longer monolithic, you can keep using the bits you need for BBB, while selectively updating newer pieces. The more loosely-coupled the pieces are, the more likely such a "partial upgrade" is to work. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsIWO+gerLs4ltQ4RAlWuAKCwUyNkbz9zKaLHgWp/WwTTPjufVgCePgxk PIIdR4FnOAUMuJgKupdjpYQ= =WiRX -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 22:11 +0100: > ... >> backwards compatibility at all costs, > >I agree that have erred on the side of too much backwards compatibility. >That increased the overhead of changes tremendously and blocked innovation. Large applications are built upon the framework. If the framework too often drifts away, the maintenance costs for these applications gets too high -- and make the framework unattractive. -- Dieter ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote at 2009-3-3 17:21 +0900: > ... >How many times have we gotten bogged down in semantics or >naming discussions and killed off the momentum behind something? A clear notion of semantics and well chosen names are important for any project. I would not want momentum resulting in confused semantics and misleading names. -- Dieter ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 00:36 +0100: > ... >* how will the community make hard decisions where lots of people >disagree? You try to achieve consensus. When you do not, you get the chance that people turn away. > ... >* who reminds us of necessary tasks and directions we're going into? Beside the reminders, you need people that do the work. For this, at least, these people must be convinced. -- Dieter ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 19:00:12 schrieb Baiju M: > On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen > wrote: > > [snip] > > > The steering group isn't intended to take a responsibility for the > > entirety of the Zope software. Zope 2, Grok and the Zope 3 app server > > (which would be a distinct entity) would manage themselves and the Zope > > Framework steering group would not have a say over the libraries and > > configuration they add. > > [snip] > > > I do also think that we should go to a smaller set of libraries. We > > currently share a huge amount of code that only one consumer actually > > uses. For instance, I think all of the zope.app.* packages which contain > > ZMI code can eventually be left to the management of the Zope 3 > > developers, meaning they'd not be part of the Zope Framework anymore. > > [snip] > > > """ > > As a service to the users of the Zope Framework, the Zope developers > > also make available lists of version numbers of core libraries that > > have been tested to work together as a "Known Good Set". This receives > > a version number and is the Zope Framework release. Users of the Zope > > framework can use this list, but may also diverge from it where they > > see fit. Other projects (such as the Zope 3 application server and the > > Grok project) also have a Known Good Sets that expand on the Zope > > framework list (and may diverge from it). Each of these consumer > > projects can of course have their own release process, schedule and > > version numbering. > > """ > > [snip] > > > It may very well be true that in some time we'll develop clusters of > > libraries that can be more or less managed on their own. The ZMI is such > > a cluster that I hope will eventually emerge (and that the Zope > > Framework Steering Group doesn't care about directly). That'd reduce the > > coordination overhead. But sometimes we do need to take coordinated > > action, and I don't see that need disappearing entirely. > > I think those who care about "Zope 3" (framework/app server/libraries/ > or whatever) > should form a team and mailing list to discuss about the future > development. All other major consumers of the "Zope Framework Project" has > their on mailing list for discussions. I guess very soon zope-dev list > will become inappropriate to discuss about "Zope 3". Just like Grok,Repoze > etc. it is better > to create a list for "Zope 3", may be re-activate zope3-dev list to > discuss about > the "Zope 3" (framework/app server/libraries/ or whatever). Well, if > no one cares > about "Zope 3", let's leave it. What would be interesting to know is: - Who is out there - What these people are using: * Zope libraries * Zope 2 * Zope 3 app server * Plone * Grok * Something else - Who has already contributed (and what) - Who has the technical expertise and time to contribute This probably would help us/the steering group to form teams around different projects. For instance, as the steering group is not about the Zope 3 app server, there needs to be some team for that part. And I am personally interested if the Zope 3 app server is something that's dying in favour for other projects (Plone/Grok) or is actively used. Best Regards Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 17:48:37 schrieb Martijn Faassen: > Hi there, > > Lennart Regebro wrote: > [snip] > > > And it is in any case in no way even remotely connected to the group > > Martijn proposed and has been discussed in this thread. > > - Attracting newbies to web development is not a task of the Zope > Framework project directly, and here I diverge from Hermann. That's a > task of the Plone project or the Grok project, etc. I do think that the > Zope Framework leadership could be much better at attracting and > stimulating contributions to the libraries. > > Attracting more users is important, but that's a task for the Zope 3 app > server developers (however they organize) or the Grok project. The Zope > Framework is a second-level provider to these projects, and in reality > of course people who care about these projects will do most of the > driving of development of the Zope Framework. It's a forum where all > users of these libraries (many or just a few) can get together, work out > our diverse interests, and coordinate. Ok, it seems I mixed up the Zope3 app server and the Zope Framework a little.So, I agree that attracting newbies should better be done via Grok/Zope3 app server or anything else that build on top of the Zope Framework, as this is the logic path. Nevertheless the Zope Framework should have: - Documentation - Central Website - Some other structure for collaboration (mailing list...) And I think that these points should also be a topic of the steering group. I think an ideal approach would be that the above can be seamingless integrated in upper-level frameworks, so that the step from Zope3 app server/Grok to the Zope Framework is as easy as possible, and, moreover, that efforts need not to be doubled (e.g. that someone writing documentation for Zope 3 app server has to write something about interfaces or the component architecture). Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 18:03:17 schrieb Lennart Regebro: > On Wed, Mar 4, 2009 at 17:48, Martijn Faassen wrote: > > Note that the Zope Steering group is not about > > packages that are not in the framework, so if lovely.remotetask isn't > > there, it can say little. > > Which is exactly my point. It surely isn't at the moment, and I don't > see that it should be any time soon. What Hermann suggested is > somebody that keeps track of all Zope software modules and tells him > which is good and which is bad. That's not what you suggested, and as > mention, I don't think it's even possible, and definitely not a good > idea. Well, yes and no: My idea is that there will be a well-defined set of core packages, and probably some extra packages that are also embraced (e.g. maybe z3c packages, e.g. z3c.form). Of course, trying to embrace every zope package out there will not work. But I think it will make sense to embrace packages that cover a common usecase, for instance, creating remote tasks is nothing uncommon and will be needed by many people. Therefore I'd suggest to embrace at least one package that covers that functionality (e.g. lovely.remotetaks, or zc.async, or something else). For all other packages, it will make sense to create some infrastructure, as stated in another mail of Martijn. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hey Tres, Could you repost this to a new thread as I think people aren't paying attention to this thread very much anymore? I'd very much like to make progress on actual cleanups now. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > Paul Everitt wrote: > [snip] >> Hopefully the Zope Framework proposal helps untangle this, and gets to a >> point where you don't have to keep the Uberthing in your head when doing >> something small. > > It's not small, as it has an impact on a lot of things that build on > zope.component. Changing things low in something that lots of people > have built stacks on is almost never a small change. > > Just look at Python 3, which makes a bunch of actually rather small but > still incompatible changes to the language. While small from the > perspective of the language, they're *huge* from the perspective of the > users. > > So you need ways to coordinate such changes. > > I hope that having someone actually taking responsibility for > zope.component's evolution can get the zope.security dependency out of > it, and then improvements of repoze.zcml into it, or alternatively move > the ZCML implementations *entirely* out of zope.component. I hope Chris > will coordinate with us where necessary. > > I don't want security bits to sit around in zope.component either. > grokcore.component doesn't need that code, just like repoze.zcml doesn't > need that code. It's still there, even if you use repoze.zcml, just > inactive. I tried to propose various ways forward. I got nowhere as I > got 10 people giving 10 answers. Original problem unresolved. > > I'd like there to be someone who can make this decision and I'd like > this someone to usually make *positive* decisions that work towards > resolving the underlying issue, while coordinating with everybody that > is impacted by this decision. > > The zope.component ZCML case was very much in my head as I wrote this > proposal. OK, can we table the proposal per se for the moment, and "prototype" the process around the "how do we move zope.component forward" question? I'm not even sure I understand why you think anything in repoze.zcml has squat to do with zope.component, but I could just be missing the obvious. I have a "strawman" proposal, focused on stripping zope.component down as far as possible: 1. Merge my branch which drops the deferred import stuff. 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one "extra" out to a package, *including* its testing dependencies. 3. Move the ZCML directive implementations out into another package, taking the zope.security and zope.configuration dependencies along with them. 4. Rework zope.hookable to use a pure-Python implementation via descriptors, instead of the C extension. Make it a non-optional dependency (but small and lightweight) of zope.component. If *current* profiling shows that the hooked things are bottlenecks, make the C version and optional replacement for the Python version. At the end, we would have three packages: zope.component depends on: - zope.interface - zope.event - zope.hookable zope.componentzcml (BIKESHED NAMING ALERT) depends on: - zope.configuration - zope.security - zope.configuration - zope.proxy - zope.i18nmessageid zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 Folks could then work on refactoring the new packages (e.g., depending on a separate 'persistent' package, making the secuirity bits optional, etc.). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrv9u+gerLs4ltQ4RApPjAJ4nZKFNxrrpiQfXgR8YRxtgn4YMSQCgk4wx TnvvQUfwhVo2X64YAyPAdm0= =KDnz -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hey everybody, This thread is now closed, thanks everybody for your contributions! See my unilateral announcement about the formation of the Steering Group and Zope Framework. It do its best to try to balance the concerns in this thread. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 18:27, Martijn Faassen wrote: >> If it's impossible for these people to agree when discussing on this >> mailing list today, why would the suddenly agree on this mailing list >> if we call them The Zope Framework Steering Group? I really don't >> understand that. > > Two answers: > > * they wouldn't all be on the steering group Why not? They are the people who should have a say, and they are the people most likely to be able to actually implement the decisions. > * the steering group is *tasked* with coming to a single answer that is > recorded. And implement it? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 11:38 PM, Martijn Faassen wrote: > Real soon now, zope.app.container and zope.app.folder and > zope.app.keyreference and zope.app.catalog are not going to be the > business of the Zope Framework developers anymore. They contain ZMI > stuff the Zope Framework developers do not care about directly and > will only care about indirectly if enough people speak up for it and > are willing to work on it. I hope many of them join the real soon now. > We have a line behind which I, and many others, don't have to care > anymore. A receding line, leaving many things behind. > > I don't want to stop anyone else from caring about these other things. > I can't anyway. If people do get together who want to develop "Zope 3 > the app server" they should get together and organize. I hope I can > convince them that this line is important and I hope I can convince > people in general to care *more* about the stuff in the Zope Framework > than anything else. The ZMI isn't the main thrust of Zope 3 > development, and hasn't been for a long time anyway. I want to stop > having to worry about it as soon as possible, and am willing to do > work to get there. +1 for organizing a "Zope 3" team, may be we should re-activate zope3-dev list? Well, ripping out ZMI and other things can be discussed there. I think "Zope 3" should bring many packages in 'z3c' namespace into core "Zope 3" (no need to change namespace) Documenting how Zope 3 packages can be used together to build application is also very important. Regards, Baiju M ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: > I believe to get success here (measured as gaining new Python developer > users), > our path forward needs to be way, way, way more radical and needs to involve > making hard choices that treat individual packages on their own merit rather > than even considering their role as part of a larger collection. That's the > bottom line and I believe it's our fundamental point of disagreement. IMO, > the > part a package plays as part of the larger collection should be utterly and > brutally subservient to its merit as a standalone package. Also IMO, if there > were absolutely no list of versions known to work together, but each piece > worked on its own and had merit on its own, we'd be in a far better place as > far > as attracting new users. Any list of packages-known-to-work-together should > be > a "oh, by the way, this might be handy", not the raison d'etre of the group > and > this discussion. + lots Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, On Wed, Mar 4, 2009 at 6:26 PM, Chris McDonough wrote: > Martijn Faassen wrote: > > >> * A clear set of explicit, layered dependencies in software is generally >> a good thing. We can start thinking about smaller pieces better. By >> splitting up into individually packaged and released bits, we are forced >> to think about these things more. > > (I'm running out of steam on responses here. This will likely be one of the > last). > > You've been saying this: "we'll just identitfy and maintain this giant set of > versions for backwards compatibility purposes and for purposes of *moving > platforms forward through time*". But you also seem to be saying "*real soon > now* we'll also be making hard choices about the life and death of things that > make up the 'framework' and evaluating each on its merit as an idependent > entity." Personally, I disbelieve that this "real soon now" will ever happen > without having it as the *primary* and maybe the *only* goal. It can't be the only goal, we also want to build new stuff, right? Anyway, cleaning this stuff up is one of my most important goals for me personally; I and 5 others spent a week of our life doing that a month ago. Real soon now, zope.app.container and zope.app.folder and zope.app.keyreference and zope.app.catalog are not going to be the business of the Zope Framework developers anymore. They contain ZMI stuff the Zope Framework developers do not care about directly and will only care about indirectly if enough people speak up for it and are willing to work on it. I hope many of them join the real soon now. We have a line behind which I, and many others, don't have to care anymore. A receding line, leaving many things behind. I don't want to stop anyone else from caring about these other things. I can't anyway. If people do get together who want to develop "Zope 3 the app server" they should get together and organize. I hope I can convince them that this line is important and I hope I can convince people in general to care *more* about the stuff in the Zope Framework than anything else. The ZMI isn't the main thrust of Zope 3 development, and hasn't been for a long time anyway. I want to stop having to worry about it as soon as possible, and am willing to do work to get there. > I believe to get success here (measured as gaining new Python developer > users), I think success is not just python developer users, but also serving current users in the Zope 2, Zope 3 and Grok worlds better by having a more comprehensible platform. > our path forward needs to be way, way, way more radical and needs to involve > making hard choices that treat individual packages on their own merit rather > than even considering their role as part of a larger collection. That's the > bottom line and I believe it's our fundamental point of disagreement. IMO, the > part a package plays as part of the larger collection should be utterly and > brutally subservient to its merit as a standalone package. Look, I know you are not using the packages the way that I am, but can't we work together? I want these packages to make sense stand-alone very much, but I also need to consider them as part of a whole that needs to be managed. > Also IMO, if there > were absolutely no list of versions known to work together, but each piece > worked on its own and had merit on its own, we'd be in a far better place as > far > as attracting new users. Any list of packages-known-to-work-together should > be > a "oh, by the way, this might be handy", not the raison d'etre of the group > and > this discussion. I think the group needs to have a list of packages it cares about, so we know what we're talking about. That way we know which packages we need to document and present and clean up, and we know *what* code we want to move out of packages that are in that list. And none of these packages can be broken so they *need* to work together! And we also present a list of versions that we have tested together as a service to the people who need such lists. If we *don't* make such a list we'll remain in the limbo where *all* packages are of some nebulous importance. >> I don't see this as at all incompatible with a group managing a list of >> versions that is known to work together, as a service to various groups >> which do need such lists anyway. > > Maybe not. But as far as I can tell, maintaining such a list is just business > as usual and doesn't require any proposal at all. We're maintaining a different list now, for the Zope 3 app server that you install. What's in the list is mainly just inertia and ad-hoc decision making. That's not the list I'm talking about, though there'll be tremendous overlap to start with. I'm proposing not just a different list but a community that cares about those libraries. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross po
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen wrote: [snip] > The steering group isn't intended to take a responsibility for the > entirety of the Zope software. Zope 2, Grok and the Zope 3 app server > (which would be a distinct entity) would manage themselves and the Zope > Framework steering group would not have a say over the libraries and > configuration they add. [snip] > I do also think that we should go to a smaller set of libraries. We > currently share a huge amount of code that only one consumer actually > uses. For instance, I think all of the zope.app.* packages which contain > ZMI code can eventually be left to the management of the Zope 3 > developers, meaning they'd not be part of the Zope Framework anymore. [snip] > """ > As a service to the users of the Zope Framework, the Zope developers > also make available lists of version numbers of core libraries that > have been tested to work together as a "Known Good Set". This receives > a version number and is the Zope Framework release. Users of the Zope > framework can use this list, but may also diverge from it where they > see fit. Other projects (such as the Zope 3 application server and the > Grok project) also have a Known Good Sets that expand on the Zope > framework list (and may diverge from it). Each of these consumer > projects can of course have their own release process, schedule and > version numbering. > """ [snip] > It may very well be true that in some time we'll develop clusters of > libraries that can be more or less managed on their own. The ZMI is such > a cluster that I hope will eventually emerge (and that the Zope > Framework Steering Group doesn't care about directly). That'd reduce the > coordination overhead. But sometimes we do need to take coordinated > action, and I don't see that need disappearing entirely. I think those who care about "Zope 3" (framework/app server/libraries/ or whatever) should form a team and mailing list to discuss about the future development. All other major consumers of the "Zope Framework Project" has their on mailing list for discussions. I guess very soon zope-dev list will become inappropriate to discuss about "Zope 3". Just like Grok,Repoze etc. it is better to create a list for "Zope 3", may be re-activate zope3-dev list to discuss about the "Zope 3" (framework/app server/libraries/ or whatever). Well, if no one cares about "Zope 3", let's leave it. Regards, Baiju M ___ 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 )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote: > On Wed, Mar 4, 2009 at 18:03, Martijn Faassen wrote: >> I'd like there to be someone who can make this decision and I'd like >> this someone to usually make *positive* decisions that work towards >> resolving the underlying issue, while coordinating with everybody that >> is impacted by this decision. > > But we know pretty much who is impacted by this, and the people with > enough gravitas to be able to say Yay or Nay to these sorts of > refactoring. And they are all on this list. And if there was a > Steering Group, most of them would need to be on that group. > > If it's impossible for these people to agree when discussing on this > mailing list today, why would the suddenly agree on this mailing list > if we call them The Zope Framework Steering Group? I really don't > understand that. Two answers: * they wouldn't all be on the steering group * the steering group is *tasked* with coming to a single answer that is recorded. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote:
> On Wed, Mar 4, 2009 at 17:48, Martijn Faassen wrote:
>> Note that the Zope Steering group is not about
>> packages that are not in the framework, so if lovely.remotetask isn't
>> there, it can say little.
>
> Which is exactly my point. It surely isn't at the moment, and I don't
> see that it should be any time soon. What Hermann suggested is
> somebody that keeps track of all Zope software modules and tells him
> which is good and which is bad. That's not what you suggested, and as
> mention, I don't think it's even possible, and definitely not a good
> idea.
I think it would be possible to provide an infrastructure so that people
who care about communicating certain bits of information ("this package
exists and here is its documentation", "this package is really not
maintained and therefore deprecated") could do so.
Perhaps this infrastructure will be developed as a side-effect of what
needs to be done for those libraries in the Zope Framework anyway.
Regards,
Martijn
___
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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > * A clear set of explicit, layered dependencies in software is generally > a good thing. We can start thinking about smaller pieces better. By > splitting up into individually packaged and released bits, we are forced > to think about these things more. (I'm running out of steam on responses here. This will likely be one of the last). You've been saying this: "we'll just identitfy and maintain this giant set of versions for backwards compatibility purposes and for purposes of *moving platforms forward through time*". But you also seem to be saying "*real soon now* we'll also be making hard choices about the life and death of things that make up the 'framework' and evaluating each on its merit as an idependent entity." Personally, I disbelieve that this "real soon now" will ever happen without having it as the *primary* and maybe the *only* goal. I believe to get success here (measured as gaining new Python developer users), our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a "oh, by the way, this might be handy", not the raison d'etre of the group and this discussion. > I don't see this as at all incompatible with a group managing a list of > versions that is known to work together, as a service to various groups > which do need such lists anyway. Maybe not. But as far as I can tell, maintaining such a list is just business as usual and doesn't require any proposal at all. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04.03.2009 17:26 Uhr, Martijn Faassen wrote: >> Hi there, >> >> Andreas Jung wrote: >> [snip] >>> This would definitely make sense to me. With respect to a steering >>> committee: I am also a bit skeptical about such a committee. I think >>> that the upcoming ZF board will have a good representation of each Zope >>> project on the board in order to address things on the board level. >> You haven't read my document very well if you think I'm proposing a >> Steering Group for all Zope projects > > I wasn't proposing that. I wanted to point out that the persons on the > board could work out on proposal or on some agreement how to approach > the controversial points...basically to layout a consensus plan. This > not about steering the development but about finding some overall consensus. If you're talking about consensus about code, that's really not my vision of what the Zope Foundation board is for. I do think the Zope Foundation board might do something about community organization. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 18:03, Martijn Faassen wrote: > I'd like there to be someone who can make this decision and I'd like > this someone to usually make *positive* decisions that work towards > resolving the underlying issue, while coordinating with everybody that > is impacted by this decision. But we know pretty much who is impacted by this, and the people with enough gravitas to be able to say Yay or Nay to these sorts of refactoring. And they are all on this list. And if there was a Steering Group, most of them would need to be on that group. If it's impossible for these people to agree when discussing on this mailing list today, why would the suddenly agree on this mailing list if we call them The Zope Framework Steering Group? I really don't understand that. I think it is WAY more likely that we get agreement and come forward if we first of all stop having the internet between us. We all know how easy it is to misunderstand intentions and tone of voices on mailing lists as compared to real life. And if it *still* is impossible for these people to agree, then I can't see the Steering Group working either, and then we need a new dictator. But I don't think that's needed, because the technical disagreements we have here are so minor, and seems mostly based in massinderstindung. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Paul Everitt wrote: [snip] > Hopefully the Zope Framework proposal helps untangle this, and gets to a > point where you don't have to keep the Uberthing in your head when doing > something small. It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 17:48, Martijn Faassen wrote: > Note that the Zope Steering group is not about > packages that are not in the framework, so if lovely.remotetask isn't > there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 17:26 Uhr, Martijn Faassen wrote: > Hi there, > > Andreas Jung wrote: > [snip] >> This would definitely make sense to me. With respect to a steering >> committee: I am also a bit skeptical about such a committee. I think >> that the upcoming ZF board will have a good representation of each Zope >> project on the board in order to address things on the board level. > > You haven't read my document very well if you think I'm proposing a > Steering Group for all Zope projects I wasn't proposing that. I wanted to point out that the persons on the board could work out on proposal or on some agreement how to approach the controversial points...basically to layout a consensus plan. This not about steering the development but about finding some overall consensus. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmuszUACgkQCJIWIbr9KYwcbgCglkri5JcNPKHAQu/pWGcYWgUM WNIAoKQXa0HW404juEf/6zDo1ENdnjhU =h1TJ -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. & Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
Re: [Zope-dev] the Zope Framework project
Baiju M wrote: > On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer wrote: > [snip] >> - I think, Zope 3 is not only about some seperate packages, but about a >> complete "programming experience". Thus there needs to be some integrating >> force, that draws together all these packages, writes some documentation / >> tutorial / website etc. > > +1 > > I believe packages developed as part of the Zope 3 project is > here to stay for a long time (of course, after dependency cleanup > some of them may become obsolete). This will happen even if some > of the frameworks based on it are no more available. I'm fine if some people want to get together and organize "Zope 3" to offer an integrated experience. Zope 3 is the thing people install and start projects with. It's what should have a website explaining what it is all about. It's not what the Zope Framework Steering Group cares for however. It doesn't directly care for Zope 3. Zope 3 is explictly *not* the Zope Framework project, just like Grok isn't the Zope Framework project. Both have a stake in the project and will participate in the project, but just like the Zope Framework Steering Group doesn't manage grok.zope.org, it won't manage zope3.zope.org (if such a thing exists) either. While I'm quite interested in volunteering to help coordinate Zope Framework development, I'm not at all interested in volunteering to help coordinate Zope 3 app server development. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: [snip] > And it is in any case in no way even remotely connected to the group > Martijn proposed and has been discussed in this thread. Of course it is connected. The Zope Framework needs leadership that can help: - bless efforts by individuals and subgroups that want to take care of particular areas. - help with the coordination between individuals and groups that want to make changes. The Steering Group will need to keep an overview of what is going on so they can help point out points where coordination is necessary. - mark status (deprecation ,etc) of particular packages that are part of the Zope Framework. Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. The idea is to limit the things that Zope Framework is about so we can take better care of it. Hopefully it can provide the infrastructure and encouragement so that others will do this work however. How this will turn out is a bit of a gray area. - Individual systems such as Grok, Zope 3, Zope 2 and repoze.bfg each provide their own complete "programming experience". The Zope Framework is at best only part of this experience, but it *is* a part of the experience. We could for instance provide a website with documentation about framework packages that individual projects could refer to. - Attracting newbies to web development is not a task of the Zope Framework project directly, and here I diverge from Hermann. That's a task of the Plone project or the Grok project, etc. I do think that the Zope Framework leadership could be much better at attracting and stimulating contributions to the libraries. Attracting more users is important, but that's a task for the Zope 3 app server developers (however they organize) or the Grok project. The Zope Framework is a second-level provider to these projects, and in reality of course people who care about these projects will do most of the driving of development of the Zope Framework. It's a forum where all users of these libraries (many or just a few) can get together, work out our diverse interests, and coordinate. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: [snip] > This just seems like a blindingly obvious antigoal to actually breaking apart > the software into more discrete bits using eggs. Why not just stick with a > huge > tarball release or one single egg if it all has to be versioned through time > to > 99% of its consumers as one giant collection of software treated as a unit? Why not: * Repoze and others couldn't use the bits they care about. * Grok (or anything else) couldn't diverge from a common KGS when it needs to. * individual apps couldn't diverge from a common KGS when *they* need to. * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wednesday 04 March 2009, Martijn Faassen wrote: > I don't agree the Zope Foundation board should directly steer > development of the Zope software. I totally agree. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Andreas Jung wrote: [snip] > This would definitely make sense to me. With respect to a steering > committee: I am also a bit skeptical about such a committee. I think > that the upcoming ZF board will have a good representation of each Zope > project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects. I don't agree the Zope Foundation board should directly steer development of the Zope software. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hey there, Chris McDonough wrote: > 1) I'm not in favor of a single steering group for the *entirety* of all Zope > software. We've tried a similar thing in the past (via the foundation > structure); it didn't work and I'm not sure how we'd expect things to turn out > any differently this time. Instead, perhaps the focus of groups should be on > some much smaller subset of Zope-related software (e.g. the > zope.interface+zope.component group, the zope.schema group, the ZODB group, > etc). Could we consider this? I don't recall we actually did anything within the Foundation structure. The structure was there in the bylaws but was never applied, so I don't think that can be qualified as a failure. :) The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. I do think the steering group should start worrying about a larger amount of the libraries rather than a small set. Part of the reason is exactly so we *can* identify subsets and properly delegate their management. Delegating their management will require some kind of agreement on groups coordinating however. We need to have an overview of the whole in order to know how to evolve the parts in many cases. For instance, if we move some class due to a dependency cleanup, we need to have an effort to update the libraries in the whole to use the new imports relations. I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. The ZODB is a good example where I'm not sure whether the ZODB should be considered part of the Zope Framework at all. I think we should see this as an external library that the framework builds on. The idea that there is a bunch of people who take the responsibility for managing the whole doesn't mean they should be obstructing moves to improve the parts. Similarly I assume you're taking some form of responsibility for "Repoze" and that this is helpful the evolution of the parts of it. My hope is that we'll see more of a catalyst function than anything else. I think the answer to proposed changes in the lower layers (which is always risky) should be to point out potential risks and say: we can make this change, but we also need to make sure we do X. The answer should typically not be "no". If it is a "no", we should actively try to identify the use cases driving the proposed change and look for alternative solutions. > 2) I'm also not in favor of a giant lockstep set of software versions shared > between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this > as > continuing our mistakes of old by trying to treat some collection of software > as > "Zope" as opposed to letting parts of it survive or die on their own based on > merit; it'd be more effective to just let each framework use (or disuse!) > whatever versions of stuff that work best for it. That's why the software is > broken out into individual components in the first place; we should encourage > diversity in component usage. Instead of trying to legislate and bless some > set > of components as a "version", we should just work to make each piece better > and > worthwhile to use independently; it's value would be in its actual usefulness > rather than some belief that it works well with the other components in the > "version". I don't understand why you think a list of versions that has release numbers that we know works together is a blocker for independent evolution for the individual libraries. I think there are two parallel efforts: * evolving libraries standalone. We should improve those libraries so we can think about them standalone. If a library contains ZMI code, it's harder to think about it standalone for instance. * making sure that there is a list of library versions that people can install that isn't broken. That is, run the tests for these libraries in isolation and together. If a decision was made to change one library, make sure that all the other libraries in the list are updated so they actually still work. I see both efforts as necessary. If you just care about a smaller list of libraries, you don't have to worry about a larger list of course, though you will have to coordinate with some people who do. You probably can do quite well constructing your own list as it's a much smaller one. That's fine, and nothing should stop you. But the reality is that many people in this group *do* care about a larger list of libraries. > Could we at least agree that l
Re: [Zope-dev] the Zope Framework project
Hi there,
Hanno Schlichting wrote:
[snip]
> You can try to bake more leadership of the overall Zope community into
> this, but I think this is a fruitless fight right now. Reduce the scope,
> try make some things better and don't step on other peoples feet if you
> don't need to. For example don't try to push out style-guides for the
> entirety of the svn.zope.org repository. They lead to bike-shed
> discussions and discourage contributions.
Yes, I agree with restricting scope. I wanted to restrict scope to a set
of libraries that's shared between a bunch of the big consumer projects,
and that I called "the Zope Framework". It's not something you install
by itself, and it's not something that everybody uses every bit of. But
it is something that is shared by a lot of people and we need to take
responsibility for and manage as a whole, not just as a whole bunch of
parts.
Beyond that in our repository, the framework steering group would have
influence but no authority. The document reflects that thinking.
Repository-wide guidelines do exist, such as the copyright assignment
policy, and the general 'trunk'/'branches'/'tags' structure of projects,
and the way people name distributions of packages the same name as the
package name ('zope.foo' is released as 'zope.foo'), and I'm sure we can
come up with many more of such conventions. It's not something for the
Zope Framework group to care about though. Part of that will just happen
by consensus and example anyway, but outside of the realm of the Zope
Framework Steering Group.
Regards,
Martijn
___
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 )
Re: [Zope-dev] the Zope Framework project
Gary Poster wrote: > On Mar 3, 2009, at 12:31 PM, Martijn Faassen wrote: > >> Hey Gary, >> >> [panarchist approach where we have people starting groups that could >> compete for attention] > > [Had to look up panarchist, but yes, essentially.] I shouldn't have used that word, I actually didn't realize anyone else had made it up beyond me but it seems to have a century + history. :) [snip] > I think your statements and mine mesh well enough. If you don't > agree, that's fine. Practically, it means I support what you are > trying to do (and in fact I would tend towards your camp in my > proposed panarchy), if from a slightly different perspective. Sure, they mesh well enough. I'm just pointing out that freely competing projects only work to a certain extent; as soon as there's code or community resources shared between them there are going to be points of conflicts of interests that need to be resolved somehow. I think often this can be resolved to the satisfaction of everybody, but I do think we need a structure in which things can be resolved. Freely competing structures might equal no structure, and that's something to watch out for. > I'm glad you sent your proposal email first. Now that you have, I > hope you pursue your vision without needing 100% buy-in from the > community. I'm optimistic that you will. :-) I'm a stubborn fool with no idea of what I seem to be signing up for, so I guess I might. :) Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 9:47 AM, Roger Ineichen wrote: > Hi Paul > >> Betreff: Re: [Zope-dev] the Zope Framework project >> >> On 3/4/09 8:16 AM, Martin Aspeli wrote: > > [...] > >> Chameleon provided something that made it work for those >> users, while allowing it to not be burdened by those needs. >> Everybody wins. >> Hopefully such solutions will be the norm in the future. >> >>> That particular discussion is over, though, and I have no >> interest in >>> having it again. > > I hope not! I don't like to have any code in an application which > I don't use. > > But right now I don't see a better solution for the chicken > and egg problem we have with z3c.pt and chameleon support > in our base packages. In older days we used monkey patches > for that problem, but that's no solution anymore. I agree, and I think this case is a good exemplar for the challenge. Chameleon wanted to make a good templating engine that was independent of megaframeworks. For that, it needed/wanted a configuration language that met your statement "I don't like to have any code...I don't use". But legacy in one of the projects changed this from a self-contained, 1x amount of work into a cobweb of bigger issues, control in the hands of others, and 10x the work. Human nature says that's demoralizing. Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi Paul > Betreff: Re: [Zope-dev] the Zope Framework project > > On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] > Chameleon provided something that made it work for those > users, while allowing it to not be burdened by those needs. > Everybody wins. > Hopefully such solutions will be the norm in the future. > > > That particular discussion is over, though, and I have no > interest in > > having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. Regards Roger Ineichen > These two paragraphs seem contradictory. [wink] We'll > consider the matter closed. > > --Paul > > ___ > 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 ) > ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Thu, Mar 5, 2009 at 3:04 AM, Hermann Himmelbauer wrote: > Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: >> Tather than reply in kind here, let me summarize: I'm glad we agree more >> than we disagree, and I apologize if I've attributed to you beliefs that >> you don't have. It's heartening to hear that you're in favor of most of >> the things I'm also in favor of. But we do have real differences in >> opinion I think. I'd rather be constructive than obstructionist here: at >> the end of each item below I ask for an opinion based on a suggestion. >> >> 1) I'm not in favor of a single steering group for the *entirety* of all >> Zope software. We've tried a similar thing in the past (via the >> foundation structure); it didn't work and I'm not sure how we'd expect >> things to turn out any differently this time. Instead, perhaps the focus >> of groups should be on some much smaller subset of Zope-related software >> (e.g. the >> zope.interface+zope.component group, the zope.schema group, the ZODB group, >> etc). Could we consider this? > > What I don't see in your proposal is, how these subset-groups would be > coordinated, which leads to the following: > > - How would these groups be formed? If there's nobody who encourages people to > do so, > > - Higher level package/groups may have a hard life in case basic > packages/groups are not coordinated and all "go their own way". > > - How does some foreigner know, if a package is actively supported, > umaintaned, deprecated etc.? How does he know, what packages exist, what they > are good for and the like? For instance, I yesterday wrote that I use > lovely.remotetask, then I was asked on the list why I did not use the (maybe > better) zc.async package. Know why? I did not know that it existed. > > - I think, Zope 3 is not only about some seperate packages, but about a > complete "programming experience". Thus there needs to be some integrating > force, that draws together all these packages, writes some documentation / > tutorial / website etc. > > - Newbies won't be attracted by single packages. Instead, they want something > complete. Who would be interested in Plone if it would consist of various > packages that people would have to draw together by themselves, without > decent documentation? > > To my mind, one key point is attracting more users. And that can only be done > if we try to view things from an external, newbie-perspective. Some Ruby on > Rails / Java / Turbogears programmer will only be attracted by some "big > picture" but probably not by a collection of some subpackages. > > So, my impression is that there is a need for some steering group, that will, > however, encourage people to form groups around packages and maintain them. I envision a "Council of Elders" with student representation. The Elders either know, or know who knows the history and current state of affairs, the students know the struggles of the newbies. They could provide welcome wagon, triage, and guide service for navigating the Zope wilds. > > Best Regards, > Hermann > > -- > herm...@qwer.tk > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > ___ > Zope-Dev maillist - zope-...@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 ) > ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 8:16 AM, Martin Aspeli wrote: > Paul Everitt wrote: > >> When I read Martin's post, I had a similar reaction. Namely, that the >> convenience of the Uberthing (Plone in this case) will always trump the >> desire of packages trying to survive on their own for new audiences. At >> the time of the configuration scolding, I remember thinking: there's >> little interest here in Chameleon's goal to be bigger than Zope. "Keep >> things convenient for us in Plone!" > > In this case, you totally misread my post. It broke for all users of > zope.component, and I never, once, made the argument that Chameleon was > part of Plone or should be driven purely by Plone's needs. I have no > such pretentions, nor does anyone else I know, about this, or zope.* or > the CMF package or, well, anything that is not expressly part of Plone. Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. > That particular discussion is over, though, and I have no interest in > having it again. These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: > When I read Martin's post, I had a similar reaction. Namely, that the > convenience of the Uberthing (Plone in this case) will always trump the > desire of packages trying to survive on their own for new audiences. At > the time of the configuration scolding, I remember thinking: there's > little interest here in Chameleon's goal to be bigger than Zope. "Keep > things convenient for us in Plone!" In this case, you totally misread my post. It broke for all users of zope.component, and I never, once, made the argument that Chameleon was part of Plone or should be driven purely by Plone's needs. I have no such pretentions, nor does anyone else I know, about this, or zope.* or the CMF package or, well, anything that is not expressly part of Plone. That particular discussion is over, though, and I have no interest in having it again. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 1:07 AM, Chris McDonough wrote: > Martin Aspeli wrote: >> Chris McDonough wrote: >> >>> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. >> Note that the "scolding" had something to do with you breaking Plone >> trunk due to a transitive change in Chameleon, and the realisation that >> from this point on, any package shared between repoze.bfg and Plone (or >> anything else) that is configured with ZCML, will probably need to be >> forked. We found a workaround with Chameleon, but not one that will scale. > > The fix is totally scalable and completely correct. Chameleon.zpt just does > not > have any (real) ZCML anymore. Any package that has ZCML is, by definition, > written for some framework as stuff that is meant to be overridden, otherwise > it > wouldn't be written as configuration. ZCML is unlike code in this way. If it > wasn't meant to be overridden, it would be in code. > > All packages which are meant to be maximally useful outside the scope of that > framework should be split into two things: the library portion, then some > portion that contains ZCML for gluing in to some framework that wants ZCML in > some specific configuration. When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. "Keep things convenient for us in Plone!" Package sharing between repoze.bfg and Plone should not mean that BFG gets dragged down, paying for things it specifically doesn't want to eat. BFG never claimed to sign up for Plone's contracts. I sense the logic of Chris's position: if the Zope Framework is as big as every current use case in Zope2+Zope3+Grok+etc., with nine years of accumulations on each (3 forms systems in one of them), then we're missing the goal (IMO). We'll make life incrementally better for ourselves, but we'll still scare off the folks who aren't after Uberthing. Plone is going towards a smaller-and-smaller "core" that is only as big as the manpower to do a great job at keeping it stable. Meaning, very small. Hopefully the Zope Framework is a tiny little thing that pays only for what it eats. Hopefully the goal is to make a very good microframework (or even better, set of libraries). If "you can't make the best configuration language possible because one line of includes to get trusted adapters is an unconscionable burden" is the rule, then I know how this movie ends. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 10:56, Hermann Himmelbauer wrote: > Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro: >> On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer wrote: >> > What I don't see in your proposal is, how these subset-groups would be >> > coordinated, which leads to the following: >> > - How does some foreigner know, if a package is actively supported, >> > umaintaned, deprecated etc.? How does he know, what packages exist, what >> > they are good for and the like? For instance, I yesterday wrote that I >> > use lovely.remotetask, then I was asked on the list why I did not use the >> > (maybe better) zc.async package. Know why? I did not know that it >> > existed. [...] >> The steering group would not and could not help with any of these problems. > > Why? Can you elaborate? Who/what group woud play that central/integrating > role? Maybe we have different perceptions of a "steering group", but my > impression was that this group would see the above points as their key > topics. I don't think it's possible, and it seems to me to be a rather strange idea to have a group keep track of all the packages in the Zope world and somehow categorize them by quality. And it is in any case in no way even remotely connected to the group Martijn proposed and has been discussed in this thread. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro: > On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer wrote: > > What I don't see in your proposal is, how these subset-groups would be > > coordinated, which leads to the following: > > - How does some foreigner know, if a package is actively supported, > > umaintaned, deprecated etc.? How does he know, what packages exist, what > > they are good for and the like? For instance, I yesterday wrote that I > > use lovely.remotetask, then I was asked on the list why I did not use the > > (maybe better) zc.async package. Know why? I did not know that it > > existed. > > > > - I think, Zope 3 is not only about some seperate packages, but about a > > complete "programming experience". Thus there needs to be some > > integrating force, that draws together all these packages, writes some > > documentation / tutorial / website etc. > > > > - Newbies won't be attracted by single packages. Instead, they want > > something complete. Who would be interested in Plone if it would consist > > of various packages that people would have to draw together by > > themselves, without decent documentation? > > > > To my mind, one key point is attracting more users. And that can only be > > done if we try to view things from an external, newbie-perspective. Some > > Ruby on Rails / Java / Turbogears programmer will only be attracted by > > some "big picture" but probably not by a collection of some subpackages. > > > > So, my impression is that there is a need for some steering group, that > > will, however, encourage people to form groups around packages and > > maintain them. > > The steering group would not and could not help with any of these problems. Why? Can you elaborate? Who/what group woud play that central/integrating role? Maybe we have different perceptions of a "steering group", but my impression was that this group would see the above points as their key topics. Maybe I don't get your point, but your suggestion seems to be to "let things go in a natural flow as it happens now". But that would imply that the current situation is satisfying, which seems not to be, as can be read in all those various posts regarding this topic. What would be further interesting is, if there are any successful open-source projects, that implement such a non-leadership/natural flow model, because I'm not aware of any. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer wrote: [snip] > - I think, Zope 3 is not only about some seperate packages, but about a > complete "programming experience". Thus there needs to be some integrating > force, that draws together all these packages, writes some documentation / > tutorial / website etc. +1 I believe packages developed as part of the Zope 3 project is here to stay for a long time (of course, after dependency cleanup some of them may become obsolete). This will happen even if some of the frameworks based on it are no more available. Regards, Baiju M ___ 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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 08:16:26 schrieb Lennart Regebro: > On Wed, Mar 4, 2009 at 07:52, Chris McDonough wrote: > > Tather than reply in kind here, let me summarize: I'm glad we agree more > > than we disagree, and I apologize if I've attributed to you beliefs that > > you don't have. It's heartening to hear that you're in favor of most of > > the things I'm also in favor of. But we do have real differences in > > opinion I think. I'd rather be constructive than obstructionist here: at > > the end of each item below I ask for an opinion based on a suggestion. > > > > 1) I'm not in favor of a single steering group for the *entirety* of all > > Zope software. We've tried a similar thing in the past (via the > > foundation structure); it didn't work and I'm not sure how we'd expect > > things to turn out any differently this time. Instead, perhaps the focus > > of groups should be on some much smaller subset of Zope-related software > > (e.g. the > > zope.interface+zope.component group, the zope.schema group, the ZODB > > group, etc). Could we consider this? > > It's better certainly, but isn't this small enough in itself that > these groups will form naturally by whoever is working on it? But isn't that the current situation? I think there are two scenarious when people will deal with a package in-depth on their own: 1) They found a bug: I made the experience that in case I find some bug and dig into some Zope 3 code, things tend to become very complicated and I often can't understand/fix it. For instance, I found some bug/misbehaviour regarding combination of virtual hosts and ++xyz++ URL-variables (forgot the name for that) and was not able to apply a clean fix due to lack of understanding. I could not find anyone on the list, who was responsible for that piece of code, so I did some hacking and never committed this (dirty) hack as it's certainly not up to the Zope 3 standards. 2) They want to extend a package: In order to do that, I'd first like to understand the package in-depth, so that my extensions don't break concepts and code. But it seems that there are many packages (and even core packages) where nobody seems to feel responsible for, or, I just don't know who it is and can therefore not get to the required information. If there's no one that is motivated by (1) or (2), the package is abandoned (although it may even have core functionality). And my impression is that this has already happend for some packages, which is bad. Therefore I think it would be a great advantage if there is some group that makes sure that each package has someone associated with, who has in-depth knowledge and maintains it. And if there is no interest in a package anymore and it's not used, this group may give it the status "umaintained" and kill it off. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer wrote: > What I don't see in your proposal is, how these subset-groups would be > coordinated, which leads to the following: > > - How would these groups be formed? If there's nobody who encourages people to > do so, They will be formed by people grouping together to work on a piece of software, if such a group is necessary. > - Higher level package/groups may have a hard life in case basic > packages/groups are not coordinated and all "go their own way". Then these "higher level groups" will help coordinate the lower level packages. > - How does some foreigner know, if a package is actively supported, > umaintaned, deprecated etc.? How does he know, what packages exist, what they > are good for and the like? For instance, I yesterday wrote that I use > lovely.remotetask, then I was asked on the list why I did not use the (maybe > better) zc.async package. Know why? I did not know that it existed. > > - I think, Zope 3 is not only about some seperate packages, but about a > complete "programming experience". Thus there needs to be some integrating > force, that draws together all these packages, writes some documentation / > tutorial / website etc. > > - Newbies won't be attracted by single packages. Instead, they want something > complete. Who would be interested in Plone if it would consist of various > packages that people would have to draw together by themselves, without > decent documentation? > > To my mind, one key point is attracting more users. And that can only be done > if we try to view things from an external, newbie-perspective. Some Ruby on > Rails / Java / Turbogears programmer will only be attracted by some "big > picture" but probably not by a collection of some subpackages. > > So, my impression is that there is a need for some steering group, that will, > however, encourage people to form groups around packages and maintain them. The steering group would not and could not help with any of these problems. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 09:21, Chris McDonough wrote:
> To the extent we can discourage the formation of the
> one-big-group-to-rule-them-all by encouraging the formation of smaller
> groups, I
> think it's a good idea. But in reality, I think nothing needs to be done:
> group-forming will always be a self-selecting process.
Well, at least we should try this first, I agree with that.
>> No, we want Zope 3.4 to have one set of modules with one API, and Grok
>> 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
>> Grok 1.1 (or something) and a Zope 2.13. So we DO want "lockstep" and
>> to use the same major KGS over all these versions. At least I do I
>> don't see why this must result in parts that should die being left
>> undead.
>
> This just seems like a blindingly obvious antigoal to actually breaking apart
> the software into more discrete bits using eggs. Why not just stick with a
> huge
> tarball release or one single egg if it all has to be versioned through time
> to
> 99% of its consumers as one giant collection of software treated as a unit?
But it doesn't have to be treated as a unit. I don't know what you
mean with "version through time to 99% of its customers". To me having
releases of modules and releases of sets of modules is orthogonal and
does not contradict each other.
>> Then again, if Repoze
>> doens't want to be a part of The Zope Framework users but always make
>> their own set of modules, that will admittedly lessen the purpose of
>> it, as the minimalistic attitude of Repoze.bfg would work as a good
>> test of what should be in the framework in the first place.
>
> Right. No one except people who've already bought in to the notion of Zope
> software as one huge pile will benefit from the lockstep centralized planning.
I have the feeling that either you or me have completely misunderstood
the proposal, because I don't think you are talking about the same
proposal as me.
>>> Could we also agree that this would tend to result in better dependency
>>> partitioning
>>> ("X depends on Y, I don't need Y, I just need X, let's fix that")?
>>
>> I don't see how these are related.
>
> When components are not treated as one giant pile, and it's expected that you
> should be able to use pieces of the pile selectively without buying in to some
> unrelated software, dependency management becomes far more brutal and
> realistic.
Yes. And I still do not see how this is related to the proposal. It is
expected that you should be able to use pieces of the pile
selectively, and it will continue to be expected.
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
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 )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: > Tather than reply in kind here, let me summarize: I'm glad we agree more > than we disagree, and I apologize if I've attributed to you beliefs that > you don't have. It's heartening to hear that you're in favor of most of > the things I'm also in favor of. But we do have real differences in > opinion I think. I'd rather be constructive than obstructionist here: at > the end of each item below I ask for an opinion based on a suggestion. > > 1) I'm not in favor of a single steering group for the *entirety* of all > Zope software. We've tried a similar thing in the past (via the > foundation structure); it didn't work and I'm not sure how we'd expect > things to turn out any differently this time. Instead, perhaps the focus > of groups should be on some much smaller subset of Zope-related software > (e.g. the > zope.interface+zope.component group, the zope.schema group, the ZODB group, > etc). Could we consider this? What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all "go their own way". - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete "programming experience". Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some "big picture" but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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 )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote:
> On Wed, Mar 4, 2009 at 07:52, Chris McDonough wrote:
>> Tather than reply in kind here, let me summarize: I'm glad we agree more
>> than
>> we disagree, and I apologize if I've attributed to you beliefs that you don't
>> have. It's heartening to hear that you're in favor of most of the things I'm
>> also in favor of. But we do have real differences in opinion I think. I'd
>> rather be constructive than obstructionist here: at the end of each item
>> below I
>> ask for an opinion based on a suggestion.
>>
>> 1) I'm not in favor of a single steering group for the *entirety* of all
>> Zope
>> software. We've tried a similar thing in the past (via the foundation
>> structure); it didn't work and I'm not sure how we'd expect things to turn
>> out
>> any differently this time. Instead, perhaps the focus of groups should be on
>> some much smaller subset of Zope-related software (e.g. the
>> zope.interface+zope.component group, the zope.schema group, the ZODB group,
>> etc). Could we consider this?
>
> It's better certainly, but isn't this small enough in itself that
> these groups will form naturally by whoever is working on it?
To the extent we can discourage the formation of the
one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I
think it's a good idea. But in reality, I think nothing needs to be done:
group-forming will always be a self-selecting process.
> No, we want Zope 3.4 to have one set of modules with one API, and Grok
> 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
> Grok 1.1 (or something) and a Zope 2.13. So we DO want "lockstep" and
> to use the same major KGS over all these versions. At least I do I
> don't see why this must result in parts that should die being left
> undead.
This just seems like a blindingly obvious antigoal to actually breaking apart
the software into more discrete bits using eggs. Why not just stick with a huge
tarball release or one single egg if it all has to be versioned through time to
99% of its consumers as one giant collection of software treated as a unit?
> If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep
> would not pose a problem for Repoze, would it?
Nope.
> Then again, if Repoze
> doens't want to be a part of The Zope Framework users but always make
> their own set of modules, that will admittedly lessen the purpose of
> it, as the minimalistic attitude of Repoze.bfg would work as a good
> test of what should be in the framework in the first place.
Right. No one except people who've already bought in to the notion of Zope
software as one huge pile will benefit from the lockstep centralized planning.
It won't gain Zope any new users; no different framework users will begin to use
Zope software as a result of this plan. How is this different than the current
status quo?
>> Could we at least agree that lockstep versioning of a huge set of
>> Zope eggs to be shared across many frameworks is not optimal for the long
>> term
>
> Well, since it's shared by many frameworks, I'm not sure it would be
> "huge". But that's a matter of taste of course. But in any case,
> through this discussion, I must admit that I not not understand why
> this would pose problem.
It doesn't pose a problem. It's just business as usual.
>> and that it would be better if each framework could pick and choose whatever
>> components and versions it actually needed?
>
> It can. These are not mutually exclusive. A central KGS for the core
> framework does not exclude you making your own KGS, neither does it
> mean you can't release each module separately.
>
>> Could we also agree that this would tend to result in better dependency
>> partitioning
>> ("X depends on Y, I don't need Y, I just need X, let's fix that")?
>
> I don't see how these are related.
When components are not treated as one giant pile, and it's expected that you
should be able to use pieces of the pile selectively without buying in to some
unrelated software, dependency management becomes far more brutal and realistic.
- C
___
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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2009 8:50 Uhr, Chris McDonough wrote:
> Andreas Jung wrote:
>
>>> 2) I'm also not in favor of a giant lockstep set of software versions shared
>>> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see
>>> this as
>>> continuing our mistakes of old by trying to treat some collection of
>>> software as
>>> "Zope" as opposed to letting parts of it survive or die on their own based
>>> on
>>> merit; it'd be more effective to just let each framework use (or disuse!)
>>> whatever versions of stuff that work best for it. That's why the software
>>> is
>>> broken out into individual components in the first place; we should
>>> encourage
>>> diversity in component usage. Instead of trying to legislate and bless
>>> some set
>>> of components as a "version", we should just work to make each piece better
>>> and
>>> worthwhile to use independently; it's value would be in its actual
>>> usefulness
>>> rather than some belief that it works well with the other components in the
>>> "version". Could we at least agree that lockstep versioning of a huge set
>>> of
>>> Zope eggs to be shared across many frameworks is not optimal for the long
>>> term
>>> and that it would be better if each framework could pick and choose whatever
>>> components and versions it actually needed? Could we also agree that this
>>> would
>>> tend to result in better dependency partitioning ("X depends on Y, I don't
>>> need
>>> Y, I just need X, let's fix that")?
>>
>> A central maintained KGS for Zope 3.X components is necessary since only
>> a minor number of core developers knows exactly which version match
>> together. You can not expect that non-core developers have this
>> knowledge.
>
> In places that require cross-package API contracts, each contract should be
> spelled out in an interface. If each contract is spelled out in an interface,
> non-core developers should have no problem gaining this knowledge. That's
> what
> interfaces are for.
Interfaces are one side of the medal, the other side are dependencies
expressed through version pinning. We have had enough examples with
version conflict with modules that would obviously fit together based
on their interface definitions. That's where a KGS helps a lot - however
this is not a contradiction to the approach that Tres pointed out with
maintaining a per-project index with hand-selected packages. I find this
idea very compelling for a bunch of usecases - not sure if this a
general approach - one out of many.
Andreas
- --
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
-
E-Publishing, Python, Zope & Plone development, Consulting
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkmuOPAACgkQCJIWIbr9KYwOjQCgt9O7I4qdRBlzqsm93OfzYBf2
VYQAoII60shD+EkPF9TqaTb5ZaQQ3rDT
=DrbH
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard
___
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 )
Re: [Zope-dev] the Zope Framework project
Andreas Jung wrote:
>> 2) I'm also not in favor of a giant lockstep set of software versions shared
>> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see
>> this as
>> continuing our mistakes of old by trying to treat some collection of
>> software as
>> "Zope" as opposed to letting parts of it survive or die on their own based on
>> merit; it'd be more effective to just let each framework use (or disuse!)
>> whatever versions of stuff that work best for it. That's why the software is
>> broken out into individual components in the first place; we should encourage
>> diversity in component usage. Instead of trying to legislate and bless some
>> set
>> of components as a "version", we should just work to make each piece better
>> and
>> worthwhile to use independently; it's value would be in its actual usefulness
>> rather than some belief that it works well with the other components in the
>> "version". Could we at least agree that lockstep versioning of a huge set of
>> Zope eggs to be shared across many frameworks is not optimal for the long
>> term
>> and that it would be better if each framework could pick and choose whatever
>> components and versions it actually needed? Could we also agree that this
>> would
>> tend to result in better dependency partitioning ("X depends on Y, I don't
>> need
>> Y, I just need X, let's fix that")?
>
>
> A central maintained KGS for Zope 3.X components is necessary since only
> a minor number of core developers knows exactly which version match
> together. You can not expect that non-core developers have this
> knowledge.
In places that require cross-package API contracts, each contract should be
spelled out in an interface. If each contract is spelled out in an interface,
non-core developers should have no problem gaining this knowledge. That's what
interfaces are for.
On the other hand, it shouldn't be as difficult as you mention above to
determine which versions of which packages work together: at least not
difficult enough to require the subcontracting of such work to some committee.
There shouldn't *be* that many things! If one package is depending on an
implementation detail of another package that isn't spelled out in an interface,
the two packages shouldn't be separate in the first place; they should be a
single package. If we took this simple idea to heart, I suspect lots of related
packages could be re-collapsed into a single package, making the set of packages
would less giant in the first place and more manageable.
> I agree on the point of making the components having their
> own lifecycle and to make them usable more independently.
Cool.
- C
___
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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 07:52, Chris McDonough wrote:
> Tather than reply in kind here, let me summarize: I'm glad we agree more than
> we disagree, and I apologize if I've attributed to you beliefs that you don't
> have. It's heartening to hear that you're in favor of most of the things I'm
> also in favor of. But we do have real differences in opinion I think. I'd
> rather be constructive than obstructionist here: at the end of each item
> below I
> ask for an opinion based on a suggestion.
>
> 1) I'm not in favor of a single steering group for the *entirety* of all Zope
> software. We've tried a similar thing in the past (via the foundation
> structure); it didn't work and I'm not sure how we'd expect things to turn out
> any differently this time. Instead, perhaps the focus of groups should be on
> some much smaller subset of Zope-related software (e.g. the
> zope.interface+zope.component group, the zope.schema group, the ZODB group,
> etc). Could we consider this?
It's better certainly, but isn't this small enough in itself that
these groups will form naturally by whoever is working on it?
> 2) I'm also not in favor of a giant lockstep set of software versions shared
> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this
> as
> continuing our mistakes of old by trying to treat some collection of software
> as
> "Zope" as opposed to letting parts of it survive or die on their own based on
> merit; it'd be more effective to just let each framework use (or disuse!)
> whatever versions of stuff that work best for it. That's why the software is
> broken out into individual components in the first place; we should encourage
> diversity in component usage. Instead of trying to legislate and bless some
> set
> of components as a "version", we should just work to make each piece better
> and
> worthwhile to use independently; it's value would be in its actual usefulness
> rather than some belief that it works well with the other components in the
> "version".
I'm pretty sure Zope 2, Zope 3 and Grok wants to go in lockstep if
possible. I'm just pondering the nightmare of working having say Zope
3.4 with one API, and Zope 3.5 with a subtyly different API, and Grok
1.0, with yet another subtly different API and Grok 1.1 with another
subtly different API and Zope 2.12 with yet another subtly different
API and Zope 2.13 with yet another subtly different API. Urgh.
No, we want Zope 3.4 to have one set of modules with one API, and Grok
1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
Grok 1.1 (or something) and a Zope 2.13. So we DO want "lockstep" and
to use the same major KGS over all these versions. At least I do I
don't see why this must result in parts that should die being left
undead.
If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep
would not pose a problem for Repoze, would it? Then again, if Repoze
doens't want to be a part of The Zope Framework users but always make
their own set of modules, that will admittedly lessen the purpose of
it, as the minimalistic attitude of Repoze.bfg would work as a good
test of what should be in the framework in the first place.
> Could we at least agree that lockstep versioning of a huge set of
> Zope eggs to be shared across many frameworks is not optimal for the long term
Well, since it's shared by many frameworks, I'm not sure it would be
"huge". But that's a matter of taste of course. But in any case,
through this discussion, I must admit that I not not understand why
this would pose problem.
> and that it would be better if each framework could pick and choose whatever
> components and versions it actually needed?
It can. These are not mutually exclusive. A central KGS for the core
framework does not exclude you making your own KGS, neither does it
mean you can't release each module separately.
> Could we also agree that this would tend to result in better dependency
> partitioning
> ("X depends on Y, I don't need Y, I just need X, let's fix that")?
I don't see how these are related.
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2009 7:52 Uhr, Chris McDonough wrote:
> Tather than reply in kind here, let me summarize: I'm glad we agree more than
> we disagree, and I apologize if I've attributed to you beliefs that you don't
> have. It's heartening to hear that you're in favor of most of the things I'm
> also in favor of. But we do have real differences in opinion I think. I'd
> rather be constructive than obstructionist here: at the end of each item
> below I
> ask for an opinion based on a suggestion.
>
> 1) I'm not in favor of a single steering group for the *entirety* of all Zope
> software. We've tried a similar thing in the past (via the foundation
> structure); it didn't work and I'm not sure how we'd expect things to turn out
> any differently this time. Instead, perhaps the focus of groups should be on
> some much smaller subset of Zope-related software (e.g. the
> zope.interface+zope.component group, the zope.schema group, the ZODB group,
> etc). Could we consider this?
This would definitely make sense to me. With respect to a steering
committee: I am also a bit skeptical about such a committee. I think
that the upcoming ZF board will have a good representation of each Zope
project on the board in order to address things on the board level.
>
> 2) I'm also not in favor of a giant lockstep set of software versions shared
> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this
> as
> continuing our mistakes of old by trying to treat some collection of software
> as
> "Zope" as opposed to letting parts of it survive or die on their own based on
> merit; it'd be more effective to just let each framework use (or disuse!)
> whatever versions of stuff that work best for it. That's why the software is
> broken out into individual components in the first place; we should encourage
> diversity in component usage. Instead of trying to legislate and bless some
> set
> of components as a "version", we should just work to make each piece better
> and
> worthwhile to use independently; it's value would be in its actual usefulness
> rather than some belief that it works well with the other components in the
> "version". Could we at least agree that lockstep versioning of a huge set of
> Zope eggs to be shared across many frameworks is not optimal for the long term
> and that it would be better if each framework could pick and choose whatever
> components and versions it actually needed? Could we also agree that this
> would
> tend to result in better dependency partitioning ("X depends on Y, I don't
> need
> Y, I just need X, let's fix that")?
>
A central maintained KGS for Zope 3.X components is necessary since only
a minor number of core developers knows exactly which version match
together. You can not expect that non-core developers have this
knowledge. I agree on the point of making the components having their
own lifecycle and to make them usable more independently.
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkmuKckACgkQCJIWIbr9KYwyVQCg4wa+BwWKTR++sHQGJRlD7K6/
C3cAoMgUSnynhrno3ja+m9Bf8wYJb9w1
=P85M
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard
___
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 )
Re: [Zope-dev] the Zope Framework project
Tather than reply in kind here, let me summarize: I'm glad we agree more than
we disagree, and I apologize if I've attributed to you beliefs that you don't
have. It's heartening to hear that you're in favor of most of the things I'm
also in favor of. But we do have real differences in opinion I think. I'd
rather be constructive than obstructionist here: at the end of each item below I
ask for an opinion based on a suggestion.
1) I'm not in favor of a single steering group for the *entirety* of all Zope
software. We've tried a similar thing in the past (via the foundation
structure); it didn't work and I'm not sure how we'd expect things to turn out
any differently this time. Instead, perhaps the focus of groups should be on
some much smaller subset of Zope-related software (e.g. the
zope.interface+zope.component group, the zope.schema group, the ZODB group,
etc). Could we consider this?
2) I'm also not in favor of a giant lockstep set of software versions shared
between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this as
continuing our mistakes of old by trying to treat some collection of software as
"Zope" as opposed to letting parts of it survive or die on their own based on
merit; it'd be more effective to just let each framework use (or disuse!)
whatever versions of stuff that work best for it. That's why the software is
broken out into individual components in the first place; we should encourage
diversity in component usage. Instead of trying to legislate and bless some set
of components as a "version", we should just work to make each piece better and
worthwhile to use independently; it's value would be in its actual usefulness
rather than some belief that it works well with the other components in the
"version". Could we at least agree that lockstep versioning of a huge set of
Zope eggs to be shared across many frameworks is not optimal for the long term
and that it would be better if each framework could pick and choose whatever
components and versions it actually needed? Could we also agree that this would
tend to result in better dependency partitioning ("X depends on Y, I don't need
Y, I just need X, let's fix that")?
- C
Martijn Faassen wrote:
> Hi there,
>
> I thought I should highlight this characterization of the Zope project
> because I agree with much of it but also disagree with much of it.
>
> Chris McDonough wrote:
>> I have no faith whatsoever that staying on the course we've been on for the
>> last
>> 9 years (
>
> 9 years is a long time, and while I agree that some cultural
> deficiencies (bad presentation) have lasted a very long time without
> much awareness of them, other deficiencies we're aware of and we're
> making progress on.
>
>> large interconnected codebase,
>
> You might've noticed a certain effort back in 2007 to split up our large
> interconnected codebase into small components, and efforts over time to
> try to break the connections in this code base. I think we could've been
> further along the breaking connections if we'd have some people with an
> overview of what's going on and an active interesting in driving that
> effort forward.
>
> Anyway, this is a characterization of where Zope technology is now, but
> it's a mischaracterization if you think that's where it wants to be or
> that no effort was spent on improving the situation.
>
>> backwards compatibility at all costs,
>
> I agree that have erred on the side of too much backwards compatibility.
> That increased the overhead of changes tremendously and blocked innovation.
>
> That said, I also see a lot of value of having a lot of components that
> can work together, and we do have quite a collection of those in the
> Zope ecosystem. This is why Grok is so careful to stay compatible with
> Zope 3, so we can share that pool of components.
>
> I'm in favor of an evolutionary approach where backwards compatibility
> on occasion is broken and it's clearly documented what developers should
> do to fix things. I'm also in favor of an approach where due to proper
> dependency factoring we can dump whole chunks of code (in particular ZMI
> chunks) in a large step.
>
>> lack of any consumable documentation at a package level,
>
> I agree that most package-level documentation could be improved
> tremendously by focusing on writing real documentation instead of
> half-test stuff.
>
> That said, we also have a tremendous level of package-level
> documentation and interface documentation, and it's a
> mischaracterization of the values of the Zope project to say we haven't
> cared about documentation at all. We innovated with interface-level
> documentation and doctests and making those available on PyPI. You've
> said in the past that this is a sort of "false optimum" that stops
> people from really fixing documentation issues, and I agree.
>
> We should make an effort to change our culture and redirect our
> documentation efforts to go beyo
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote: > Chris McDonough wrote: > >> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. > > Note that the "scolding" had something to do with you breaking Plone > trunk due to a transitive change in Chameleon, and the realisation that > from this point on, any package shared between repoze.bfg and Plone (or > anything else) that is configured with ZCML, will probably need to be > forked. We found a workaround with Chameleon, but not one that will scale. The fix is totally scalable and completely correct. Chameleon.zpt just does not have any (real) ZCML anymore. Any package that has ZCML is, by definition, written for some framework as stuff that is meant to be overridden, otherwise it wouldn't be written as configuration. ZCML is unlike code in this way. If it wasn't meant to be overridden, it would be in code. All packages which are meant to be maximally useful outside the scope of that framework should be split into two things: the library portion, then some portion that contains ZCML for gluing in to some framework that wants ZCML in some specific configuration. So currently a glue package (five.pt) contains the ZCML that makes Chameleon work under Plone. All we did was remove the ZCML from chameleon.zpt itself and make some other package responsible for configuring the CA components used by chameleon.zpt. Frameworks that don't use ZCML don't even need to do this; they just import stuff. > The other cause for frustration was that you'd basically discounted all > possibility of doing this at the zope.component level (and thus letting > others benefit - Zope 2, Five and Plone needs rid of the zope.security > dependency too) before you'd even tried. However, I didn't know then > quite how disillusioned you were with Zope, or that you were quite so > willing to maintain forks/spin-offs/re-implementations under the Repoze > brand. How is the current situation where chameleon.zpt just has no ZCML not 100% exactly the right thing? And again, why can't Plone and Zope 2 just use repoze.zcml in reality? Why would this not work? I just don't understand. >>> And you think it's all due to the brand... >> Yes! Someone who *wants* to use basic ZCML directives but doesn't want >> zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and >> pytz can *already* use repoze.zcml; the only thing they don't get here is >> the brand. > > At least when the change was made to Chameleon, it caused > incompatibilities that basically broke another application using > zope.component's versions of these directives. I'm sure those could be > resolved (and were, with a workaround, in Chameleon), but it caused a > fair bit of pain. How could it have? The only difference was that the package stopped including the two ZCML utility declarations and you had to configure them independently. That was hard? What promises could possibly have been made to Plone that those declarations would exist exactly in the place they were previously until the end of time? If working around that particular problem was at all hard, or caused any pain, we've got huge problems because people *completely* misunderstand the purpose of ZCML and configuration in general. > But more importantly, there are lots of people using Zope the platform, > who have the same types of problems. For Zope 2 or Five or Plone to > switch wholesale to repoze.zcml is probably going to be impossible, for > documentation-related, practical and technical reasons. Sounds pretty handwavy. I am particularly suspect of these practical reasons; they just don't need to exist. I suspect my only crime here is that I didn't do it "the way its done" (nicely, with lots of maillist chatter, over the course of weeks); if I had, the outcome would have been the same: a package that offered ZCML component registration handlers that doesn't rely on zope.security. It might have been named "zope.foo" rather than "repoze.foo". But the outcome would have been exactly the same. There is no way to change zope.component and get both b/w compat and no dependence on zope.security. This is still true. Note that there's some misguided idea that repoze.zcml has "magic" in it for dealing with multiregistries and WSGI or somesuch; this is not true. It knows nothing of either; all it does is implement "utility", "adapter", and the "subscriber" directives without security-related attributes. > By forking > without attempting to solve the problem at the framework level, the > chance for collaboration and shared effort is lost. There is no loss here. At very worst, if folks are unwilling to actually just *use* the package, there is a blueprint for some merge into zope.component that does not require security stuff. Once there's enough political will to actually *do* the merge, and tell the people who want the security stuff that they'll need to lose (or at least change code), putting the code in is cutnpaste.
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Gary Poster wrote: > > We do have this system today. > > > > http://zope3.afpy.org/buildbot/waterfall > > Wow, great. > > Too bad about the failures. How are you announcing the failures ATM? No, maybe someone can provide that service? ;-) BTW, I have decided not to go after the failures until after PyCon, since I think a lot will be happening there. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Gary Poster wrote: > FWIW, the only polish I'd love to see is static pages for past dev > releases (or did I miss them?) Well, it is a matter of version numbering, but all versions that have a unique version number are listed here: http://download.zope.org/zope3.4/ We have not yet started giving Zope 3.5 dev releases unique numbers: http://download.zope.org/zope3.5/ Maybe we should make it a policy to name the releases Zope3.5dev1, Zope3.5dev2, etc. This would make it easier to identify failures of particular versions. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 10:57 AM, Stephan Richter wrote: > On Tuesday 03 March 2009, Gary Poster wrote: >> My mild counter proposal was this. >> >> - The ZF formally institutes an easy way for people to start "Zope" >> projects >> >> - Hopefully, Martijn F. starts something like the project he >> described >> >> - Hopefully, people follow it. >> >> In other words, I suppose, Just Do It. > > Actually Martijn tried to be better than that. :-) Instead of just > forming a > steering group (which I would interpret as a Zope project) and > announcing it > to the community, he asked for feedback first. :-) :-) Yes, that is better. > I probably agree he should have just done it by gathering the > various release > managers. BTW, in one of my original responses, I proposed to > Martijn that > the steering group should be mostly the release managers plus one or > two > strong developers so that the group reaches an odd number. Now that he's proposed it, hopefully he does it, without 100% buy-in, as I just wrote to Martijn. >> Beyond that, I didn't say my other smaller thought, which was that I >> think the KGS should ideally be looser and more flexible than what >> Martijn described. If you have a project that wants in on the KGS, >> great, you can add it. > > That is the case right now and I think a steering group would be > pretty open > to additions. > > However, I think Martijn made a much more important point. What he > wants, if I > understood him correctly, is more of an organization around a > hierarchy of > KGSs. OK. > The reason for this is that Zope/Plone, grok, and Zope 3 AS all > share a > common core and maybe a coreplus set. Then each sub-project > maintains a KGS > on top of that with their specific extensions. > > (1) This will make interoperability much easier, since I could > potentially use > grok X.Y in Zope 2.Z without worrying about version conflicts. > > (2) If the steering group contains all of the release managers, then > releases > can be synced effectively. > >> Institute a "nightly" KGS for an upcoming >> release (and maybe the most recent release). > > We do have this system today. > > http://zope3.afpy.org/buildbot/waterfall Wow, great. Too bad about the failures. How are you announcing the failures ATM? >> It stays around forever >> at a specific URL. Include only the projects whose tests pass in the >> nightly KGS. Have a list elsewhere of the ones for which the tests >> fail. If the tests don't pass for some period of time, apparently >> the >> maintainers and users don't exist or don't care, and they get taken >> off the list to be tested. > > That statement is a massive over-simplification of what's going > on. ;-) Heh, well, that's not exactly a surprise. :-) > There > are several problems: > > (1) Tests that pass in isolation might not pass in a complete run. > This might > be due to this or another packages incomplete teardown. (Several > people spent > weeks getting this right for the 3.4 KGS.) > > (2) A new release of one package might break 5 others. Who is > responsible for > updating the 5 breaking packages. The author that just released the > new > package or the ones from the 5 others? What if those other packages > do not > have clear, single maintainers (e.g. zope.*)? > > I am not making up these cases. They are real and they exist today. I know you are correct. I've experienced very similar things myself. > The idea > that one package has 1 or more concrete and devoted authors is > simply not > real in the Zope world of 200+ packages. Sure. There certainly are stakeholders who are willing to invest on this, particularly on core packages (where "core" differs for the stakeholders). >> The "Zope Framework" team leader then >> decides some time to make a release, so people might shuffle around >> versions more than usual, but it's just another KGS. > > Yep, this is basically what happens today. For example, at Keas we use > different versions (even trunk) of at least 20 packages. The point > is that > people have a stable point to start with. I think that would not > change. Great. (And thank you, this is much farther along than the last time I looked.) FWIW, the only polish I'd love to see is static pages for past dev releases (or did I miss them?) Thanks, Gary ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 12:31 PM, Martijn Faassen wrote: > Hey Gary, > > [panarchist approach where we have people starting groups that could > compete for attention] [Had to look up panarchist, but yes, essentially.] > I agree that it should be relatively easy to start "Zope" projects > under > the Zope umbrella. > > I agree that such projects could compete for attention and may the > best > one win. > > I think this is what's more or less already happening anyway, and I > think it's great and it makes me appreciative of open source and > Zope's > component oriented culture that makes it possible. > > We can't just fork everything and branch off into our direction > everywhere however; these projects will share a common codebase. I am very much in favor of someone having this perspective, and acting on it. ;-) > This common codebase needs to be managed and have a direction, > taking as > inputs the needs of the projects using them. We don't have an umbrella project (e.g., grok, repoze) with this goal. I think your statements and mine mesh well enough. If you don't agree, that's fine. Practically, it means I support what you are trying to do (and in fact I would tend towards your camp in my proposed panarchy), if from a slightly different perspective. > > Gary Poster wrote: >> Moreover, if you are willing to step up and declare that you are >> starting something called the "Zope Framework" that manages a known >> good set of code, and you hope other projects and people join in and >> help, that makes sense to me. > > The open source mantra: "those who take responsibility get > responsibility" Yup. > I agree very much with that. > > It might be we are able to establish a "framework team" without > elections by just picking out the bunch of people who are interested > in > this. Of course if we have a significant fraction of our community who > disagrees with the authority to make decisions for larger changes in > these components, we still have a problem. Two diverging branches of > the > same package doesn't seem to be a maintainable situation; at some > point > someone is going to make a release with a single version number. > > That's why I don't think I or anyone else can just "do it" without > reaching a bit of wider consensus first. I think we have a transition > problem to get from where we are now, where everybody and nobody is > recognized, to a generally recognized group with some authority to > make > decisions where needed and provide guidance that should be taken into > account. Sure. I'm glad you sent your proposal email first. Now that you have, I hope you pursue your vision without needing 100% buy-in from the community. I'm optimistic that you will. :-) Gary >> With what I've seen on the Grok list, >> you can do a great job as a project leader, generally being positive, >> open, and motivating. > > Thanks! I have my flaws, but I try to be aware of them. :) Yup, same here. Gary ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > Okay, I guess we do differ here. I think a leader can provide > encouragement and stimulate people into action, point out interesting > outstanding tasks, and make sure that people who are motivated actually > get grip on improving the project and don't get discouraged. Of course > all these things only happen *some* of the time. It's hardly magic. But > it does contribute in my experience. A good example of this working well, is the role Martijn plays on the Grok list. He collates things that need doing, spells them out, and asks for volunteers. Sometimes that's all it takes. He also provides some degree of authority to make conversations productive. I remember being slapped down rather well over the Grok website at one point, for example. :) And if we are to beat the website analogy again (I really shouldn't...), then having that leadership probably allowed Grok to create a website with content, whereas the equivalent (and parallel) Zope effort died because no-one felt particularly obliged to answer a "cold call" for volunteers. There's more to leadership than that, but I think it's a useful comparison. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: > Different participants will report differently about the success, no > doubt. One unexpected outcome (for some) was classifying the > "decisions" taken at the PSPS as "advisory", "just talk", etc: having > no force in governing the more "tactical" decisions. I don't know why this should be surprising. Things only happen in open source when people do them. A deliberately limited cross-section of the Plone community (not all core developers were even invited, and more than half of the people there were not core developers at all, but included integrators, end users and businesses) could in no way make binding decisions "offline" in the space of two days, and somehow impose them on the other people who would actually have to do the work. We did achieve what we wanted though: We discussed a lot of pain points and clarified a lot of things that people had been arriving at independently, but not quite expressed. We created a lot of consensus around things we wanted to focus on. That consensus helps us develop new versions of Plone. >> (though I did hear positive news about it). I do have the >> impression the framework team strategy works reasonably well; it's been >> operating for about 2 releases now? > > It works as a way of sharing the load with the release manager. Because > its members don't feel empowered to make longer-term decisions, I don't > think it quite fits the model you have proposed for a steering group. No, it doesn't, any apologies for jumping in with this and perhaps making it sound more "same" than it was. I think it's a useful example of how to *organise* such a thing, even if the exact tasks may be a little bit different. > In effect, Hanno Schlicting is doing the "long-term" direction setting > as the Plone4 release manager: Limi is basically cheering him on. I don't think it's quite as simple as that. The release manager has some veto rights and a loud voice, because he is tasked with thinking about how these things fit together. He doesn't get to wear a dictator hat. The discourse on the plone-dev list (and conferences and sprints and IRC) is setting the long-term direction, as a product of the community. I think perhaps Plone has a better structure (release manager, framework team, Foundation) through which that discourse is channelled, in order to build consensus and, perhaps, make for some more productive discussions, than what we sometimes see on this list. In my experience, having the right amount of structure (be that in a team, or a company, or a community) makes it easier to be productive and constructive. Maritjn's proposal addresses some of Zope's challenges by adding some structure where there is currently a void. > Here is where I think we differ: I can't imagine the group you are > sketching out having much of *any* impact on day-to-day stuff. In > particular, I don't believe that a BDFL (whether an individual or a > group) "channels" energies: mostly, the BDFL serves as a "court of > final appeal" when the developers can't reach consensus. I think a good BDFL prods people into reaching consensus before it ever comes to that point. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: > Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. Note that the "scolding" had something to do with you breaking Plone trunk due to a transitive change in Chameleon, and the realisation that from this point on, any package shared between repoze.bfg and Plone (or anything else) that is configured with ZCML, will probably need to be forked. We found a workaround with Chameleon, but not one that will scale. The other cause for frustration was that you'd basically discounted all possibility of doing this at the zope.component level (and thus letting others benefit - Zope 2, Five and Plone needs rid of the zope.security dependency too) before you'd even tried. However, I didn't know then quite how disillusioned you were with Zope, or that you were quite so willing to maintain forks/spin-offs/re-implementations under the Repoze brand. > I also mentioned "or anyone else" above; the point is just to reduce > inappropriate dependencies. Inappropriate dependencies still remain in > zope.component's implementation of these ZCML directives. These inappropriate > dependencies are shed when you want ZCML and you use repoze.zcml. Fine, Grok > may not need it because it just doesn't care about ZCML at all; but other > people > who want to use ZCML without the other kitchen sinkness do. I think you'd be hard pressed to find anyone on this list who disagrees with that statement. ;) >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. At least when the change was made to Chameleon, it caused incompatibilities that basically broke another application using zope.component's versions of these directives. I'm sure those could be resolved (and were, with a workaround, in Chameleon), but it caused a fair bit of pain. But more importantly, there are lots of people using Zope the platform, who have the same types of problems. For Zope 2 or Five or Plone to switch wholesale to repoze.zcml is probably going to be impossible, for documentation-related, practical and technical reasons. By forking without attempting to solve the problem at the framework level, the chance for collaboration and shared effort is lost. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > It might be we are able to establish a "framework team" without > elections by just picking out the bunch of people who are interested in > this. That's been the Plone approach to creating the "framework team". Some people just decided to do it and didn't even bothered to ask publicly on any mailing list. If you want to mimic the Plone approach you do: Martijn, Stephan and Andreas form the "Zope Framework" team. They decide by themselves if they should take on exactly two more people or not. If one of the three doesn't want to do it, the other two find someone else. Their only task is to release version 1 of the "Zope Framework" by this summer. It's primary concern is to serve as a common stable ground for Zope 2.12, Zope 3.5 and the next Grok version. As part of such a release they get the power of deciding what packages are part of the release and which versions of them. They are responsible for taking care of proper release procedure and documentation of the release. If they cannot encourage people to help them, the shitty work is on them. And that's it. Obviously you get to do some decisions which are really about strategies beyond the release, but you can only execute them in the limited scope of the one release. By the end of it, you look at what you got, find some new people (with some overlap to the old team) to steer on the next version of the Zope Framework and see how it goes. You don't try to organize all of Zope at once, but claim your own little field. If everything goes well, you established communications between three large communities and they have a way of discussing changes based on their technical merit. Maybe "Zope Framework" version 2 brings even further reduced dependencies and ditches the publisher for a real WSGI story. But that's not the discussion right now. You can try to bake more leadership of the overall Zope community into this, but I think this is a fruitless fight right now. Reduce the scope, try make some things better and don't step on other peoples feet if you don't need to. For example don't try to push out style-guides for the entirety of the svn.zope.org repository. They lead to bike-shed discussions and discourage contributions. Hanno ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, I thought I should highlight this characterization of the Zope project because I agree with much of it but also disagree with much of it. Chris McDonough wrote: > I have no faith whatsoever that staying on the course we've been on for the > last > 9 years ( 9 years is a long time, and while I agree that some cultural deficiencies (bad presentation) have lasted a very long time without much awareness of them, other deficiencies we're aware of and we're making progress on. > large interconnected codebase, You might've noticed a certain effort back in 2007 to split up our large interconnected codebase into small components, and efforts over time to try to break the connections in this code base. I think we could've been further along the breaking connections if we'd have some people with an overview of what's going on and an active interesting in driving that effort forward. Anyway, this is a characterization of where Zope technology is now, but it's a mischaracterization if you think that's where it wants to be or that no effort was spent on improving the situation. > backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. That said, I also see a lot of value of having a lot of components that can work together, and we do have quite a collection of those in the Zope ecosystem. This is why Grok is so careful to stay compatible with Zope 3, so we can share that pool of components. I'm in favor of an evolutionary approach where backwards compatibility on occasion is broken and it's clearly documented what developers should do to fix things. I'm also in favor of an approach where due to proper dependency factoring we can dump whole chunks of code (in particular ZMI chunks) in a large step. > lack of any consumable documentation at a package level, I agree that most package-level documentation could be improved tremendously by focusing on writing real documentation instead of half-test stuff. That said, we also have a tremendous level of package-level documentation and interface documentation, and it's a mischaracterization of the values of the Zope project to say we haven't cared about documentation at all. We innovated with interface-level documentation and doctests and making those available on PyPI. You've said in the past that this is a sort of "false optimum" that stops people from really fixing documentation issues, and I agree. We should make an effort to change our culture and redirect our documentation efforts to go beyond doctests. I'll also note that documentation for the whole *system* has traditionally been lacking (how to get started, install it?). I know you don't like the whole Zope 3 system anyway, but it's also something I think we could improve (and we've been doing so for Grok). > not much curiosity about how other Python web frameworks work, I'm not sure whether this characterization is accurate or not. Because Zope was there sooner than many other Python web frameworks, it's probably partially true we've ignored the competition. I've personally been quite interested in seeing how the cultures surrounding other web frameworks work and trying to adopt lessons from this. I've also played with some other web frameworks and used TurboGears 1 for real work, but not as much as I should, perhaps. I've been able to apply the things I've learned from other web frameworks far better in the context of Grok than I have been in the context of the wider Zope community, and I wish that would change. > not much real cooperation with folks that maintain other Python web > frameworks, What is "real cooperation"? It's hard to judge this one, though we can definitely do better. I'd note that the culture of cooperation between other Python web frameworks has started really taking off surrounding WSGI, and we've been trying to make use of this technology but haven't had the full benefits yet. Anyway, it's hard to say how much of a goal "real cooperation" should be for our community. I think we should do our best to integrate other technology in our own stuff, and we've had some progress with things like WSGI, Twisted and SQLAlchemy. Maybe Repoze is next, but I hear they think very badly of us indeed. :) > a constitutional inability to attract new users I share that concern very much. It's good that the Zope technology is so central to other projects which do attract new users so we still have at least some influx here. Part of the reason is our lack of attention to documentation, proper web presentation, and our "here's a giant toolbox, you figure it out" approach. I'm not sure how the collection of libraries I dubbed the Zope Framework would operate in this regard. Individual libraries should present themselves to attract new users. At the same time the larger collection (the ball of 70somethin
Re: [Zope-dev] the Zope Framework project
Hi there, Chris, I think you are misunderstanding my position quite dramatically. Perhaps you should calm down and reconsider what I've been saying, as I believe we're a lot closer than you seem to think. On Tue, Mar 3, 2009 at 8:42 PM, Chris McDonough wrote: [snip] >> I'd rather have one underlying action API that did the minimal but right >> thing in zope.component that grokcore.component and repoze.zcml and the >> Zope Framework (with its additional requirements for security) can all >> build on. > > Why does it *have* to be in zope.component? What magic does this name imply? It doesn't, but it should then be *removed* from zope.component into some other package (which could be repoze.zcml for all I care). I don't want there to be a duplicate implementation laying around and I'd like there to be a clean dependency structure. At the same time, directives need to exist that are compatible with the Zope Framework. It'd be nice if there wasn't a duplicate implementation of their actions. [snip] >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. Yes, why are you explaining this to me? For a year now people could use grokcore.component, where they could register their objects without pulling in those dependencies as well, and not having to deal with a lot of ZCML either. > Why should we punish the folks who are already using the zope.component > directives with security in them by changing them in order to service some > goal > of fidelity with brand? Who cares what it's called? I'm not talking about the fidelity of the brand. If you use repoze.zcml or grokcore.component today you'll use two implementations of the actions and in the case of repoze.zcml, two implementations of the ZCML directives. Granted those are very minimal in grokcore.component and mostly the registration functions themselves. But repoze.zcml contains wisdom about certain WSGI situations that grokcore.component and zope.component don't have. What I'd like to do is consolidate all that wisdom about how things should be registered in *one* place (I don't care what it's called, and it *could* be zope.component or repoze.zcml) and then build grokcore.component, repoze.zcml and Zope 3 on top of this. That way they all share the same underlying technique, including your multi-app support. It appears to be the coordination overhead required seems to make this impossible. Even you who should have an interest in not carrying in the ZCML implementations in zope.component as they're duplicating and possibly confusing users of repoze.zcml seem not to agree that it'd be nicer. [snip] > I don't know what's so hard to understand about this: not everyone wants to > use > the ~78 packages that currently make up "the Zope framework". This is the > entire point of what I'm saying. Very few people will never care about "the > Zope Framework" in entirety, if it's defined as you define it above. I'm talking about zope.component here, and you don't seem to want to change that either. I'm trying to see the big picture of the different users of this package and think about ways to arrange it so that it'd be better. Less redundant code, more shared code. You don't seem to be interested in that, because to you the problem is already solved. I understand that, but I also don't understand your resistance. > 99% of people in the Python community *dont use anything related to Zope* and > *WILL NEVER USE ANYTHING FROM IT IF IT'S ALWAYS A BALL OF 78, 60, OR EVEN 10 > PACKAGES*. If you're defining "everyone" in your sentence above as "everyone > who already uses Zope", I believe that is incredibly short sighted. We could > do > so much more if we ditched the notion that the big glob of packages you're > trying to recast as "The Zope Framework" is of more value as a glob than as > individual packages that any Python programmer could use. Please don't yell at me. I don't take the position that you think I am. You're telling me things I already agree with. Why do you think I care so much about clean dependencies in the Zope Framework? Because I want people to be able to enter the Zope Framework at any point in the tree. People who don't care about the rest. Because I want the tree to be simpler so that Grok uses less of it and I can understand more of it. But that takes coordinated effort as we do have people using the entire tree and we don't want to leave those with a broken system. I'm taking both perspectives at the same time. I don't think they're mutually incompatible. You're doing this thing called Repoze. That's a lot of packages and presumably they share a few philosophies and you make sure they tend to work together. At the same time people can pick up on individual packages. Why can't we have somethi
Re: [Zope-dev] the Zope Framework project
On 3/3/09 2:42 PM, Chris McDonough wrote: > Martijn Faassen wrote: >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. If we change the word "brand" to "megaframework", things might become clearer. Grok makes framework decisions based on getting value from the Zope 3 platform. "So what if our configuration language sucks in zope.location and pytz, we needed it anyway in our megaframework!" This view likely represents the (indeterminately sized) population of Zope insiders. Repoze doesn't have fidelity to the Zope 3 megaframework as its goal. "I asked for a configuration parser and you sucked in a security model, WTF!!" As such, Repoze probably wants something more like Zope-the-library than Zope-the-megaframework. This view likely represents the (indeterminately sized) population of Zope skeptics. Which group wins when there's a tie in the Zope Framework? It will be interesting to see. I think there's also a point about the "brand" related to how diluted the word "Zope" has become, but that is a second point to the megaframework/platform discussion. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > Hi there, > > Chris McDonough wrote: >> Martijn Faassen wrote: >>> Martin Aspeli wrote: >>> [snip] You and I had a discussion a while back about forking the zope.component ZCML directives, and how it would've been better to work within the boundaries of the Zope packages so that everyone who wanted to lose the zope.security dependency could benefit, rather than fork this and all other configuration that depends on the core ZCML directives. >> As I remember it, you scolded me about doing it, then when I did it anyway, >> it >> worked its way over to the Grok list, where any alternate idea other than a >> plain fork died on the vine. That's what I figured was going to happen, so >> I'm >> glad I actually took action. > > Huh? Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. > We need a refactored zope.component for the Grok project as well. > Why did it die on the vine? Perhaps if someone had been integrating > these experiences and requirements properly on zope-dev it'd have > transformed into positive improvements in zope.component itself by now. AFACIT, you (meaning Faassen) wanted to focus on lower-hanging fruit at the time: http://mail.zope.org/pipermail/grok-dev/2008-December/006946.html (which I believe was totally reasonable). > [snip] >> Frankly, I don't care that I had to create alternative ZCML directives. This >> was, and is, and always will have been, the right thing to do. In fact, the >> only thing preventing Grok or anyone else from using the stuff created out of >> that effort wholesale (repoze.zcml) is the *brand*. > > That's incorrect. We already have an implementation of alternate > directive (aka grokkers) to register the zope.component components in > grokcore.component, and have had them for much longer than you did. > > Adding a *third* way to configure components, i.e. repoze.zcml, to the > mix is hardly going to improve matters for Grok. It's useless anyway as > we need to support the zope.component[ZCML] way anyway for ZCML, and > support grokcore.component for code that does it the Grok way. I also mentioned "or anyone else" above; the point is just to reduce inappropriate dependencies. Inappropriate dependencies still remain in zope.component's implementation of these ZCML directives. These inappropriate dependencies are shed when you want ZCML and you use repoze.zcml. Fine, Grok may not need it because it just doesn't care about ZCML at all; but other people who want to use ZCML without the other kitchen sinkness do. > I'd rather have one underlying action API that did the minimal but right > thing in zope.component that grokcore.component and repoze.zcml and the > Zope Framework (with its additional requirements for security) can all > build on. Why does it *have* to be in zope.component? What magic does this name imply? > Switching over to repoze.zcml would only gain Grok *more* code and a > harder to comprehend situation. Maybe *Grok* doesn't need it, but given that an application needs some ZCML to kick off the loading of components, and given that this ZCML needs to include one of the "utility", "adapter" or "subscriber" directives, *eventually* you could ditch zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and pytz by using repoze.zcml directives instead of the ones built in to zope.component. Here's an example of a non-Zope application that might make use of such a package: http://plope.com/Members/chrism/pluginizing_an_app > And you think it's all due to the brand... Yes! Someone who *wants* to use basic ZCML directives but doesn't want zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and pytz can *already* use repoze.zcml; the only thing they don't get here is the brand. Why should we punish the folks who are already using the zope.component directives with security in them by changing them in order to service some goal of fidelity with brand? Who cares what it's called? >> I don't care about >> Zope-the-brand anymore, I just care about Zope-the-technologies. Why would >> the >> fact that this more reasonable set of directives is not named Zope anymore >> matter? What about that whole situation was not a win? > > I already spelled out the above on the grok-dev mailing list before, but > you didn't seem to pick up on my explanation. I guess not. >>> When I brought up the issue of trying to improve zope.component >>> recently, I got a lot of divergent feedback and nothing happened. It'd >>> be nice if instead such energy instead resulted in a concrete set of >>> actions. >> I didn't participate because I had already scratched that particular itch. I >> created something that *everyone* can use; it might not be named Zope, so be >> it. > > I pointed out above why it'd be not very useful for Grok to use it. In > fact you created something that is redundant if you use the rest of the > Z
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 19:09, Tres Seaver wrote: > Different participants will report differently about the success, no > doubt. One unexpected outcome (for some) was classifying the > "decisions" taken at the PSPS as "advisory", "just talk", etc: having > no force in governing the more "tactical" decisions. I don't remember us actually doing any "tactical decisions". There was discussions, and to a large part consensus about these, but not actual decisions. The end result of the PSPS was a bunch of actions, entered into the bugtracker, and people assigned to them. These were sometime connected to tactical decisions, but not decisions per se. I may misremember, but in any case, this to me seems (in retrospect) as a good idea, as complaints at that time was raised that it wasn't inclusive enough, which would have been a problem if it really was a decision making meeting. Instead it functioned as a way to get the contributors focused and if not on the same page then at least in the same book, and get energy into the group. As such, I thought it was a success. And fun. And I learnt a cool way to run meetings. :) I do think that this, together with day-to-day release teams is a good working solution we should try for Zope too. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
On 3 Mar 2009, at 18:25, Martijn Faassen wrote: > Ah, so Plone currently has long term direction as they think 2 > releases > ahead of just one? Plone 4 discussions are happening around now, there are demos of suggested concepts and people generally working on the codebase. Plone 5 is a long way off, but we have some ideas, for example Hanno has already suggested it should target Python 3.x. 2 major releases in the Plone world is about 3/4 years. Matt (Proud Plone 4 Framework team member, ftr) ___ 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 )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: [snip] >> (though I did hear positive news about it). I do have the >> impression the framework team strategy works reasonably well; it's been >> operating for about 2 releases now? > It works as a way of sharing the load with the release manager. Because > its members don't feel empowered to make longer-term decisions, I don't > think it quite fits the model you have proposed for a steering group. Okay, that's interesting. Undoubtedly some ideas about long term direction sneak into a framework team to guide them with decision making, but it's not exactly the same model indeed. >> So you have one mechanism to set long term directions (and I think >> another one, namely Alexander Limi), and another to execute these long >> term directions and make smaller decisions in the light of them. > > In effect, Hanno Schlicting is doing the "long-term" direction setting > as the Plone4 release manager: Limi is basically cheering him on. Ah, so Plone currently has long term direction as they think 2 releases ahead of just one? I guess my proposed Steering Group would take on some of the aspects of both. I think you could set up a Steering Group per release with a bit more mandate to cover long term directions than perhaps the Plone group has. There'll be continuity as some of the membership will carry on to the next release typically. >> In reality of course a lot of micro decisions can result in a long term >> direction, so there's a gray area there. >> >> For the Zope Framework I think it's more important to get the day to day >> decision making working in our community than it is to do the long term >> setting of directions and planning. We do have some form of long term >> direction emerging that we can recognize often enough (though we can do >> a lot better still). The core problem in my mind is the day to day >> decision making and channeling of energies. > > Here is where I think we differ: I can't imagine the group you are > sketching out having much of *any* impact on day-to-day stuff. In > particular, I don't believe that a BDFL (whether an individual or a > group) "channels" energies: mostly, the BDFL serves as a "court of > final appeal" when the developers can't reach consensus. Okay, I guess we do differ here. I think a leader can provide encouragement and stimulate people into action, point out interesting outstanding tasks, and make sure that people who are motivated actually get grip on improving the project and don't get discouraged. Of course all these things only happen *some* of the time. It's hardly magic. But it does contribute in my experience. >> I myself am inclined, for the Zope Framework, to start with the day to >> day team. I think it can deduce at least some long term directions from >> the community on the mailing list and usage in practice (also by >> consultation). We could amend such a process with a strategic planning >> summit construction, later. > > If the team you are talking about is going to manage a "root KGS", or > something, from which Zope2, Zope3, Grok, etc. derive their own > versions, then it seems to me that success lies in keeping that KGS > smaller than larger, and focused mostly on the "libraryin" bits. > Expanding the core KGS later will be lots easier than shrinking it. I agree the end product should be smaller rather than larger and more library-like. But it should also be concerned with turning a larger set of libraries into better libraries. Imagine we had defined the KGS to contain zope.* and not zope.app.* back in december 2008. It wouldn't have had a container implementation, which I think is an interesting piece of shared technology. If we did it today we'd have had zope.container. That's why I think it should start inclusive and then focus heavily on turning it into a better set of libraries. In my mind such a "turn it into a better collection of libraries" is one of the most important long-term activities for the framework developers. I think that's something everybody can be on board about. In the end it's a tree of packages where people should be able to participate at any node, but I do think we need to keep an overview of the tree as well. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Chris McDonough wrote: > Martijn Faassen wrote: >> Martin Aspeli wrote: >> [snip] >>> You and I had a discussion a while back about forking the zope.component >>> ZCML directives, and how it would've been better to work within the >>> boundaries of the Zope packages so that everyone who wanted to lose the >>> zope.security dependency could benefit, rather than fork this and all >>> other configuration that depends on the core ZCML directives. > > As I remember it, you scolded me about doing it, then when I did it anyway, it > worked its way over to the Grok list, where any alternate idea other than a > plain fork died on the vine. That's what I figured was going to happen, so > I'm > glad I actually took action. Huh? We need a refactored zope.component for the Grok project as well. Why did it die on the vine? Perhaps if someone had been integrating these experiences and requirements properly on zope-dev it'd have transformed into positive improvements in zope.component itself by now. [snip] > Frankly, I don't care that I had to create alternative ZCML directives. This > was, and is, and always will have been, the right thing to do. In fact, the > only thing preventing Grok or anyone else from using the stuff created out of > that effort wholesale (repoze.zcml) is the *brand*. That's incorrect. We already have an implementation of alternate directive (aka grokkers) to register the zope.component components in grokcore.component, and have had them for much longer than you did. Adding a *third* way to configure components, i.e. repoze.zcml, to the mix is hardly going to improve matters for Grok. It's useless anyway as we need to support the zope.component[ZCML] way anyway for ZCML, and support grokcore.component for code that does it the Grok way. I'd rather have one underlying action API that did the minimal but right thing in zope.component that grokcore.component and repoze.zcml and the Zope Framework (with its additional requirements for security) can all build on. Switching over to repoze.zcml would only gain Grok *more* code and a harder to comprehend situation. And you think it's all due to the brand... > I don't care about > Zope-the-brand anymore, I just care about Zope-the-technologies. Why would > the > fact that this more reasonable set of directives is not named Zope anymore > matter? What about that whole situation was not a win? I already spelled out the above on the grok-dev mailing list before, but you didn't seem to pick up on my explanation. >> When I brought up the issue of trying to improve zope.component >> recently, I got a lot of divergent feedback and nothing happened. It'd >> be nice if instead such energy instead resulted in a concrete set of >> actions. > > I didn't participate because I had already scratched that particular itch. I > created something that *everyone* can use; it might not be named Zope, so be > it. I pointed out above why it'd be not very useful for Grok to use it. In fact you created something that is redundant if you use the rest of the Zope Framework as well (or even just zope.component[zcml]). It isn't something that *everybody* can use just like that. Forking is one way to solve the problem and forget about it, if you don't care about compatibility with the Zope Framework. That's fine. It's something you have the freedom to do of course and undoubtedly you are much happier with it. It's also unfortunate for me, as your improvements are not making in into the shared component. So while the problem is solved for you, it isn't solved for me. Grok has different goals concerning compatibility with the Zope Framework, and therefore more interest in improving the underlying framework itself. These are different philosophies. You with your philosophy should have no problem with me trying to improve the framework experience though, as you can go off on your own anyway and cooperate on bits of it whenever you want. So I find it frustrating to hear you say "no" so much now. It's fine if you don't care about the "Zope" brand anymore, but I'm still allowed to care about it, right? Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Paul Everitt wrote: >> On 3/2/09 10:13 PM, Martin Aspeli wrote: >>> We recognised that there was a problem in trying to make sure we >>> represented the interests of various stakeholders, and that we needed >>> someone to think "big picture" in terms of what technologies we adopted >>> and how we used them. >> Just to be clear, I believe the Plone framework team has specifically >> disavowed management of Plone's "strategy". Meaning, they approve PLIPs >> on a release-to-release basis. They don't make edicts like "replace >> Archetypes". >> >> This was the vacuum that the "strategic planning summit" advertised >> itself as addressing. >> >> I think this clarification is informative to Martijn's discussion. > > That's interesting indeed. > > It's hard to know whether Plone's method of a "strategic planning > summit" is working on the long term as you only had one as far as I > know. Different participants will report differently about the success, no doubt. One unexpected outcome (for some) was classifying the "decisions" taken at the PSPS as "advisory", "just talk", etc: having no force in governing the more "tactical" decisions. > (though I did hear positive news about it). I do have the > impression the framework team strategy works reasonably well; it's been > operating for about 2 releases now? It works as a way of sharing the load with the release manager. Because its members don't feel empowered to make longer-term decisions, I don't think it quite fits the model you have proposed for a steering group. > So you have one mechanism to set long term directions (and I think > another one, namely Alexander Limi), and another to execute these long > term directions and make smaller decisions in the light of them. In effect, Hanno Schlicting is doing the "long-term" direction setting as the Plone4 release manager: Limi is basically cheering him on. > In reality of course a lot of micro decisions can result in a long term > direction, so there's a gray area there. > > For the Zope Framework I think it's more important to get the day to day > decision making working in our community than it is to do the long term > setting of directions and planning. We do have some form of long term > direction emerging that we can recognize often enough (though we can do > a lot better still). The core problem in my mind is the day to day > decision making and channeling of energies. Here is where I think we differ: I can't imagine the group you are sketching out having much of *any* impact on day-to-day stuff. In particular, I don't believe that a BDFL (whether an individual or a group) "channels" energies: mostly, the BDFL serves as a "court of final appeal" when the developers can't reach consensus. > I myself am inclined, for the Zope Framework, to start with the day to > day team. I think it can deduce at least some long term directions from > the community on the mailing list and usage in practice (also by > consultation). We could amend such a process with a strategic planning > summit construction, later. If the team you are talking about is going to manage a "root KGS", or something, from which Zope2, Zope3, Grok, etc. derive their own versions, then it seems to me that success lies in keeping that KGS smaller than larger, and focused mostly on the "libraryin" bits. Expanding the core KGS later will be lots easier than shrinking it. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrXI/+gerLs4ltQ4RAvf1AKCpRxuSfU6pOzhv5GNCwoOioZwmCwCgsXK/ M7L/DTDqiGyu/lhdBw56e2s= =vnGh -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
Boy, there's no point in trying to outrun this thread, I'd better just jump in here. Martin I think you said that very well and I'm convinced. I appreciate and generally support Martijn's proposal. When in doubt, I'd be in favour of emulating what's been shown to work in the Plone community - eg lightweight per-release teams. I guess a responsive, transparent steering group with slower turnover can also be useful, though. ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hey, Stephan Richter wrote: [snip] > Actually Martijn tried to be better than that. :-) Instead of just forming a > steering group (which I would interpret as a Zope project) and announcing it > to the community, he asked for feedback first. :-) Thanks. :) > I probably agree he should have just done it by gathering the various release > managers. BTW, in one of my original responses, I proposed to Martijn that > the steering group should be mostly the release managers plus one or two > strong developers so that the group reaches an odd number. I'm not convinced such a group could provide the kind of leadership I'm looking for. It'd like something a bit more agile. >> Beyond that, I didn't say my other smaller thought, which was that I >> think the KGS should ideally be looser and more flexible than what >> Martijn described. If you have a project that wants in on the KGS, >> great, you can add it. > > That is the case right now and I think a steering group would be pretty open > to additions. > > However, I think Martijn made a much more important point. What he wants, if > I > understood him correctly, is more of an organization around a hierarchy of > KGSs. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a > common core and maybe a coreplus set. Then each sub-project maintains a KGS > on top of that with their specific extensions. Yes, I think eventually we will end up with a hierarchy of KGSes. I think we still need to delineate what a Steering Group or Framework Team actually has authority over, so that would define the Zope Framework. I think we should start with something quite inclusive there. One of the goals of the project would be to whittle it down to something smaller and more comprehensible. Which in turn might make space for wholesale replacement with newer libraries. Anyway, what is the Zope Framework is determined organically and changes slowly over time. > (1) This will make interoperability much easier, since I could potentially > use > grok X.Y in Zope 2.Z without worrying about version conflicts. I don't think it'll ever be perfect. Grok 1.0x for instance looks like it needs a newer version of zope.publisher than is in the Zope 3.4 KGS in order to function. But the *more* similar these lists are, the better. This common ground brings us community. [snip] > (1) Tests that pass in isolation might not pass in a complete run. And vice versa! We spent quite a bit of time to make tests work in isolation and have compattest infrastructure for it now. > This might > be due to this or another packages incomplete teardown. (Several people spent > weeks getting this right for the 3.4 KGS.) > > (2) A new release of one package might break 5 others. Who is responsible for > updating the 5 breaking packages. The author that just released the new > package or the ones from the 5 others? What if those other packages do not > have clear, single maintainers (e.g. zope.*)? > > I am not making up these cases. They are real and they exist today. The idea > that one package has 1 or more concrete and devoted authors is simply not > real in the Zope world of 200+ packages. Definitely. Changes in one package have repercussions in a huge amount of other packages. When we did dependency refactoring we'd need to reach out to many other packages to update *their* dependencies. Sometimes we couldn't even get the tests to run properly in the original package before doing so, as otherwise the wrong pre-refactored package would be imported from. :) On the other hand we should of course recognize that some of these packages do work in isolation, and move towards a dependency structure and code organization that creates more such "work by themselves" packages. That's what the dependency refactoring project is all about. We need a balance of a good integrated experience and a good stand-alone experience. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hey Gary, [panarchist approach where we have people starting groups that could compete for attention] I agree that it should be relatively easy to start "Zope" projects under the Zope umbrella. I agree that such projects could compete for attention and may the best one win. I think this is what's more or less already happening anyway, and I think it's great and it makes me appreciative of open source and Zope's component oriented culture that makes it possible. We can't just fork everything and branch off into our direction everywhere however; these projects will share a common codebase. This common codebase needs to be managed and have a direction, taking as inputs the needs of the projects using them. Gary Poster wrote: > Moreover, if you are willing to step up and declare that you are > starting something called the "Zope Framework" that manages a known > good set of code, and you hope other projects and people join in and > help, that makes sense to me. The open source mantra: "those who take responsibility get responsibility" I agree very much with that. It might be we are able to establish a "framework team" without elections by just picking out the bunch of people who are interested in this. Of course if we have a significant fraction of our community who disagrees with the authority to make decisions for larger changes in these components, we still have a problem. Two diverging branches of the same package doesn't seem to be a maintainable situation; at some point someone is going to make a release with a single version number. That's why I don't think I or anyone else can just "do it" without reaching a bit of wider consensus first. I think we have a transition problem to get from where we are now, where everybody and nobody is recognized, to a generally recognized group with some authority to make decisions where needed and provide guidance that should be taken into account. > With what I've seen on the Grok list, > you can do a great job as a project leader, generally being positive, > open, and motivating. Thanks! I have my flaws, but I try to be aware of them. :) Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Tuesday 03 March 2009, Tres Seaver wrote: >> Stephan, I *have* managed a large set, and I'm *certain* that the KGS is >> useful for many cases: it just doesn't work for me for any large >> production application: I don't want to rely on the iffy availability >> of eggs from PyPI, for instance, which means that running a separate, >> per-project index is my only recourse anyway. Once you are running your >> own index, it's contents *are* a KGS, just not one managed using the >> 'versions.cfg' machinery. > > Who says that you cannot use your own index with the KGS? Do you think I use > the official PyPI location for production? We use two approaches at Keas: If I'm running my own project-specific index, it *is* the KGS for that project: I don't need to manage versions anyplace else. > (1) Use a PyPI proxy server that caches all needed packages locally. Not an option: I don't let new pacakges, or new versions, into my index without reviewing them first. Typically, this means adding the egg to my sandbox (e.g., via easy_install, or a develop-egg), verifying that it works with the other pacakges, has reasonable tests and docs, and does what I need. Once I'm done with that review, I copy the sdist to my project index, and update the dependencies and / or buildout config to pull it in. > (2) Use zc.sourcerelease so that all packages are part of the big source TAR > ball. I don't need the big tarball, because I have an index: I can just enumerate the eggs I need (e.g., in 'install_requires' or in buildout.cfg) without any versioning at all, and trust that the index will supply the "blessed" versions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrWjU+gerLs4ltQ4RApviAJ9Ul8m8FXzbYV9YK2Mt2ofNs2SfhQCfWLCt E9CK+vzQnGQG7djluyL8cew= =PcE6 -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > Hi there, > > Martin Aspeli wrote: > [snip] >> You and I had a discussion a while back about forking the zope.component >> ZCML directives, and how it would've been better to work within the >> boundaries of the Zope packages so that everyone who wanted to lose the >> zope.security dependency could benefit, rather than fork this and all >> other configuration that depends on the core ZCML directives. As I remember it, you scolded me about doing it, then when I did it anyway, it worked its way over to the Grok list, where any alternate idea other than a plain fork died on the vine. That's what I figured was going to happen, so I'm glad I actually took action. > The main >> reason you had for creating your own package, was the lack of momentum >> (and/or stop energy) encountered when trying to do this in the Zope >> world. If there was someone who could both consider BFG's needs in a >> more objective light, and have the power to actually do something rather >> than just bicker, then maybe we could've gone a different route on that >> one. With more and more dependency untangling happening, I am pretty >> sure this same situation is going to come up again. > > Yes, this is a very good example of why Chris should be in favor of > leadership for the Zope Framework. The Grok project would've appreciated > such improvements right there in zope.component too. Frankly, I don't care that I had to create alternative ZCML directives. This was, and is, and always will have been, the right thing to do. In fact, the only thing preventing Grok or anyone else from using the stuff created out of that effort wholesale (repoze.zcml) is the *brand*. I don't care about Zope-the-brand anymore, I just care about Zope-the-technologies. Why would the fact that this more reasonable set of directives is not named Zope anymore matter? What about that whole situation was not a win? > When I brought up the issue of trying to improve zope.component > recently, I got a lot of divergent feedback and nothing happened. It'd > be nice if instead such energy instead resulted in a concrete set of > actions. I didn't participate because I had already scratched that particular itch. I created something that *everyone* can use; it might not be named Zope, so be it. - C ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 18:20, Martijn Faassen wrote: > I myself am inclined, for the Zope Framework, to start with the day to > day team. I think it can deduce at least some long term directions from > the community on the mailing list and usage in practice (also by > consultation). We could amend such a process with a strategic planning > summit construction, later. Such a day to day group sounds like me as the same thing as a release team, and if so, me and Martijn, as usually, agree comepletely. :) -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > Tres Seaver wrote: > [snip] >> Stephan, I *have* managed a large set, and I'm *certain* that the KGS is >> useful for many cases: it just doesn't work for me for any large >> production application: I don't want to rely on the iffy availability >> of eggs from PyPI, for instance, which means that running a separate, >> per-project index is my only recourse anyway. Once you are running your >> own index, it's contents *are* a KGS, just not one managed using the >> 'versions.cfg' machinery. >> >> That said, I do appreciate the work you have done and are doing to make >> the KGS useful for others. > > Distinguish KGS the concept (a list of locked down versions as > suggestions to users of the framework) from KGS the implementation. > > Let's agree on the *concept* of a locked down list of versions that's > maintained by the community, or in fact more than one such list. Acknowledging the idea that we might have more than one removes the sting for me. > If people want to diverge in the implementation, fine. Different > implementations have different advantages during development and deployment. Yup, or for different "styles" of projects. As a *personal* example: *every* time I try to short-cut the process of setting up a project-specific index representing the KGS *for that project,* I end up getting burned by something. At this point, I don't even think about skipping the index setup, any more than I would skip setting up a VCS repository or mailing lists for the project. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrWeH+gerLs4ltQ4RAoB+AKCL7Hypan2VGvmdQc1XvEMLk/0uPQCeJr1r xXJnto/QQdlLcKozkid74M8= =1g4r -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: > On 3/2/09 10:13 PM, Martin Aspeli wrote: >> We recognised that there was a problem in trying to make sure we >> represented the interests of various stakeholders, and that we needed >> someone to think "big picture" in terms of what technologies we adopted >> and how we used them. > > Just to be clear, I believe the Plone framework team has specifically > disavowed management of Plone's "strategy". Meaning, they approve PLIPs > on a release-to-release basis. They don't make edicts like "replace > Archetypes". > > This was the vacuum that the "strategic planning summit" advertised > itself as addressing. > > I think this clarification is informative to Martijn's discussion. That's interesting indeed. It's hard to know whether Plone's method of a "strategic planning summit" is working on the long term as you only had one as far as I know. (though I did hear positive news about it). I do have the impression the framework team strategy works reasonably well; it's been operating for about 2 releases now? So you have one mechanism to set long term directions (and I think another one, namely Alexander Limi), and another to execute these long term directions and make smaller decisions in the light of them. In reality of course a lot of micro decisions can result in a long term direction, so there's a gray area there. For the Zope Framework I think it's more important to get the day to day decision making working in our community than it is to do the long term setting of directions and planning. We do have some form of long term direction emerging that we can recognize often enough (though we can do a lot better still). The core problem in my mind is the day to day decision making and channeling of energies. I myself am inclined, for the Zope Framework, to start with the day to day team. I think it can deduce at least some long term directions from the community on the mailing list and usage in practice (also by consultation). We could amend such a process with a strategic planning summit construction, later. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: [snip] >> As much as I prefer discussing with people in real life, there is the >> notion of "no backroom conversations" WRT to driving development of an >> open source project. > > OK. *Cough*. You and Martijn wrote this proposal. And you asked > Stephan about it. You did backroom conversations. I wrote the proposal based on conversations I had with Christian and also Jim, and Christian and several others gave input. Backroom work will happen (conversations and decisions both). But it cannot be the only thing that drives the open source project. > Aren't we now saying that to avoid excluding some people, we should > exclude all but a steering group? :-) You have a very different perspective on a Steering Group. It's not a mechanism for exclusion but for *inclusion*. The steering group should care about the different interests in our community and actively balance them and consult them, and channel existing energies allowing them to result in something instead of dissipate. Of course you seem to say this all depends on the people in the steering group and that in practice this won't happen. This is something we'll need to try to find out, right? Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: [snip] >> No. The steering group should not have backroom discussions. They should >> act as open as possible. I think of it as a catalyst. > > The operative here is *should*. Compare that to *will*. These are > different words. What the steering group *should* do and what they > *will* do is not the same thing. Yes, and you're asserting it won't even though it'll be founded with that exact intent. You may be right of course, though I don't think so. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: > 1. Areas that need somebody responsible should get one. We need > somebody to bug people about bugs in the bug tracker. That should be > one person, for example. Responsibilities need to be well defined and > individual. There isn't anybody called Someone here, so if Someone has > to do it, that doesn't get done. Who defines these responsibilities and hands them out? Who reminds people of bits of the project that could use a responsible person to take charge? I'm asking this as I've taken this role for the Grok project, and sometimes my reminding results in volunteers taking responsibility for a bit of the project, whether it's code or documentation or management. Without someone who identifies these responsibilities, there's far less chance of people taking them. > 2. To get things done release-wise, I think it would be good to have a > release-team for each release. And that would reasonable be different > teams for Zope2 and Zope 3, and possibly even for The Zope Framework, > obviously most likely with personnel overlaps. Are you talking about a team like the Plone Framework team that guides development leading *up* to a release (and including it), or are you talking about a team of people who set up the KGS, write release notes and release packages to PyPI? > 3. To steer, and keep the community on track, I think regular meetings > of people in real life will beat any steering group, all hands down. > This would best happen at the same time as a conference, and either > the Plone conference or PyCon or Europython. Whoever shows up will have the say and people not there will just have to put up with it? I think that works to a certain extent in sprints, but we are an internet based open source project and we should have ways to make progress while distributed. Who is doing to take care about such decisions being executed when we're back online again after a meeting? Is anyone going to keep track of decisions made and remind people to finish up on efforts started? > I think this will give us enough steering. We aren't as many people as > for example Plone or Python. Maybe, if we get everybody on track, we > will be, and then we'll have to rethink. But currently the people > involved, and the people that need to be "steered" are so few we can > fit them all into one room at a time. And then I do not see why would > would need a steering group. I don't agree that we have such a small group. It's also a question about whether we really *want* this to be a small group. I also don't think this is a sound mechanism in the long run. People are going to inevitably drop out from our community and we need fresh blood, also for fresh ideas and energy. If the only decisions are going to be made in real life meetings, there'll be little chance new people will get involved, as they'd not show up to such meetings. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Martin Aspeli wrote: [snip] > I'm not sure Plone's model fits Zope perfectly, but certainly there are > some lessons to be learned. We also have some of processes and > documentation already in place, having made a few mistakes along the way. Definitely, I'm very interested in seeing whether we can't adopt much of this model for Zope. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Martin Aspeli wrote: [snip] > You and I had a discussion a while back about forking the zope.component > ZCML directives, and how it would've been better to work within the > boundaries of the Zope packages so that everyone who wanted to lose the > zope.security dependency could benefit, rather than fork this and all > other configuration that depends on the core ZCML directives. The main > reason you had for creating your own package, was the lack of momentum > (and/or stop energy) encountered when trying to do this in the Zope > world. If there was someone who could both consider BFG's needs in a > more objective light, and have the power to actually do something rather > than just bicker, then maybe we could've gone a different route on that > one. With more and more dependency untangling happening, I am pretty > sure this same situation is going to come up again. Yes, this is a very good example of why Chris should be in favor of leadership for the Zope Framework. The Grok project would've appreciated such improvements right there in zope.component too. When I brought up the issue of trying to improve zope.component recently, I got a lot of divergent feedback and nothing happened. It'd be nice if instead such energy instead resulted in a concrete set of actions. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Christian Theune wrote: > On Tue, 2009-03-03 at 02:35 +0100, Martijn Faassen wrote: >> * leadership could help sustain efforts like "we want the Zope Framework >> to run on Jython" and make detailed decisions based on this. Nobody >> right now can really decide on this. > > Anecdote: Our current Jython story (due to last GSOC) is having lots of > conditional imports sprinkled all over the code base with an 'if > sys.platform == "java"'. For some reason there was no discussion about > that and we even didn't get enough stop-energy in my POV. ;) Yeah, that was a seriously disfunctional Summer of Code project. In that case I did encourage communication very much from our end. Those checkins were some form unilateral "week after the deadline" rescue effort on the student's part so that he'd get paid. Whether he got away with it I don't know, as the PSF was in charge of that project in the end. This shows that even if you have people on top of things (I saw the danger signals in this project *way* ahead of time) it still can go wrong. :) Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: > On 3/3/09 9:37 AM, Kent Tenney wrote: >> I'll chime in as a newbie. >> >> It seems many of the comments preferring ad-hoc to structure >> come from "we know what we are doing, we can take care of ourselves" >> >> I think Zope has the goal of attracting new users, and the proposal >> has potential to make Zope more inviting to the uninitiated. >> >> Zope is very diffuse, making it a challenge to grasp. I know I would benefit >> from any initiative which sought to provide an overview role. > > I'm not sure that's a goal of this proposal. The word "Zope" will > continue to have its previous series of semi-competing meanings. The > word will now also be attached to "Framework", which will be the emphasis. > > As I read it, regarding the diffusion, asking the stakeholders in the > existing meanings of the word to yield is not part of the proposal. > (Thankfully, as that is hopeless.) > > The focus, though, will be on greatest-common-factor of the shared > meaning. Not a solution to diffusion, but an improvement. I find myself in agreement with both Kent and Paul. :) I think that a leadership that cares about the beginner experience could help improve the beginner experience tremendously. Also the beginner *contributor* experience, who I think feels also very overwhelmed. I think leadership *should* care about such experiences and encourage people to improve matters. With the Grok project I've found that people are quite willing to contribute beginner's documentation and they only need a space to do so and a bit of encouragement. I think we could use the Zope Framework to integrate some ideas and lessons we've learned in the diffusion. In that sense it's an integrative force. I like Paul's description of "greatest-common-factor". I think we should work to expand that greatest common factor in adoption, but we can do so by reducing the size of the whole thing. I.e. the Zope Framework is something we want to be widely adopted but we can encourage adoption best by making it smaller and easier to understand. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Martin Aspeli wrote: [snip] > I think Martijn is trying to address something that Zope has lacked for > a while. I don't think it'll solve all of the world's problems, nor do I > think that Martijn things so, but it will make some things - things like > this very debate - a bit easier and more productive. Thanks very much Martin for putting all of this to words so well. Yes, exactly! +100 Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Gary Poster wrote: > My mild counter proposal was this. > > - The ZF formally institutes an easy way for people to start "Zope" > projects > > - Hopefully, Martijn F. starts something like the project he described > > - Hopefully, people follow it. > > In other words, I suppose, Just Do It. Actually Martijn tried to be better than that. :-) Instead of just forming a steering group (which I would interpret as a Zope project) and announcing it to the community, he asked for feedback first. :-) I probably agree he should have just done it by gathering the various release managers. BTW, in one of my original responses, I proposed to Martijn that the steering group should be mostly the release managers plus one or two strong developers so that the group reaches an odd number. > Beyond that, I didn't say my other smaller thought, which was that I > think the KGS should ideally be looser and more flexible than what > Martijn described. If you have a project that wants in on the KGS, > great, you can add it. That is the case right now and I think a steering group would be pretty open to additions. However, I think Martijn made a much more important point. What he wants, if I understood him correctly, is more of an organization around a hierarchy of KGSs. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a common core and maybe a coreplus set. Then each sub-project maintains a KGS on top of that with their specific extensions. (1) This will make interoperability much easier, since I could potentially use grok X.Y in Zope 2.Z without worrying about version conflicts. (2) If the steering group contains all of the release managers, then releases can be synced effectively. > Institute a "nightly" KGS for an upcoming > release (and maybe the most recent release). We do have this system today. http://zope3.afpy.org/buildbot/waterfall > It stays around forever > at a specific URL. Include only the projects whose tests pass in the > nightly KGS. Have a list elsewhere of the ones for which the tests > fail. If the tests don't pass for some period of time, apparently the > maintainers and users don't exist or don't care, and they get taken > off the list to be tested. That statement is a massive over-simplification of what's going on. ;-) There are several problems: (1) Tests that pass in isolation might not pass in a complete run. This might be due to this or another packages incomplete teardown. (Several people spent weeks getting this right for the 3.4 KGS.) (2) A new release of one package might break 5 others. Who is responsible for updating the 5 breaking packages. The author that just released the new package or the ones from the 5 others? What if those other packages do not have clear, single maintainers (e.g. zope.*)? I am not making up these cases. They are real and they exist today. The idea that one package has 1 or more concrete and devoted authors is simply not real in the Zope world of 200+ packages. > The "Zope Framework" team leader then > decides some time to make a release, so people might shuffle around > versions more than usual, but it's just another KGS. Yep, this is basically what happens today. For example, at Keas we use different versions (even trunk) of at least 20 packages. The point is that people have a stable point to start with. I think that would not change. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Tres Seaver wrote: > Stephan, I *have* managed a large set, and I'm *certain* that the KGS is > useful for many cases: it just doesn't work for me for any large > production application: I don't want to rely on the iffy availability > of eggs from PyPI, for instance, which means that running a separate, > per-project index is my only recourse anyway. Once you are running your > own index, it's contents *are* a KGS, just not one managed using the > 'versions.cfg' machinery. Who says that you cannot use your own index with the KGS? Do you think I use the official PyPI location for production? We use two approaches at Keas: (1) Use a PyPI proxy server that caches all needed packages locally. (2) Use zc.sourcerelease so that all packages are part of the big source TAR ball. Both approaches work just fine and we are still using the KGS for our version pinning. So here is an example of a typical buildout.cfg that we have: [buildout] extends = versions-3.4.0.cfg versions = versions extensions=lovely.buildouthttp find-links = http://eggs.gokeas.com/eggs [versions] keas.kmi = 0.3.1 lxml = 2.1.2 mechanize = 0.1.8 MySQL-python = 1.2.2 python-dateutil = 1.4.1 RelStorage = 1.1.1 setuptools = 0.6c9 z3c.datagenerator = 0.0.3 z3c.form = z3c.formjs = z3c.menu.ready2go = z3c.rest = 0.2.5 z3c.traverser = 0.2.3 z3c.versionedresource = 0.4.0 zc.testbrowser = zope.annotation = 3.4.1 zope.app.appsetup = 3.8.0 zope.app.container = 3.7.0 zope.container = 3.7.0 zope.app.locales = 3.4.5 zope.app.publisher = 3.5.0 zope.i18n = 3.5.0 zope.publisher = 3.5.4 zope.security = 3.5.2 # Updated secure function list for Python 2.5 zope.sendmail = 3.5.0 zope.server = 3.5.0 zope.testing = 3.5.5 simplejson = 1.9.1 hurry.query = gocept.registration = lovely.session = Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Lennart Regebro wrote: > On Tue, Mar 3, 2009 at 09:21, Martin Aspeli wrote: > > If anything, we started out with too little process and found there were > > gaps we had to plug. > > Ah. Now, THIS I like. Let's focus on this: Start out with as little > process and as few officialisms as possible. And I don't see that a > steering group is as little as possible. If it turns out to be > necessary, we add it then. Martijn is asserting (correctly in my opinion) that we tried the no leader approach for a while and failed. We are now discussing the necessary steps to resolve the problem. Martijn's solution is a steering group. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hi there, Tres Seaver wrote: [snip] > Stephan, I *have* managed a large set, and I'm *certain* that the KGS is > useful for many cases: it just doesn't work for me for any large > production application: I don't want to rely on the iffy availability > of eggs from PyPI, for instance, which means that running a separate, > per-project index is my only recourse anyway. Once you are running your > own index, it's contents *are* a KGS, just not one managed using the > 'versions.cfg' machinery. > > That said, I do appreciate the work you have done and are doing to make > the KGS useful for others. Distinguish KGS the concept (a list of locked down versions as suggestions to users of the framework) from KGS the implementation. Let's agree on the *concept* of a locked down list of versions that's maintained by the community, or in fact more than one such list. If people want to diverge in the implementation, fine. Different implementations have different advantages during development and deployment. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Chris Withers wrote: > Adam GROSZER wrote: >> Someone releases a new package version and your project just break the >> next day. That's a nightmare. > > That shouldn't happen with individual package releases where releases > are done sensibly. > (ie: if you're going to do a big backwards-incompatible release, let > people know. If you rely on a package, put in some sensible version > constraints in your setup.py, if your *project* (rather than your > packages) is paranoid (and it should be!) then lock the versions you use > down in something project-specific like a buildout.cfg, if you use buildout. The community can give suggestions about locking down. this is not some kind of fancy theory but something that has worked for Zope 3 and Grok since late 2007. One of the things wrong with the zope-dev community is that we way too heavily in favor of the "here's a giant toolbox, just figure it out" attitude in the name of ultimate flexibility. Instead we have to think about ways to figure out things *for* people so they don't have to do a lot of duplicate work. We should of course still support the giant toolbox use case. I'm just saying we should do *more* than that, too. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Hey, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martin Aspeli wrote: >> Tres Seaver wrote: > > > >>> - - How many need *all* of Zope3, including the ZMI? I'm betting that >>> set is much smaller than either of the others? >> Probably none. So having better dependencies would obviously be good. I >> think you still need a KGS of sorts, but you don't need to depend on >> *all* of it. :) > > I'm sure that the set is bigger than that. However, I want to identify > the critical subset the *everybody* needs, and ensure that we prioritize > "steering" efforts there: the other packages can mostly just be left in > the hands of the disjoint groups that need them. That critical subset is very small, and it's "zope.interface", which Twisted also needs, and only needs. We can't define the framework by what everybody needs. We can define it by what lots of people need. The people with less buy-in into this framework will have to care just about the smaller bits of course, but the developers as a whole will need to coordinate a larger chunk. Surrounding that chunk we'll have broader projects that care about even bigger chunks, definitely. My goal with the Zope Framework is to identify at least one chunk shared between the Zope 3 app server, Zope 2 and Grok. Other projects use less of it, and I think it's in our interests to cut it down to size, but it'll never be cut down to the size of zope.interface. I realize that this is only an approximation of the messy reality, but we need an approximation of reality we can all understand to be able to communicate about it and work together. Regards, Martijn ___ 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 )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: >> Plone, by the way, had a similar problem, and solved it by creating "the >> framework team". This is a rolling body of people who are responsible >> for putting out calls for and reviewing improvements proposals. They >> basically report to the release manager, who makes the final call. The >> release manager is nominated by the framework team, confirmed by the >> Plone Foundation, and given a small stipend for his troubles. > > Funny you should pick them as your example. I've seen members of that > team *actively deny* that the team has any role in setting technical > direction for Plone (which is ironic, given that what they actually do > is to review and approvie PEPs, as well as choosing the release manager). I probably took the analogy a bit far: I meant to show the type of process that would enable such a team to have some degree of legitimacy as well as purpose, and that a team-based approach can work well in a community where there's no pope/dictator/whatever. The framework team has a role in setting technical direction for a single release, by virtue of what it does. The team is changed for each release, so it does not have a role in setting technical direction further than that, although of course the choices made for one release will often have some bearing on the future. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Martijn Faassen wrote: > >> What is going to make us more effective is: >> >> * a recognition of current reality, i.e. the Zope Framework is not the >> same as the Zope 3 application server and it serves a far wider audience. >> >> * leadership > > I really couldn't agree more. There's unfortunately a bit of a > leadership vacuum in the Zope community. > > I think Tres and Chris are suggesting we focus leadership around > individual packages or sets of packages, and Martijn is suggesting we > have something a bit broader focusing on all of Zope. I think the two > are not necessarily mutually exclusive. And I'd take any leadership over > none at all. > > Plone, by the way, had a similar problem, and solved it by creating "the > framework team". This is a rolling body of people who are responsible > for putting out calls for and reviewing improvements proposals. They > basically report to the release manager, who makes the final call. The > release manager is nominated by the framework team, confirmed by the > Plone Foundation, and given a small stipend for his troubles. Funny you should pick them as your example. I've seen members of that team *actively deny* that the team has any role in setting technical direction for Plone (which is ironic, given that what they actually do is to review and approvie PEPs, as well as choosing the release manager). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrVLl+gerLs4ltQ4RAvlfAJ9+fN/QKeP0rKPYAYWfIgRxIamMGACguQEi WFITE1Q+ICLT4MMhquvcWc0= =KyEB -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Monday 02 March 2009, Chris Withers wrote: >> Adam GROSZER wrote: >>> Someone releases a new package version and your project just break the >>> next day. That's a nightmare. >> That shouldn't happen with individual package releases where releases >> are done sensibly. > > Let me tell you from experience: Before the KGS we had exactely this problem. > No carefully crafted release can male up for that. And if a single package > pins versions generically, then you stall development. We also had that > ha[[en before the KGS came around. Both reasons actually promted my to do the > KGS in the first place. > > In general, and not specific to you Chris, I think that unless you have > managed a large set of packages, you should shut up and listen. Stephan, I *have* managed a large set, and I'm *certain* that the KGS is useful for many cases: it just doesn't work for me for any large production application: I don't want to rely on the iffy availability of eggs from PyPI, for instance, which means that running a separate, per-project index is my only recourse anyway. Once you are running your own index, it's contents *are* a KGS, just not one managed using the 'versions.cfg' machinery. That said, I do appreciate the work you have done and are doing to make the KGS useful for others. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrU/N+gerLs4ltQ4RAhhjAKCXFz/UWoahvRiBkWYy7oWT7+2wZgCfdZ0h Nwc71oEYwqV1Jm0liFofTUA= =7Y6k -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Martijn Pieters wrote: > The irony is that the proposed solution, organized leadership, is > going to suffer the same fate as the aforementioned ideas. Everyone is > putting in their oar, +1s and -1s are flying right, left and centre, > and this idea is either going to die, or Martijn will have to push it > through and implement it. No one else seems enthusiastic enough to > make this happen outright, there is no clear direction. I had the same sentiment while reading the thread, which is why I am mostly staying out of it. Just in case it is not clear from my previous responses, I agree with Martijn's analysis and I am in favor of Martijns proposal and will help him as much as I can to get it implemented. I will gladly work on the proposed KGS split, keep doing Zope Framework and Zope 3 App server releases, and serve on the steering group. We got to try something and I think this is a good and honest attempt. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: >> - - How many need *all* of Zope3, including the ZMI? I'm betting that >> set is much smaller than either of the others? > > Probably none. So having better dependencies would obviously be good. I > think you still need a KGS of sorts, but you don't need to depend on > *all* of it. :) I'm sure that the set is bigger than that. However, I want to identify the critical subset the *everybody* needs, and ensure that we prioritize "steering" efforts there: the other packages can mostly just be left in the hands of the disjoint groups that need them. >> - - Of the first set, what is the likelihood that different projects >> will have conflicting goals about the direction of one or more >> packages? >> >> Given the likelihood that a monolithic Zope 3.5 release is not >> interesting to lots of the folks who both develop and consume its >> packages, how much coordination is going to be possible (or even useful) >> around the idea of another release? > > Maybe we could identify some "vectors" down the dependency graph that we > *do* care about. If we analysed our projects (Plone, and a bunch of > add-on products, for instance), we could probably manage to maintain > KGS' that say "if you want the container interfaces, these packages are > known to work together". I suggested one such vector (zope.interface, zope.component). Another one is "the packages which Zope2 (really) needs." >> Maybe we need to create something more like self-organizing >> mini-communities around the various packages (or maybe sets). > > Heh... right. ;-) > >> E.g., I >> would bet that almost everyone active on this list has a stake in >> zope.interface, zope.component, and their dependencies. Note that *two* >> of the remaining dependencies (zope.deferredimport, zope.deprecation) >> are only there to deal with BBB isssues: maybe they should go? > > Why? They're tiny, and BBB is good. No piece of framework code can be > taken seriously if it pretends that people are not going to need > backwards compatibility. Some BBB may be worth keeping: I have argued before, however, that the specific BBB strategy which requires those three packages is not a big success: rather than proxying all modules with deprecations, for instance, I would rather just leave the BBB imports in place *forever*, without emitting warnings. >> Another, zope.proxy, is a blocker for using the packages on non-CPython >> platforms: should it go? If we consider those packages *in isolation*, >> as things potentially useful outside any larger framework, the answers >> to those questions might be different. > > True. > >> I'm not so sure that any other package is going to be as widely >> interesting. > > I can think of a few: the container stuff, browser views and pages, page > template files, for example. We already have "successful" forks for a number of those. >> I also think that having the *whole* Zope community do >> oversight oversee on the rest is less useful than having the folks with >> "skin in the game" for a particular package steer it. I am unlikely to >> care much about anything in the Z3 ZMI, for instance, or about a number >> of other packages in our various namespaces: I could do my job better, >> *and* keep from interfering in others' interests (e.g., the "stop >> energy" Chris mentioned), if we separated out the various areas of concerns. > > True. However, someone still needs to think about whether these things > are pulling in the same direction, or becoming incompatible with one > another. Note that divergence may be an acceptable outcome, here, especially if we adopt the pattern that fundamental disagreements on the direction of a shared package can be resolved by the "amicable divorce" of a fork. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrU4N+gerLs4ltQ4RAuFaAKC2eBkntSauZvi0qWm5wgAvuwVD+QCgxIa8 y8wKdscbD9+f4bfyq+42yfM= =71WM -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Monday 02 March 2009, Chris Withers wrote: > Adam GROSZER wrote: > > Someone releases a new package version and your project just break the > > next day. That's a nightmare. > > That shouldn't happen with individual package releases where releases > are done sensibly. Let me tell you from experience: Before the KGS we had exactely this problem. No carefully crafted release can male up for that. And if a single package pins versions generically, then you stall development. We also had that ha[[en before the KGS came around. Both reasons actually promted my to do the KGS in the first place. In general, and not specific to you Chris, I think that unless you have managed a large set of packages, you should shut up and listen. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 8:43 AM, Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - Show quoted text - > On 03.03.2009 15:37 Uhr, Kent Tenney wrote: >> On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer wrote: >>> Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen >>> wrote: > Who is going to make that decision to encourage this? Allow this? You? > Me? Who? Right now, *nobody* is making such decisions and nobody can > properly get away with saying they allow it. Leadership is a way to get > out of it. I think open source in general has shown two things: 1. Communities can mostly take decisions without having official authorities to do so. This is hyper democratic. 2. When they can't, usually committees can't either. In those cases somebody with a deciding vote is needed. This isn't democratic at all, but efficient. >>> Exactly. And that's what we currently don't have. >>> > +1, though a simple discouraging of utterance can't accomplish it by > itself. What you need is active leadership that encourages such > experimentation. I don't know about that. I agree with you that there hasn't been active leadership for a while. But look what has happened without this active leadership. * We have two cool new Zope 3 based frameworks. One which throws out the whole concept of ZCML for doing configuration by radical code introspection, and as a result making the Zope Framework immensely more accessible. And another one which experiments with revamping the way Zope publishes things, and a related effort of rewriting the whole publisher. Both frameworks have during these experimentation reached big audiences and gained widespread if still experimental acceptance in the community. >>> True - but to me it seems that this happened because someone took leadership >>> in this scenario. >>> * Zope 2 has been eggified. * Buildout has totally massacred all other forms of deployment of Zope projects. >>> All that is true and very positive, but what has not happened and maybe >>> never >>> will that way, is the aggregation of all those Zope 3 efforts, >>> documentation, >>> website and the like. And that is something very important in order to >>> attract a broader user base. >>> > Who decides to kill something off? If it doesn't get maintained, is dead. I guess you want somebody to make it official. I'm not sure it's necessary in a component based reality. With Zope 2 eggified for example, ZClasses gets a separate module, and it lives as long as somebody maintains it. It's then just a matter of deciding if it should be a part of the release or not, which the release manager(s) decide. >>> That's fine for one thing: Newbies don't know which packages are maintained >>> and which are not. They find themselves confronted with a bunch of packages >>> and don't know what they should use and what not. Example: zope.formlib vs. >>> z3c.form. >>> For instance, I decided to use lovely.remotetask - but I recognized that the >>> last commit is quite some time ago and don't really know if it's actively >>> used/maintained. >> >> I'll chime in as a newbie. >> >> It seems many of the comments preferring ad-hoc to structure >> come from "we know what we are doing, we can take care of ourselves" >> >> I think Zope has the goal of attracting new users, and the proposal >> has potential to make Zope more inviting to the uninitiated. >> >> Zope is very diffuse, making it a challenge to grasp. I know I would benefit >> from any initiative which sought to provide an overview role. >> >> > > I started up with something for zope2.zope.org in order to bring > sort out the various things a bit: > > http://zope2.zopyx.de/about-zope-2/the-zope-eco-system That's very useful, and seems to describe the theory of the Zope world. In theory, theory and practice are the same, in practice they are not. My post was prompted by the mention of knowing which of several similar components is preferred, deprecated, abandoned. Maybe this doesn't fall within the proposal, but it strikes me as an element of 'steering'. I think that watching exchanges between a steering entity and the dev community would be a good vantage point for getting a picture of the Zope landscape. Thanks, Kent > > Andreas > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk > uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY > =y1Df > -END PGP SIGNATURE- > ___ 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://
Re: [Zope-dev] the Zope Framework project
On 3/3/09 9:37 AM, Kent Tenney wrote: > I'll chime in as a newbie. > > It seems many of the comments preferring ad-hoc to structure > come from "we know what we are doing, we can take care of ourselves" > > I think Zope has the goal of attracting new users, and the proposal > has potential to make Zope more inviting to the uninitiated. > > Zope is very diffuse, making it a challenge to grasp. I know I would benefit > from any initiative which sought to provide an overview role. I'm not sure that's a goal of this proposal. The word "Zope" will continue to have its previous series of semi-competing meanings. The word will now also be attached to "Framework", which will be the emphasis. As I read it, regarding the diffusion, asking the stakeholders in the existing meanings of the word to yield is not part of the proposal. (Thankfully, as that is hopeless.) The focus, though, will be on greatest-common-factor of the shared meaning. Not a solution to diffusion, but an improvement. --Paul ___ 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 )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.03.2009 15:37 Uhr, Kent Tenney wrote: > On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer wrote: >> Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: >>> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen >> wrote: Who is going to make that decision to encourage this? Allow this? You? Me? Who? Right now, *nobody* is making such decisions and nobody can properly get away with saying they allow it. Leadership is a way to get out of it. >>> I think open source in general has shown two things: >>> >>> 1. Communities can mostly take decisions without having official >>> authorities to do so. This is hyper democratic. >>> 2. When they can't, usually committees can't either. In those cases >>> somebody with a deciding vote is needed. This isn't democratic at all, >>> but efficient. >> Exactly. And that's what we currently don't have. >> +1, though a simple discouraging of utterance can't accomplish it by itself. What you need is active leadership that encourages such experimentation. >>> I don't know about that. I agree with you that there hasn't been >>> active leadership for a while. But look what has happened without this >>> active leadership. >>> * We have two cool new Zope 3 based frameworks. One which throws out >>> the whole concept of ZCML for doing configuration by radical code >>> introspection, and as a result making the Zope Framework immensely >>> more accessible. And another one which experiments with revamping the >>> way Zope publishes things, and a related effort of rewriting the whole >>> publisher. Both frameworks have during these experimentation reached >>> big audiences and gained widespread if still experimental acceptance >>> in the community. >> True - but to me it seems that this happened because someone took leadership >> in this scenario. >> >>> * Zope 2 has been eggified. >>> * Buildout has totally massacred all other forms of deployment of Zope >>> projects. >> All that is true and very positive, but what has not happened and maybe never >> will that way, is the aggregation of all those Zope 3 efforts, documentation, >> website and the like. And that is something very important in order to >> attract a broader user base. >> Who decides to kill something off? >>> If it doesn't get maintained, is dead. I guess you want somebody to >>> make it official. I'm not sure it's necessary in a component based >>> reality. With Zope 2 eggified for example, ZClasses gets a separate >>> module, and it lives as long as somebody maintains it. It's then just >>> a matter of deciding if it should be a part of the release or not, >>> which the release manager(s) decide. >> That's fine for one thing: Newbies don't know which packages are maintained >> and which are not. They find themselves confronted with a bunch of packages >> and don't know what they should use and what not. Example: zope.formlib vs. >> z3c.form. >> For instance, I decided to use lovely.remotetask - but I recognized that the >> last commit is quite some time ago and don't really know if it's actively >> used/maintained. > > I'll chime in as a newbie. > > It seems many of the comments preferring ad-hoc to structure > come from "we know what we are doing, we can take care of ourselves" > > I think Zope has the goal of attracting new users, and the proposal > has potential to make Zope more inviting to the uninitiated. > > Zope is very diffuse, making it a challenge to grasp. I know I would benefit > from any initiative which sought to provide an overview role. > > I started up with something for zope2.zope.org in order to bring sort out the various things a bit: http://zope2.zopyx.de/about-zope-2/the-zope-eco-system Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY =y1Df -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. & Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ 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 )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer wrote: > Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: >> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen > wrote: >> > Who is going to make that decision to encourage this? Allow this? You? >> > Me? Who? Right now, *nobody* is making such decisions and nobody can >> > properly get away with saying they allow it. Leadership is a way to get >> > out of it. >> >> I think open source in general has shown two things: >> >> 1. Communities can mostly take decisions without having official >> authorities to do so. This is hyper democratic. >> 2. When they can't, usually committees can't either. In those cases >> somebody with a deciding vote is needed. This isn't democratic at all, >> but efficient. > > Exactly. And that's what we currently don't have. > >> > +1, though a simple discouraging of utterance can't accomplish it by >> > itself. What you need is active leadership that encourages such >> > experimentation. >> >> I don't know about that. I agree with you that there hasn't been >> active leadership for a while. But look what has happened without this >> active leadership. >> * We have two cool new Zope 3 based frameworks. One which throws out >> the whole concept of ZCML for doing configuration by radical code >> introspection, and as a result making the Zope Framework immensely >> more accessible. And another one which experiments with revamping the >> way Zope publishes things, and a related effort of rewriting the whole >> publisher. Both frameworks have during these experimentation reached >> big audiences and gained widespread if still experimental acceptance >> in the community. > > True - but to me it seems that this happened because someone took leadership > in this scenario. > >> * Zope 2 has been eggified. >> * Buildout has totally massacred all other forms of deployment of Zope >> projects. > > All that is true and very positive, but what has not happened and maybe never > will that way, is the aggregation of all those Zope 3 efforts, documentation, > website and the like. And that is something very important in order to > attract a broader user base. > >> > Who decides to kill something off? >> >> If it doesn't get maintained, is dead. I guess you want somebody to >> make it official. I'm not sure it's necessary in a component based >> reality. With Zope 2 eggified for example, ZClasses gets a separate >> module, and it lives as long as somebody maintains it. It's then just >> a matter of deciding if it should be a part of the release or not, >> which the release manager(s) decide. > > That's fine for one thing: Newbies don't know which packages are maintained > and which are not. They find themselves confronted with a bunch of packages > and don't know what they should use and what not. Example: zope.formlib vs. > z3c.form. > For instance, I decided to use lovely.remotetask - but I recognized that the > last commit is quite some time ago and don't really know if it's actively > used/maintained. I'll chime in as a newbie. It seems many of the comments preferring ad-hoc to structure come from "we know what we are doing, we can take care of ourselves" I think Zope has the goal of attracting new users, and the proposal has potential to make Zope more inviting to the uninitiated. Zope is very diffuse, making it a challenge to grasp. I know I would benefit from any initiative which sought to provide an overview role. Thanks, Kent > >> > Who decides we should have a documentation website for a widely used >> > component. >> >> Those who writes the documentation in question. :) > > In some way, that's already done - nearly every package has some doctest, > which does often cover the package specifics very well. However, I remember > the days I looked at z3c.form: I recognized that I needed to get to know the > following other packages: > > - interfaces/adapters > - z3c.pagelet > - z3c.template > - (and quite some more) > > This was very cumbersome. > >> > * who reminds us of necessary tasks and directions we're going into? >> > Sometimes the community collectively decides on moving forward. >> > Sometimes it doesn't. Are we really maintaining our issue tracker well, >> > say? >> >> No, but then a person should get some sort of responsibility for that. >> Note: A person. Not a committee. A committee means a bunch of people >> are responsible, which is the same thing as saying that nobody is. > > Yes, that's probably true. So either this steering group is "a person" or has > some person who decides. > > Best Regards, > Hermann > > -- > herm...@qwer.tk > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > ___ > - Show quoted text - > Zope-Dev maillist - zope-...@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://ma
