Re: [Zope-dev] the Zope Framework project
Hi, On Tue, 2009-03-03 at 08:52 +0100, Lennart Regebro wrote: On Tue, Mar 3, 2009 at 08:42, Christian Theune c...@gocept.com wrote: On Tue, 2009-03-03 at 08:35 +0100, 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. That's a valid point. However, the steering group was thought of with having fail over in mind so that few people would know about the tasks at hand and can jump in for each other (in a coordinated fashion). Sure. But what happens in those cases is that everybody sits around waiting for the steering group to do it, so it stops acting as a failover, and gets swamped. However, the group should be able to make a better job at keeping things in flow and focused. Well, maybe it should. I don't think it would. Groups generally don't. For some reason the argument evades me: People randomly doing stuff will end in good things. People (trying) to thoughtfully organize won't. 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. No, you did not do anything wrong. You did everything completely correct. But forget not having backroom conversations. That will and must happen. It is backroom *decisions* that is the problem. When a group will come out with a decision they made by themselves. This *will* happen when you have a dedicated group of people making decision. The only way to avoid that is to not have a steering group, but somehow have everybody involved in a decision. And that is as noted not always practical either. I do see the contradiction in this. ;) But as Martijn pointed out for his doing with grok: it's thought of as a hack. We've done this backroom discussion because we felt that zope-dev won't be able to drive a fruitful discussion without preparing as much. However, I'd like that to not be the default or the desired state of things. Having major issues resolved in RL meetings will exclude all those whose schedules don't match and those who can't afford to travel to Far Far Away. Aren't we now saying that to avoid excluding some people, we should exclude all but a steering group? :-) No. The steering group should not have backroom discussions. They should act as open as possible. I think of it as a catalyst. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development signature.asc Description: This is a digitally signed message part ___ 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: I'm talking about a group of people who act as if they're responsible, not your mythical committee. We should be able to find a bunch of people with a sense of responsibility, right? Yes. But I don't think making them a steering group is going to help. Just to take some experience from Plone again: sometimes it's *very* useful to have someone (be that one or more persons) with some legitimacy and responsibility, for two reasons: - it makes other people sit up and listen - it nudges those people into performing a role that may not otherwise have So, in Plone, we have a few loci of legitimacy: - The founders, Alex and (now to a lesser extent involved) Alan, who get it through respect and historical position - The Plone Foundation Board, who have a proper voting structure and deals with non-code/functionality matters. - The release manager, who is elected, confirmed by the board, and paid (a tiny bit) for his duties - The framework team, who are lieutenants and advisers to the release manager Sometimes, those people can step in and say enough is enough in a discussion. Sometimes they can take the lead and summarise a particular debate, or try to nudge people into being more constructive. Sometimes, they will cast the deciding vote if the community is split in its opinion. Sometimes they will be careful to ensure that decisions are recorded and disseminated through documentation, mailing lists and blogs. This role is very important, and I think it's lacking in the Zope community. How many discussions have there been recently that just died under the sheer weight of the number of lengthy and opinionated replies there were? How many times have we gotten bogged down in semantics or naming discussions and killed off the momentum behind something? I'd argue that the reason this happens is not (just) that we're a bunch of opinionated people. It happens because no-one, save perhaps Jim, who is largely silent in these debates, has the legitimacy to make any kind of decision or prod people to move along. And even if someone does have that legicimacy, they don't *feel* that they do (or think that others feel that they do) and so they don't exercise it. We're not talking about dictatorship here, nor are we talking about anyone going off and making a whole bunch of decisions that others have to blindly follow. Open source doesn't work like that. But there are ways to provide some guidance: - Elect rather than appoint, so that the people being led feel that they have a stake in the decisions made. - Elect the right types of people. Thankfully, we have many capable and pragmatic people to choose from. - Create a process for self-perpetuation of the group that means responsibility rotates. This is a good way to get people more involved in a project as well as a way to share the burden when there's a lot of work. - Be transparent and document the discussions that take place, to avoid conspiracy theories. Again, looking at Plone, the framework team has worked out pretty well. If anything, we started out with too little process and found there were gaps we had to plug. It's not overly process-heavy, though, nor does anyone have any illusion that a team that is focused on achieving a particular task (roughly, getting a good release out the door without compromising the future of the stack) for a particular period of time (one major release) is going to be able to boss anybody around. But having *some* process and *some* structure is incredibly useful, if only because it makes things a bit more predictable and easier to fit oneself into. I'm sure that if you asked an outsider how they could contribute meaningfully to the architectural direction of Zope, they wouldn't have a clue, because it's all ephemeral, undocumented and dynamic. We rely on a lot of unwritten rules. If you asked them the same question about Plone, they would at least have some ideas, because there's some structure there to be understood and taken advantage of. This type of thing is pretty well researched in the social science of organisations and groups. It's also pretty common in other open source projects that have reached a certain size or age, including Plone. 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. 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
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 09:13, Christian Theune c...@gocept.com wrote: For some reason the argument evades me: People randomly doing stuff will end in good things. People (trying) to thoughtfully organize won't. It's not an argument, it's a statement of fact. 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. -- 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 Tue, Mar 3, 2009 at 09:21, Martin Aspeli optilude+li...@gmail.com 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. -- 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. They were used when we had the zope3 application server and we plugged some components into it, like sites are plugged into debian apache/nginx setups, but now-a-days, when it seems that most people just build their own applications using their custom app configuration files, I don't think that there's much sense for package-includes for including components like zope.file. I can think of a use for package-includes for some CMS application that include website configuration (like debian apache), but not the component configuration. -- WBR, Dan Korostelev ___ 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. I cannot see similar slugs in other packages either. -- 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 Montag 02 März 2009 18:11:59 schrieb Chris McDonough: Martijn Faassen wrote: The Zope Framework project == :Author: Martijn Faassen :Date: 2009-03-02 Introduction This document offers suggestions to reorganize our community so we can act more effectively. It does this by trying to clarify what our community is about. The document tries to innovate minimally in concepts and naming in order to provide a relatively small evolutionary step forward that can still make us all work together better. Even though this is an evolutionary step, it will still have a big impact if implemented, so please read on. This document should be relevant to *all* the parts of our community that build web applications, whether they use Zope 2, Zope 3, Grok, Repoze, or applications built on top of these such as Plone or Silva. While it talks a lot about Zope 3 this is because the Zope technology within Zope 3 is used within all these projects. The document wants to recognize this officially. The main innovations in concepts are the name Zope Framework to distinguish it from the Zope 3 application server and the core/extra concept. These are all hopefully descriptions of what are current practices, simply making them more explicit. The biggest innovation is the introduction of a Zope Framework Steering Group as a new entity that will be the steward for the development of this framework. The steering group's primary aim is to facilitate developers in the community so that they can continue to maintain and develop the framework so that it is useful to all of us. I'm pretty sure a steering group and a rebranding of existing software is not going to make us more effective. Here's what I believe would make us more effective: - encouraging radical change for experimentation purposes, releasing folks from various constraints (backwards compatibility, style policing, historical ownership) No, I really disagree with that. In my opinion. To my mind, the problems of Zope 3 do not come from too few radical ideas but from the fact, that many components are simply not yet finished and documented. Building something new is for sure interesting, experimenting can and will be enlightening, but what we need is a very stable base. - discourage the contribution of stop energy (discourage the utterances of don't, stop, this is wrong, stop talking about this). People like me, who build long-term projects, need to rely on a continuous development process. What I really don't want, is to overwork my whole code every half year in order to be able to upgrade to the current Zope 3 release. I very much appreciate some sandbox-idea, where people can branch and experiment. But I think we miss so often the point, that Zope 3 technology is hard for newcomers (maybe different with Grok): The newbie (or, let's say the PHP-Junkie) is confronted with entirely new concepts: - buildout (KGS) - component architecture - object database ... and much more. And there is no clear entry point to learn all that, so the user is really overwhelmed. And later on he may realize that various features are still absent in Zope 3 (e.g. session management via URLs etc.), or, what also happens quite often - he just does not find what he needs as some functionality is in some unknown lovely/z3c/zc/other package. I think a key elelement in a project that decides over success/failure is the growth of its user base. So my suggestion is to really look closely what can be done in this area instead on focussing on radical architecture changes. Martijn's document, which tries to clear things up, is a good start in this area, I think. 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
Martijn Faassen wrote: The main innovations in concepts are the name Zope Framework to distinguish it from the Zope 3 application server and the core/extra concept. These are all hopefully descriptions of what are current practices, simply making them more explicit. From what I read we do agree on this in general. The terms of what packages are in the core are not fully fledged out, but this can easily be done. The biggest innovation is the introduction of a Zope Framework Steering Group as a new entity that will be the steward for the development of this framework. The steering group's primary aim is to facilitate developers in the community so that they can continue to maintain and develop the framework so that it is useful to all of us. The introduction of any kind of group equipped with whatever power seems to be controversial. I'll try to share a bit of how we approached this issue in the Plone community. Before Plone 2.5 we had no organized group of whatever kind and overloaded the release manager with all concerns. People recognized that more process distributed over multiple shoulders was required. What we introduced is our Framework Team. It is in its very inception a release team. It is focused on figuring out how to make a next release of whatever crazy innovations happened in the community and bundle it up as a consistent story. It serves for one release and is focused on it. While you get some power of making decisions for the next release, your powers are limited and have a natural end. You also get some boring and tedious tasks to do as part of your job. This for naturally avoids to have people on the team, who just talk but never deliver. What our framework team does not do, is to care about long term strategy nor guiding the community at large into one direction. Long term strategy planning is done on the unorganized basis of some people caring about it and doing the work required to push things into those directions. Once those things have stabilized, the framework team can pick them up and try to get them into the next release. In order to provide guidance to the community, we have played another mind trick to let people not feel like they are lead. We have made the Plone Fondation be relevant, but not interface with the actual development of the project in any real way. We then elected natural good leaders into serving as the Foundation Board. As part of their role, they do not possess any kind of actual power to decide anything in the development process. They have however been recognized by the community as leaders and been elected. This official community recognition alone makes sure they are listened to in the community. 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
Am Montag 02 März 2009 18:49:43 schrieb Adam GROSZER: Hello, I think we need some sort of stering group (or person(s)). Without rules and decisions to follow we're going to end up like headless chicken running around in the kitchen. Noone knows the direction. Exactly. And if we look at other projects, we always recognize some well known key persons, who have leader roles. For instance, SQLAlchemy has Michael Bayer, Linux has Linus, Python has Guido and so on. That does not mean that these key person(s) dictate the way the development goes, but consideres/embraces ideas and leads in one direction, where everyone follows. My impression (from an external perspective) is that Zope Corporation did just that for Zope 2/3, but nowadays tries to give this role to the community. That's bad as this leaves an empty void, which is currently somehow filled out by some key persons, which are extremely capable, but don't have a leader role. 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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Mon Mar 2 12:00:00 2009 UTC to Tue Mar 3 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:25:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011217.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:27:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011218.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:29:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011219.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Mon Mar 2 20:31:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011220.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:33:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011221.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Mon Mar 2 20:35:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011222.html ___ 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 Montag 02 März 2009 19:34:11 schrieb Tres Seaver: Adam GROSZER wrote: I think we need some sort of stering group (or person(s)). Without rules and decisions to follow we're going to end up like headless chicken running around in the kitchen. Noone knows the direction. Yes sometimes radical changes are good. We're also carrying a lot of old baggage around with Zope3. It is lurking around the corner. Like Shane's zope.pipeline, repoze stuff, etc. BUT at the same we have projects that have to be kept running (and migrated, possibly smoothly) Keeping our packages together at least with a KGS is a must in my opinion. Unless you want yourself to find a working set between the permutations of all required packages versions. Someone releases a new package version and your project just break the next day. That's a nightmare. Maybe we need to create something more like self-organizing mini-communities around the various packages (or maybe sets). E.g., I Isn't that the scenario we currently have? I already see some grouping around zope packages, Grok, z3c packages and others. But of course, these groups must work together, which will be difficult unless there's something that concentrates/coordinates the group's effort to form something bigger. 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
Hi Betreff: Re: [Zope-dev] the Zope Framework project [...] Grok and Repoze are in part *workarounds* for the deficiencies in this community. For Grok I'm very sure it's a workaround, as I had quite something to do with it and this was explicit in my mind. It's not *only* a workaround, but it's definitely a community hack, too. I don't agree one bit it's workaround for deficiencies in the community. It's workarounds for deficiencies Zope3. And the community has fixed them. You can also call this anticipation the oposit of participation But I know it's much more productive to impelement a new framework then to convince other developer to change something in existing zope. And sometimes it has to happen. We also did this in several z3c packages. The good thing right now is that we have different experiences and can merge the good concepts back to the zope core or offer different implementations solving similar problems in different ways. The big questions now is, do we like to merge this good things back to the zope core or do we like to stay with different packages because we can't find an agreement what we like to do. Regards Roger Ineichen ___ 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 12:53, Hermann Himmelbauer du...@qwer.tk wrote: My impression (from an external perspective) is that Zope Corporation did just that for Zope 2/3, but nowadays tries to give this role to the community. No, I don't think we ever tried that. I think we should. -- 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 Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com 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. 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 ___ 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 13:04, Roger Ineichen d...@projekt01.ch wrote: You can also call this anticipation the oposit of participation :) The big questions now is, do we like to merge this good things back to the zope core or do we like to stay with different packages because we can't find an agreement what we like to do. Just to be completely clear: I do absolutely think we should merge as much goodness back as possible. I also agree with everything Martijn Faassen said. Except, I do not think a steering group is necessary to achieve these goals, and that in fact there is a significant risk that is ends up hindering them. I thought I could organize freedom. How Scandinavian of me --Björk: Hunter. -- 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 Dienstag 03 März 2009 08:19:37 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 01:51, Martijn Faassen faas...@startifact.com wrote: Can you stop using the word committee? I didn't use it. A committee is a bunch of people who has regular meetings, behind closed doors, to make decisions. That's not what the Steering Group is designed to be. I'm talking about a group of people who act as if they're responsible, not your mythical committee. We should be able to find a bunch of people with a sense of responsibility, right? Yes. But I don't think making them a steering group is going to help. Hmmm, I have the slight feeling that your opinions are not that far away. Maybe both of you should define what this steer group exactly is. 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
I find this thread quite ironic. Martijn Faassen recognizes a problem, namely that there is no direction in Zope development. Instead, when ideas are put forth lots of people put in their oar with +1s and -1s and stop energy and cheer leading one direction or another. In the end the ideas either get pushed through by determined contributors or (more often) they die. 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. So to me, the least this thread does is to prove that the flagged problem does exist. And so far I haven't heard any better ideas than what Martijn is proposing (no, leaving the status quo, deny there is a problem and steer by majority is not a counter proposal in my view). It may be that the idea needs some tweaking, but that's just details. Would it be possible to focus this discussion around clearer lines? Create counter proposals if you have to, discuss things on their merits, but if you cannot add more than a vague +1 and -1, please refrain. -- Martijn Pieters ___ 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 13:33, Hermann Himmelbauer du...@qwer.tk wrote: Hmmm, I have the slight feeling that your opinions are not that far away. Of course not. This is, as aways, just a question of loudly agreeing. -- 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
Martijn Pieters wrote: Would it be possible to focus this discussion around clearer lines? Create counter proposals if you have to, discuss things on their merits, but if you cannot add more than a vague +1 and -1, please refrain. I think that would be easier if we had a shorter proposal. I suspect a lot of people only read bits of it, leading to some of the present confusion. 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 Mar 3, 2009, at 7:35 AM, Martijn Pieters wrote: ... And so far I haven't heard any better ideas than what Martijn is proposing (no, leaving the status quo, deny there is a problem and steer by majority is not a counter proposal in my view). It may be that the idea needs some tweaking, but that's just details. Would it be possible to focus this discussion around clearer lines? Create counter proposals if you have to ... I'm surprised my proposal didn't generate any replies, and can only assume that it is because it created the silence of everyone quietly saying Whaaa? :-) 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. I don't think Martijn, nor anyone else who has been part of the community long enough to be on the ZF, needs the entire community to bless his idea to try to move forward--they need just an absence of a veto for the use of the chosen name, as I proposed more concretely in the original email. I think that incorporates some of the more laissez-faire advocates are arguing for: someone else can also start their own counter project, if desired. Maybe they won't, but they can. And this freedom could allow us to escape the need to feel that everyone has to agree about this. 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. Institute a nightly KGS for an upcoming release (and maybe the most recent release). 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. 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. 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 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. --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 3/2/09 6:36 PM, Martijn Faassen wrote: Hi there, To people who are suggesting we don't need a steering group nor a name for the Zope Framework, please answer the following questions: * how will the community make hard decisions where lots of people disagree? What is the mechanism for making hard decisions? Don't say Jim makes them because as you may have noticed Jim *hasn't* been making so many of those in recent times. We need to solve this problem. Ultimately I think I agree with Chris's position. I think the days are past when we could commit to the success of an overarching Uberthing, be it a macroframework, platform, or app server. Rather than commit your reserves in a desperate attempt to win the battle, you withdraw to avoid losing your whole army. That notwithstanding, if Zope is still the goal, I endorse Martijn's proposal. Like Gary said, it's admirable that he's taking a shot at this and we should bite our tongues on quibbling. In the past we've seen things like let's unify Zope by merging the Zope2 and Zope3 mailing lists get shot down by a couple of loud no votes. Loud no's have grown paralyzing. If Martijn's proposal gets traction, then perhaps we have a way around them. --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 14:45 Uhr, Paul Everitt wrote: In the past we've seen things like let's unify Zope by merging the Zope2 and Zope3 mailing lists get shot down by a couple of loud no votes. Loud no's have grown paralyzing. This topic is still on the agenda and it all depends on who says no and how one says no and why one says no. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmtNWkACgkQCJIWIbr9KYzTFQCcDlRtNXiPW+0o4W2is6DW64Nm aRIAn3UcnHq0L2tWyFEW59c9XZGYYjtr =YGZL -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 du...@qwer.tk wrote: Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com 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://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org
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 du...@qwer.tk wrote: Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com 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 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
On Wed, Mar 4, 2009 at 8:43 AM, Andreas Jung li...@zopyx.com 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 du...@qwer.tk wrote: Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com 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://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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: snip - - 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 Designhttp://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 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 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 Designhttp://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
-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 Designhttp://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
Hey, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: snip - - 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
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
On Tuesday 03 March 2009, Lennart Regebro wrote: On Tue, Mar 3, 2009 at 09:21, Martin Aspeli optilude+li...@gmail.com 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
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, 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
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
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
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
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, 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, 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: [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
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
-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 Designhttp://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
-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 Designhttp://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
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
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
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
-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 Designhttp://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
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
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
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
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
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 70something of them) tends
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] SVN: zope.component/branches/tseaver-wo_zope_deferred/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: Log message for revision 97465: Branch removing zope.deferred. This checkin is the branch I had in mind when sketching out a non-CPython-only zope.component story today. Notes on the changes: - - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE. - - Ripping out 'zope.deferredimport' required shifting to from imports to avoid cycles. I moved one other cycle down into a non-module-scope import, as well, using a 'global base' to avoid extra imports. - - All its tests pass in a buildout. - - Due to the 'test' extra, buildout pulls in a bunch of extra dependencies, which I would like to zap (ZODB? really? just to verify that the persistent registry survives 'dumps' and 'loads'?) - - The branch can be installed into a virtualenv via 'setup.py develop', with only 'zope.interface' and 'zope.event' added. - - 'setup.py test' needs 'zope.testing', but then doesn't do anything (missing metadata). If I added the metadata, the tests would then pull in those extra packages: maybe I'll work on trimming them down, too. - - It probably breaks something in the 'compattests' realm; I haven't tried that, yet. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJra8y+gerLs4ltQ4RAnxvAJ9WijLQGtxOnqMX1XvNJFS4LWZ+PACfWhqJ KMrDhDwlA+kHYMOVuP34K6k= =K8ZI -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] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: 2009/3/4 Tres Seaver tsea...@palladion.com: Log message for revision 97465: Branch removing zope.deferred. Changed: D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/ -# BBB: Backward-compatibility; 12/05/2004 -from bbb.interfaces import * Note, that the context-dependent/presentation/view stuff that was in BBB interfaces are still used in some places, like zope.publisher, so this needs more careful (re)moving. I think that one of the nice places for those interfaces is zope.browser, however they are not necessary browser-related, so maybe they should be moved elsewhere or just placed in zope.component.interfaces for now, as they're really tiny. Yup. That was probably a case of premature deprecation (back in 2004). Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. -- WBR, Dan Korostelev ___ 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] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: 2009/3/4 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: 2009/3/4 Tres Seaver tsea...@palladion.com: Log message for revision 97465: Branch removing zope.deferred. Changed: D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/ -# BBB: Backward-compatibility; 12/05/2004 -from bbb.interfaces import * Note, that the context-dependent/presentation/view stuff that was in BBB interfaces are still used in some places, like zope.publisher, so this needs more careful (re)moving. I think that one of the nice places for those interfaces is zope.browser, however they are not necessary browser-related, so maybe they should be moved elsewhere or just placed in zope.component.interfaces for now, as they're really tiny. Yup. That was probably a case of premature deprecation (back in 2004). Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. Well, part of the dependency cleanup involves making a possibly- controversial coding style change (from imports), and I may have broken something in the 'compattests'. I would also like to make 'setup.py test' actually work in the absence of buildout. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrbMN+gerLs4ltQ4RAp7FAJ9WewCeb9MjTCs+uLjBzKVGjxTgIACghhhI Zm+bEA0HXgd7ULswVhJ8zzo= =1lIL -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
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
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
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] SVN: zope.component/branches/tseaver-wo_zope_deferred/
Tres Seaver wrote: - - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE. Why is zope.deferredimport a problem? Does it do something CPython specific? As a small utility, I don't think it's a particualrly troublesome dependency. 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] SVN: zope.component/branches/tseaver-wo_zope_deferred/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: - - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE. Why is zope.deferredimport a problem? Does it do something CPython specific? As a small utility, I don't think it's a particualrly troublesome dependency. Have you looked at what zope.deferredimport actually does? It uses zope.proxy to create wrappers around objects in sys.modules! There is effectively no way that any Python developer who hasn't already drunk the Zope Koolaid will ever willingly put up with such a grotexque^Wingenious hack. The only way it can do that is via a C modlue (in zope.proxy), because CPython won't tolerate duck typing of module objects, which makes it a deal-killer for the non-CPython platforms, too. I thought originally that the dependency was there to support emitting deprecation warnings, but not so: essentially, the deferreed imports were there to paper over import cycles. Ripping it out meant making the inter-module dependencies *within* zope.component explicit and sane, which was a net win, too, even without losing the C extension. Note that I also had to switch to from imports, because the other style is the actual source of the cycles (e.g., using the '@component.adapter' decorator at module scope). The transitive dependencies in the released zope.component (not counting testing dependencies) are: - zope.interface - zope.event - zope.deprecation - zope.deferredimport - zope.proxy On my branch, the transitive dependencies (again, not counting tests) are: - zope.interface - zope.event which feels a lot saner to me: zope.interface is obviously required for anybody using zope.component, and zope.event is tiny, unchanging, and pure Python (I *am* dubious of the real-world utility of the events it actually emits, but that is another story). I think that minimizing non-essential dependencies is crucial to getting wider use of the packages, especially outside the purple-lipped crew here in the compound. :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrflv+gerLs4ltQ4RAnylAJ0f/uulXowSBdulTT0kO+bUzIXwWwCgoSyi a6M2GtcQN/qKag/bYammkmI= =iE1H -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 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
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 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 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
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. I fail to see how this is any sort of problem at all. - C
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 beyond doctests. I'll also note that documentation for the whole *system*
Re: [Zope-dev] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver tsea...@palladion.com: Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. Well, part of the dependency cleanup involves making a possibly- controversial coding style change (from imports), Will it cause any problems in packages that use existing zope.component with its current coding style? If not, then why can it be a problem? and I may have broken something in the 'compattests'. Well, that certainly needs to be tested, but I don't think it's a blocker for merging. We're on the development version anyway. :-) (however, of course if would be nicer to do compattests before merging, but this should'nt take much time?) I would also like to make 'setup.py test' actually work in the absence of buildout. Isn't this as easy as adding the contents of test extra to the test_requires parameter? -- WBR, Dan Korostelev ___ 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
On Wed, Mar 4, 2009 at 07:52, Chris McDonough chr...@plope.com 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 )
