DISCUSS How to retire a subproject/component

[Jan Matèrne]

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  

  

Re: DISCUSS How to retire a subproject/component

[Rm Beer]

is this a free software. is obviously that anyone can contribute or not
contribute. You only need remember that have one or something subproject
without maintain and later hope. This subprojects always can hope, not need
a clean

2016-11-21 4:08 GMT-03:00 Jan Matèrne :

> 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
>
>
>
>

Re: DISCUSS How to retire a subproject/component

[Stefan Bodewig]

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

AW: DISCUSS How to retire a subproject/component

[jhm]

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?   

---

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? 
  Do we have to announce the reactivation of the subproject announce@apache?

- 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. 
  
 






-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: DISCUSS How to retire a subproject/component

[Stefan Bodewig]

On 2016-11-25, Jan Matèrne (jhm) wrote:

> So here are the updated proposals for the two processes/todo-lists.

looks good to me

  Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: DISCUSS How to retire a subproject/component

[Conor MacNeill]

It does look good.

+1 from me

Conor


On 25 November 2016 at 18:18, Jan Matèrne (jhm)  wrote:
> 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?
>
> ---
>
> 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?
>   Do we have to announce the reactivation of the subproject announce@apache?
>
> - 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.
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: DISCUSS How to retire a subproject/component

[Nicolas Lalevée]

Hi,

See my comments inline.

> Le 25 nov. 2016 à 08:18, Jan Matèrne (jhm)  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

AW: DISCUSS How to retire a subproject/component

[jhm]

> > - 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 ?

This is a misunderstanding in my wording.
Here I use "release" as "not using any more" (like release a lock) and not 
"release a new version".

Maybe this clearer?

--8-<8-<8-<8-<--
- free further resources

  Maybe a subproject locks further resources (update-site, ...). So we have
  to release/delete them?   
--8-<8-<8-<8-<--


> 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 ?

Sounds good.
But if we delete them, how get they archived?


> The formal vote has no special reason to be private, so I guess
> everything will be discussed and advertised there.

Ok, I added on both:
"... is started by a formal vote of the Ant PMC at dev@ant."


> >  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.

Ok, decision postponed  ...

"Announce the reactivation of the subproject at dev@ant.
Decide about announcing the reactivation of the subproject at announce@apache."


Where could I write these infos?
Wiki seems to be read-only.
New paragraph in site/ant/production/bylaws.html
A new page on the homepage (Project Management | Processes)?


Jan


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: DISCUSS How to retire a subproject/component

[Stefan Bodewig]

On 2016-11-30, Jan Matèrne (jhm) wrote:

>> 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 ?

> Sounds good.
> But if we delete them, how get they archived?

They should already be somewhere under
http://archive.apache.org/dist/ant/ (or the corresponding incubator
folder).

> Where could I write these infos?
> Wiki seems to be read-only.

No, shouldn't be. Somebody with access to the right wiki pages (e.g. me)
needs to add your Wiki user name. See the front page :-)

,
| If you wish to contribute, please create a user profile and log
| in. Unfortunately we've been receiving more spam than we can handle so
| after you have created your profile you need to ask on either the user
| or dev list once and your profile will be granted the right to edit
| existing or create new pages.
`

> New paragraph in site/ant/production/bylaws.html

Probably only in the "Actions" section right next to "Adoption of New
Codebase". This would cover the "how to approve" but not the process
itself.

> A new page on the homepage (Project Management | Processes)?

I'd vote for the Wiki with a link from the home page or an extra page
rather than the bylaws.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

AW: DISCUSS How to retire a subproject/component

[jhm]

I am updating the homepage.
Before committing and make that "official" please comment:

http://materne.de/ant/processes.html
http://materne.de/ant/archive.html


Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Mittwoch, 30. November 2016 13:35
> An: dev@ant.apache.org
> Betreff: Re: DISCUSS How to retire a subproject/component
> 
> On 2016-11-30, Jan Matèrne (jhm) wrote:
> 
> >> 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 ?
> 
> > Sounds good.
> > But if we delete them, how get they archived?
> 
> They should already be somewhere under
> http://archive.apache.org/dist/ant/ (or the corresponding incubator
> folder).
> 
> > Where could I write these infos?
> > Wiki seems to be read-only.
> 
> No, shouldn't be. Somebody with access to the right wiki pages (e.g.
> me) needs to add your Wiki user name. See the front page :-)
> 
> ,
> | If you wish to contribute, please create a user profile and log in.
> | Unfortunately we've been receiving more spam than we can handle so
> | after you have created your profile you need to ask on either the
> user
> | or dev list once and your profile will be granted the right to edit
> | existing or create new pages.
> `
> 
> > New paragraph in site/ant/production/bylaws.html
> 
> Probably only in the "Actions" section right next to "Adoption of New
> Codebase". This would cover the "how to approve" but not the process
> itself.
> 
> > A new page on the homepage (Project Management | Processes)?
> 
> I'd vote for the Wiki with a link from the home page or an extra page
> rather than the bylaws.
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: DISCUSS How to retire a subproject/component

