[Zope-dev] summary of suggestions

[Martijn Faassen]

Hi there,

Tres Seaver wrote:
> One issue with insta-updates to ztk.cfg is that ongoing development of a
> package can be in real tension with the needs of ZTK consumers for
> "stability" in the package set.  

Since there are no ZTK releases Grok and BlueBream gain stability by 
pinning to a particular revision of ztk.cfg (and moving it forward when 
needed). Zope 2 could easily do the same. If more is needed, then a 
branch or tag can easily be made. Besides the perennial documentation 
issues, I also don't see why we couldn't just start releasing the ZTK; 
instead of pinning to an SVN revision we'd start pinning to an SVN tag 
(or a release URL with version number in it). What's the holdup, really?

One objection I can see is that we might end up with quite a few 
releases in a short period, and it might be nicer to have a more stable 
base that people can build on. But they could simply pin to one release 
and stick with it for a while, right?

> E.g., I have updated
> zope.testbrowser/trunk to use the new version of mechanize, but don't
> know whether pulling that version into the ZTK proper is reasonable (in
> fact, I decided to have the ZTK development buildout use a "stable"
> branch for the meanwhile).

Why wouldn't it be reasonable to try at least? If you tested it with the 
ZTK, you might find issues with your integration of a new version of 
mechanize. But anyway, you didn't release zope.testbrowser either yet, 
so this isn't a very good example of what I'm complaining about.

I understand that you sometimes want to be careful about what to 
include, but this kind of "ZTK-breaking" release is very rare and I 
haven't seen a good example of it in Zope 2's list. Is there?

> If you are a ZTK consumer, and would like to see the ZTK include a newer
> version of one of its packages, then that need has to be balanced with
> the needs of the "downstream" projects.  In effect, the new "release
> manager group" is supposed to represent the interests of Grok, Zope2,
> and BlueBream in a shared definition of the ZTK "known good set."
> Getting that nailed down into a version which works for all three is
> *way* more important than picking up individual package changes.

I'll note that Zope 2's fork is moving *faster* than the ZTK itself 
right now; a whole slew of mostly bugfix versions are used by Zope 2's 
list that aren't in the ZTK. I don't see a reason why instead the ZTK 
couldn't have been updated with those bugfix releases and Zope 2 
could've used that. That way Grok and BlueBream would have benefited 
from the same fixes.

And if Zope 2 needs to do a bigger change of a package that's in the 
ZTK, that might break other users of the ZTK, and do a release without 
discussing it here, then there is something wrong already.

Anyway, this all has nothing to do with why the fork happened in 
december. The fork happened in december because of a very specific 
debate that has nothing to do with this. Such lack of commitment made me 
less interested in committing my own time and energy as well.

Regards,

Martijn