[Zope-dev] the Zope Framework project

[Gary Poster]

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