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.


> 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.


There certainly are stakeholders who are willing to invest on this,  
particularly on core packages (where "core" differs for the  

>> 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?)


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to