On 3/13/10 6:58 AM, Simone Giannecchini wrote:
> 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.

+1 to this idea. There is definitely need of an incubator space since 
they should really be treated differently from unsupported. I would be 
happy leaving unsupported as is but adding an incubator section for new 
modules and experimentation.
>
> 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


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

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