community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: Documented Process for archiving project/module?
Date Wed, 16 Nov 2016 00:39:03 GMT
Is anything wrong with that the PMC is handling this on a
project-by-project basis?

Likewise, you could say similar "communicating that status to the larger
public community" for just about every aspect of a project's life, and that
those are inconsistent across the ASF.

* Release cycles
* Programming Language
* Versioning conventions
* Git vs Svn
* Number of repositories
* Number of release artifacts
* Use of issue tracker vs mailing lists
* Number of mailing lists in a project
* Barrier level for becoming committer and PMC member
* Responsiveness to external patches
* Maturity level
* Build systems
* Prerequisites

I have always viewed that as a strength rather than a weakness. So my
simple question is; Why is software development lifecycle management any
different to any of the above?


On Wed, Nov 16, 2016 at 6:52 AM, Shane Curcuru <> wrote:

> Do we have an overview of the whole decision/action process around
> retiring each of a podling, a TLP, and a module/subproject within a TLP?
> I know the Attic has technical process documentation - but do we have a
> guide for the whole process, starting with either a community member (or
> the board!) noticing a project is mostly inactive, to actually deciding
> it's not active enough to be maintained, etc.?
> The board regularly sees or hears about projects or modules that aren't
> active, and want to retire.  But we aren't consistent across the ASF at
> communicating that status to the larger *public* community - sometimes
> it's just the PMC list that decides and moves to the board.
> Just an idea...
> - Shane
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Niclas Hedhman, Software Developer - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message