[Zope-dev] the Zope Framework project

[Stephan Richter]

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"