Hi there, I just completed removing the python herd from the metadata of about 70 packages in the net-zope category (all of these packages are still nominally maintained by the net-zope herd). This happened due to the fact that the majority of the python team isn't interested in maintaining Zope-related packages (there's 200+ of them in the net-zope category), and a different herd already exists that should in theory be able to take care of them.
The net-zope herd nominally has two members: radek and tupone. From grepping changelogs, radek hasn't committed anything in net-zope since 2007. tupone committed one change in net-zope in 2010 and 4 in 2009. Instead, most of the recent work has been done by arfrever, who has recently been retired. Given this situation, I'm not sure it makes sense for us to keep all of those packages in the tree. Except for dependencies on zope-interface, which is pretty accepted and will keep being maintained by the python team in addition to the net-zope team, not much is depending on net-zope packages, either: app-admin/zprod-manager depends on net-zope/zope (hasn't been committed to since 2008) dev-python/rdflib has an optional dependency on net-zope/zodb, in addition to many other storage backends media-libs/FusionSound for whatever reason blocks net-zope/zodb (There are two packages in dev-python that depend on zope-testing, but those are actually only dependencies of net-zope packages again.) Zope maintenance is a lot of work and delays other stuff indefinitely: https://bugs.gentoo.org/show_bug.cgi?id=148333 (blockers for Python 2.5) https://bugs.gentoo.org/show_bug.cgi?id=335248 (new Plone requires 80-100 new ebuilds) And there are 3 open security bugs from 2011 with vulnerabilities in Zope and/or Plone. So unless someone steps up to takes a serious whack at all of this stuff, perhaps we should just cut it from the portage tree. Cheers, Dirkjan
