Re: [Zope-dev] the Zope Framework project
Andreas Jung wrote:
>> 2) I'm also not in favor of a giant lockstep set of software versions shared
>> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see
>> this as
>> continuing our mistakes of old by trying to treat some collection of
>> software as
>> "Zope" as opposed to letting parts of it survive or die on their own based on
>> merit; it'd be more effective to just let each framework use (or disuse!)
>> whatever versions of stuff that work best for it. That's why the software is
>> broken out into individual components in the first place; we should encourage
>> diversity in component usage. Instead of trying to legislate and bless some
>> set
>> of components as a "version", we should just work to make each piece better
>> and
>> worthwhile to use independently; it's value would be in its actual usefulness
>> rather than some belief that it works well with the other components in the
>> "version". Could we at least agree that lockstep versioning of a huge set of
>> Zope eggs to be shared across many frameworks is not optimal for the long
>> term
>> and that it would be better if each framework could pick and choose whatever
>> components and versions it actually needed? Could we also agree that this
>> would
>> tend to result in better dependency partitioning ("X depends on Y, I don't
>> need
>> Y, I just need X, let's fix that")?
>
>
> A central maintained KGS for Zope 3.X components is necessary since only
> a minor number of core developers knows exactly which version match
> together. You can not expect that non-core developers have this
> knowledge.
In places that require cross-package API contracts, each contract should be
spelled out in an interface. If each contract is spelled out in an interface,
non-core developers should have no problem gaining this knowledge. That's what
interfaces are for.
On the other hand, it shouldn't be as difficult as you mention above to
determine which versions of which packages work together: at least not
difficult enough to require the subcontracting of such work to some committee.
There shouldn't *be* that many things! If one package is depending on an
implementation detail of another package that isn't spelled out in an interface,
the two packages shouldn't be separate in the first place; they should be a
single package. If we took this simple idea to heart, I suspect lots of related
packages could be re-collapsed into a single package, making the set of packages
would less giant in the first place and more manageable.
> I agree on the point of making the components having their
> own lifecycle and to make them usable more independently.
Cool.
- C
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 07:52, Chris McDonough wrote:
> Tather than reply in kind here, let me summarize: I'm glad we agree more than
> we disagree, and I apologize if I've attributed to you beliefs that you don't
> have. It's heartening to hear that you're in favor of most of the things I'm
> also in favor of. But we do have real differences in opinion I think. I'd
> rather be constructive than obstructionist here: at the end of each item
> below I
> ask for an opinion based on a suggestion.
>
> 1) I'm not in favor of a single steering group for the *entirety* of all Zope
> software. We've tried a similar thing in the past (via the foundation
> structure); it didn't work and I'm not sure how we'd expect things to turn out
> any differently this time. Instead, perhaps the focus of groups should be on
> some much smaller subset of Zope-related software (e.g. the
> zope.interface+zope.component group, the zope.schema group, the ZODB group,
> etc). Could we consider this?
It's better certainly, but isn't this small enough in itself that
these groups will form naturally by whoever is working on it?
> 2) I'm also not in favor of a giant lockstep set of software versions shared
> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this
> as
> continuing our mistakes of old by trying to treat some collection of software
> as
> "Zope" as opposed to letting parts of it survive or die on their own based on
> merit; it'd be more effective to just let each framework use (or disuse!)
> whatever versions of stuff that work best for it. That's why the software is
> broken out into individual components in the first place; we should encourage
> diversity in component usage. Instead of trying to legislate and bless some
> set
> of components as a "version", we should just work to make each piece better
> and
> worthwhile to use independently; it's value would be in its actual usefulness
> rather than some belief that it works well with the other components in the
> "version".
I'm pretty sure Zope 2, Zope 3 and Grok wants to go in lockstep if
possible. I'm just pondering the nightmare of working having say Zope
3.4 with one API, and Zope 3.5 with a subtyly different API, and Grok
1.0, with yet another subtly different API and Grok 1.1 with another
subtly different API and Zope 2.12 with yet another subtly different
API and Zope 2.13 with yet another subtly different API. Urgh.
No, we want Zope 3.4 to have one set of modules with one API, and Grok
1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
Grok 1.1 (or something) and a Zope 2.13. So we DO want "lockstep" and
to use the same major KGS over all these versions. At least I do I
don't see why this must result in parts that should die being left
undead.
If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep
would not pose a problem for Repoze, would it? Then again, if Repoze
doens't want to be a part of The Zope Framework users but always make
their own set of modules, that will admittedly lessen the purpose of
it, as the minimalistic attitude of Repoze.bfg would work as a good
test of what should be in the framework in the first place.
> Could we at least agree that lockstep versioning of a huge set of
> Zope eggs to be shared across many frameworks is not optimal for the long term
Well, since it's shared by many frameworks, I'm not sure it would be
"huge". But that's a matter of taste of course. But in any case,
through this discussion, I must admit that I not not understand why
this would pose problem.
> and that it would be better if each framework could pick and choose whatever
> components and versions it actually needed?
It can. These are not mutually exclusive. A central KGS for the core
framework does not exclude you making your own KGS, neither does it
mean you can't release each module separately.
> Could we also agree that this would tend to result in better dependency
> partitioning
> ("X depends on Y, I don't need Y, I just need X, let's fix that")?
I don't see how these are related.
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04.03.2009 7:52 Uhr, Chris McDonough wrote:
> Tather than reply in kind here, let me summarize: I'm glad we agree more than
> we disagree, and I apologize if I've attributed to you beliefs that you don't
> have. It's heartening to hear that you're in favor of most of the things I'm
> also in favor of. But we do have real differences in opinion I think. I'd
> rather be constructive than obstructionist here: at the end of each item
> below I
> ask for an opinion based on a suggestion.
>
> 1) I'm not in favor of a single steering group for the *entirety* of all Zope
> software. We've tried a similar thing in the past (via the foundation
> structure); it didn't work and I'm not sure how we'd expect things to turn out
> any differently this time. Instead, perhaps the focus of groups should be on
> some much smaller subset of Zope-related software (e.g. the
> zope.interface+zope.component group, the zope.schema group, the ZODB group,
> etc). Could we consider this?
This would definitely make sense to me. With respect to a steering
committee: I am also a bit skeptical about such a committee. I think
that the upcoming ZF board will have a good representation of each Zope
project on the board in order to address things on the board level.
>
> 2) I'm also not in favor of a giant lockstep set of software versions shared
> between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this
> as
> continuing our mistakes of old by trying to treat some collection of software
> as
> "Zope" as opposed to letting parts of it survive or die on their own based on
> merit; it'd be more effective to just let each framework use (or disuse!)
> whatever versions of stuff that work best for it. That's why the software is
> broken out into individual components in the first place; we should encourage
> diversity in component usage. Instead of trying to legislate and bless some
> set
> of components as a "version", we should just work to make each piece better
> and
> worthwhile to use independently; it's value would be in its actual usefulness
> rather than some belief that it works well with the other components in the
> "version". Could we at least agree that lockstep versioning of a huge set of
> Zope eggs to be shared across many frameworks is not optimal for the long term
> and that it would be better if each framework could pick and choose whatever
> components and versions it actually needed? Could we also agree that this
> would
> tend to result in better dependency partitioning ("X depends on Y, I don't
> need
> Y, I just need X, let's fix that")?
>
A central maintained KGS for Zope 3.X components is necessary since only
a minor number of core developers knows exactly which version match
together. You can not expect that non-core developers have this
knowledge. I agree on the point of making the components having their
own lifecycle and to make them usable more independently.
Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkmuKckACgkQCJIWIbr9KYwyVQCg4wa+BwWKTR++sHQGJRlD7K6/
C3cAoMgUSnynhrno3ja+m9Bf8wYJb9w1
=P85M
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver :
>>> Note that I'm not actually proposing that we merge this branch any time
>>> soon: it is a bit of a straw man for the ongoing process conversation.
>>
>> Why not? It looks that it's just a dependency cleanup, so it can be
>> merged (and released!) really soon (if noone objects, of course). I
>> personally don't like long-living branches and forks.
>
> Well, part of the dependency cleanup involves making a possibly-
> controversial coding style change ("from imports"),
Will it cause any problems in packages that use existing
zope.component with its current coding style? If not, then why can it
be a problem?
> and I may have broken something in the 'compattests'.
Well, that certainly needs to be tested, but I don't think it's a
blocker for merging. We're on the development version anyway. :-)
(however, of course if would be nicer to do compattests before
merging, but this should'nt take much time?)
> I would also like to make 'setup.py test' actually work in the absence of
> buildout.
Isn't this as easy as adding the contents of "test" extra to the
"test_requires" parameter?
--
WBR, Dan Korostelev
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Tather than reply in kind here, let me summarize: I'm glad we agree more than
we disagree, and I apologize if I've attributed to you beliefs that you don't
have. It's heartening to hear that you're in favor of most of the things I'm
also in favor of. But we do have real differences in opinion I think. I'd
rather be constructive than obstructionist here: at the end of each item below I
ask for an opinion based on a suggestion.
1) I'm not in favor of a single steering group for the *entirety* of all Zope
software. We've tried a similar thing in the past (via the foundation
structure); it didn't work and I'm not sure how we'd expect things to turn out
any differently this time. Instead, perhaps the focus of groups should be on
some much smaller subset of Zope-related software (e.g. the
zope.interface+zope.component group, the zope.schema group, the ZODB group,
etc). Could we consider this?
2) I'm also not in favor of a giant lockstep set of software versions shared
between notional releases Zope 3.5, Grok, and Zope 2.12. I can only see this as
continuing our mistakes of old by trying to treat some collection of software as
"Zope" as opposed to letting parts of it survive or die on their own based on
merit; it'd be more effective to just let each framework use (or disuse!)
whatever versions of stuff that work best for it. That's why the software is
broken out into individual components in the first place; we should encourage
diversity in component usage. Instead of trying to legislate and bless some set
of components as a "version", we should just work to make each piece better and
worthwhile to use independently; it's value would be in its actual usefulness
rather than some belief that it works well with the other components in the
"version". Could we at least agree that lockstep versioning of a huge set of
Zope eggs to be shared across many frameworks is not optimal for the long term
and that it would be better if each framework could pick and choose whatever
components and versions it actually needed? Could we also agree that this would
tend to result in better dependency partitioning ("X depends on Y, I don't need
Y, I just need X, let's fix that")?
- C
Martijn Faassen wrote:
> Hi there,
>
> I thought I should highlight this characterization of the Zope project
> because I agree with much of it but also disagree with much of it.
>
> Chris McDonough wrote:
>> I have no faith whatsoever that staying on the course we've been on for the
>> last
>> 9 years (
>
> 9 years is a long time, and while I agree that some cultural
> deficiencies (bad presentation) have lasted a very long time without
> much awareness of them, other deficiencies we're aware of and we're
> making progress on.
>
>> large interconnected codebase,
>
> You might've noticed a certain effort back in 2007 to split up our large
> interconnected codebase into small components, and efforts over time to
> try to break the connections in this code base. I think we could've been
> further along the breaking connections if we'd have some people with an
> overview of what's going on and an active interesting in driving that
> effort forward.
>
> Anyway, this is a characterization of where Zope technology is now, but
> it's a mischaracterization if you think that's where it wants to be or
> that no effort was spent on improving the situation.
>
>> backwards compatibility at all costs,
>
> I agree that have erred on the side of too much backwards compatibility.
> That increased the overhead of changes tremendously and blocked innovation.
>
> That said, I also see a lot of value of having a lot of components that
> can work together, and we do have quite a collection of those in the
> Zope ecosystem. This is why Grok is so careful to stay compatible with
> Zope 3, so we can share that pool of components.
>
> I'm in favor of an evolutionary approach where backwards compatibility
> on occasion is broken and it's clearly documented what developers should
> do to fix things. I'm also in favor of an approach where due to proper
> dependency factoring we can dump whole chunks of code (in particular ZMI
> chunks) in a large step.
>
>> lack of any consumable documentation at a package level,
>
> I agree that most package-level documentation could be improved
> tremendously by focusing on writing real documentation instead of
> half-test stuff.
>
> That said, we also have a tremendous level of package-level
> documentation and interface documentation, and it's a
> mischaracterization of the values of the Zope project to say we haven't
> cared about documentation at all. We innovated with interface-level
> documentation and doctests and making those available on PyPI. You've
> said in the past that this is a sort of "false optimum" that stops
> people from really fixing documentation issues, and I agree.
>
> We should make an effort to change our culture and redirect our
> documentation efforts to go beyo
Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
2009/3/4 Tres Seaver : > > - - Due to the 'test' extra, buildout pulls in a bunch of extra > dependencies, which I would like to zap (ZODB? really? just to > verify that the persistent registry survives 'dumps' and 'loads'?) > > - - 'setup.py test' needs 'zope.testing', but then doesn't do anything > (missing metadata). If I added the metadata, the tests would then > pull in those extra packages: maybe I'll work on trimming them down, > too. What's the motivation behind removing test dependenices for functionality that actually requires these dependencies, like ZODB/hookable/etc.? -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martin Aspeli wrote: > Chris McDonough wrote: > >> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. > > Note that the "scolding" had something to do with you breaking Plone > trunk due to a transitive change in Chameleon, and the realisation that > from this point on, any package shared between repoze.bfg and Plone (or > anything else) that is configured with ZCML, will probably need to be > forked. We found a workaround with Chameleon, but not one that will scale. The fix is totally scalable and completely correct. Chameleon.zpt just does not have any (real) ZCML anymore. Any package that has ZCML is, by definition, written for some framework as stuff that is meant to be overridden, otherwise it wouldn't be written as configuration. ZCML is unlike code in this way. If it wasn't meant to be overridden, it would be in code. All packages which are meant to be maximally useful outside the scope of that framework should be split into two things: the library portion, then some portion that contains ZCML for gluing in to some framework that wants ZCML in some specific configuration. So currently a glue package (five.pt) contains the ZCML that makes Chameleon work under Plone. All we did was remove the ZCML from chameleon.zpt itself and make some other package responsible for configuring the CA components used by chameleon.zpt. Frameworks that don't use ZCML don't even need to do this; they just import stuff. > The other cause for frustration was that you'd basically discounted all > possibility of doing this at the zope.component level (and thus letting > others benefit - Zope 2, Five and Plone needs rid of the zope.security > dependency too) before you'd even tried. However, I didn't know then > quite how disillusioned you were with Zope, or that you were quite so > willing to maintain forks/spin-offs/re-implementations under the Repoze > brand. How is the current situation where chameleon.zpt just has no ZCML not 100% exactly the right thing? And again, why can't Plone and Zope 2 just use repoze.zcml in reality? Why would this not work? I just don't understand. >>> And you think it's all due to the brand... >> Yes! Someone who *wants* to use basic ZCML directives but doesn't want >> zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and >> pytz can *already* use repoze.zcml; the only thing they don't get here is >> the brand. > > At least when the change was made to Chameleon, it caused > incompatibilities that basically broke another application using > zope.component's versions of these directives. I'm sure those could be > resolved (and were, with a workaround, in Chameleon), but it caused a > fair bit of pain. How could it have? The only difference was that the package stopped including the two ZCML utility declarations and you had to configure them independently. That was hard? What promises could possibly have been made to Plone that those declarations would exist exactly in the place they were previously until the end of time? If working around that particular problem was at all hard, or caused any pain, we've got huge problems because people *completely* misunderstand the purpose of ZCML and configuration in general. > But more importantly, there are lots of people using Zope the platform, > who have the same types of problems. For Zope 2 or Five or Plone to > switch wholesale to repoze.zcml is probably going to be impossible, for > documentation-related, practical and technical reasons. Sounds pretty handwavy. I am particularly suspect of these practical reasons; they just don't need to exist. I suspect my only crime here is that I didn't do it "the way its done" (nicely, with lots of maillist chatter, over the course of weeks); if I had, the outcome would have been the same: a package that offered ZCML component registration handlers that doesn't rely on zope.security. It might have been named "zope.foo" rather than "repoze.foo". But the outcome would have been exactly the same. There is no way to change zope.component and get both b/w compat and no dependence on zope.security. This is still true. Note that there's some misguided idea that repoze.zcml has "magic" in it for dealing with multiregistries and WSGI or somesuch; this is not true. It knows nothing of either; all it does is implement "utility", "adapter", and the "subscriber" directives without security-related attributes. > By forking > without attempting to solve the problem at the framework level, the > chance for collaboration and shared effort is lost. There is no loss here. At very worst, if folks are unwilling to actually just *use* the package, there is a blueprint for some merge into zope.component that does not require security stuff. Once there's enough political will to actually *do* the merge, and tell the people who want the security stuff that they'll need to lose (or at least change code), putting the code in is cutnpaste.
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Gary Poster wrote: > > We do have this system today. > > > > http://zope3.afpy.org/buildbot/waterfall > > Wow, great. > > Too bad about the failures. How are you announcing the failures ATM? No, maybe someone can provide that service? ;-) BTW, I have decided not to go after the failures until after PyCon, since I think a lot will be happening there. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Gary Poster wrote: > FWIW, the only polish I'd love to see is static pages for past dev > releases (or did I miss them?) Well, it is a matter of version numbering, but all versions that have a unique version number are listed here: http://download.zope.org/zope3.4/ We have not yet started giving Zope 3.5 dev releases unique numbers: http://download.zope.org/zope3.5/ Maybe we should make it a policy to name the releases Zope3.5dev1, Zope3.5dev2, etc. This would make it easier to identify failures of particular versions. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 10:57 AM, Stephan Richter wrote: > On Tuesday 03 March 2009, Gary Poster wrote: >> My mild counter proposal was this. >> >> - The ZF formally institutes an easy way for people to start "Zope" >> projects >> >> - Hopefully, Martijn F. starts something like the project he >> described >> >> - Hopefully, people follow it. >> >> In other words, I suppose, Just Do It. > > Actually Martijn tried to be better than that. :-) Instead of just > forming a > steering group (which I would interpret as a Zope project) and > announcing it > to the community, he asked for feedback first. :-) :-) Yes, that is better. > I probably agree he should have just done it by gathering the > various release > managers. BTW, in one of my original responses, I proposed to > Martijn that > the steering group should be mostly the release managers plus one or > two > strong developers so that the group reaches an odd number. Now that he's proposed it, hopefully he does it, without 100% buy-in, as I just wrote to Martijn. >> Beyond that, I didn't say my other smaller thought, which was that I >> think the KGS should ideally be looser and more flexible than what >> Martijn described. If you have a project that wants in on the KGS, >> great, you can add it. > > That is the case right now and I think a steering group would be > pretty open > to additions. > > However, I think Martijn made a much more important point. What he > wants, if I > understood him correctly, is more of an organization around a > hierarchy of > KGSs. OK. > The reason for this is that Zope/Plone, grok, and Zope 3 AS all > share a > common core and maybe a coreplus set. Then each sub-project > maintains a KGS > on top of that with their specific extensions. > > (1) This will make interoperability much easier, since I could > potentially use > grok X.Y in Zope 2.Z without worrying about version conflicts. > > (2) If the steering group contains all of the release managers, then > releases > can be synced effectively. > >> Institute a "nightly" KGS for an upcoming >> release (and maybe the most recent release). > > We do have this system today. > > http://zope3.afpy.org/buildbot/waterfall Wow, great. Too bad about the failures. How are you announcing the failures ATM? >> It stays around forever >> at a specific URL. Include only the projects whose tests pass in the >> nightly KGS. Have a list elsewhere of the ones for which the tests >> fail. If the tests don't pass for some period of time, apparently >> the >> maintainers and users don't exist or don't care, and they get taken >> off the list to be tested. > > That statement is a massive over-simplification of what's going > on. ;-) Heh, well, that's not exactly a surprise. :-) > There > are several problems: > > (1) Tests that pass in isolation might not pass in a complete run. > This might > be due to this or another packages incomplete teardown. (Several > people spent > weeks getting this right for the 3.4 KGS.) > > (2) A new release of one package might break 5 others. Who is > responsible for > updating the 5 breaking packages. The author that just released the > new > package or the ones from the 5 others? What if those other packages > do not > have clear, single maintainers (e.g. zope.*)? > > I am not making up these cases. They are real and they exist today. I know you are correct. I've experienced very similar things myself. > The idea > that one package has 1 or more concrete and devoted authors is > simply not > real in the Zope world of 200+ packages. Sure. There certainly are stakeholders who are willing to invest on this, particularly on core packages (where "core" differs for the stakeholders). >> The "Zope Framework" team leader then >> decides some time to make a release, so people might shuffle around >> versions more than usual, but it's just another KGS. > > Yep, this is basically what happens today. For example, at Keas we use > different versions (even trunk) of at least 20 packages. The point > is that > people have a stable point to start with. I think that would not > change. Great. (And thank you, this is much farther along than the last time I looked.) FWIW, the only polish I'd love to see is static pages for past dev releases (or did I miss them?) Thanks, Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 12:31 PM, Martijn Faassen wrote: > Hey Gary, > > [panarchist approach where we have people starting groups that could > compete for attention] [Had to look up panarchist, but yes, essentially.] > I agree that it should be relatively easy to start "Zope" projects > under > the Zope umbrella. > > I agree that such projects could compete for attention and may the > best > one win. > > I think this is what's more or less already happening anyway, and I > think it's great and it makes me appreciative of open source and > Zope's > component oriented culture that makes it possible. > > We can't just fork everything and branch off into our direction > everywhere however; these projects will share a common codebase. I am very much in favor of someone having this perspective, and acting on it. ;-) > This common codebase needs to be managed and have a direction, > taking as > inputs the needs of the projects using them. We don't have an umbrella project (e.g., grok, repoze) with this goal. I think your statements and mine mesh well enough. If you don't agree, that's fine. Practically, it means I support what you are trying to do (and in fact I would tend towards your camp in my proposed panarchy), if from a slightly different perspective. > > Gary Poster wrote: >> Moreover, if you are willing to step up and declare that you are >> starting something called the "Zope Framework" that manages a known >> good set of code, and you hope other projects and people join in and >> help, that makes sense to me. > > The open source mantra: "those who take responsibility get > responsibility" Yup. > I agree very much with that. > > It might be we are able to establish a "framework team" without > elections by just picking out the bunch of people who are interested > in > this. Of course if we have a significant fraction of our community who > disagrees with the authority to make decisions for larger changes in > these components, we still have a problem. Two diverging branches of > the > same package doesn't seem to be a maintainable situation; at some > point > someone is going to make a release with a single version number. > > That's why I don't think I or anyone else can just "do it" without > reaching a bit of wider consensus first. I think we have a transition > problem to get from where we are now, where everybody and nobody is > recognized, to a generally recognized group with some authority to > make > decisions where needed and provide guidance that should be taken into > account. Sure. I'm glad you sent your proposal email first. Now that you have, I hope you pursue your vision without needing 100% buy-in from the community. I'm optimistic that you will. :-) Gary >> With what I've seen on the Grok list, >> you can do a great job as a project leader, generally being positive, >> open, and motivating. > > Thanks! I have my flaws, but I try to be aware of them. :) Yup, same here. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: > >> - - The branch kills off both the use of 'zope.deferredimport' and the >> 'bbb' subpackage, leaving something which could be used in Jython, or >> IronPython, or the GAE. > > Why is zope.deferredimport a problem? Does it do something CPython > specific? As a small utility, I don't think it's a particualrly > troublesome dependency. Have you looked at what zope.deferredimport actually does? It uses zope.proxy to create wrappers around objects in sys.modules! There is effectively no way that any Python developer who hasn't already drunk the Zope Koolaid will ever willingly put up with such a grotexque^Wingenious hack. The only way it can do that is via a C modlue (in zope.proxy), because CPython won't tolerate "duck typing" of module objects, which makes it a deal-killer for the non-CPython platforms, too. I thought originally that the dependency was there to support emitting deprecation warnings, but not so: essentially, the deferreed imports were there to paper over import cycles. Ripping it out meant making the inter-module dependencies *within* zope.component explicit and sane, which was a net win, too, even without losing the C extension. Note that I also had to switch to "from imports", because the other style is the actual source of the cycles (e.g., using the '@component.adapter' decorator at module scope). The transitive dependencies in the released zope.component (not counting testing dependencies) are: - zope.interface - zope.event - zope.deprecation - zope.deferredimport - zope.proxy On my branch, the transitive dependencies (again, not counting tests) are: - zope.interface - zope.event which feels a lot saner to me: zope.interface is obviously required for anybody using zope.component, and zope.event is tiny, unchanging, and pure Python (I *am* dubious of the real-world utility of the events it actually emits, but that is another story). I think that minimizing non-essential dependencies is crucial to getting wider use of the packages, especially outside the purple-lipped crew here in the compound. :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrflv+gerLs4ltQ4RAnylAJ0f/uulXowSBdulTT0kO+bUzIXwWwCgoSyi a6M2GtcQN/qKag/bYammkmI= =iE1H -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: zope.component/branches/tseaver-wo_zope_deferred/
Tres Seaver wrote: > - - The branch kills off both the use of 'zope.deferredimport' and the > 'bbb' subpackage, leaving something which could be used in Jython, or > IronPython, or the GAE. Why is zope.deferredimport a problem? Does it do something CPython specific? As a small utility, I don't think it's a particualrly troublesome dependency. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > Okay, I guess we do differ here. I think a leader can provide > encouragement and stimulate people into action, point out interesting > outstanding tasks, and make sure that people who are motivated actually > get grip on improving the project and don't get discouraged. Of course > all these things only happen *some* of the time. It's hardly magic. But > it does contribute in my experience. A good example of this working well, is the role Martijn plays on the Grok list. He collates things that need doing, spells them out, and asks for volunteers. Sometimes that's all it takes. He also provides some degree of authority to make conversations productive. I remember being slapped down rather well over the Grok website at one point, for example. :) And if we are to beat the website analogy again (I really shouldn't...), then having that leadership probably allowed Grok to create a website with content, whereas the equivalent (and parallel) Zope effort died because no-one felt particularly obliged to answer a "cold call" for volunteers. There's more to leadership than that, but I think it's a useful comparison. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: > Different participants will report differently about the success, no > doubt. One unexpected outcome (for some) was classifying the > "decisions" taken at the PSPS as "advisory", "just talk", etc: having > no force in governing the more "tactical" decisions. I don't know why this should be surprising. Things only happen in open source when people do them. A deliberately limited cross-section of the Plone community (not all core developers were even invited, and more than half of the people there were not core developers at all, but included integrators, end users and businesses) could in no way make binding decisions "offline" in the space of two days, and somehow impose them on the other people who would actually have to do the work. We did achieve what we wanted though: We discussed a lot of pain points and clarified a lot of things that people had been arriving at independently, but not quite expressed. We created a lot of consensus around things we wanted to focus on. That consensus helps us develop new versions of Plone. >> (though I did hear positive news about it). I do have the >> impression the framework team strategy works reasonably well; it's been >> operating for about 2 releases now? > > It works as a way of sharing the load with the release manager. Because > its members don't feel empowered to make longer-term decisions, I don't > think it quite fits the model you have proposed for a steering group. No, it doesn't, any apologies for jumping in with this and perhaps making it sound more "same" than it was. I think it's a useful example of how to *organise* such a thing, even if the exact tasks may be a little bit different. > In effect, Hanno Schlicting is doing the "long-term" direction setting > as the Plone4 release manager: Limi is basically cheering him on. I don't think it's quite as simple as that. The release manager has some veto rights and a loud voice, because he is tasked with thinking about how these things fit together. He doesn't get to wear a dictator hat. The discourse on the plone-dev list (and conferences and sprints and IRC) is setting the long-term direction, as a product of the community. I think perhaps Plone has a better structure (release manager, framework team, Foundation) through which that discourse is channelled, in order to build consensus and, perhaps, make for some more productive discussions, than what we sometimes see on this list. In my experience, having the right amount of structure (be that in a team, or a company, or a community) makes it easier to be productive and constructive. Maritjn's proposal addresses some of Zope's challenges by adding some structure where there is currently a void. > Here is where I think we differ: I can't imagine the group you are > sketching out having much of *any* impact on day-to-day stuff. In > particular, I don't believe that a BDFL (whether an individual or a > group) "channels" energies: mostly, the BDFL serves as a "court of > final appeal" when the developers can't reach consensus. I think a good BDFL prods people into reaching consensus before it ever comes to that point. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Chris McDonough wrote: > Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. Note that the "scolding" had something to do with you breaking Plone trunk due to a transitive change in Chameleon, and the realisation that from this point on, any package shared between repoze.bfg and Plone (or anything else) that is configured with ZCML, will probably need to be forked. We found a workaround with Chameleon, but not one that will scale. The other cause for frustration was that you'd basically discounted all possibility of doing this at the zope.component level (and thus letting others benefit - Zope 2, Five and Plone needs rid of the zope.security dependency too) before you'd even tried. However, I didn't know then quite how disillusioned you were with Zope, or that you were quite so willing to maintain forks/spin-offs/re-implementations under the Repoze brand. > I also mentioned "or anyone else" above; the point is just to reduce > inappropriate dependencies. Inappropriate dependencies still remain in > zope.component's implementation of these ZCML directives. These inappropriate > dependencies are shed when you want ZCML and you use repoze.zcml. Fine, Grok > may not need it because it just doesn't care about ZCML at all; but other > people > who want to use ZCML without the other kitchen sinkness do. I think you'd be hard pressed to find anyone on this list who disagrees with that statement. ;) >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. At least when the change was made to Chameleon, it caused incompatibilities that basically broke another application using zope.component's versions of these directives. I'm sure those could be resolved (and were, with a workaround, in Chameleon), but it caused a fair bit of pain. But more importantly, there are lots of people using Zope the platform, who have the same types of problems. For Zope 2 or Five or Plone to switch wholesale to repoze.zcml is probably going to be impossible, for documentation-related, practical and technical reasons. By forking without attempting to solve the problem at the framework level, the chance for collaboration and shared effort is lost. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dan Korostelev wrote:
> 2009/3/4 Tres Seaver :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Dan Korostelev wrote:
>>> 2009/3/4 Tres Seaver :
Log message for revision 97465:
Branch removing zope.deferred.
Changed:
D
zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/
-# BBB: Backward-compatibility; 12/05/2004
-from bbb.interfaces import *
>>> Note, that the context-dependent/presentation/view stuff that was in
>>> BBB interfaces are still used in some places, like zope.publisher, so
>>> this needs more careful (re)moving. I think that one of the nice
>>> places for those interfaces is zope.browser, however they are not
>>> necessary browser-related, so maybe they should be moved elsewhere or
>>> just placed in zope.component.interfaces for now, as they're really
>>> tiny.
>> Yup. That was probably a case of premature deprecation (back in 2004).
>>
>> Note that I'm not actually proposing that we merge this branch any time
>> soon: it is a bit of a straw man for the ongoing process conversation.
>
> Why not? It looks that it's just a dependency cleanup, so it can be
> merged (and released!) really soon (if noone objects, of course). I
> personally don't like long-living branches and forks.
Well, part of the dependency cleanup involves making a possibly-
controversial coding style change ("from imports"), and I may have
broken something in the 'compattests'. I would also like to make
'setup.py test' actually work in the absence of buildout.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJrbMN+gerLs4ltQ4RAp7FAJ9WewCeb9MjTCs+uLjBzKVGjxTgIACghhhI
Zm+bEA0HXgd7ULswVhJ8zzo=
=1lIL
-END PGP SIGNATURE-
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
2009/3/4 Tres Seaver : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dan Korostelev wrote: >> 2009/3/4 Tres Seaver : >>> Log message for revision 97465: >>> Branch removing zope.deferred. >>> >>> >>> Changed: >>> D >>> zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/ >> >>> -# BBB: Backward-compatibility; 12/05/2004 >>> -from bbb.interfaces import * >> >> Note, that the context-dependent/presentation/view stuff that was in >> BBB interfaces are still used in some places, like zope.publisher, so >> this needs more careful (re)moving. I think that one of the nice >> places for those interfaces is zope.browser, however they are not >> necessary browser-related, so maybe they should be moved elsewhere or >> just placed in zope.component.interfaces for now, as they're really >> tiny. > > Yup. That was probably a case of premature deprecation (back in 2004). > > Note that I'm not actually proposing that we merge this branch any time > soon: it is a bit of a straw man for the ongoing process conversation. Why not? It looks that it's just a dependency cleanup, so it can be merged (and released!) really soon (if noone objects, of course). I personally don't like long-living branches and forks. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.component/branches/tseaver-wo_zope_deferred/ Branch removing zope.deferred.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Korostelev wrote: > 2009/3/4 Tres Seaver : >> Log message for revision 97465: >> Branch removing zope.deferred. >> >> >> Changed: >> D zope.component/branches/tseaver-wo_zope_deferred/src/zope/component/bbb/ > >> -# BBB: Backward-compatibility; 12/05/2004 >> -from bbb.interfaces import * > > Note, that the context-dependent/presentation/view stuff that was in > BBB interfaces are still used in some places, like zope.publisher, so > this needs more careful (re)moving. I think that one of the nice > places for those interfaces is zope.browser, however they are not > necessary browser-related, so maybe they should be moved elsewhere or > just placed in zope.component.interfaces for now, as they're really > tiny. Yup. That was probably a case of premature deprecation (back in 2004). Note that I'm not actually proposing that we merge this branch any time soon: it is a bit of a straw man for the ongoing process conversation. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJra+4+gerLs4ltQ4RAtw3AJ9sS97lAUFp09XHeYUy9HGgt+DHzQCcDKEY s40FAqfVUgblyg4OosNm7WM= =EyRo -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] SVN: zope.component/branches/tseaver-wo_zope_deferred/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Log message for revision 97465: > Branch removing zope.deferred. This checkin is the branch I had in mind when sketching out a non-CPython-only zope.component story today. Notes on the changes: - - The branch kills off both the use of 'zope.deferredimport' and the 'bbb' subpackage, leaving something which could be used in Jython, or IronPython, or the GAE. - - Ripping out 'zope.deferredimport' required shifting to "from imports" to avoid cycles. I moved one other cycle down into a non-module-scope import, as well, using a 'global base' to avoid extra imports. - - All its tests pass in a buildout. - - Due to the 'test' extra, buildout pulls in a bunch of extra dependencies, which I would like to zap (ZODB? really? just to verify that the persistent registry survives 'dumps' and 'loads'?) - - The branch can be installed into a virtualenv via 'setup.py develop', with only 'zope.interface' and 'zope.event' added. - - 'setup.py test' needs 'zope.testing', but then doesn't do anything (missing metadata). If I added the metadata, the tests would then pull in those extra packages: maybe I'll work on trimming them down, too. - - It probably breaks something in the 'compattests' realm; I haven't tried that, yet. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJra8y+gerLs4ltQ4RAnxvAJ9WijLQGtxOnqMX1XvNJFS4LWZ+PACfWhqJ KMrDhDwlA+kHYMOVuP34K6k= =K8ZI -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > It might be we are able to establish a "framework team" without > elections by just picking out the bunch of people who are interested in > this. That's been the Plone approach to creating the "framework team". Some people just decided to do it and didn't even bothered to ask publicly on any mailing list. If you want to mimic the Plone approach you do: Martijn, Stephan and Andreas form the "Zope Framework" team. They decide by themselves if they should take on exactly two more people or not. If one of the three doesn't want to do it, the other two find someone else. Their only task is to release version 1 of the "Zope Framework" by this summer. It's primary concern is to serve as a common stable ground for Zope 2.12, Zope 3.5 and the next Grok version. As part of such a release they get the power of deciding what packages are part of the release and which versions of them. They are responsible for taking care of proper release procedure and documentation of the release. If they cannot encourage people to help them, the shitty work is on them. And that's it. Obviously you get to do some decisions which are really about strategies beyond the release, but you can only execute them in the limited scope of the one release. By the end of it, you look at what you got, find some new people (with some overlap to the old team) to steer on the next version of the Zope Framework and see how it goes. You don't try to organize all of Zope at once, but claim your own little field. If everything goes well, you established communications between three large communities and they have a way of discussing changes based on their technical merit. Maybe "Zope Framework" version 2 brings even further reduced dependencies and ditches the publisher for a real WSGI story. But that's not the discussion right now. You can try to bake more leadership of the overall Zope community into this, but I think this is a fruitless fight right now. Reduce the scope, try make some things better and don't step on other peoples feet if you don't need to. For example don't try to push out style-guides for the entirety of the svn.zope.org repository. They lead to bike-shed discussions and discourage contributions. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, I thought I should highlight this characterization of the Zope project because I agree with much of it but also disagree with much of it. Chris McDonough wrote: > I have no faith whatsoever that staying on the course we've been on for the > last > 9 years ( 9 years is a long time, and while I agree that some cultural deficiencies (bad presentation) have lasted a very long time without much awareness of them, other deficiencies we're aware of and we're making progress on. > large interconnected codebase, You might've noticed a certain effort back in 2007 to split up our large interconnected codebase into small components, and efforts over time to try to break the connections in this code base. I think we could've been further along the breaking connections if we'd have some people with an overview of what's going on and an active interesting in driving that effort forward. Anyway, this is a characterization of where Zope technology is now, but it's a mischaracterization if you think that's where it wants to be or that no effort was spent on improving the situation. > backwards compatibility at all costs, I agree that have erred on the side of too much backwards compatibility. That increased the overhead of changes tremendously and blocked innovation. That said, I also see a lot of value of having a lot of components that can work together, and we do have quite a collection of those in the Zope ecosystem. This is why Grok is so careful to stay compatible with Zope 3, so we can share that pool of components. I'm in favor of an evolutionary approach where backwards compatibility on occasion is broken and it's clearly documented what developers should do to fix things. I'm also in favor of an approach where due to proper dependency factoring we can dump whole chunks of code (in particular ZMI chunks) in a large step. > lack of any consumable documentation at a package level, I agree that most package-level documentation could be improved tremendously by focusing on writing real documentation instead of half-test stuff. That said, we also have a tremendous level of package-level documentation and interface documentation, and it's a mischaracterization of the values of the Zope project to say we haven't cared about documentation at all. We innovated with interface-level documentation and doctests and making those available on PyPI. You've said in the past that this is a sort of "false optimum" that stops people from really fixing documentation issues, and I agree. We should make an effort to change our culture and redirect our documentation efforts to go beyond doctests. I'll also note that documentation for the whole *system* has traditionally been lacking (how to get started, install it?). I know you don't like the whole Zope 3 system anyway, but it's also something I think we could improve (and we've been doing so for Grok). > not much curiosity about how other Python web frameworks work, I'm not sure whether this characterization is accurate or not. Because Zope was there sooner than many other Python web frameworks, it's probably partially true we've ignored the competition. I've personally been quite interested in seeing how the cultures surrounding other web frameworks work and trying to adopt lessons from this. I've also played with some other web frameworks and used TurboGears 1 for real work, but not as much as I should, perhaps. I've been able to apply the things I've learned from other web frameworks far better in the context of Grok than I have been in the context of the wider Zope community, and I wish that would change. > not much real cooperation with folks that maintain other Python web > frameworks, What is "real cooperation"? It's hard to judge this one, though we can definitely do better. I'd note that the culture of cooperation between other Python web frameworks has started really taking off surrounding WSGI, and we've been trying to make use of this technology but haven't had the full benefits yet. Anyway, it's hard to say how much of a goal "real cooperation" should be for our community. I think we should do our best to integrate other technology in our own stuff, and we've had some progress with things like WSGI, Twisted and SQLAlchemy. Maybe Repoze is next, but I hear they think very badly of us indeed. :) > a constitutional inability to attract new users I share that concern very much. It's good that the Zope technology is so central to other projects which do attract new users so we still have at least some influx here. Part of the reason is our lack of attention to documentation, proper web presentation, and our "here's a giant toolbox, you figure it out" approach. I'm not sure how the collection of libraries I dubbed the Zope Framework would operate in this regard. Individual libraries should present themselves to attract new users. At the same time the larger collection (the ball of 70somethin
Re: [Zope-dev] the Zope Framework project
Hi there, Chris, I think you are misunderstanding my position quite dramatically. Perhaps you should calm down and reconsider what I've been saying, as I believe we're a lot closer than you seem to think. On Tue, Mar 3, 2009 at 8:42 PM, Chris McDonough wrote: [snip] >> I'd rather have one underlying action API that did the minimal but right >> thing in zope.component that grokcore.component and repoze.zcml and the >> Zope Framework (with its additional requirements for security) can all >> build on. > > Why does it *have* to be in zope.component? What magic does this name imply? It doesn't, but it should then be *removed* from zope.component into some other package (which could be repoze.zcml for all I care). I don't want there to be a duplicate implementation laying around and I'd like there to be a clean dependency structure. At the same time, directives need to exist that are compatible with the Zope Framework. It'd be nice if there wasn't a duplicate implementation of their actions. [snip] >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. Yes, why are you explaining this to me? For a year now people could use grokcore.component, where they could register their objects without pulling in those dependencies as well, and not having to deal with a lot of ZCML either. > Why should we punish the folks who are already using the zope.component > directives with security in them by changing them in order to service some > goal > of fidelity with brand? Who cares what it's called? I'm not talking about the fidelity of the brand. If you use repoze.zcml or grokcore.component today you'll use two implementations of the actions and in the case of repoze.zcml, two implementations of the ZCML directives. Granted those are very minimal in grokcore.component and mostly the registration functions themselves. But repoze.zcml contains wisdom about certain WSGI situations that grokcore.component and zope.component don't have. What I'd like to do is consolidate all that wisdom about how things should be registered in *one* place (I don't care what it's called, and it *could* be zope.component or repoze.zcml) and then build grokcore.component, repoze.zcml and Zope 3 on top of this. That way they all share the same underlying technique, including your multi-app support. It appears to be the coordination overhead required seems to make this impossible. Even you who should have an interest in not carrying in the ZCML implementations in zope.component as they're duplicating and possibly confusing users of repoze.zcml seem not to agree that it'd be nicer. [snip] > I don't know what's so hard to understand about this: not everyone wants to > use > the ~78 packages that currently make up "the Zope framework". This is the > entire point of what I'm saying. Very few people will never care about "the > Zope Framework" in entirety, if it's defined as you define it above. I'm talking about zope.component here, and you don't seem to want to change that either. I'm trying to see the big picture of the different users of this package and think about ways to arrange it so that it'd be better. Less redundant code, more shared code. You don't seem to be interested in that, because to you the problem is already solved. I understand that, but I also don't understand your resistance. > 99% of people in the Python community *dont use anything related to Zope* and > *WILL NEVER USE ANYTHING FROM IT IF IT'S ALWAYS A BALL OF 78, 60, OR EVEN 10 > PACKAGES*. If you're defining "everyone" in your sentence above as "everyone > who already uses Zope", I believe that is incredibly short sighted. We could > do > so much more if we ditched the notion that the big glob of packages you're > trying to recast as "The Zope Framework" is of more value as a glob than as > individual packages that any Python programmer could use. Please don't yell at me. I don't take the position that you think I am. You're telling me things I already agree with. Why do you think I care so much about clean dependencies in the Zope Framework? Because I want people to be able to enter the Zope Framework at any point in the tree. People who don't care about the rest. Because I want the tree to be simpler so that Grok uses less of it and I can understand more of it. But that takes coordinated effort as we do have people using the entire tree and we don't want to leave those with a broken system. I'm taking both perspectives at the same time. I don't think they're mutually incompatible. You're doing this thing called Repoze. That's a lot of packages and presumably they share a few philosophies and you make sure they tend to work together. At the same time people can pick up on individual packages. Why can't we have somethi
Re: [Zope-dev] the Zope Framework project
On 3/3/09 2:42 PM, Chris McDonough wrote: > Martijn Faassen wrote: >> And you think it's all due to the brand... > > Yes! Someone who *wants* to use basic ZCML directives but doesn't want > zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and > pytz can *already* use repoze.zcml; the only thing they don't get here is the > brand. If we change the word "brand" to "megaframework", things might become clearer. Grok makes framework decisions based on getting value from the Zope 3 platform. "So what if our configuration language sucks in zope.location and pytz, we needed it anyway in our megaframework!" This view likely represents the (indeterminately sized) population of Zope insiders. Repoze doesn't have fidelity to the Zope 3 megaframework as its goal. "I asked for a configuration parser and you sucked in a security model, WTF!!" As such, Repoze probably wants something more like Zope-the-library than Zope-the-megaframework. This view likely represents the (indeterminately sized) population of Zope skeptics. Which group wins when there's a tie in the Zope Framework? It will be interesting to see. I think there's also a point about the "brand" related to how diluted the word "Zope" has become, but that is a second point to the megaframework/platform discussion. --Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > Hi there, > > Chris McDonough wrote: >> Martijn Faassen wrote: >>> Martin Aspeli wrote: >>> [snip] You and I had a discussion a while back about forking the zope.component ZCML directives, and how it would've been better to work within the boundaries of the Zope packages so that everyone who wanted to lose the zope.security dependency could benefit, rather than fork this and all other configuration that depends on the core ZCML directives. >> As I remember it, you scolded me about doing it, then when I did it anyway, >> it >> worked its way over to the Grok list, where any alternate idea other than a >> plain fork died on the vine. That's what I figured was going to happen, so >> I'm >> glad I actually took action. > > Huh? Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen. > We need a refactored zope.component for the Grok project as well. > Why did it die on the vine? Perhaps if someone had been integrating > these experiences and requirements properly on zope-dev it'd have > transformed into positive improvements in zope.component itself by now. AFACIT, you (meaning Faassen) wanted to focus on lower-hanging fruit at the time: http://mail.zope.org/pipermail/grok-dev/2008-December/006946.html (which I believe was totally reasonable). > [snip] >> Frankly, I don't care that I had to create alternative ZCML directives. This >> was, and is, and always will have been, the right thing to do. In fact, the >> only thing preventing Grok or anyone else from using the stuff created out of >> that effort wholesale (repoze.zcml) is the *brand*. > > That's incorrect. We already have an implementation of alternate > directive (aka grokkers) to register the zope.component components in > grokcore.component, and have had them for much longer than you did. > > Adding a *third* way to configure components, i.e. repoze.zcml, to the > mix is hardly going to improve matters for Grok. It's useless anyway as > we need to support the zope.component[ZCML] way anyway for ZCML, and > support grokcore.component for code that does it the Grok way. I also mentioned "or anyone else" above; the point is just to reduce inappropriate dependencies. Inappropriate dependencies still remain in zope.component's implementation of these ZCML directives. These inappropriate dependencies are shed when you want ZCML and you use repoze.zcml. Fine, Grok may not need it because it just doesn't care about ZCML at all; but other people who want to use ZCML without the other kitchen sinkness do. > I'd rather have one underlying action API that did the minimal but right > thing in zope.component that grokcore.component and repoze.zcml and the > Zope Framework (with its additional requirements for security) can all > build on. Why does it *have* to be in zope.component? What magic does this name imply? > Switching over to repoze.zcml would only gain Grok *more* code and a > harder to comprehend situation. Maybe *Grok* doesn't need it, but given that an application needs some ZCML to kick off the loading of components, and given that this ZCML needs to include one of the "utility", "adapter" or "subscriber" directives, *eventually* you could ditch zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and pytz by using repoze.zcml directives instead of the ones built in to zope.component. Here's an example of a non-Zope application that might make use of such a package: http://plope.com/Members/chrism/pluginizing_an_app > And you think it's all due to the brand... Yes! Someone who *wants* to use basic ZCML directives but doesn't want zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and pytz can *already* use repoze.zcml; the only thing they don't get here is the brand. Why should we punish the folks who are already using the zope.component directives with security in them by changing them in order to service some goal of fidelity with brand? Who cares what it's called? >> I don't care about >> Zope-the-brand anymore, I just care about Zope-the-technologies. Why would >> the >> fact that this more reasonable set of directives is not named Zope anymore >> matter? What about that whole situation was not a win? > > I already spelled out the above on the grok-dev mailing list before, but > you didn't seem to pick up on my explanation. I guess not. >>> When I brought up the issue of trying to improve zope.component >>> recently, I got a lot of divergent feedback and nothing happened. It'd >>> be nice if instead such energy instead resulted in a concrete set of >>> actions. >> I didn't participate because I had already scratched that particular itch. I >> created something that *everyone* can use; it might not be named Zope, so be >> it. > > I pointed out above why it'd be not very useful for Grok to use it. In > fact you created something that is redundant if you use the rest of the > Z
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 19:09, Tres Seaver wrote: > Different participants will report differently about the success, no > doubt. One unexpected outcome (for some) was classifying the > "decisions" taken at the PSPS as "advisory", "just talk", etc: having > no force in governing the more "tactical" decisions. I don't remember us actually doing any "tactical decisions". There was discussions, and to a large part consensus about these, but not actual decisions. The end result of the PSPS was a bunch of actions, entered into the bugtracker, and people assigned to them. These were sometime connected to tactical decisions, but not decisions per se. I may misremember, but in any case, this to me seems (in retrospect) as a good idea, as complaints at that time was raised that it wasn't inclusive enough, which would have been a problem if it really was a decision making meeting. Instead it functioned as a way to get the contributors focused and if not on the same page then at least in the same book, and get energy into the group. As such, I thought it was a success. And fun. And I learnt a cool way to run meetings. :) I do think that this, together with day-to-day release teams is a good working solution we should try for Zope too. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On 3 Mar 2009, at 18:25, Martijn Faassen wrote: > Ah, so Plone currently has long term direction as they think 2 > releases > ahead of just one? Plone 4 discussions are happening around now, there are demos of suggested concepts and people generally working on the codebase. Plone 5 is a long way off, but we have some ideas, for example Hanno has already suggested it should target Python 3.x. 2 major releases in the Plone world is about 3/4 years. Matt (Proud Plone 4 Framework team member, ftr) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: [snip] >> (though I did hear positive news about it). I do have the >> impression the framework team strategy works reasonably well; it's been >> operating for about 2 releases now? > It works as a way of sharing the load with the release manager. Because > its members don't feel empowered to make longer-term decisions, I don't > think it quite fits the model you have proposed for a steering group. Okay, that's interesting. Undoubtedly some ideas about long term direction sneak into a framework team to guide them with decision making, but it's not exactly the same model indeed. >> So you have one mechanism to set long term directions (and I think >> another one, namely Alexander Limi), and another to execute these long >> term directions and make smaller decisions in the light of them. > > In effect, Hanno Schlicting is doing the "long-term" direction setting > as the Plone4 release manager: Limi is basically cheering him on. Ah, so Plone currently has long term direction as they think 2 releases ahead of just one? I guess my proposed Steering Group would take on some of the aspects of both. I think you could set up a Steering Group per release with a bit more mandate to cover long term directions than perhaps the Plone group has. There'll be continuity as some of the membership will carry on to the next release typically. >> In reality of course a lot of micro decisions can result in a long term >> direction, so there's a gray area there. >> >> For the Zope Framework I think it's more important to get the day to day >> decision making working in our community than it is to do the long term >> setting of directions and planning. We do have some form of long term >> direction emerging that we can recognize often enough (though we can do >> a lot better still). The core problem in my mind is the day to day >> decision making and channeling of energies. > > Here is where I think we differ: I can't imagine the group you are > sketching out having much of *any* impact on day-to-day stuff. In > particular, I don't believe that a BDFL (whether an individual or a > group) "channels" energies: mostly, the BDFL serves as a "court of > final appeal" when the developers can't reach consensus. Okay, I guess we do differ here. I think a leader can provide encouragement and stimulate people into action, point out interesting outstanding tasks, and make sure that people who are motivated actually get grip on improving the project and don't get discouraged. Of course all these things only happen *some* of the time. It's hardly magic. But it does contribute in my experience. >> I myself am inclined, for the Zope Framework, to start with the day to >> day team. I think it can deduce at least some long term directions from >> the community on the mailing list and usage in practice (also by >> consultation). We could amend such a process with a strategic planning >> summit construction, later. > > If the team you are talking about is going to manage a "root KGS", or > something, from which Zope2, Zope3, Grok, etc. derive their own > versions, then it seems to me that success lies in keeping that KGS > smaller than larger, and focused mostly on the "libraryin" bits. > Expanding the core KGS later will be lots easier than shrinking it. I agree the end product should be smaller rather than larger and more library-like. But it should also be concerned with turning a larger set of libraries into better libraries. Imagine we had defined the KGS to contain zope.* and not zope.app.* back in december 2008. It wouldn't have had a container implementation, which I think is an interesting piece of shared technology. If we did it today we'd have had zope.container. That's why I think it should start inclusive and then focus heavily on turning it into a better set of libraries. In my mind such a "turn it into a better collection of libraries" is one of the most important long-term activities for the framework developers. I think that's something everybody can be on board about. In the end it's a tree of packages where people should be able to participate at any node, but I do think we need to keep an overview of the tree as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Chris McDonough wrote: > Martijn Faassen wrote: >> Martin Aspeli wrote: >> [snip] >>> You and I had a discussion a while back about forking the zope.component >>> ZCML directives, and how it would've been better to work within the >>> boundaries of the Zope packages so that everyone who wanted to lose the >>> zope.security dependency could benefit, rather than fork this and all >>> other configuration that depends on the core ZCML directives. > > As I remember it, you scolded me about doing it, then when I did it anyway, it > worked its way over to the Grok list, where any alternate idea other than a > plain fork died on the vine. That's what I figured was going to happen, so > I'm > glad I actually took action. Huh? We need a refactored zope.component for the Grok project as well. Why did it die on the vine? Perhaps if someone had been integrating these experiences and requirements properly on zope-dev it'd have transformed into positive improvements in zope.component itself by now. [snip] > Frankly, I don't care that I had to create alternative ZCML directives. This > was, and is, and always will have been, the right thing to do. In fact, the > only thing preventing Grok or anyone else from using the stuff created out of > that effort wholesale (repoze.zcml) is the *brand*. That's incorrect. We already have an implementation of alternate directive (aka grokkers) to register the zope.component components in grokcore.component, and have had them for much longer than you did. Adding a *third* way to configure components, i.e. repoze.zcml, to the mix is hardly going to improve matters for Grok. It's useless anyway as we need to support the zope.component[ZCML] way anyway for ZCML, and support grokcore.component for code that does it the Grok way. I'd rather have one underlying action API that did the minimal but right thing in zope.component that grokcore.component and repoze.zcml and the Zope Framework (with its additional requirements for security) can all build on. Switching over to repoze.zcml would only gain Grok *more* code and a harder to comprehend situation. And you think it's all due to the brand... > I don't care about > Zope-the-brand anymore, I just care about Zope-the-technologies. Why would > the > fact that this more reasonable set of directives is not named Zope anymore > matter? What about that whole situation was not a win? I already spelled out the above on the grok-dev mailing list before, but you didn't seem to pick up on my explanation. >> When I brought up the issue of trying to improve zope.component >> recently, I got a lot of divergent feedback and nothing happened. It'd >> be nice if instead such energy instead resulted in a concrete set of >> actions. > > I didn't participate because I had already scratched that particular itch. I > created something that *everyone* can use; it might not be named Zope, so be > it. I pointed out above why it'd be not very useful for Grok to use it. In fact you created something that is redundant if you use the rest of the Zope Framework as well (or even just zope.component[zcml]). It isn't something that *everybody* can use just like that. Forking is one way to solve the problem and forget about it, if you don't care about compatibility with the Zope Framework. That's fine. It's something you have the freedom to do of course and undoubtedly you are much happier with it. It's also unfortunate for me, as your improvements are not making in into the shared component. So while the problem is solved for you, it isn't solved for me. Grok has different goals concerning compatibility with the Zope Framework, and therefore more interest in improving the underlying framework itself. These are different philosophies. You with your philosophy should have no problem with me trying to improve the framework experience though, as you can go off on your own anyway and cooperate on bits of it whenever you want. So I find it frustrating to hear you say "no" so much now. It's fine if you don't care about the "Zope" brand anymore, but I'm still allowed to care about it, right? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Paul Everitt wrote: >> On 3/2/09 10:13 PM, Martin Aspeli wrote: >>> We recognised that there was a problem in trying to make sure we >>> represented the interests of various stakeholders, and that we needed >>> someone to think "big picture" in terms of what technologies we adopted >>> and how we used them. >> Just to be clear, I believe the Plone framework team has specifically >> disavowed management of Plone's "strategy". Meaning, they approve PLIPs >> on a release-to-release basis. They don't make edicts like "replace >> Archetypes". >> >> This was the vacuum that the "strategic planning summit" advertised >> itself as addressing. >> >> I think this clarification is informative to Martijn's discussion. > > That's interesting indeed. > > It's hard to know whether Plone's method of a "strategic planning > summit" is working on the long term as you only had one as far as I > know. Different participants will report differently about the success, no doubt. One unexpected outcome (for some) was classifying the "decisions" taken at the PSPS as "advisory", "just talk", etc: having no force in governing the more "tactical" decisions. > (though I did hear positive news about it). I do have the > impression the framework team strategy works reasonably well; it's been > operating for about 2 releases now? It works as a way of sharing the load with the release manager. Because its members don't feel empowered to make longer-term decisions, I don't think it quite fits the model you have proposed for a steering group. > So you have one mechanism to set long term directions (and I think > another one, namely Alexander Limi), and another to execute these long > term directions and make smaller decisions in the light of them. In effect, Hanno Schlicting is doing the "long-term" direction setting as the Plone4 release manager: Limi is basically cheering him on. > In reality of course a lot of micro decisions can result in a long term > direction, so there's a gray area there. > > For the Zope Framework I think it's more important to get the day to day > decision making working in our community than it is to do the long term > setting of directions and planning. We do have some form of long term > direction emerging that we can recognize often enough (though we can do > a lot better still). The core problem in my mind is the day to day > decision making and channeling of energies. Here is where I think we differ: I can't imagine the group you are sketching out having much of *any* impact on day-to-day stuff. In particular, I don't believe that a BDFL (whether an individual or a group) "channels" energies: mostly, the BDFL serves as a "court of final appeal" when the developers can't reach consensus. > I myself am inclined, for the Zope Framework, to start with the day to > day team. I think it can deduce at least some long term directions from > the community on the mailing list and usage in practice (also by > consultation). We could amend such a process with a strategic planning > summit construction, later. If the team you are talking about is going to manage a "root KGS", or something, from which Zope2, Zope3, Grok, etc. derive their own versions, then it seems to me that success lies in keeping that KGS smaller than larger, and focused mostly on the "libraryin" bits. Expanding the core KGS later will be lots easier than shrinking it. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrXI/+gerLs4ltQ4RAvf1AKCpRxuSfU6pOzhv5GNCwoOioZwmCwCgsXK/ M7L/DTDqiGyu/lhdBw56e2s= =vnGh -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Boy, there's no point in trying to outrun this thread, I'd better just jump in here. Martin I think you said that very well and I'm convinced. I appreciate and generally support Martijn's proposal. When in doubt, I'd be in favour of emulating what's been shown to work in the Plone community - eg lightweight per-release teams. I guess a responsive, transparent steering group with slower turnover can also be useful, though. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hey, Stephan Richter wrote: [snip] > Actually Martijn tried to be better than that. :-) Instead of just forming a > steering group (which I would interpret as a Zope project) and announcing it > to the community, he asked for feedback first. :-) Thanks. :) > I probably agree he should have just done it by gathering the various release > managers. BTW, in one of my original responses, I proposed to Martijn that > the steering group should be mostly the release managers plus one or two > strong developers so that the group reaches an odd number. I'm not convinced such a group could provide the kind of leadership I'm looking for. It'd like something a bit more agile. >> Beyond that, I didn't say my other smaller thought, which was that I >> think the KGS should ideally be looser and more flexible than what >> Martijn described. If you have a project that wants in on the KGS, >> great, you can add it. > > That is the case right now and I think a steering group would be pretty open > to additions. > > However, I think Martijn made a much more important point. What he wants, if > I > understood him correctly, is more of an organization around a hierarchy of > KGSs. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a > common core and maybe a coreplus set. Then each sub-project maintains a KGS > on top of that with their specific extensions. Yes, I think eventually we will end up with a hierarchy of KGSes. I think we still need to delineate what a Steering Group or Framework Team actually has authority over, so that would define the Zope Framework. I think we should start with something quite inclusive there. One of the goals of the project would be to whittle it down to something smaller and more comprehensible. Which in turn might make space for wholesale replacement with newer libraries. Anyway, what is the Zope Framework is determined organically and changes slowly over time. > (1) This will make interoperability much easier, since I could potentially > use > grok X.Y in Zope 2.Z without worrying about version conflicts. I don't think it'll ever be perfect. Grok 1.0x for instance looks like it needs a newer version of zope.publisher than is in the Zope 3.4 KGS in order to function. But the *more* similar these lists are, the better. This common ground brings us community. [snip] > (1) Tests that pass in isolation might not pass in a complete run. And vice versa! We spent quite a bit of time to make tests work in isolation and have compattest infrastructure for it now. > This might > be due to this or another packages incomplete teardown. (Several people spent > weeks getting this right for the 3.4 KGS.) > > (2) A new release of one package might break 5 others. Who is responsible for > updating the 5 breaking packages. The author that just released the new > package or the ones from the 5 others? What if those other packages do not > have clear, single maintainers (e.g. zope.*)? > > I am not making up these cases. They are real and they exist today. The idea > that one package has 1 or more concrete and devoted authors is simply not > real in the Zope world of 200+ packages. Definitely. Changes in one package have repercussions in a huge amount of other packages. When we did dependency refactoring we'd need to reach out to many other packages to update *their* dependencies. Sometimes we couldn't even get the tests to run properly in the original package before doing so, as otherwise the wrong pre-refactored package would be imported from. :) On the other hand we should of course recognize that some of these packages do work in isolation, and move towards a dependency structure and code organization that creates more such "work by themselves" packages. That's what the dependency refactoring project is all about. We need a balance of a good integrated experience and a good stand-alone experience. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hey Gary, [panarchist approach where we have people starting groups that could compete for attention] I agree that it should be relatively easy to start "Zope" projects under the Zope umbrella. I agree that such projects could compete for attention and may the best one win. I think this is what's more or less already happening anyway, and I think it's great and it makes me appreciative of open source and Zope's component oriented culture that makes it possible. We can't just fork everything and branch off into our direction everywhere however; these projects will share a common codebase. This common codebase needs to be managed and have a direction, taking as inputs the needs of the projects using them. Gary Poster wrote: > Moreover, if you are willing to step up and declare that you are > starting something called the "Zope Framework" that manages a known > good set of code, and you hope other projects and people join in and > help, that makes sense to me. The open source mantra: "those who take responsibility get responsibility" I agree very much with that. It might be we are able to establish a "framework team" without elections by just picking out the bunch of people who are interested in this. Of course if we have a significant fraction of our community who disagrees with the authority to make decisions for larger changes in these components, we still have a problem. Two diverging branches of the same package doesn't seem to be a maintainable situation; at some point someone is going to make a release with a single version number. That's why I don't think I or anyone else can just "do it" without reaching a bit of wider consensus first. I think we have a transition problem to get from where we are now, where everybody and nobody is recognized, to a generally recognized group with some authority to make decisions where needed and provide guidance that should be taken into account. > With what I've seen on the Grok list, > you can do a great job as a project leader, generally being positive, > open, and motivating. Thanks! I have my flaws, but I try to be aware of them. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Tuesday 03 March 2009, Tres Seaver wrote: >> Stephan, I *have* managed a large set, and I'm *certain* that the KGS is >> useful for many cases: it just doesn't work for me for any large >> production application: I don't want to rely on the iffy availability >> of eggs from PyPI, for instance, which means that running a separate, >> per-project index is my only recourse anyway. Once you are running your >> own index, it's contents *are* a KGS, just not one managed using the >> 'versions.cfg' machinery. > > Who says that you cannot use your own index with the KGS? Do you think I use > the official PyPI location for production? We use two approaches at Keas: If I'm running my own project-specific index, it *is* the KGS for that project: I don't need to manage versions anyplace else. > (1) Use a PyPI proxy server that caches all needed packages locally. Not an option: I don't let new pacakges, or new versions, into my index without reviewing them first. Typically, this means adding the egg to my sandbox (e.g., via easy_install, or a develop-egg), verifying that it works with the other pacakges, has reasonable tests and docs, and does what I need. Once I'm done with that review, I copy the sdist to my project index, and update the dependencies and / or buildout config to pull it in. > (2) Use zc.sourcerelease so that all packages are part of the big source TAR > ball. I don't need the big tarball, because I have an index: I can just enumerate the eggs I need (e.g., in 'install_requires' or in buildout.cfg) without any versioning at all, and trust that the index will supply the "blessed" versions. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrWjU+gerLs4ltQ4RApviAJ9Ul8m8FXzbYV9YK2Mt2ofNs2SfhQCfWLCt E9CK+vzQnGQG7djluyL8cew= =PcE6 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Martijn Faassen wrote: > Hi there, > > Martin Aspeli wrote: > [snip] >> You and I had a discussion a while back about forking the zope.component >> ZCML directives, and how it would've been better to work within the >> boundaries of the Zope packages so that everyone who wanted to lose the >> zope.security dependency could benefit, rather than fork this and all >> other configuration that depends on the core ZCML directives. As I remember it, you scolded me about doing it, then when I did it anyway, it worked its way over to the Grok list, where any alternate idea other than a plain fork died on the vine. That's what I figured was going to happen, so I'm glad I actually took action. > The main >> reason you had for creating your own package, was the lack of momentum >> (and/or stop energy) encountered when trying to do this in the Zope >> world. If there was someone who could both consider BFG's needs in a >> more objective light, and have the power to actually do something rather >> than just bicker, then maybe we could've gone a different route on that >> one. With more and more dependency untangling happening, I am pretty >> sure this same situation is going to come up again. > > Yes, this is a very good example of why Chris should be in favor of > leadership for the Zope Framework. The Grok project would've appreciated > such improvements right there in zope.component too. Frankly, I don't care that I had to create alternative ZCML directives. This was, and is, and always will have been, the right thing to do. In fact, the only thing preventing Grok or anyone else from using the stuff created out of that effort wholesale (repoze.zcml) is the *brand*. I don't care about Zope-the-brand anymore, I just care about Zope-the-technologies. Why would the fact that this more reasonable set of directives is not named Zope anymore matter? What about that whole situation was not a win? > When I brought up the issue of trying to improve zope.component > recently, I got a lot of divergent feedback and nothing happened. It'd > be nice if instead such energy instead resulted in a concrete set of > actions. I didn't participate because I had already scratched that particular itch. I created something that *everyone* can use; it might not be named Zope, so be it. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Tue, Mar 3, 2009 at 18:20, Martijn Faassen wrote: > I myself am inclined, for the Zope Framework, to start with the day to > day team. I think it can deduce at least some long term directions from > the community on the mailing list and usage in practice (also by > consultation). We could amend such a process with a strategic planning > summit construction, later. Such a day to day group sounds like me as the same thing as a release team, and if so, me and Martijn, as usually, agree comepletely. :) -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > Tres Seaver wrote: > [snip] >> Stephan, I *have* managed a large set, and I'm *certain* that the KGS is >> useful for many cases: it just doesn't work for me for any large >> production application: I don't want to rely on the iffy availability >> of eggs from PyPI, for instance, which means that running a separate, >> per-project index is my only recourse anyway. Once you are running your >> own index, it's contents *are* a KGS, just not one managed using the >> 'versions.cfg' machinery. >> >> That said, I do appreciate the work you have done and are doing to make >> the KGS useful for others. > > Distinguish KGS the concept (a list of locked down versions as > suggestions to users of the framework) from KGS the implementation. > > Let's agree on the *concept* of a locked down list of versions that's > maintained by the community, or in fact more than one such list. Acknowledging the idea that we might have more than one removes the sting for me. > If people want to diverge in the implementation, fine. Different > implementations have different advantages during development and deployment. Yup, or for different "styles" of projects. As a *personal* example: *every* time I try to short-cut the process of setting up a project-specific index representing the KGS *for that project,* I end up getting burned by something. At this point, I don't even think about skipping the index setup, any more than I would skip setting up a VCS repository or mailing lists for the project. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrWeH+gerLs4ltQ4RAoB+AKCL7Hypan2VGvmdQc1XvEMLk/0uPQCeJr1r xXJnto/QQdlLcKozkid74M8= =1g4r -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: > On 3/2/09 10:13 PM, Martin Aspeli wrote: >> We recognised that there was a problem in trying to make sure we >> represented the interests of various stakeholders, and that we needed >> someone to think "big picture" in terms of what technologies we adopted >> and how we used them. > > Just to be clear, I believe the Plone framework team has specifically > disavowed management of Plone's "strategy". Meaning, they approve PLIPs > on a release-to-release basis. They don't make edicts like "replace > Archetypes". > > This was the vacuum that the "strategic planning summit" advertised > itself as addressing. > > I think this clarification is informative to Martijn's discussion. That's interesting indeed. It's hard to know whether Plone's method of a "strategic planning summit" is working on the long term as you only had one as far as I know. (though I did hear positive news about it). I do have the impression the framework team strategy works reasonably well; it's been operating for about 2 releases now? So you have one mechanism to set long term directions (and I think another one, namely Alexander Limi), and another to execute these long term directions and make smaller decisions in the light of them. In reality of course a lot of micro decisions can result in a long term direction, so there's a gray area there. For the Zope Framework I think it's more important to get the day to day decision making working in our community than it is to do the long term setting of directions and planning. We do have some form of long term direction emerging that we can recognize often enough (though we can do a lot better still). The core problem in my mind is the day to day decision making and channeling of energies. I myself am inclined, for the Zope Framework, to start with the day to day team. I think it can deduce at least some long term directions from the community on the mailing list and usage in practice (also by consultation). We could amend such a process with a strategic planning summit construction, later. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: [snip] >> As much as I prefer discussing with people in real life, there is the >> notion of "no backroom conversations" WRT to driving development of an >> open source project. > > OK. *Cough*. You and Martijn wrote this proposal. And you asked > Stephan about it. You did backroom conversations. I wrote the proposal based on conversations I had with Christian and also Jim, and Christian and several others gave input. Backroom work will happen (conversations and decisions both). But it cannot be the only thing that drives the open source project. > Aren't we now saying that to avoid excluding some people, we should > exclude all but a steering group? :-) You have a very different perspective on a Steering Group. It's not a mechanism for exclusion but for *inclusion*. The steering group should care about the different interests in our community and actively balance them and consult them, and channel existing energies allowing them to result in something instead of dissipate. Of course you seem to say this all depends on the people in the steering group and that in practice this won't happen. This is something we'll need to try to find out, right? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: [snip] >> No. The steering group should not have backroom discussions. They should >> act as open as possible. I think of it as a catalyst. > > The operative here is *should*. Compare that to *will*. These are > different words. What the steering group *should* do and what they > *will* do is not the same thing. Yes, and you're asserting it won't even though it'll be founded with that exact intent. You may be right of course, though I don't think so. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Lennart Regebro wrote: > 1. Areas that need somebody responsible should get one. We need > somebody to bug people about bugs in the bug tracker. That should be > one person, for example. Responsibilities need to be well defined and > individual. There isn't anybody called Someone here, so if Someone has > to do it, that doesn't get done. Who defines these responsibilities and hands them out? Who reminds people of bits of the project that could use a responsible person to take charge? I'm asking this as I've taken this role for the Grok project, and sometimes my reminding results in volunteers taking responsibility for a bit of the project, whether it's code or documentation or management. Without someone who identifies these responsibilities, there's far less chance of people taking them. > 2. To get things done release-wise, I think it would be good to have a > release-team for each release. And that would reasonable be different > teams for Zope2 and Zope 3, and possibly even for The Zope Framework, > obviously most likely with personnel overlaps. Are you talking about a team like the Plone Framework team that guides development leading *up* to a release (and including it), or are you talking about a team of people who set up the KGS, write release notes and release packages to PyPI? > 3. To steer, and keep the community on track, I think regular meetings > of people in real life will beat any steering group, all hands down. > This would best happen at the same time as a conference, and either > the Plone conference or PyCon or Europython. Whoever shows up will have the say and people not there will just have to put up with it? I think that works to a certain extent in sprints, but we are an internet based open source project and we should have ways to make progress while distributed. Who is doing to take care about such decisions being executed when we're back online again after a meeting? Is anyone going to keep track of decisions made and remind people to finish up on efforts started? > I think this will give us enough steering. We aren't as many people as > for example Plone or Python. Maybe, if we get everybody on track, we > will be, and then we'll have to rethink. But currently the people > involved, and the people that need to be "steered" are so few we can > fit them all into one room at a time. And then I do not see why would > would need a steering group. I don't agree that we have such a small group. It's also a question about whether we really *want* this to be a small group. I also don't think this is a sound mechanism in the long run. People are going to inevitably drop out from our community and we need fresh blood, also for fresh ideas and energy. If the only decisions are going to be made in real life meetings, there'll be little chance new people will get involved, as they'd not show up to such meetings. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Martin Aspeli wrote: [snip] > I'm not sure Plone's model fits Zope perfectly, but certainly there are > some lessons to be learned. We also have some of processes and > documentation already in place, having made a few mistakes along the way. Definitely, I'm very interested in seeing whether we can't adopt much of this model for Zope. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Martin Aspeli wrote: [snip] > You and I had a discussion a while back about forking the zope.component > ZCML directives, and how it would've been better to work within the > boundaries of the Zope packages so that everyone who wanted to lose the > zope.security dependency could benefit, rather than fork this and all > other configuration that depends on the core ZCML directives. The main > reason you had for creating your own package, was the lack of momentum > (and/or stop energy) encountered when trying to do this in the Zope > world. If there was someone who could both consider BFG's needs in a > more objective light, and have the power to actually do something rather > than just bicker, then maybe we could've gone a different route on that > one. With more and more dependency untangling happening, I am pretty > sure this same situation is going to come up again. Yes, this is a very good example of why Chris should be in favor of leadership for the Zope Framework. The Grok project would've appreciated such improvements right there in zope.component too. When I brought up the issue of trying to improve zope.component recently, I got a lot of divergent feedback and nothing happened. It'd be nice if instead such energy instead resulted in a concrete set of actions. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Christian Theune wrote: > On Tue, 2009-03-03 at 02:35 +0100, Martijn Faassen wrote: >> * leadership could help sustain efforts like "we want the Zope Framework >> to run on Jython" and make detailed decisions based on this. Nobody >> right now can really decide on this. > > Anecdote: Our current Jython story (due to last GSOC) is having lots of > conditional imports sprinkled all over the code base with an 'if > sys.platform == "java"'. For some reason there was no discussion about > that and we even didn't get enough stop-energy in my POV. ;) Yeah, that was a seriously disfunctional Summer of Code project. In that case I did encourage communication very much from our end. Those checkins were some form unilateral "week after the deadline" rescue effort on the student's part so that he'd get paid. Whether he got away with it I don't know, as the PSF was in charge of that project in the end. This shows that even if you have people on top of things (I saw the danger signals in this project *way* ahead of time) it still can go wrong. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Paul Everitt wrote: > On 3/3/09 9:37 AM, Kent Tenney wrote: >> I'll chime in as a newbie. >> >> It seems many of the comments preferring ad-hoc to structure >> come from "we know what we are doing, we can take care of ourselves" >> >> I think Zope has the goal of attracting new users, and the proposal >> has potential to make Zope more inviting to the uninitiated. >> >> Zope is very diffuse, making it a challenge to grasp. I know I would benefit >> from any initiative which sought to provide an overview role. > > I'm not sure that's a goal of this proposal. The word "Zope" will > continue to have its previous series of semi-competing meanings. The > word will now also be attached to "Framework", which will be the emphasis. > > As I read it, regarding the diffusion, asking the stakeholders in the > existing meanings of the word to yield is not part of the proposal. > (Thankfully, as that is hopeless.) > > The focus, though, will be on greatest-common-factor of the shared > meaning. Not a solution to diffusion, but an improvement. I find myself in agreement with both Kent and Paul. :) I think that a leadership that cares about the beginner experience could help improve the beginner experience tremendously. Also the beginner *contributor* experience, who I think feels also very overwhelmed. I think leadership *should* care about such experiences and encourage people to improve matters. With the Grok project I've found that people are quite willing to contribute beginner's documentation and they only need a space to do so and a bit of encouragement. I think we could use the Zope Framework to integrate some ideas and lessons we've learned in the diffusion. In that sense it's an integrative force. I like Paul's description of "greatest-common-factor". I think we should work to expand that greatest common factor in adoption, but we can do so by reducing the size of the whole thing. I.e. the Zope Framework is something we want to be widely adopted but we can encourage adoption best by making it smaller and easier to understand. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Martin Aspeli wrote: [snip] > I think Martijn is trying to address something that Zope has lacked for > a while. I don't think it'll solve all of the world's problems, nor do I > think that Martijn things so, but it will make some things - things like > this very debate - a bit easier and more productive. Thanks very much Martin for putting all of this to words so well. Yes, exactly! +100 Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Gary Poster wrote: > My mild counter proposal was this. > > - The ZF formally institutes an easy way for people to start "Zope" > projects > > - Hopefully, Martijn F. starts something like the project he described > > - Hopefully, people follow it. > > In other words, I suppose, Just Do It. Actually Martijn tried to be better than that. :-) Instead of just forming a steering group (which I would interpret as a Zope project) and announcing it to the community, he asked for feedback first. :-) I probably agree he should have just done it by gathering the various release managers. BTW, in one of my original responses, I proposed to Martijn that the steering group should be mostly the release managers plus one or two strong developers so that the group reaches an odd number. > Beyond that, I didn't say my other smaller thought, which was that I > think the KGS should ideally be looser and more flexible than what > Martijn described. If you have a project that wants in on the KGS, > great, you can add it. That is the case right now and I think a steering group would be pretty open to additions. However, I think Martijn made a much more important point. What he wants, if I understood him correctly, is more of an organization around a hierarchy of KGSs. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a common core and maybe a coreplus set. Then each sub-project maintains a KGS on top of that with their specific extensions. (1) This will make interoperability much easier, since I could potentially use grok X.Y in Zope 2.Z without worrying about version conflicts. (2) If the steering group contains all of the release managers, then releases can be synced effectively. > Institute a "nightly" KGS for an upcoming > release (and maybe the most recent release). We do have this system today. http://zope3.afpy.org/buildbot/waterfall > It stays around forever > at a specific URL. Include only the projects whose tests pass in the > nightly KGS. Have a list elsewhere of the ones for which the tests > fail. If the tests don't pass for some period of time, apparently the > maintainers and users don't exist or don't care, and they get taken > off the list to be tested. That statement is a massive over-simplification of what's going on. ;-) There are several problems: (1) Tests that pass in isolation might not pass in a complete run. This might be due to this or another packages incomplete teardown. (Several people spent weeks getting this right for the 3.4 KGS.) (2) A new release of one package might break 5 others. Who is responsible for updating the 5 breaking packages. The author that just released the new package or the ones from the 5 others? What if those other packages do not have clear, single maintainers (e.g. zope.*)? I am not making up these cases. They are real and they exist today. The idea that one package has 1 or more concrete and devoted authors is simply not real in the Zope world of 200+ packages. > The "Zope Framework" team leader then > decides some time to make a release, so people might shuffle around > versions more than usual, but it's just another KGS. Yep, this is basically what happens today. For example, at Keas we use different versions (even trunk) of at least 20 packages. The point is that people have a stable point to start with. I think that would not change. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Tres Seaver wrote: > Stephan, I *have* managed a large set, and I'm *certain* that the KGS is > useful for many cases: it just doesn't work for me for any large > production application: I don't want to rely on the iffy availability > of eggs from PyPI, for instance, which means that running a separate, > per-project index is my only recourse anyway. Once you are running your > own index, it's contents *are* a KGS, just not one managed using the > 'versions.cfg' machinery. Who says that you cannot use your own index with the KGS? Do you think I use the official PyPI location for production? We use two approaches at Keas: (1) Use a PyPI proxy server that caches all needed packages locally. (2) Use zc.sourcerelease so that all packages are part of the big source TAR ball. Both approaches work just fine and we are still using the KGS for our version pinning. So here is an example of a typical buildout.cfg that we have: [buildout] extends = versions-3.4.0.cfg versions = versions extensions=lovely.buildouthttp find-links = http://eggs.gokeas.com/eggs [versions] keas.kmi = 0.3.1 lxml = 2.1.2 mechanize = 0.1.8 MySQL-python = 1.2.2 python-dateutil = 1.4.1 RelStorage = 1.1.1 setuptools = 0.6c9 z3c.datagenerator = 0.0.3 z3c.form = z3c.formjs = z3c.menu.ready2go = z3c.rest = 0.2.5 z3c.traverser = 0.2.3 z3c.versionedresource = 0.4.0 zc.testbrowser = zope.annotation = 3.4.1 zope.app.appsetup = 3.8.0 zope.app.container = 3.7.0 zope.container = 3.7.0 zope.app.locales = 3.4.5 zope.app.publisher = 3.5.0 zope.i18n = 3.5.0 zope.publisher = 3.5.4 zope.security = 3.5.2 # Updated secure function list for Python 2.5 zope.sendmail = 3.5.0 zope.server = 3.5.0 zope.testing = 3.5.5 simplejson = 1.9.1 hurry.query = gocept.registration = lovely.session = Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Lennart Regebro wrote: > On Tue, Mar 3, 2009 at 09:21, Martin Aspeli wrote: > > If anything, we started out with too little process and found there were > > gaps we had to plug. > > Ah. Now, THIS I like. Let's focus on this: Start out with as little > process and as few officialisms as possible. And I don't see that a > steering group is as little as possible. If it turns out to be > necessary, we add it then. Martijn is asserting (correctly in my opinion) that we tried the no leader approach for a while and failed. We are now discussing the necessary steps to resolve the problem. Martijn's solution is a steering group. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hi there, Tres Seaver wrote: [snip] > Stephan, I *have* managed a large set, and I'm *certain* that the KGS is > useful for many cases: it just doesn't work for me for any large > production application: I don't want to rely on the iffy availability > of eggs from PyPI, for instance, which means that running a separate, > per-project index is my only recourse anyway. Once you are running your > own index, it's contents *are* a KGS, just not one managed using the > 'versions.cfg' machinery. > > That said, I do appreciate the work you have done and are doing to make > the KGS useful for others. Distinguish KGS the concept (a list of locked down versions as suggestions to users of the framework) from KGS the implementation. Let's agree on the *concept* of a locked down list of versions that's maintained by the community, or in fact more than one such list. If people want to diverge in the implementation, fine. Different implementations have different advantages during development and deployment. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Chris Withers wrote: > Adam GROSZER wrote: >> Someone releases a new package version and your project just break the >> next day. That's a nightmare. > > That shouldn't happen with individual package releases where releases > are done sensibly. > (ie: if you're going to do a big backwards-incompatible release, let > people know. If you rely on a package, put in some sensible version > constraints in your setup.py, if your *project* (rather than your > packages) is paranoid (and it should be!) then lock the versions you use > down in something project-specific like a buildout.cfg, if you use buildout. The community can give suggestions about locking down. this is not some kind of fancy theory but something that has worked for Zope 3 and Grok since late 2007. One of the things wrong with the zope-dev community is that we way too heavily in favor of the "here's a giant toolbox, just figure it out" attitude in the name of ultimate flexibility. Instead we have to think about ways to figure out things *for* people so they don't have to do a lot of duplicate work. We should of course still support the giant toolbox use case. I'm just saying we should do *more* than that, too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Hey, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Martin Aspeli wrote: >> Tres Seaver wrote: > > > >>> - - How many need *all* of Zope3, including the ZMI? I'm betting that >>> set is much smaller than either of the others? >> Probably none. So having better dependencies would obviously be good. I >> think you still need a KGS of sorts, but you don't need to depend on >> *all* of it. :) > > I'm sure that the set is bigger than that. However, I want to identify > the critical subset the *everybody* needs, and ensure that we prioritize > "steering" efforts there: the other packages can mostly just be left in > the hands of the disjoint groups that need them. That critical subset is very small, and it's "zope.interface", which Twisted also needs, and only needs. We can't define the framework by what everybody needs. We can define it by what lots of people need. The people with less buy-in into this framework will have to care just about the smaller bits of course, but the developers as a whole will need to coordinate a larger chunk. Surrounding that chunk we'll have broader projects that care about even bigger chunks, definitely. My goal with the Zope Framework is to identify at least one chunk shared between the Zope 3 app server, Zope 2 and Grok. Other projects use less of it, and I think it's in our interests to cut it down to size, but it'll never be cut down to the size of zope.interface. I realize that this is only an approximation of the messy reality, but we need an approximation of reality we can all understand to be able to communicate about it and work together. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Tres Seaver wrote: >> Plone, by the way, had a similar problem, and solved it by creating "the >> framework team". This is a rolling body of people who are responsible >> for putting out calls for and reviewing improvements proposals. They >> basically report to the release manager, who makes the final call. The >> release manager is nominated by the framework team, confirmed by the >> Plone Foundation, and given a small stipend for his troubles. > > Funny you should pick them as your example. I've seen members of that > team *actively deny* that the team has any role in setting technical > direction for Plone (which is ironic, given that what they actually do > is to review and approvie PEPs, as well as choosing the release manager). I probably took the analogy a bit far: I meant to show the type of process that would enable such a team to have some degree of legitimacy as well as purpose, and that a team-based approach can work well in a community where there's no pope/dictator/whatever. The framework team has a role in setting technical direction for a single release, by virtue of what it does. The team is changed for each release, so it does not have a role in setting technical direction further than that, although of course the choices made for one release will often have some bearing on the future. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Martijn Faassen wrote: > >> What is going to make us more effective is: >> >> * a recognition of current reality, i.e. the Zope Framework is not the >> same as the Zope 3 application server and it serves a far wider audience. >> >> * leadership > > I really couldn't agree more. There's unfortunately a bit of a > leadership vacuum in the Zope community. > > I think Tres and Chris are suggesting we focus leadership around > individual packages or sets of packages, and Martijn is suggesting we > have something a bit broader focusing on all of Zope. I think the two > are not necessarily mutually exclusive. And I'd take any leadership over > none at all. > > Plone, by the way, had a similar problem, and solved it by creating "the > framework team". This is a rolling body of people who are responsible > for putting out calls for and reviewing improvements proposals. They > basically report to the release manager, who makes the final call. The > release manager is nominated by the framework team, confirmed by the > Plone Foundation, and given a small stipend for his troubles. Funny you should pick them as your example. I've seen members of that team *actively deny* that the team has any role in setting technical direction for Plone (which is ironic, given that what they actually do is to review and approvie PEPs, as well as choosing the release manager). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrVLl+gerLs4ltQ4RAvlfAJ9+fN/QKeP0rKPYAYWfIgRxIamMGACguQEi WFITE1Q+ICLT4MMhquvcWc0= =KyEB -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Monday 02 March 2009, Chris Withers wrote: >> Adam GROSZER wrote: >>> Someone releases a new package version and your project just break the >>> next day. That's a nightmare. >> That shouldn't happen with individual package releases where releases >> are done sensibly. > > Let me tell you from experience: Before the KGS we had exactely this problem. > No carefully crafted release can male up for that. And if a single package > pins versions generically, then you stall development. We also had that > ha[[en before the KGS came around. Both reasons actually promted my to do the > KGS in the first place. > > In general, and not specific to you Chris, I think that unless you have > managed a large set of packages, you should shut up and listen. Stephan, I *have* managed a large set, and I'm *certain* that the KGS is useful for many cases: it just doesn't work for me for any large production application: I don't want to rely on the iffy availability of eggs from PyPI, for instance, which means that running a separate, per-project index is my only recourse anyway. Once you are running your own index, it's contents *are* a KGS, just not one managed using the 'versions.cfg' machinery. That said, I do appreciate the work you have done and are doing to make the KGS useful for others. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrU/N+gerLs4ltQ4RAhhjAKCXFz/UWoahvRiBkWYy7oWT7+2wZgCfdZ0h Nwc71oEYwqV1Jm0liFofTUA= =7Y6k -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Tuesday 03 March 2009, Martijn Pieters wrote: > The irony is that the proposed solution, organized leadership, is > going to suffer the same fate as the aforementioned ideas. Everyone is > putting in their oar, +1s and -1s are flying right, left and centre, > and this idea is either going to die, or Martijn will have to push it > through and implement it. No one else seems enthusiastic enough to > make this happen outright, there is no clear direction. I had the same sentiment while reading the thread, which is why I am mostly staying out of it. Just in case it is not clear from my previous responses, I agree with Martijn's analysis and I am in favor of Martijns proposal and will help him as much as I can to get it implemented. I will gladly work on the proposed KGS split, keep doing Zope Framework and Zope 3 App server releases, and serve on the steering group. We got to try something and I think this is a good and honest attempt. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: > Tres Seaver wrote: >> - - How many need *all* of Zope3, including the ZMI? I'm betting that >> set is much smaller than either of the others? > > Probably none. So having better dependencies would obviously be good. I > think you still need a KGS of sorts, but you don't need to depend on > *all* of it. :) I'm sure that the set is bigger than that. However, I want to identify the critical subset the *everybody* needs, and ensure that we prioritize "steering" efforts there: the other packages can mostly just be left in the hands of the disjoint groups that need them. >> - - Of the first set, what is the likelihood that different projects >> will have conflicting goals about the direction of one or more >> packages? >> >> Given the likelihood that a monolithic Zope 3.5 release is not >> interesting to lots of the folks who both develop and consume its >> packages, how much coordination is going to be possible (or even useful) >> around the idea of another release? > > Maybe we could identify some "vectors" down the dependency graph that we > *do* care about. If we analysed our projects (Plone, and a bunch of > add-on products, for instance), we could probably manage to maintain > KGS' that say "if you want the container interfaces, these packages are > known to work together". I suggested one such vector (zope.interface, zope.component). Another one is "the packages which Zope2 (really) needs." >> Maybe we need to create something more like self-organizing >> mini-communities around the various packages (or maybe sets). > > Heh... right. ;-) > >> E.g., I >> would bet that almost everyone active on this list has a stake in >> zope.interface, zope.component, and their dependencies. Note that *two* >> of the remaining dependencies (zope.deferredimport, zope.deprecation) >> are only there to deal with BBB isssues: maybe they should go? > > Why? They're tiny, and BBB is good. No piece of framework code can be > taken seriously if it pretends that people are not going to need > backwards compatibility. Some BBB may be worth keeping: I have argued before, however, that the specific BBB strategy which requires those three packages is not a big success: rather than proxying all modules with deprecations, for instance, I would rather just leave the BBB imports in place *forever*, without emitting warnings. >> Another, zope.proxy, is a blocker for using the packages on non-CPython >> platforms: should it go? If we consider those packages *in isolation*, >> as things potentially useful outside any larger framework, the answers >> to those questions might be different. > > True. > >> I'm not so sure that any other package is going to be as widely >> interesting. > > I can think of a few: the container stuff, browser views and pages, page > template files, for example. We already have "successful" forks for a number of those. >> I also think that having the *whole* Zope community do >> oversight oversee on the rest is less useful than having the folks with >> "skin in the game" for a particular package steer it. I am unlikely to >> care much about anything in the Z3 ZMI, for instance, or about a number >> of other packages in our various namespaces: I could do my job better, >> *and* keep from interfering in others' interests (e.g., the "stop >> energy" Chris mentioned), if we separated out the various areas of concerns. > > True. However, someone still needs to think about whether these things > are pulling in the same direction, or becoming incompatible with one > another. Note that divergence may be an acceptable outcome, here, especially if we adopt the pattern that fundamental disagreements on the direction of a shared package can be resolved by the "amicable divorce" of a fork. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJrU4N+gerLs4ltQ4RAuFaAKC2eBkntSauZvi0qWm5wgAvuwVD+QCgxIa8 y8wKdscbD9+f4bfyq+42yfM= =71WM -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Monday 02 March 2009, Chris Withers wrote: > Adam GROSZER wrote: > > Someone releases a new package version and your project just break the > > next day. That's a nightmare. > > That shouldn't happen with individual package releases where releases > are done sensibly. Let me tell you from experience: Before the KGS we had exactely this problem. No carefully crafted release can male up for that. And if a single package pins versions generically, then you stall development. We also had that ha[[en before the KGS came around. Both reasons actually promted my to do the KGS in the first place. In general, and not specific to you Chris, I think that unless you have managed a large set of packages, you should shut up and listen. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 8:43 AM, Andreas Jung wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > - Show quoted text - > On 03.03.2009 15:37 Uhr, Kent Tenney wrote: >> On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer wrote: >>> Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: On Tue, Mar 3, 2009 at 00:16, Martijn Faassen >>> wrote: > Who is going to make that decision to encourage this? Allow this? You? > Me? Who? Right now, *nobody* is making such decisions and nobody can > properly get away with saying they allow it. Leadership is a way to get > out of it. I think open source in general has shown two things: 1. Communities can mostly take decisions without having official authorities to do so. This is hyper democratic. 2. When they can't, usually committees can't either. In those cases somebody with a deciding vote is needed. This isn't democratic at all, but efficient. >>> Exactly. And that's what we currently don't have. >>> > +1, though a simple discouraging of utterance can't accomplish it by > itself. What you need is active leadership that encourages such > experimentation. I don't know about that. I agree with you that there hasn't been active leadership for a while. But look what has happened without this active leadership. * We have two cool new Zope 3 based frameworks. One which throws out the whole concept of ZCML for doing configuration by radical code introspection, and as a result making the Zope Framework immensely more accessible. And another one which experiments with revamping the way Zope publishes things, and a related effort of rewriting the whole publisher. Both frameworks have during these experimentation reached big audiences and gained widespread if still experimental acceptance in the community. >>> True - but to me it seems that this happened because someone took leadership >>> in this scenario. >>> * Zope 2 has been eggified. * Buildout has totally massacred all other forms of deployment of Zope projects. >>> All that is true and very positive, but what has not happened and maybe >>> never >>> will that way, is the aggregation of all those Zope 3 efforts, >>> documentation, >>> website and the like. And that is something very important in order to >>> attract a broader user base. >>> > Who decides to kill something off? If it doesn't get maintained, is dead. I guess you want somebody to make it official. I'm not sure it's necessary in a component based reality. With Zope 2 eggified for example, ZClasses gets a separate module, and it lives as long as somebody maintains it. It's then just a matter of deciding if it should be a part of the release or not, which the release manager(s) decide. >>> That's fine for one thing: Newbies don't know which packages are maintained >>> and which are not. They find themselves confronted with a bunch of packages >>> and don't know what they should use and what not. Example: zope.formlib vs. >>> z3c.form. >>> For instance, I decided to use lovely.remotetask - but I recognized that the >>> last commit is quite some time ago and don't really know if it's actively >>> used/maintained. >> >> I'll chime in as a newbie. >> >> It seems many of the comments preferring ad-hoc to structure >> come from "we know what we are doing, we can take care of ourselves" >> >> I think Zope has the goal of attracting new users, and the proposal >> has potential to make Zope more inviting to the uninitiated. >> >> Zope is very diffuse, making it a challenge to grasp. I know I would benefit >> from any initiative which sought to provide an overview role. >> >> > > I started up with something for zope2.zope.org in order to bring > sort out the various things a bit: > > http://zope2.zopyx.de/about-zope-2/the-zope-eco-system That's very useful, and seems to describe the theory of the Zope world. In theory, theory and practice are the same, in practice they are not. My post was prompted by the mention of knowing which of several similar components is preferred, deprecated, abandoned. Maybe this doesn't fall within the proposal, but it strikes me as an element of 'steering'. I think that watching exchanges between a steering entity and the dev community would be a good vantage point for getting a picture of the Zope landscape. Thanks, Kent > > Andreas > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk > uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY > =y1Df > -END PGP SIGNATURE- > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://
Re: [Zope-dev] the Zope Framework project
On 3/3/09 9:37 AM, Kent Tenney wrote: > I'll chime in as a newbie. > > It seems many of the comments preferring ad-hoc to structure > come from "we know what we are doing, we can take care of ourselves" > > I think Zope has the goal of attracting new users, and the proposal > has potential to make Zope more inviting to the uninitiated. > > Zope is very diffuse, making it a challenge to grasp. I know I would benefit > from any initiative which sought to provide an overview role. I'm not sure that's a goal of this proposal. The word "Zope" will continue to have its previous series of semi-competing meanings. The word will now also be attached to "Framework", which will be the emphasis. As I read it, regarding the diffusion, asking the stakeholders in the existing meanings of the word to yield is not part of the proposal. (Thankfully, as that is hopeless.) The focus, though, will be on greatest-common-factor of the shared meaning. Not a solution to diffusion, but an improvement. --Paul ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.03.2009 15:37 Uhr, Kent Tenney wrote: > On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer wrote: >> Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: >>> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen >> wrote: Who is going to make that decision to encourage this? Allow this? You? Me? Who? Right now, *nobody* is making such decisions and nobody can properly get away with saying they allow it. Leadership is a way to get out of it. >>> I think open source in general has shown two things: >>> >>> 1. Communities can mostly take decisions without having official >>> authorities to do so. This is hyper democratic. >>> 2. When they can't, usually committees can't either. In those cases >>> somebody with a deciding vote is needed. This isn't democratic at all, >>> but efficient. >> Exactly. And that's what we currently don't have. >> +1, though a simple discouraging of utterance can't accomplish it by itself. What you need is active leadership that encourages such experimentation. >>> I don't know about that. I agree with you that there hasn't been >>> active leadership for a while. But look what has happened without this >>> active leadership. >>> * We have two cool new Zope 3 based frameworks. One which throws out >>> the whole concept of ZCML for doing configuration by radical code >>> introspection, and as a result making the Zope Framework immensely >>> more accessible. And another one which experiments with revamping the >>> way Zope publishes things, and a related effort of rewriting the whole >>> publisher. Both frameworks have during these experimentation reached >>> big audiences and gained widespread if still experimental acceptance >>> in the community. >> True - but to me it seems that this happened because someone took leadership >> in this scenario. >> >>> * Zope 2 has been eggified. >>> * Buildout has totally massacred all other forms of deployment of Zope >>> projects. >> All that is true and very positive, but what has not happened and maybe never >> will that way, is the aggregation of all those Zope 3 efforts, documentation, >> website and the like. And that is something very important in order to >> attract a broader user base. >> Who decides to kill something off? >>> If it doesn't get maintained, is dead. I guess you want somebody to >>> make it official. I'm not sure it's necessary in a component based >>> reality. With Zope 2 eggified for example, ZClasses gets a separate >>> module, and it lives as long as somebody maintains it. It's then just >>> a matter of deciding if it should be a part of the release or not, >>> which the release manager(s) decide. >> That's fine for one thing: Newbies don't know which packages are maintained >> and which are not. They find themselves confronted with a bunch of packages >> and don't know what they should use and what not. Example: zope.formlib vs. >> z3c.form. >> For instance, I decided to use lovely.remotetask - but I recognized that the >> last commit is quite some time ago and don't really know if it's actively >> used/maintained. > > I'll chime in as a newbie. > > It seems many of the comments preferring ad-hoc to structure > come from "we know what we are doing, we can take care of ourselves" > > I think Zope has the goal of attracting new users, and the proposal > has potential to make Zope more inviting to the uninitiated. > > Zope is very diffuse, making it a challenge to grasp. I know I would benefit > from any initiative which sought to provide an overview role. > > I started up with something for zope2.zope.org in order to bring sort out the various things a bit: http://zope2.zopyx.de/about-zope-2/the-zope-eco-system Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY =y1Df -END PGP SIGNATURE- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. & Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer wrote: > Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro: >> On Tue, Mar 3, 2009 at 00:16, Martijn Faassen > wrote: >> > Who is going to make that decision to encourage this? Allow this? You? >> > Me? Who? Right now, *nobody* is making such decisions and nobody can >> > properly get away with saying they allow it. Leadership is a way to get >> > out of it. >> >> I think open source in general has shown two things: >> >> 1. Communities can mostly take decisions without having official >> authorities to do so. This is hyper democratic. >> 2. When they can't, usually committees can't either. In those cases >> somebody with a deciding vote is needed. This isn't democratic at all, >> but efficient. > > Exactly. And that's what we currently don't have. > >> > +1, though a simple discouraging of utterance can't accomplish it by >> > itself. What you need is active leadership that encourages such >> > experimentation. >> >> I don't know about that. I agree with you that there hasn't been >> active leadership for a while. But look what has happened without this >> active leadership. >> * We have two cool new Zope 3 based frameworks. One which throws out >> the whole concept of ZCML for doing configuration by radical code >> introspection, and as a result making the Zope Framework immensely >> more accessible. And another one which experiments with revamping the >> way Zope publishes things, and a related effort of rewriting the whole >> publisher. Both frameworks have during these experimentation reached >> big audiences and gained widespread if still experimental acceptance >> in the community. > > True - but to me it seems that this happened because someone took leadership > in this scenario. > >> * Zope 2 has been eggified. >> * Buildout has totally massacred all other forms of deployment of Zope >> projects. > > All that is true and very positive, but what has not happened and maybe never > will that way, is the aggregation of all those Zope 3 efforts, documentation, > website and the like. And that is something very important in order to > attract a broader user base. > >> > Who decides to kill something off? >> >> If it doesn't get maintained, is dead. I guess you want somebody to >> make it official. I'm not sure it's necessary in a component based >> reality. With Zope 2 eggified for example, ZClasses gets a separate >> module, and it lives as long as somebody maintains it. It's then just >> a matter of deciding if it should be a part of the release or not, >> which the release manager(s) decide. > > That's fine for one thing: Newbies don't know which packages are maintained > and which are not. They find themselves confronted with a bunch of packages > and don't know what they should use and what not. Example: zope.formlib vs. > z3c.form. > For instance, I decided to use lovely.remotetask - but I recognized that the > last commit is quite some time ago and don't really know if it's actively > used/maintained. I'll chime in as a newbie. It seems many of the comments preferring ad-hoc to structure come from "we know what we are doing, we can take care of ourselves" I think Zope has the goal of attracting new users, and the proposal has potential to make Zope more inviting to the uninitiated. Zope is very diffuse, making it a challenge to grasp. I know I would benefit from any initiative which sought to provide an overview role. Thanks, Kent > >> > Who decides we should have a documentation website for a widely used >> > component. >> >> Those who writes the documentation in question. :) > > In some way, that's already done - nearly every package has some doctest, > which does often cover the package specifics very well. However, I remember > the days I looked at z3c.form: I recognized that I needed to get to know the > following other packages: > > - interfaces/adapters > - z3c.pagelet > - z3c.template > - (and quite some more) > > This was very cumbersome. > >> > * who reminds us of necessary tasks and directions we're going into? >> > Sometimes the community collectively decides on moving forward. >> > Sometimes it doesn't. Are we really maintaining our issue tracker well, >> > say? >> >> No, but then a person should get some sort of responsibility for that. >> Note: A person. Not a committee. A committee means a bunch of people >> are responsible, which is the same thing as saying that nobody is. > > Yes, that's probably true. So either this steering group is "a person" or has > some person who decides. > > Best Regards, > Hermann > > -- > herm...@qwer.tk > GPG key ID: 299893C7 (on keyservers) > FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 > ___ > - Show quoted text - > Zope-Dev maillist - zope-...@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://ma
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 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
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 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
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 Tue, Mar 3, 2009 at 13:33, Hermann Himmelbauer 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
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
Am Dienstag 03 März 2009 08:19:37 schrieb Lennart Regebro: > On Tue, Mar 3, 2009 at 01:51, Martijn Faassen 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
On Tue, Mar 3, 2009 at 13:04, Roger Ineichen 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 00:48:38 schrieb Lennart Regebro: > On Tue, Mar 3, 2009 at 00:16, Martijn Faassen wrote: > > Who is going to make that decision to encourage this? Allow this? You? > > Me? Who? Right now, *nobody* is making such decisions and nobody can > > properly get away with saying they allow it. Leadership is a way to get > > out of it. > > I think open source in general has shown two things: > > 1. Communities can mostly take decisions without having official > authorities to do so. This is hyper democratic. > 2. When they can't, usually committees can't either. In those cases > somebody with a deciding vote is needed. This isn't democratic at all, > but efficient. Exactly. And that's what we currently don't have. > > +1, though a simple discouraging of utterance can't accomplish it by > > itself. What you need is active leadership that encourages such > > experimentation. > > I don't know about that. I agree with you that there hasn't been > active leadership for a while. But look what has happened without this > active leadership. > * We have two cool new Zope 3 based frameworks. One which throws out > the whole concept of ZCML for doing configuration by radical code > introspection, and as a result making the Zope Framework immensely > more accessible. And another one which experiments with revamping the > way Zope publishes things, and a related effort of rewriting the whole > publisher. Both frameworks have during these experimentation reached > big audiences and gained widespread if still experimental acceptance > in the community. True - but to me it seems that this happened because someone took leadership in this scenario. > * Zope 2 has been eggified. > * Buildout has totally massacred all other forms of deployment of Zope > projects. All that is true and very positive, but what has not happened and maybe never will that way, is the aggregation of all those Zope 3 efforts, documentation, website and the like. And that is something very important in order to attract a broader user base. > > Who decides to kill something off? > > If it doesn't get maintained, is dead. I guess you want somebody to > make it official. I'm not sure it's necessary in a component based > reality. With Zope 2 eggified for example, ZClasses gets a separate > module, and it lives as long as somebody maintains it. It's then just > a matter of deciding if it should be a part of the release or not, > which the release manager(s) decide. That's fine for one thing: Newbies don't know which packages are maintained and which are not. They find themselves confronted with a bunch of packages and don't know what they should use and what not. Example: zope.formlib vs. z3c.form. For instance, I decided to use lovely.remotetask - but I recognized that the last commit is quite some time ago and don't really know if it's actively used/maintained. > > 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 12:53, Hermann Himmelbauer 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
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
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 )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Mon Mar 2 12:00:00 2009 UTC to Tue Mar 3 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:25:23 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011217.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:27:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011218.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:29:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011219.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Mon Mar 2 20:31:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011220.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon Mar 2 20:33:29 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011221.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Mon Mar 2 20:35:30 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-March/011222.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Am Montag 02 März 2009 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
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: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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev wrote: > 2009/3/2 Tres Seaver : - >>> I believe people still use the ZCML "slug" files like the above. >> >> They certainly aren't related to 'zpkg'. The intent of the slugs was to >> allow for something like 'sites-available' / 'sites-enabled' (the >> pattern in a stock Debian Apache2 install). >> >> I think it is particularly unfortunate to remove support for explicit, >> granular configuration at the same time as folks seem to be jumping to >> implicit (aka "majyk") tools. >> >> Please revert this part of the change. > > I just reverted the change, however, I don't think that the "slug" > files are useful anymore. I cannot see similar slugs in other packages either. -- Baiju M ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] GSOC 2009
Hi All, A reminder... On Tue, Feb 17, 2009 at 12:39 AM, Martijn Faassen wrote: > Hey, > > The Zope Foundation would be happy to see people organize this. I > personally won't be spending time on the summer of code this year > however, so don't count on my helping to organize it this time. > > While some projects went fairly well, overall I wasn't happy with the > results visible in our community. My evaluation overall is that there > are better ways to invest my time to help the community make progress, > so count me out. The date is approaching to submit proposal. If any one want to become the administrator, please come forward. I have created few pages in wiki: http://wiki.zope.org/gsoc/SummerOfCode2009 http://wiki.zope.org/gsoc/ZopeFoundationsApplicationQuestionnaire2009 Can anyone please add 2008 experience to the questionnaire (Aroldo or Martijn ?) ? The "Zope 2 porting to Python 2.5" was technically a failure, but they did some real work with help of mentor (and later mentor himself completed it). so, we can consider it as a success. I am not sure about other projects. Anyway, in order to complete that questionnaire we need a summary of 2008 experience. 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] [Checkins] SVN: zope.file/trunk/ Update package mailing list address. Remove zpkg stuff.
2009/3/2 Tres Seaver : >>> - >> I believe people still use the ZCML "slug" files like the above. > > They certainly aren't related to 'zpkg'. The intent of the slugs was to > allow for something like 'sites-available' / 'sites-enabled' (the > pattern in a stock Debian Apache2 install). > > I think it is particularly unfortunate to remove support for explicit, > granular configuration at the same time as folks seem to be jumping to > implicit (aka "majyk") tools. > > Please revert this part of the change. I just reverted the change, however, I don't think that the "slug" files are useful anymore. They were used when we had "the zope3 application server" and we plugged some components into it, like sites are plugged into debian apache/nginx setups, but now-a-days, when it seems that most people just build their own applications using their custom app configuration files, I don't think that there's much sense for package-includes for including components like zope.file. I can think of a use for package-includes for some CMS application that include "website configuration" (like debian apache), but not the "component configuration". -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
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. ;) -- 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
On Tue, Mar 3, 2009 at 09:21, Martin Aspeli wrote: > If anything, we started out with too little process and found there were > gaps we had to plug. Ah. Now, THIS I like. Let's focus on this: Start out with as little process and as few officialisms as possible. And I don't see that a steering group is as little as possible. If it turns out to be necessary, we add it then. -- 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:13, Christian Theune 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
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 http://mail.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 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 )
