Thanks for these suggestions. This is *exactly* what we (the ztk release team)
Are there other recommendations from other people?
Martijn Faassen a écrit :
> Hi there,
> Because my suggestions (besides the fork issue) as a ZTK
> user/contributor were scattered through the thread, here's a handy summary:
> * please construct guidelines for updating the ZTK when making a release
> of a package that's managed by the ZTK project. It's useful people
> test their changes within the ZTK.
> * 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
We have already started discussing about this. One idea is to let the ZTK
or even release by itself, with the help of the buildbot infrastructure.
I would like to replace the expected ztk bureaucracy with automated scripts
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.
> * 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
checking different buildout files with possibly different versions.
> * (new idea) similarly it'd be nice if there were a script integrated
> that could check which binary egg releases exist for Windows (32 bit,
> 64 bit,
> Python version). Right now BlueBream is maintaining a list here:
> * Please update the ZTK documentation about the status of the ZTK
> steering group and the ZTK release team. It's unclear to newcomers
> such as myself.
> * 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
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -