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