[Nicolas Lalevée]

> Le 30 nov. 2016 à 15:54, Jan Matèrne (jhm)  a écrit :
> 
> I am updating the homepage.
> Before committing and make that "official" please comment:
> 
> http://materne.de/ant/processes.html <http://materne.de/ant/processes.html>

Since some of the subtitles are common between « Retire » and « Reactivate », 
there are duplicate anchors, so some links are not working as expected.

In http://materne.de/ant/processes.html#mailing list 
<http://materne.de/ant/processes.html#mailing%20list>, « has its own mailing 
list » is missing.

Also as discussed, I think the section « free further resources » could be 
removed and replaced by a section « releases ». In this section I would write 
that:

The last released artifacts, if any, should be removed from the Apache 
distribution serveur. To do so, remove any artifact related to the retired 
subproject in https://dist.apache.org/repos/dist/release/ant/ 
<https://dist.apache.org/repos/dist/release/ant/> (it is managed with 
subversion). Note: as every Apache release, nothing is deleted but everything 
is archived, the artifacts will still be available at 
https://archive.apache.org/dist/ant/ <https://archive.apache.org/dist/ant/>.

> http://materne.de/ant/archive.html <http://materne.de/ant/archive.html>

LGTM

Nicolas


> 
> 
> Jan
> 
>> -Ursprüngliche Nachricht-
>> Von: Stefan Bodewig [mailto:bode...@apache.org]
>> Gesendet: Mittwoch, 30. November 2016 13:35
>> An: dev@ant.apache.org
>> Betreff: Re: DISCUSS How to retire a subproject/component
>> 
>> On 2016-11-30, Jan Matèrne (jhm) wrote:
>> 
>>>> 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 ?
>> 
>>> Sounds good.
>>> But if we delete them, how get they archived?
>> 
>> They should already be somewhere under
>> http://archive.apache.org/dist/ant/ (or the corresponding incubator
>> folder).
>> 
>>> Where could I write these infos?
>>> Wiki seems to be read-only.
>> 
>> No, shouldn't be. Somebody with access to the right wiki pages (e.g.
>> me) needs to add your Wiki user name. See the front page :-)
>> 
>> ,
>> | If you wish to contribute, please create a user profile and log in.
>> | Unfortunately we've been receiving more spam than we can handle so
>> | after you have created your profile you need to ask on either the
>> user
>> | or dev list once and your profile will be granted the right to edit
>> | existing or create new pages.
>> `
>> 
>>> New paragraph in site/ant/production/bylaws.html
>> 
>> Probably only in the "Actions" section right next to "Adoption of New
>> Codebase". This would cover the "how to approve" but not the process
>> itself.
>> 
>>> A new page on the homepage (Project Management | Processes)?
>> 
>> I'd vote for the Wiki with a link from the home page or an extra page
>> rather than the bylaws.
>> 
>> Stefan
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
>> commands, e-mail: dev-h...@ant.apache.org
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 

AW: DISCUSS How to retire a subproject/component

[jhm]

Thanks for feedback.

> Since some of the subtitles are common between « Retire » and «
> Reactivate », there are duplicate anchors, so some links are not
> working as expected.

Fixed by adding a prefix "retire: " / "reactivate: "


> In http://materne.de/ant/processes.html#mailing list
> , « has its own
> mailing list » is missing.

Added.


> Also as discussed, I think the section « free further resources » could
> be removed 

I don't think so. This is a placeholder to think about further resources a 
subproject
could locked. Maybe some docker images somewhere? ;-) That's up to the 
subproject. But don't forget that.


> and replaced by a section « releases ». In this section I
> would write that:
> 
> The last released artifacts, if any, should be removed from the Apache
> distribution serveur. To do so, remove any artifact related to the
> retired subproject in https://dist.apache.org/repos/dist/release/ant/
>  (it is managed with
> subversion). Note: as every Apache release, nothing is deleted but
> everything is archived, the artifacts will still be available at
> https://archive.apache.org/dist/ant/
> .

Added.
Added also a paragraph "reactivate: releases".

  
All earlier releases are available at https://archive.apache.org/dist/ant/";>https://archive.apache.org/dist/ant/.
We don't have to copy them back to https://dist.apache.org/repos/dist/release/ant/";>https://dist.apache.org/repos/dist/release/ant/.
But further releases are placed here. 
  


Added also "note"-section to the archives-page.

Added also a note about incubator-releases.


Again:
http://materne.de/ant/processes.html
http://materne.de/ant/archive.html


Jan




-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org