Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 18:03:17 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote: Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. Well, yes and no: My idea is that there will be a well-defined set of core packages, and probably some extra packages that are also embraced (e.g. maybe z3c packages, e.g. z3c.form). Of course, trying to embrace every zope package out there will not work. But I think it will make sense to embrace packages that cover a common usecase, for instance, creating remote tasks is nothing uncommon and will be needed by many people. Therefore I'd suggest to embrace at least one package that covers that functionality (e.g. lovely.remotetaks, or zc.async, or something else). For all other packages, it will make sense to create some infrastructure, as stated in another mail of Martijn. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 17:48:37 schrieb Martijn Faassen: Hi there, Lennart Regebro wrote: [snip] And it is in any case in no way even remotely connected to the group Martijn proposed and has been discussed in this thread. - Attracting newbies to web development is not a task of the Zope Framework project directly, and here I diverge from Hermann. That's a task of the Plone project or the Grok project, etc. I do think that the Zope Framework leadership could be much better at attracting and stimulating contributions to the libraries. Attracting more users is important, but that's a task for the Zope 3 app server developers (however they organize) or the Grok project. The Zope Framework is a second-level provider to these projects, and in reality of course people who care about these projects will do most of the driving of development of the Zope Framework. It's a forum where all users of these libraries (many or just a few) can get together, work out our diverse interests, and coordinate. Ok, it seems I mixed up the Zope3 app server and the Zope Framework a little.So, I agree that attracting newbies should better be done via Grok/Zope3 app server or anything else that build on top of the Zope Framework, as this is the logic path. Nevertheless the Zope Framework should have: - Documentation - Central Website - Some other structure for collaboration (mailing list...) And I think that these points should also be a topic of the steering group. I think an ideal approach would be that the above can be seamingless integrated in upper-level frameworks, so that the step from Zope3 app server/Grok to the Zope Framework is as easy as possible, and, moreover, that efforts need not to be doubled (e.g. that someone writing documentation for Zope 3 app server has to write something about interfaces or the component architecture). Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 19:00:12 schrieb Baiju M: On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com wrote: [snip] The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. [snip] I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. [snip] As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. Users of the Zope framework can use this list, but may also diverge from it where they see fit. Other projects (such as the Zope 3 application server and the Grok project) also have a Known Good Sets that expand on the Zope framework list (and may diverge from it). Each of these consumer projects can of course have their own release process, schedule and version numbering. [snip] It may very well be true that in some time we'll develop clusters of libraries that can be more or less managed on their own. The ZMI is such a cluster that I hope will eventually emerge (and that the Zope Framework Steering Group doesn't care about directly). That'd reduce the coordination overhead. But sometimes we do need to take coordinated action, and I don't see that need disappearing entirely. I think those who care about Zope 3 (framework/app server/libraries/ or whatever) should form a team and mailing list to discuss about the future development. All other major consumers of the Zope Framework Project has their on mailing list for discussions. I guess very soon zope-dev list will become inappropriate to discuss about Zope 3. Just like Grok,Repoze etc. it is better to create a list for Zope 3, may be re-activate zope3-dev list to discuss about the Zope 3 (framework/app server/libraries/ or whatever). Well, if no one cares about Zope 3, let's leave it. What would be interesting to know is: - Who is out there - What these people are using: * Zope libraries * Zope 2 * Zope 3 app server * Plone * Grok * Something else - Who has already contributed (and what) - Who has the technical expertise and time to contribute This probably would help us/the steering group to form teams around different projects. For instance, as the steering group is not about the Zope 3 app server, there needs to be some team for that part. And I am personally interested if the Zope 3 app server is something that's dying in favour for other projects (Plone/Grok) or is actively used. Best Regards Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 00:36 +0100: ... * how will the community make hard decisions where lots of people disagree? You try to achieve consensus. When you do not, you get the chance that people turn away. ... * who reminds us of necessary tasks and directions we're going into? Beside the reminders, you need people that do the work. For this, at least, these people must be convinced. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote at 2009-3-3 17:21 +0900: ... How many times have we gotten bogged down in semantics or naming discussions and killed off the momentum behind something? A clear notion of semantics and well chosen names are important for any project. I would not want momentum resulting in confused semantics and misleading names. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote at 2009-3-3 22:11 +0100: ... backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. Large applications are built upon the framework. If the framework too often drifts away, the maintenance costs for these applications gets too high -- and make the framework unattractive. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: Martijn Faassen wrote at 2009-3-3 22:11 +0100: ... backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. Large applications are built upon the framework. If the framework too often drifts away, the maintenance costs for these applications gets too high -- and make the framework unattractive. But if the framework is no longer monolithic, you can keep using the bits you need for BBB, while selectively updating newer pieces. The more loosely-coupled the pieces are, the more likely such a partial upgrade is to work. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsIWO+gerLs4ltQ4RAlWuAKCwUyNkbz9zKaLHgWp/WwTTPjufVgCePgxk PIIdR4FnOAUMuJgKupdjpYQ= =WiRX -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 8:50 Uhr, Chris McDonough wrote: Andreas Jung wrote: 2) I'm also not in favor of a giant lockstep set of software versions shared between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this as continuing our mistakes of old by trying to treat some collection of software as Zope as opposed to letting parts of it survive or die on their own based on merit; it'd be more effective to just let each framework use (or disuse!) whatever versions of stuff that work best for it. That's why the software is broken out into individual components in the first place; we should encourage diversity in component usage. Instead of trying to legislate and bless some set of components as a version, we should just work to make each piece better and worthwhile to use independently; it's value would be in its actual usefulness rather than some belief that it works well with the other components in the version. Could we at least agree that lockstep versioning of a huge set of Zope eggs to be shared across many frameworks is not optimal for the long term and that it would be better if each framework could pick and choose whatever components and versions it actually needed? Could we also agree that this would tend to result in better dependency partitioning (X depends on Y, I don't need Y, I just need X, let's fix that)? A central maintained KGS for Zope 3.X components is necessary since only a minor number of core developers knows exactly which version match together. You can not expect that non-core developers have this knowledge. In places that require cross-package API contracts, each contract should be spelled out in an interface. If each contract is spelled out in an interface, non-core developers should have no problem gaining this knowledge. That's what interfaces are for. Interfaces are one side of the medal, the other side are dependencies expressed through version pinning. We have had enough examples with version conflict with modules that would obviously fit together based on their interface definitions. That's where a KGS helps a lot - however this is not a contradiction to the approach that Tres pointed out with maintaining a per-project index with hand-selected packages. I find this idea very compelling for a bunch of usecases - not sure if this a general approach - one out of many. Andreas - -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - E-Publishing, Python, Zope Plone development, Consulting -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmuOPAACgkQCJIWIbr9KYwOjQCgt9O7I4qdRBlzqsm93OfzYBf2 VYQAoII60shD+EkPF9TqaTb5ZaQQ3rDT =DrbH -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote: 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? To the extent we can discourage the formation of the one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I think it's a good idea. But in reality, I think nothing needs to be done: group-forming will always be a self-selecting process. No, we want Zope 3.4 to have one set of modules with one API, and Grok 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a Grok 1.1 (or something) and a Zope 2.13. So we DO want lockstep and to use the same major KGS over all these versions. At least I do I don't see why this must result in parts that should die being left undead. This just seems like a blindingly obvious antigoal to actually breaking apart the software into more discrete bits using eggs. Why not just stick with a huge tarball release or one single egg if it all has to be versioned through time to 99% of its consumers as one giant collection of software treated as a unit? If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep would not pose a problem for Repoze, would it? Nope. Then again, if Repoze doens't want to be a part of The Zope Framework users but always make their own set of modules, that will admittedly lessen the purpose of it, as the minimalistic attitude of Repoze.bfg would work as a good test of what should be in the framework in the first place. Right. No one except people who've already bought in to the notion of Zope software as one huge pile will benefit from the lockstep centralized planning. It won't gain Zope any new users; no different framework users will begin to use Zope software as a result of this plan. How is this different than the current status quo? Could we at least agree that lockstep versioning of a huge set of Zope eggs to be shared across many frameworks is not optimal for the long term Well, since it's shared by many frameworks, I'm not sure it would be huge. But that's a matter of taste of course. But in any case, through this discussion, I must admit that I not not understand why this would pose problem. It doesn't pose a problem. It's just business as usual. and that it would be better if each framework could pick and choose whatever components and versions it actually needed? It can. These are not mutually exclusive. A central KGS for the core framework does not exclude you making your own KGS, neither does it mean you can't release each module separately. Could we also agree that this would tend to result in better dependency partitioning (X depends on Y, I don't need Y, I just need X, let's fix that)? I don't see how these are related. When components are not treated as one giant pile, and it's expected that you should be able to use pieces of the pile selectively without buying in to some unrelated software, dependency management becomes far more brutal and realistic. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 09:21, Chris McDonough chr...@plope.com wrote: To the extent we can discourage the formation of the one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I think it's a good idea. But in reality, I think nothing needs to be done: group-forming will always be a self-selecting process. Well, at least we should try this first, I agree with that. No, we want Zope 3.4 to have one set of modules with one API, and Grok 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a Grok 1.1 (or something) and a Zope 2.13. So we DO want lockstep and to use the same major KGS over all these versions. At least I do I don't see why this must result in parts that should die being left undead. This just seems like a blindingly obvious antigoal to actually breaking apart the software into more discrete bits using eggs. Why not just stick with a huge tarball release or one single egg if it all has to be versioned through time to 99% of its consumers as one giant collection of software treated as a unit? But it doesn't have to be treated as a unit. I don't know what you mean with version through time to 99% of its customers. To me having releases of modules and releases of sets of modules is orthogonal and does not contradict each other. Then again, if Repoze doens't want to be a part of The Zope Framework users but always make their own set of modules, that will admittedly lessen the purpose of it, as the minimalistic attitude of Repoze.bfg would work as a good test of what should be in the framework in the first place. Right. No one except people who've already bought in to the notion of Zope software as one huge pile will benefit from the lockstep centralized planning. I have the feeling that either you or me have completely misunderstood the proposal, because I don't think you are talking about the same proposal as me. Could we also agree that this would tend to result in better dependency partitioning (X depends on Y, I don't need Y, I just need X, let's fix that)? I don't see how these are related. When components are not treated as one giant pile, and it's expected that you should be able to use pieces of the pile selectively without buying in to some unrelated software, dependency management becomes far more brutal and realistic. Yes. And I still do not see how this is related to the proposal. It is expected that you should be able to use pieces of the pile selectively, and it will continue to be expected. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote: What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, They will be formed by people grouping together to work on a piece of software, if such a group is necessary. - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. Then these higher level groups will help coordinate the lower level packages. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. The steering group would not and could not help with any of these problems. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 08:16:26 schrieb Lennart Regebro: 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? But isn't that the current situation? I think there are two scenarious when people will deal with a package in-depth on their own: 1) They found a bug: I made the experience that in case I find some bug and dig into some Zope 3 code, things tend to become very complicated and I often can't understand/fix it. For instance, I found some bug/misbehaviour regarding combination of virtual hosts and ++xyz++ URL-variables (forgot the name for that) and was not able to apply a clean fix due to lack of understanding. I could not find anyone on the list, who was responsible for that piece of code, so I did some hacking and never committed this (dirty) hack as it's certainly not up to the Zope 3 standards. 2) They want to extend a package: In order to do that, I'd first like to understand the package in-depth, so that my extensions don't break concepts and code. But it seems that there are many packages (and even core packages) where nobody seems to feel responsible for, or, I just don't know who it is and can therefore not get to the required information. If there's no one that is motivated by (1) or (2), the package is abandoned (although it may even have core functionality). And my impression is that this has already happend for some packages, which is bad. Therefore I think it would be a great advantage if there is some group that makes sure that each package has someone associated with, who has in-depth knowledge and maintains it. And if there is no interest in a package anymore and it's not used, this group may give it the status umaintained and kill it off. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer du...@qwer.tk wrote: [snip] - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. +1 I believe packages developed as part of the Zope 3 project is here to stay for a long time (of course, after dependency cleanup some of them may become obsolete). This will happen even if some of the frameworks based on it are no more available. Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote: What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. The steering group would not and could not help with any of these problems. Why? Can you elaborate? Who/what group woud play that central/integrating role? Maybe we have different perceptions of a steering group, but my impression was that this group would see the above points as their key topics. Maybe I don't get your point, but your suggestion seems to be to let things go in a natural flow as it happens now. But that would imply that the current situation is satisfying, which seems not to be, as can be read in all those various posts regarding this topic. What would be further interesting is, if there are any successful open-source projects, that implement such a non-leadership/natural flow model, because I'm not aware of any. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 10:56, Hermann Himmelbauer du...@qwer.tk wrote: Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro: On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote: What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. [...] The steering group would not and could not help with any of these problems. Why? Can you elaborate? Who/what group woud play that central/integrating role? Maybe we have different perceptions of a steering group, but my impression was that this group would see the above points as their key topics. I don't think it's possible, and it seems to me to be a rather strange idea to have a group keep track of all the packages in the Zope world and somehow categorize them by quality. And it is in any case in no way even remotely connected to the group Martijn proposed and has been discussed in this thread. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 1:07 AM, Chris McDonough wrote: Martin Aspeli wrote: Chris McDonough wrote: Sorry, the you above in you scolded was Martin Aspeli, not Faassen. Note that the scolding had something to do with you breaking Plone trunk due to a transitive change in Chameleon, and the realisation that from this point on, any package shared between repoze.bfg and Plone (or anything else) that is configured with ZCML, will probably need to be forked. We found a workaround with Chameleon, but not one that will scale. The fix is totally scalable and completely correct. Chameleon.zpt just does not have any (real) ZCML anymore. Any package that has ZCML is, by definition, written for some framework as stuff that is meant to be overridden, otherwise it wouldn't be written as configuration. ZCML is unlike code in this way. If it wasn't meant to be overridden, it would be in code. All packages which are meant to be maximally useful outside the scope of that framework should be split into two things: the library portion, then some portion that contains ZCML for gluing in to some framework that wants ZCML in some specific configuration. When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! Package sharing between repoze.bfg and Plone should not mean that BFG gets dragged down, paying for things it specifically doesn't want to eat. BFG never claimed to sign up for Plone's contracts. I sense the logic of Chris's position: if the Zope Framework is as big as every current use case in Zope2+Zope3+Grok+etc., with nine years of accumulations on each (3 forms systems in one of them), then we're missing the goal (IMO). We'll make life incrementally better for ourselves, but we'll still scare off the folks who aren't after Uberthing. Plone is going towards a smaller-and-smaller core that is only as big as the manpower to do a great job at keeping it stable. Meaning, very small. Hopefully the Zope Framework is a tiny little thing that pays only for what it eats. Hopefully the goal is to make a very good microframework (or even better, set of libraries). If you can't make the best configuration language possible because one line of includes to get trusted adapters is an unconscionable burden is the rule, then I know how this movie ends. --Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! In this case, you totally misread my post. It broke for all users of zope.component, and I never, once, made the argument that Chameleon was part of Plone or should be driven purely by Plone's needs. I have no such pretentions, nor does anyone else I know, about this, or zope.* or the CMF package or, well, anything that is not expressly part of Plone. That particular discussion is over, though, and I have no interest in having it again. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 8:16 AM, Martin Aspeli wrote: Paul Everitt wrote: When I read Martin's post, I had a similar reaction. Namely, that the convenience of the Uberthing (Plone in this case) will always trump the desire of packages trying to survive on their own for new audiences. At the time of the configuration scolding, I remember thinking: there's little interest here in Chameleon's goal to be bigger than Zope. Keep things convenient for us in Plone! In this case, you totally misread my post. It broke for all users of zope.component, and I never, once, made the argument that Chameleon was part of Plone or should be driven purely by Plone's needs. I have no such pretentions, nor does anyone else I know, about this, or zope.* or the CMF package or, well, anything that is not expressly part of Plone. Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Thu, Mar 5, 2009 at 3:04 AM, Hermann Himmelbauer du...@qwer.tk wrote: Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough: Tather than reply in kind here, let me summarize: I'm glad we agree more than we disagree, and I apologize if I've attributed to you beliefs that you don't have. It's heartening to hear that you're in favor of most of the things I'm also in favor of. But we do have real differences in opinion I think. I'd rather be constructive than obstructionist here: at the end of each item below I ask for an opinion based on a suggestion. 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? What I don't see in your proposal is, how these subset-groups would be coordinated, which leads to the following: - How would these groups be formed? If there's nobody who encourages people to do so, - Higher level package/groups may have a hard life in case basic packages/groups are not coordinated and all go their own way. - How does some foreigner know, if a package is actively supported, umaintaned, deprecated etc.? How does he know, what packages exist, what they are good for and the like? For instance, I yesterday wrote that I use lovely.remotetask, then I was asked on the list why I did not use the (maybe better) zc.async package. Know why? I did not know that it existed. - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. - Newbies won't be attracted by single packages. Instead, they want something complete. Who would be interested in Plone if it would consist of various packages that people would have to draw together by themselves, without decent documentation? To my mind, one key point is attracting more users. And that can only be done if we try to view things from an external, newbie-perspective. Some Ruby on Rails / Java / Turbogears programmer will only be attracted by some big picture but probably not by a collection of some subpackages. So, my impression is that there is a need for some steering group, that will, however, encourage people to form groups around packages and maintain them. I envision a Council of Elders with student representation. The Elders either know, or know who knows the history and current state of affairs, the students know the struggles of the newbies. They could provide welcome wagon, triage, and guide service for navigating the Zope wilds. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - zope-...@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi Paul Betreff: Re: [Zope-dev] the Zope Framework project On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. Regards Roger Ineichen These two paragraphs seem contradictory. [wink] We'll consider the matter closed. --Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On 3/4/09 9:47 AM, Roger Ineichen wrote: Hi Paul Betreff: Re: [Zope-dev] the Zope Framework project On 3/4/09 8:16 AM, Martin Aspeli wrote: [...] Chameleon provided something that made it work for those users, while allowing it to not be burdened by those needs. Everybody wins. Hopefully such solutions will be the norm in the future. That particular discussion is over, though, and I have no interest in having it again. I hope not! I don't like to have any code in an application which I don't use. But right now I don't see a better solution for the chicken and egg problem we have with z3c.pt and chameleon support in our base packages. In older days we used monkey patches for that problem, but that's no solution anymore. I agree, and I think this case is a good exemplar for the challenge. Chameleon wanted to make a good templating engine that was independent of megaframeworks. For that, it needed/wanted a configuration language that met your statement I don't like to have any code...I don't use. But legacy in one of the projects changed this from a self-contained, 1x amount of work into a cobweb of bigger issues, control in the hands of others, and 10x the work. Human nature says that's demoralizing. Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. --Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there,
Hanno Schlichting wrote:
[snip]
You can try to bake more leadership of the overall Zope community into
this, but I think this is a fruitless fight right now. Reduce the scope,
try make some things better and don't step on other peoples feet if you
don't need to. For example don't try to push out style-guides for the
entirety of the svn.zope.org repository. They lead to bike-shed
discussions and discourage contributions.
Yes, I agree with restricting scope. I wanted to restrict scope to a set
of libraries that's shared between a bunch of the big consumer projects,
and that I called the Zope Framework. It's not something you install
by itself, and it's not something that everybody uses every bit of. But
it is something that is shared by a lot of people and we need to take
responsibility for and manage as a whole, not just as a whole bunch of
parts.
Beyond that in our repository, the framework steering group would have
influence but no authority. The document reflects that thinking.
Repository-wide guidelines do exist, such as the copyright assignment
policy, and the general 'trunk'/'branches'/'tags' structure of projects,
and the way people name distributions of packages the same name as the
package name ('zope.foo' is released as 'zope.foo'), and I'm sure we can
come up with many more of such conventions. It's not something for the
Zope Framework group to care about though. Part of that will just happen
by consensus and example anyway, but outside of the realm of the Zope
Framework Steering Group.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hey there, Chris McDonough wrote: 1) I'm not in favor of a single steering group for the *entirety* of all Zope software. We've tried a similar thing in the past (via the foundation structure); it didn't work and I'm not sure how we'd expect things to turn out any differently this time. Instead, perhaps the focus of groups should be on some much smaller subset of Zope-related software (e.g. the zope.interface+zope.component group, the zope.schema group, the ZODB group, etc). Could we consider this? I don't recall we actually did anything within the Foundation structure. The structure was there in the bylaws but was never applied, so I don't think that can be qualified as a failure. :) The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. I do think the steering group should start worrying about a larger amount of the libraries rather than a small set. Part of the reason is exactly so we *can* identify subsets and properly delegate their management. Delegating their management will require some kind of agreement on groups coordinating however. We need to have an overview of the whole in order to know how to evolve the parts in many cases. For instance, if we move some class due to a dependency cleanup, we need to have an effort to update the libraries in the whole to use the new imports relations. I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. The ZODB is a good example where I'm not sure whether the ZODB should be considered part of the Zope Framework at all. I think we should see this as an external library that the framework builds on. The idea that there is a bunch of people who take the responsibility for managing the whole doesn't mean they should be obstructing moves to improve the parts. Similarly I assume you're taking some form of responsibility for Repoze and that this is helpful the evolution of the parts of it. My hope is that we'll see more of a catalyst function than anything else. I think the answer to proposed changes in the lower layers (which is always risky) should be to point out potential risks and say: we can make this change, but we also need to make sure we do X. The answer should typically not be no. If it is a no, we should actively try to identify the use cases driving the proposed change and look for alternative solutions. 2) I'm also not in favor of a giant lockstep set of software versions shared between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this as continuing our mistakes of old by trying to treat some collection of software as Zope as opposed to letting parts of it survive or die on their own based on merit; it'd be more effective to just let each framework use (or disuse!) whatever versions of stuff that work best for it. That's why the software is broken out into individual components in the first place; we should encourage diversity in component usage. Instead of trying to legislate and bless some set of components as a version, we should just work to make each piece better and worthwhile to use independently; it's value would be in its actual usefulness rather than some belief that it works well with the other components in the version. I don't understand why you think a list of versions that has release numbers that we know works together is a blocker for independent evolution for the individual libraries. I think there are two parallel efforts: * evolving libraries standalone. We should improve those libraries so we can think about them standalone. If a library contains ZMI code, it's harder to think about it standalone for instance. * making sure that there is a list of library versions that people can install that isn't broken. That is, run the tests for these libraries in isolation and together. If a decision was made to change one library, make sure that all the other libraries in the list are updated so they actually still work. I see both efforts as necessary. If you just care about a smaller list of libraries, you don't have to worry about a larger list of course, though you will have to coordinate with some people who do. You probably can do quite well constructing your own list as it's a much smaller one. That's fine, and nothing should stop you. But the reality is that many people in this group *do* care about a larger list of libraries. Could we at least agree that lockstep versioning of a huge set of
Re: [Zope-dev] the Zope Framework project
Hi there, Andreas Jung wrote: [snip] This would definitely make sense to me. With respect to a steering committee: I am also a bit skeptical about such a committee. I think that the upcoming ZF board will have a good representation of each Zope project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects. I don't agree the Zope Foundation board should directly steer development of the Zope software. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wednesday 04 March 2009, Martijn Faassen wrote: I don't agree the Zope Foundation board should directly steer development of the Zope software. I totally agree. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: [snip] This just seems like a blindingly obvious antigoal to actually breaking apart the software into more discrete bits using eggs. Why not just stick with a huge tarball release or one single egg if it all has to be versioned through time to 99% of its consumers as one giant collection of software treated as a unit? Why not: * Repoze and others couldn't use the bits they care about. * Grok (or anything else) couldn't diverge from a common KGS when it needs to. * individual apps couldn't diverge from a common KGS when *they* need to. * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Baiju M wrote: On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer du...@qwer.tk wrote: [snip] - I think, Zope 3 is not only about some seperate packages, but about a complete programming experience. Thus there needs to be some integrating force, that draws together all these packages, writes some documentation / tutorial / website etc. +1 I believe packages developed as part of the Zope 3 project is here to stay for a long time (of course, after dependency cleanup some of them may become obsolete). This will happen even if some of the frameworks based on it are no more available. I'm fine if some people want to get together and organize Zope 3 to offer an integrated experience. Zope 3 is the thing people install and start projects with. It's what should have a website explaining what it is all about. It's not what the Zope Framework Steering Group cares for however. It doesn't directly care for Zope 3. Zope 3 is explictly *not* the Zope Framework project, just like Grok isn't the Zope Framework project. Both have a stake in the project and will participate in the project, but just like the Zope Framework Steering Group doesn't manage grok.zope.org, it won't manage zope3.zope.org (if such a thing exists) either. While I'm quite interested in volunteering to help coordinate Zope Framework development, I'm not at all interested in volunteering to help coordinate Zope 3 app server development. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 17:26 Uhr, Martijn Faassen wrote: Hi there, Andreas Jung wrote: [snip] This would definitely make sense to me. With respect to a steering committee: I am also a bit skeptical about such a committee. I think that the upcoming ZF board will have a good representation of each Zope project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects I wasn't proposing that. I wanted to point out that the persons on the board could work out on proposal or on some agreement how to approach the controversial points...basically to layout a consensus plan. This not about steering the development but about finding some overall consensus. Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmuszUACgkQCJIWIbr9KYwcbgCglkri5JcNPKHAQu/pWGcYWgUM WNIAoKQXa0HW404juEf/6zDo1ENdnjhU =h1TJ -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote: Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Paul Everitt wrote: [snip] Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 18:03, Martijn Faassen faas...@startifact.com wrote: I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. But we know pretty much who is impacted by this, and the people with enough gravitas to be able to say Yay or Nay to these sorts of refactoring. And they are all on this list. And if there was a Steering Group, most of them would need to be on that group. If it's impossible for these people to agree when discussing on this mailing list today, why would the suddenly agree on this mailing list if we call them The Zope Framework Steering Group? I really don't understand that. I think it is WAY more likely that we get agreement and come forward if we first of all stop having the internet between us. We all know how easy it is to misunderstand intentions and tone of voices on mailing lists as compared to real life. And if it *still* is impossible for these people to agree, then I can't see the Steering Group working either, and then we need a new dictator. But I don't think that's needed, because the technical disagreements we have here are so minor, and seems mostly based in massinderstindung. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.03.2009 17:26 Uhr, Martijn Faassen wrote: Hi there, Andreas Jung wrote: [snip] This would definitely make sense to me. With respect to a steering committee: I am also a bit skeptical about such a committee. I think that the upcoming ZF board will have a good representation of each Zope project on the board in order to address things on the board level. You haven't read my document very well if you think I'm proposing a Steering Group for all Zope projects I wasn't proposing that. I wanted to point out that the persons on the board could work out on proposal or on some agreement how to approach the controversial points...basically to layout a consensus plan. This not about steering the development but about finding some overall consensus. If you're talking about consensus about code, that's really not my vision of what the Zope Foundation board is for. I do think the Zope Foundation board might do something about community organization. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: snip * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. (I'm running out of steam on responses here. This will likely be one of the last). You've been saying this: we'll just identitfy and maintain this giant set of versions for backwards compatibility purposes and for purposes of *moving platforms forward through time*. But you also seem to be saying *real soon now* we'll also be making hard choices about the life and death of things that make up the 'framework' and evaluating each on its merit as an idependent entity. Personally, I disbelieve that this real soon now will ever happen without having it as the *primary* and maybe the *only* goal. I believe to get success here (measured as gaining new Python developer users), our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a oh, by the way, this might be handy, not the raison d'etre of the group and this discussion. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Maybe not. But as far as I can tell, maintaining such a list is just business as usual and doesn't require any proposal at all. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Lennart Regebro wrote: On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote: Note that the Zope Steering group is not about packages that are not in the framework, so if lovely.remotetask isn't there, it can say little. Which is exactly my point. It surely isn't at the moment, and I don't see that it should be any time soon. What Hermann suggested is somebody that keeps track of all Zope software modules and tells him which is good and which is bad. That's not what you suggested, and as mention, I don't think it's even possible, and definitely not a good idea. I think it would be possible to provide an infrastructure so that people who care about communicating certain bits of information (this package exists and here is its documentation, this package is really not maintained and therefore deprecated) could do so. Perhaps this infrastructure will be developed as a side-effect of what needs to be done for those libraries in the Zope Framework anyway. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com wrote: [snip] The steering group isn't intended to take a responsibility for the entirety of the Zope software. Zope 2, Grok and the Zope 3 app server (which would be a distinct entity) would manage themselves and the Zope Framework steering group would not have a say over the libraries and configuration they add. [snip] I do also think that we should go to a smaller set of libraries. We currently share a huge amount of code that only one consumer actually uses. For instance, I think all of the zope.app.* packages which contain ZMI code can eventually be left to the management of the Zope 3 developers, meaning they'd not be part of the Zope Framework anymore. [snip] As a service to the users of the Zope Framework, the Zope developers also make available lists of version numbers of core libraries that have been tested to work together as a Known Good Set. This receives a version number and is the Zope Framework release. Users of the Zope framework can use this list, but may also diverge from it where they see fit. Other projects (such as the Zope 3 application server and the Grok project) also have a Known Good Sets that expand on the Zope framework list (and may diverge from it). Each of these consumer projects can of course have their own release process, schedule and version numbering. [snip] It may very well be true that in some time we'll develop clusters of libraries that can be more or less managed on their own. The ZMI is such a cluster that I hope will eventually emerge (and that the Zope Framework Steering Group doesn't care about directly). That'd reduce the coordination overhead. But sometimes we do need to take coordinated action, and I don't see that need disappearing entirely. I think those who care about Zope 3 (framework/app server/libraries/ or whatever) should form a team and mailing list to discuss about the future development. All other major consumers of the Zope Framework Project has their on mailing list for discussions. I guess very soon zope-dev list will become inappropriate to discuss about Zope 3. Just like Grok,Repoze etc. it is better to create a list for Zope 3, may be re-activate zope3-dev list to discuss about the Zope 3 (framework/app server/libraries/ or whatever). Well, if no one cares about Zope 3, let's leave it. Regards, Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, On Wed, Mar 4, 2009 at 6:26 PM, Chris McDonough chr...@plope.com wrote: Martijn Faassen wrote: snip * A clear set of explicit, layered dependencies in software is generally a good thing. We can start thinking about smaller pieces better. By splitting up into individually packaged and released bits, we are forced to think about these things more. (I'm running out of steam on responses here. This will likely be one of the last). You've been saying this: we'll just identitfy and maintain this giant set of versions for backwards compatibility purposes and for purposes of *moving platforms forward through time*. But you also seem to be saying *real soon now* we'll also be making hard choices about the life and death of things that make up the 'framework' and evaluating each on its merit as an idependent entity. Personally, I disbelieve that this real soon now will ever happen without having it as the *primary* and maybe the *only* goal. It can't be the only goal, we also want to build new stuff, right? Anyway, cleaning this stuff up is one of my most important goals for me personally; I and 5 others spent a week of our life doing that a month ago. Real soon now, zope.app.container and zope.app.folder and zope.app.keyreference and zope.app.catalog are not going to be the business of the Zope Framework developers anymore. They contain ZMI stuff the Zope Framework developers do not care about directly and will only care about indirectly if enough people speak up for it and are willing to work on it. I hope many of them join the real soon now. We have a line behind which I, and many others, don't have to care anymore. A receding line, leaving many things behind. I don't want to stop anyone else from caring about these other things. I can't anyway. If people do get together who want to develop Zope 3 the app server they should get together and organize. I hope I can convince them that this line is important and I hope I can convince people in general to care *more* about the stuff in the Zope Framework than anything else. The ZMI isn't the main thrust of Zope 3 development, and hasn't been for a long time anyway. I want to stop having to worry about it as soon as possible, and am willing to do work to get there. I believe to get success here (measured as gaining new Python developer users), I think success is not just python developer users, but also serving current users in the Zope 2, Zope 3 and Grok worlds better by having a more comprehensible platform. our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Look, I know you are not using the packages the way that I am, but can't we work together? I want these packages to make sense stand-alone very much, but I also need to consider them as part of a whole that needs to be managed. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a oh, by the way, this might be handy, not the raison d'etre of the group and this discussion. I think the group needs to have a list of packages it cares about, so we know what we're talking about. That way we know which packages we need to document and present and clean up, and we know *what* code we want to move out of packages that are in that list. And none of these packages can be broken so they *need* to work together! And we also present a list of versions that we have tested together as a service to the people who need such lists. If we *don't* make such a list we'll remain in the limbo where *all* packages are of some nebulous importance. I don't see this as at all incompatible with a group managing a list of versions that is known to work together, as a service to various groups which do need such lists anyway. Maybe not. But as far as I can tell, maintaining such a list is just business as usual and doesn't require any proposal at all. We're maintaining a different list now, for the Zope 3 app server that you install. What's in the list is mainly just inertia and ad-hoc decision making. That's not the list I'm talking about, though there'll be tremendous overlap to start with. I'm proposing not just a different list but a community that cares about those libraries. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: I believe to get success here (measured as gaining new Python developer users), our path forward needs to be way, way, way more radical and needs to involve making hard choices that treat individual packages on their own merit rather than even considering their role as part of a larger collection. That's the bottom line and I believe it's our fundamental point of disagreement. IMO, the part a package plays as part of the larger collection should be utterly and brutally subservient to its merit as a standalone package. Also IMO, if there were absolutely no list of versions known to work together, but each piece worked on its own and had merit on its own, we'd be in a far better place as far as attracting new users. Any list of packages-known-to-work-together should be a oh, by the way, this might be handy, not the raison d'etre of the group and this discussion. + lots Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 18:27, Martijn Faassen faas...@startifact.com wrote: If it's impossible for these people to agree when discussing on this mailing list today, why would the suddenly agree on this mailing list if we call them The Zope Framework Steering Group? I really don't understand that. Two answers: * they wouldn't all be on the steering group Why not? They are the people who should have a say, and they are the people most likely to be able to actually implement the decisions. * the steering group is *tasked* with coming to a single answer that is recorded. And implement it? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hi there, Paul Everitt wrote: [snip] Hopefully the Zope Framework proposal helps untangle this, and gets to a point where you don't have to keep the Uberthing in your head when doing something small. It's not small, as it has an impact on a lot of things that build on zope.component. Changing things low in something that lots of people have built stacks on is almost never a small change. Just look at Python 3, which makes a bunch of actually rather small but still incompatible changes to the language. While small from the perspective of the language, they're *huge* from the perspective of the users. So you need ways to coordinate such changes. I hope that having someone actually taking responsibility for zope.component's evolution can get the zope.security dependency out of it, and then improvements of repoze.zcml into it, or alternatively move the ZCML implementations *entirely* out of zope.component. I hope Chris will coordinate with us where necessary. I don't want security bits to sit around in zope.component either. grokcore.component doesn't need that code, just like repoze.zcml doesn't need that code. It's still there, even if you use repoze.zcml, just inactive. I tried to propose various ways forward. I got nowhere as I got 10 people giving 10 answers. Original problem unresolved. I'd like there to be someone who can make this decision and I'd like this someone to usually make *positive* decisions that work towards resolving the underlying issue, while coordinating with everybody that is impacted by this decision. The zope.component ZCML case was very much in my head as I wrote this proposal. OK, can we table the proposal per se for the moment, and prototype the process around the how do we move zope.component forward question? I'm not even sure I understand why you think anything in repoze.zcml has squat to do with zope.component, but I could just be missing the obvious. I have a strawman proposal, focused on stripping zope.component down as far as possible: 1. Merge my branch which drops the deferred import stuff. 2. Move the persistent registry stuff out into another package, including whatever support is needed to allow for people to migrate existing persistent references. Effectively, this moves one extra out to a package, *including* its testing dependencies. 3. Move the ZCML directive implementations out into another package, taking the zope.security and zope.configuration dependencies along with them. 4. Rework zope.hookable to use a pure-Python implementation via descriptors, instead of the C extension. Make it a non-optional dependency (but small and lightweight) of zope.component. If *current* profiling shows that the hooked things are bottlenecks, make the C version and optional replacement for the Python version. At the end, we would have three packages: zope.component depends on: - zope.interface - zope.event - zope.hookable zope.componentzcml (BIKESHED NAMING ALERT) depends on: - zope.configuration - zope.security - zope.configuration - zope.proxy - zope.i18nmessageid zope.persistentregistry (BIKESHED NAMING ALERT) depends on: - zope.configuration - ZODB3 Folks could then work on refactoring the new packages (e.g., depending on a separate 'persistent' package, making the secuirity bits optional, etc.). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrv9u+gerLs4ltQ4RApPjAJ4nZKFNxrrpiQfXgR8YRxtgn4YMSQCgk4wx TnvvQUfwhVo2X64YAyPAdm0= =KDnz -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hey Tres, Could you repost this to a new thread as I think people aren't paying attention to this thread very much anymore? I'd very much like to make progress on actual cleanups now. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
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] 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 )
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] 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] 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 )
