Request to remove Zope community projects from LP

Asked by Jens Vagelpohl

This is a followup to https://answers.launchpad.net/launchpad/+question/683589 which has expired and I don't see any way to change the status back. Specifically, I am replying to Colin Watson from reply 14:

The list of obsolete Zope community projects that have all moved to GitHub many years ago and which we would like to have deleted:

https://launchpad.net/acquisition
https://launchpad.net/datetime
https://launchpad.net/extensionclass
https://launchpad.net/missing
https://launchpad.net/multimapping
https://launchpad.net/persistence
https://launchpad.net/products.zsqlmethods
https://launchpad.net/record
https://launchpad.net/restrictedpython
https://launchpad.net/threadlock
https://launchpad.net/zope2
https://launchpad.net/zopeundo
https://launchpad.net/five.formlib
https://launchpad.net/initgroups
https://launchpad.net/tempstorage
https://launchpad.net/z3c.etree
https://launchpad.net/zdaemon
https://launchpad.net/zope3
https://launchpad.net/zope.annotation
https://launchpad.net/zope.browser
https://launchpad.net/zope.browsermenu
https://launchpad.net/zope.browserpage
https://launchpad.net/zope.browserresource
https://launchpad.net/zope.cachedescriptors
https://launchpad.net/zope.component
https://launchpad.net/zope.componentvocabulary
https://launchpad.net/zope.configuration
https://launchpad.net/zope.container
https://launchpad.net/zope.contentprovider
https://launchpad.net/zope.contenttype
https://launchpad.net/zope.datetime
https://launchpad.net/zope.deferredimport
https://launchpad.net/zope.deprecation
https://launchpad.net/zope.dottedname
https://launchpad.net/zope.event
https://launchpad.net/zope.exceptions
https://launchpad.net/zope.filerepresentation
https://launchpad.net/zope.formlib
https://launchpad.net/zope.hookable
https://launchpad.net/zope.i18n
https://launchpad.net/zope.i18nmessageid
https://launchpad.net/zope.interface
https://launchpad.net/zope.lifecycleevent
https://launchpad.net/zope.location
https://launchpad.net/zope.mkzeoinstance
https://launchpad.net/zope.pagetemplate
https://launchpad.net/zope.processlifetime
https://launchpad.net/zope.proxy
https://launchpad.net/zope.ptresource
https://launchpad.net/zope.publisher
https://launchpad.net/zope.ramcache
https://launchpad.net/zope.schema
https://launchpad.net/zope.security
https://launchpad.net/zope.sendmail
https://launchpad.net/zope.sequencesort
https://launchpad.net/zope.site
https://launchpad.net/zope.structuredtext
https://launchpad.net/zope.tal
https://launchpad.net/zope.tales
https://launchpad.net/zope.testbrowser
https://launchpad.net/zope.testing
https://launchpad.net/zope.testrunner
https://launchpad.net/zope.traversing
https://launchpad.net/zope.viewlet

Question information

Language:
English Edit question
Status:
Solved
For:
Launchpad itself Edit question
Assignee:
No assignee Edit question
Solved by:
Colin Watson
Solved:
Last query:
Last reply:
Revision history for this message
Jens Vagelpohl (dataflake) said :
#1

By the way, I saw no way to bulk-close the obsolete issues that hang around in some of those bug trackers. Other than clocking into every single one. If you have a way to do this programmatically (and you think this is important, which we do not) go ahead and close them.

Thank you!

Revision history for this message
Colin Watson (cjwatson) said :
#2

Some of this will specifically break us: for instance, https://code.launchpad.net/~launchpad-committers/zope.testrunner/+git is the fork of zope.testrunner that we're about to start using in Launchpad, updating from a similar much older fork of zope.testing. Removing those projects would make our own code inaccessible to us, and you really can't expect us to be happy about doing that!

There are less invasive things we can do than removing the projects. Please would you at least be open to discussing them with us? It is not just about your code.

Revision history for this message
Jens Vagelpohl (dataflake) said :
#3

Please remove any and all projects that you do not depend on yourself.

All those you depend on should be closed off or clearly marked so it is very obvious this is a fork and not part of the Zope Foundation code anymore, and not related to and/or supported by the Zope Foundation.

Revision history for this message
Best Colin Watson (cjwatson) said :
#4

Some of these projects are essentially trivial (no bugs and just an obsolete trunk branch), and those are now gone from Launchpad:

  extensionclass
  initgroups
  multimapping
  persistence
  record
  tempstorage
  threadlock
  z3c.etree

The remainder have had bugs filed over their lifetime, several thousand in total. Removing the projects would make it impossible to see those bugs at all. Not only are several of these mentioned in e.g. the Launchpad codebase and commit history as part of justifications for complex changes, but lots of them also appear in the upstream changelogs for Zope projects. As an occasional Zope upstream contributor and frequent downstream consumer I've often had occasion to refer to these since long after Zope moved to GitHub, and it would be a serious pain if they were to vanish from the internet.

However, I do understand the need to make it clear that none of these projects are the home of upstream development and that nobody should be looking at them for anything more than historical information. To that end we've done the following for all these projects, which is about as close as I can manage in the absence of a formal "archived" status and I think makes it pretty obvious that they're no longer active:

 * unset the "Bugs in this project are tracked in Launchpad" flag, which should prevent any new bugs being filed
 * marked all active branches as Abandoned
 * removed all the default Git repositories, since all of these were moved wholesale into GitHub
 * removed the links from all their corresponding Ubuntu packages, where applicable
 * added a clear statement to the description of each project to the effect that it has been moved to GitHub and that it's only archived for the sake of bug history

We could also change the maintainer of all these projects to the "Registry Administrators" team, which is used for the very many Launchpad projects that exist mainly to track something that's hosted elsewhere. For those familiar with it that would be another useful indicator, and it would remove the claim that these are maintained by the ZTK Steering Group when they aren't, but I'd only do that extra step with explicit permission.

I'm in the process of bulk-closing all the still-open bugs (which certainly does not require clicking through every single one; I'm using launchpadlib for this). I have to go out now, but I'll finish it when I'm back.

Revision history for this message
Jens Vagelpohl (dataflake) said :
#5

Thank you very much for going through all those packages. I should be able to take a closer look this weekend.

Revision history for this message
Jens Vagelpohl (dataflake) said :
#6

Thank you Colin! Looking good!

Revision history for this message
LeoRochael (leorochael) said :
#7

> We could also change the maintainer of all these projects to the "Registry Administrators" team, which is used for the very many Launchpad projects that exist mainly to track something that's hosted elsewhere. For those familiar with it that would be another useful indicator, and it would remove the claim that these are maintained by the ZTK Steering Group when they aren't, but I'd only do that extra step with explicit permission.

As a zope committer, I'm ok with changing the maintainer of all these projects to "Registry Administrators".

Revision history for this message
Jens Vagelpohl (dataflake) said :
#8

Leo, it doesn't really matter, that's why I have not followed up on this.

Revision history for this message
Jens Vagelpohl (dataflake) said :
#9

Thanks Colin Watson, that solved my question.