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"
> - 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
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.
> 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.
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -