Suggestion,
what if we separate concerns here and we split modules that are dying
or that are zombies from modules that are being worked on  or close to
be supported?
The apache foundation does something similar, we could use  a similar approach.

It might probably be easier to explain why something is part of
"dormant" or "legacy" rather than mixing up things that are leaving
with things that are entering like now.

We could do:

- incubator, about to enter
- dormant, unsupported, not yet to be removed
- legacy. unsopported, about to be removed

In the end it just means to split unsupported.

Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584983027
fax:      +39 0584983027
mob:    +39 333 8128928


http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------



On Sat, Mar 13, 2010 at 11:50 AM, Andrea Aime <aa...@opengeo.org> wrote:
> Jody Garnett ha scritto:
>> I agree with the story aspect! Could we use the pom description to explain 
>> what is going on?
>
> Process process... we already have enough that it's hard
> to make it respected.
>
> If people want to note somewhere about the history of a
> module that's fine, but I would leave it up to module maintainers.
>
> I personally would go for old fashioned README files, but again,
> up to the maintainer.
> People interested in unsupported module can just also go and ask.
> Or be creative and do an "svn log" seeing who worked on it, when,
> and what he did (assuming people use self explanatory commit messages,
> which thankfully often happens around here)
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to