[Zope-dev] summary of suggestions

Martijn Faassen faassen at startifact.com
Mon May 3 18:57:08 EDT 2010


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



More information about the Zope-Dev mailing list