On 2016-11-21, Jan Matèrne wrote: > 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. I'd probably add it at the top of a README file as well so it is immediately visible to people browsing the github mirror. > We should ask infra to make the central repository read-only. +1 > - 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? I'd prefer to make it read-only so we keep history if anybody was to pick the subproject up again. > - mailing list > If the subproject/component we have to close this. We could send a final > email. s/could/should/ Furtunately there aren't that many subprojects with mailing lists of their own :-) > - announcement > I think we should announce the retirement of the subproject. absolutely. > - build jobs > All build jobs on Jenkins@Apache or TeamCity have to be deleted. Add Gump to that list. > - 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 +1 We probably need to define "how to reactivate" first. > - release further resources > Maybe a subproject locks further resources (update-site, ...). So we have > to release them? Not sure what lock and release means in this context, I've never understood the concept of update sites. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
