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