Hi, See my comments inline.
> Le 25 nov. 2016 à 08:18, Jan Matèrne (jhm) <apa...@materne.de> a écrit : > > There aren't as many comments as I hoped to get ... > A main comment was that we also need a process of reactivating a subproject. > > So here are the updated proposals for the two processes/todo-lists. > > Again - please comment. > > > Jan > > > ------------------------------ > > The retirenment of a subproject/component is started by a formal vote of the > Ant PMC. > > When retiring a subproject/component, what should and have we to do? > Basically we have to announce it and make resources read-only. > > - 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. > > Add a note 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. > > - issue tracker > > If the subproject/component has its own issue tracker we have to close that. > It is enough to make it read-only, so these information are longer available. > > - mailing list > > If the subproject/component we have to close this. We should send a final > email. > > - announcement > > We have to announce the retirement of the subproject at dev@ant, > announce@apache and the Ant main page. > > - build jobs > > All build jobs on Jenkins@Apache, TeamCity and Gump 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? I don’t understand this. How a retirement of a sub project should trigger the release of a related project ? And about the Eclipse updatesite, it can be viewed as the production of extra binary artifacts for the ease of end users, just like there are binary jars next to the sources for Ant. The Eclipse update site is not a project per se. So we shouldn’t have a specific process for it. It is a responsibility for the Ivy and the IvyDE sub projects to integrate it in their release process. This topic raises another question. What should we do about the artifact released in dist ? I guess we should delete them so they get archived ? > ----------------------- > > The Ant PMC start the reactivation of a subproject/component by a formal vote. > > When reactivating a subproject/component, what should and have we to do? > Basically we have to announce it and make resources read-write again. > > - version control > > Delete the marker file (e.g. "RETIRED_PROJECT"). > > Delete the note 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-write again. > > - issue tracker > > If the subproject/component has its own issue tracker we have to reopen that. > > - mailing list > > Because reopeing implies a smaller community we should use the main > mailinglist > dev@ant. So reactivating a special list is not required and could be > postponed > to a later PMC decision. > > - announcement > > We should announce the reactivation of the subproject dev@ant? The formal vote has no special reason to be private, so I guess everything will be discussed and advertised there. > Do we have to announce the reactivation of the subproject announce@apache? I think it will depend on the community involved, if they want more publicity. > - build jobs > > New build jobs on Jenkins@Apache, TeamCity and Gump could be created as > required. > > - homepage > > If we have an "attic/archive" page remove it from there. > > - reactivate further resources > > Make existing read-only resources read-write again. > Further resources could be gained as required. So generally, looks good to me too, +1. Thank you Jan. Nicolas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
