Sadly we have some subprojects without any committer nor community background.
Instead of leaving them as they are and hoping that "someone" will "sometime in the future" work harder on them and do a release we retire them. In that way we will reflect the real current status. As for top level projects the Apache Attic we coult reactivate them if required. When retiring a subproject/component, what should and have we to do? I collect some topics: - version control Most of our source code is in git, only "site" and "sandbox" use subversion. I propose to simply place a marker file on the top level. Copying/Moving to another location as Tomcat does on subversion (svn.a.o/repos/asf/tomcat/archive) doesn't make sense to me as with git we always have a complete repository. The marker file (e.g. "RETIRED_PROJECT") could contain the result of the vote, or further information like who to contact in case of reactivation. We should ask infra to make the central repository read-only. - issue tracker If the subproject/component has its own issue tracker we have to close that. Is it enough to make it read-only, so these information are longer available or do we have to delete it? - mailing list If the subproject/component we have to close this. We could send a final email. - announcement I think we should announce the retirement of the subproject. - build jobs All build jobs on Jenkins@Apache or TeamCity have to be deleted. - homepage We could create an "attic/archive" page and list all retired subprojects. Here we could also place information about the * the retirement "process" * where to find the old resources (vcs, mail archive, issue tracker) * who to ask current questions * how to reactivate - release further resources Maybe a subproject locks further resources (update-site, ...). So we have to release them? Please comment. Jan