Hey, Christophe Combelles wrote: > Thanks for these suggestions. This is *exactly* what we (the ztk > release team) need.
How wonderfully diplomatic and constructive, my compliments! The release team (you, Hanno and JW) look good to me. >> * please let these guidelines not block most updates by most people >> most of the time; it should be easy to update the ZTK. Gatekeepers >> tend to slow things down a lot, and we don't have them for most >> Python code. > > We have already started discussing about this. One idea is to let the > ZTK update or even release by itself, with the help of the buildbot > infrastructure. I would like to replace the expected ztk bureaucracy > with automated scripts that enforce some rules and *help* people. > Particularly the implicit rules that make people upset when they are > not respected. One example is the first message of the previous > thread ;) > The Zope ecosystem and its processes has become quite complex, and we > cannot expect people to never do errors or to know or read > everything. Yes. But I don't think you can replace people's judgment with processes completely. Differences of judgment will continue to exist too, and they shouldn't lead to deadlocks. In that case it becomes useful to have leadership with vision with the authority to break deadlocks. Vision is also useful to go beyond processes. I think one interesting distinction has to do with structure versus versions. I think we should be quite open in allowing people to release new versions of packages and update the ZTK. Especially bugfix releases, of course, but I think many feature releases can also be safely integrated. Structural changes, where packages are dropped or added, need more discussion. I think the cost for having a package in the ZTK is fairly low as long as it doesn't have a lot of things depending on it, but I realize that the cost is non-zero so shrinking the ZTK sounds like a good plan. Dropping is dangerous for other reasons than adding. Adding a package is dangerous as you give a certain commitment to maintain this package for a long time. Dropping a package is dangerous as you break this commitment. We have the complexity here that we have a *new* project that is actually the underpinning of several projects (Grok, BlueBream, Zope 2) with a long history. I therefore think the issue of dropping is immediately relevant, not only after the 1.0 release. Why is dropping a package an issue? It's an issue because you break backward compatibility promises. Another way to look at it is that you're removing features from the ZTK. Another way to look at it is that you're removing *tests* from the ZTK. We don't expect people to just remove a bunch of tests from zope.component without a very good reason and probably some discussion. I think this is why version updates are generally okay, even drastic version updates, and structural updates are more risky. Of course there are some cases where a version update can break a lot of other packages. I.e. the package is depended on a lot by other packages and you're changing a contract. This is a situation that should be as carefully considered as removing a package. I think the structural organization should follow the lines of interest of project groups more than it should follow lines of content. But I'm wary about trying to organize too much, as separating bits *does* make maintenance harder. >> * there's a 'checknew.py' script to see whether there are releases >> newer than the ZTK. I'd be useful if this were integrated in the >> standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd >> also be nice if that were reusable by other toolkit projects. > > It's on the way. It will probably take the buildout.cfg as an > argument, to allow checking different buildout files with possibly > different versions. Cool. Also reasonable to make 'buildout.cfg' the default, I think? >> * In general it'd be useful if the release team recorded decisions >> in the ZTK documentation. It's confusing to have to go look for >> them in mailing list archives and people tend to forget or >> reinterpret decisions as time goes by. > > Ok, we will write down decisions or status somewhere. We are just > starting organizing ourselves. I think you can just use this: http://docs.zope.org/zopetoolkit/ That's what it is for. It's a Sphinx site. Just a few updates that Wichert can point me to when I get confused would probably help both me and Wichert tremendously. :) I kept decisions here, though they should be reorganized: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html You could probably start a new page like that. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )