[Zope-dev] the Zope Framework project

[Martijn Faassen]

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