Future of the zope.app.* and z3c.* packages #193
Comments
|
I am all for archiving those packages. As far as I know it's not a problem un-archiving packages if someone cares enough. |
|
I would extend this question to many |
|
P.S.: I'd like to generalize that. Zope 3 the application server - roughly represented by the My question still stands: How do you select packages to work on? Do you have a list of dependencies for your own projects in the back of your mind or are you just going through page after page of package listings inside this GH organization, most of which is probably dead? |
|
We use at least https://github.com/zopefoundation/zope.app.http on Python 3.5 (still supported by the Ubuntu security team), so please do not archive that one. And yes, we do plan to upgrade. We also use a couple of z3c packages, so please announce a possible drop of support, although as mentioned, you could always unarchive them. |
|
Keep in mind that archiving does not remove existing releases, so if a user has an old application they can run and recreate that forever, regardless of archiving status. Unarchiving is only needed if someone is interested in continuing development and new releases. IMHO it's OK to then ask those people to take over that work as well. I would consider archiving more of a marker for the few people who are still active that this is a package we don't have to worry about when it comes to mass-updates like the current retirement of EOL Python versions. |
|
P.S.: And no, I don't consider it feasible to announce every archival. Nothing will break for those who care for such a package. If there is an audience interested in further development they will notice the package status easily enough and are free to ask for a change of status - or reconsider and switch to a better-supported package, which is probably a wise choice. |
@icemac announced the archival of the zope.app.* packages in bulk, so I assumed it would be possible to do the same for the z3c.* packages. I think the introduction of the meta tool also introduced a paradigm shift. In the following I refer only to non-mainstream packages, ie not used by Zope core, or not so common packages. Before the tool was introduced, we (as in any of the Zope contributors) just updated the packages we needed, or when somebody created an issue that a new release or new python support is necessary. So this was a community effort. Thousands of users, hundreds of contributors (or dozens at least). Since the introduction of the meta tool, suddenly there was an attempt to keep each package up to date. And I also noticed that most of the work is now done by @icemac - either intentionally, or at least at the beginning there was some hesitation as the meta tool was not super easy to use. Meanwhile it is at least used by a couple of contributors. And now @icemac speaks of a "maintenance burden" which needs to be reduced. I certainly get that this is a burden, but imho this is a self-inflicted burden. Why not just stop updating the repositories any more instead of archiving them? Then at least any user could work on them - without the step to ask any of the admins to reactivate it. Don't get me wrong, I am very, very thankful what @icemac and the other maintainers do, but imho nobody asked to keep every package up to date. |
|
I get a mail if GHA breaks for a package, so I decided to fix these packages. I vastly underestimated the effort necessary but now I've nearly done it. I do not like the idea of just leaving the repositories as they are. This generates a false impression of them being active and it creates even more maintenance mess. I think the active packages should kept active the no longer used ones may rest in peace. My current idea is to ensure that the tests run successfully for all currently active packages, create releases and then archive as much as possible in the namespaces But I'd like to gather some more opinions:
I think we should mark the repositories which are still in active use in projects int the wild, so they do not get archived. I did this for https://github.com/zopefoundation/Zope using a GitHub Topic and will do so for the repositories used in the projects I am maintaining. |
|
I fully agree with @icemac, if a package is no longer under active development then that fact must be communicated clearly in order to prevent bad assumptions and expectations. Archiving such a package is a good way to do that. The GitHub topic is a similar marker and a good idea, but IMHO if we archive packages it would just repeat the same information that archived vs. unarchived status already provides. An extensive cleanup among the 300+ packages in the zopefoundation organization is long overdue. My guess is that about half of them are dead or in vegetative state. @jugmac00 you seem to promote some kind of "free for all" vision of an unmaintained garden that is allowed to just grow wild, a place where no one takes any responsibility for anything. I don't think that makes these projects any more attractive and I highly doubt it will encourage anyone to contribute. @icemac has been doing the opposite, he has taken responsibility, and he wants to manage that responsibility. Now you're saying "stop complaining, this is all your own fault"? Come on. |
|
FWIW, as a regular contributor I do not have permissions to create tags in the zope repositories. Do you want me / all users to create an issue in each repository that you need to create a "maintained" tag? What is the consequence then? Will you maintain these repositories? Will you pass pypi and gh permissions to the one who created the issue? I think it is good that we have a discussion as by far not everything is clear. |
We need to distinguish between "used" and "there's a real need for further maintenance". I am sure you could find all of these old packages used somewhere in some custom application, but that doesn't mean much. |
|
I am done with marking the packages I require. (Note: I did not mark the packages in the Zope 5 stack.) @jugmac00 Creating an issue for the packages you'd like to take care of sounds like a good idea. With reference to #191 package maintainers could get additional permissions in the repositories they take care of to circumvent problems during releases. |
If no-one speaks up for a package it can get archived for now until we find out that is needs to be maintained. |
Combining this with your previous comment that you don't have an issue maintaining other packages you don't use yourself I am reading this in answer to @jugmac's question what consequences the "maintained" tag has: Marking a repository as "maintained" does not mean that other contributors like @icemac will automatically take it over. He may voluntarily help, but there is no obligation. The onus is on the person who applies the tag to find such maintainers. |
|
The only
In the Plone core development buildout we have a |
|
@mauritsvanrees Thank you for the list. I added the There was one exception: https://github.com/zopefoundation/five.pt is already archived as it is deprecated since Zope 4.0a2. So it should be dropped (CC: @jensens). |
|
You are right about |
|
I'd add the following, no claim this is complete: |
|
@dataflake I added the packages you listed. Currently we have 140 out of 281 active |
|
We use the following packages, no claim this is complete: |
@icemac, thanks for asking. My personally focus is on ZODB stack:
Maybe @perrinjerome knows better about other packages. |
|
Except for what's already listed in this thread, I see we use:
in other words, I think we don't need anything else that what was already listed here. Thanks ! |
|
I maintain zodbbrowser that depends on $ grep zope.app setup.py
"zope.app.pagetemplate",
"zope.app.publication",
"zope.app.authentication",
"zope.app.component",
"zope.app.server",
"zope.app.session", # purely BBB for old Data.fs'es
"zope.app.zcmlfiles",
"zope.app.folder",
"zope.app.container",
"zope.app.testing",(The last tree are dependencies for the The one remaining Zope 3 app in production (in long-term maintenance mode with no active development) depends on $ grep zope.app setup.py
"zope.app.exception",
"zope.app.securitypolicy",
"zope.app.appsetup",
"zope.app.authentication",
"zope.app.basicskin",
"zope.app.component",
"zope.app.container",
"zope.app.exception",
"zope.app.file",
"zope.app.folder",
"zope.app.form",
"zope.app.generations",
"zope.app.pagetemplate",
"zope.app.principalannotation",
"zope.app.publication",
"zope.app.publisher",
"zope.app.schema",
"zope.app.security",
"zope.app.server",
"zope.app.testing",
"zope.app.zopeappgenerations",
"zope.app.zcmlfiles",
"zope.applicationcontrol",
"zope.app.dublincore",
"zope.app.catalog",
"zope.app.intid",
"zope.app.session",I think I have sufficient permissions to unarchive a git repo if the need arises. |
|
@mgedmin I added the |
icemac
changed the title
|
@wosc Which packages do you need to be kept alive? |
|
Thanks for thinking of us specificially! I feel honored. :) We do indeed still use "half of a Zope3" stack for our main production CMS, so I'd be very glad if the "core" of it could be kept alive, which I think mostly consists of From the z3c realm we're using z3c.pagelet + z3c.template quite heavily (via gocept.pagelet). |
|
@wosc Thank you for sharing your list. I added the |
During making GHA green again by dropping support for Python < 3.7 a came along many
zope.app.*packages like:Some of them were used in the ZMI of Zope 3 or at least contain browser views for it.
Most of these packages had no release in the last 5 years.
Is someone still using these (kind of) packages?
Could we archive a few of them to reduce the maintenance burden? (If they are actually still used and need changes, we could unarchive them, of course.)
The text was updated successfully, but these errors were encountered: