[Zope-dev] ZTK community packages

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tres Seaver wrote:
> Christophe Combelles wrote:
>> Hi!
> 
>> I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet (and 
>> many others) are among the most important packages. I wonder why they are not 
>> included in the ZTK? I always end up using them, I believe they should even be 
>> part of the core ZTK.
> 
>> If they are not part of the core, I would like them to be part of a 
>> *community.cfg* list. There already is a community.cfg list in BlueBream, but I 
>> don't like having many foobartoolkit in the wild, with many package lists to 
>> maintain. It's already difficult enough to maintain just 1 list for the 
>> zopetoolkit. Let's focus on it.
> 
> "Clumping" vs. "splitting" debates are endless, in many fields.  In the
> case of the ZTK, we have tried to say that the "core" toolkit consists
> only of packages in wide use by more than one of the "constituent"
> communities:  any package which doesn't meet that criterion should just
> be managed by the community which already cares for it.
> 
> If that community organizes automated testing for it package set(s), and
> publishes results (especially failures) for those packages when used
> with the core, then the broader communitiy has proved willing to work to
> resolve those problems.

I'm attaching a brief overview of the various ZTK and zopeapp package
sets, showing how they are used by the variouss downstream projects.
This analysis is based on current checkouts of each of Zope2, Grok, and
Bluebream.

- - "Direct" dependencies are mentioned in the setup.py (of the generated
  project for BlueBream).

- - "Transitive" usage is computed by loading the working set inside the
  custom interpreter after running each buildout, e.g.:

 $ bin/grokpy
 ...
 >>> from pkg_resources import working_set
 >>> from pprint import pprint
 >>> pprint(sorted([x.project_name for x in working_set]))
 ...

A couple of observations:

- - There is a sizable subset of the ZTK list which is actually used by
  all three downstream projects.  These packages are likeliest to stay
  healthy.

- - There is another big subset of the ZTK list shared by Grok and
  Bluebream, but not Zope2, which makes sense given their common
  ancestry.

- - Many of these packages are used only as transitive dependencies;
  such packages become more likely to bitrot, I think.  It is possible
  that the downstream packages don't explicitly list dependencies for
  code they import directly:  if that is true, we should fix them.

- - Each downstream project has a small subset of the ZTK list which
  only it uses.  These packages should perhaps move from the ZTK orbit
  into the orbit of the interested project.   Note that I'm not sure
  about a couple of the Grok-only projects (e.g., the catalog-related
  ones):  they may be missing from the BlueBream column simply because
  the project generated by BlueBream doesn't do cataloguing.

- - There are ZTK packages which are not used by any downstream project
  (zope.documenttemplate, zope.html, zope.mimetype, zope.ramcache)
  These packages should drop out of the ZTK, unless I have overlooked
  real usage.

There is a fourth column which I have no way to tabulate, which is
"classic Zope3" applications which have been updated to track the ZTK
versions.  Obviously the folks who are maintaining those applications
have a stake in the health of the packages they use.

I believe that we need to be looking for explicit maintainers for the
projects which narrower usage across the downstream projects.  I don't
know exactly what this process would look like:  one low-tech approach
would be to add a MAINTAINERS.txt file to each project with the names of
the developers or downstream projects who care for the project.

Any other thoughts?


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvUpM4ACgkQ+gerLs4ltQ6jFgCdGFojqifKMZ2e+4Hoji7vtsSq
DlgAn1m8UIrAkULAwOpki6pkC5eOy5QX
=0KO5
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: package_sets.pdf
Type: application/pdf
Size: 53696 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20100425/5a9dbde0/attachment-0001.pdf