DISCUSS How to retire a subproject/component

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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  

         

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS How to retire a subproject/component

Stefan Bodewig
In reply to this post by Jan Matèrne
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: DISCUSS How to retire a subproject/component

Jan Matèrne (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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS How to retire a subproject/component

Conor MacNeill
In reply to this post by Jan Matèrne (jhm)
It does look good.

+1 from me

Conor


On 25 November 2016 at 18:18, Jan Matèrne (jhm) <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS How to retire a subproject/component

Nicolas Lalevée
In reply to this post by Jan Matèrne (jhm)
Hi,

See my comments inline.

> Le 25 nov. 2016 à 08:18, Jan Matèrne (jhm) <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: DISCUSS How to retire a subproject/component

Jan Matèrne (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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

AW: DISCUSS How to retire a subproject/component

Jan Matèrne (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:[hidden email]]
> Gesendet: Mittwoch, 30. November 2016 13:35
> An: [hidden email]
> 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: [hidden email] For additional
> commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: DISCUSS How to retire a subproject/component

Nicolas Lalevée

> Le 30 nov. 2016 à 15:54, Jan Matèrne (jhm) <[hidden email]> 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:[hidden email]]
>> Gesendet: Mittwoch, 30. November 2016 13:35
>> An: [hidden email]
>> 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: [hidden email] For additional
>> commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

AW: DISCUSS How to retire a subproject/component

Jan Matèrne (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
> <http://materne.de/ant/processes.html#mailing%20list>, « 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/
> <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/>.

Added.
Added also a paragraph "reactivate: releases".
    <subsection name="reactivate: releases">
      <p>
        All earlier releases are available at <a href="https://archive.apache.org/dist/ant/">https://archive.apache.org/dist/ant/</a>.
        We don't have to copy them back to <a href="https://dist.apache.org/repos/dist/release/ant/">https://dist.apache.org/repos/dist/release/ant/</a>.
        But further releases are placed here.
      </p>
    </subsection>

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: [hidden email]
For additional commands, e-mail: [hidden email]