Here is a list of community modules that I think I'm either the author,
co-author, or current maintainer of (I am pretty terrible about putting my
name in the appropriate fields in the pom, sorry about that.)
- css: definitely still maintained (although most of the real work of
this module is in a github repository, it is basically just a complicated
wicket form.)
- geosync: iirc I was involved in the original development of this
module. not sure if anyone is currently using it, i'm not.
- openplans-authentication: think this one is safe to remove
- printing: GeoNode, and I think others, use this. Maybe it would be
worth bumping this up to extension status.
- proxy: used in the OpenGeo suite, possibly others as well. Please keep.
- QueryUsers: this was an experiment leading up to restconfig. I am not
currently aware of any users and don't actively work on it.
- scriptlet: This is getting a bit of interest among OpenGeo's JavaScript
team, would like to hang on to it. Maybe someday it can merge with the
python module...
- upload: This was developed to support a couple of
prototype/experimental projects in OpenGeo - I don't actively maintain it
and am not aware of any users.
Speaking for GeoNode, we have also considered including the FTP module, so I
would be disappointed to see that one go.
One more thought about CSS - if we could bring the istyler functionality in
as a core feature and allow reusing that component, then the CSS module
could be a lot smaller, which would be nice for me. And we could get rid of
the istyler module as a separate entity.
--
David Winslow
OpenGeo - http://opengeo.org/
On Fri, May 13, 2011 at 2:14 PM, Andrea Aime
<[email protected]>wrote:
> On Fri, May 13, 2011 at 7:58 PM, Gabriel Roldán <[email protected]>
> wrote:
> > Hey, so this is my concern wrt community modules: IMHO the whole concept
> > of having community modules in the mainstream svn repo is obsolete.
> >
> > I don't quite remember if we already discussed it, but for how long are
> > we going to keep tied to svn?
>
> Good question. I'd say, for a little while longer.
> Here is the rationale. I know that many (most?) core developers are using
> the git-svn bridge nowadays and git full fledged in some project or the
> other, so moving GS to GitHub would probably be a good move for
> the most active committers.
>
> At the same time community area is about to get more people involved.
> Most of the times I go and propose git usage to a customer the answer is
> "no, too complex", and a number of people that tried it after my
> enthusiastic
> descriptions reported us that "they hate it".
>
> git-svn for me has been nothing short of fantastic so far, had a bumpier
> ride with full git but I feel the advantages overcome the shortcomings.
> For me.
>
> I'm however quite worried that forcing people to use git will add to
> the existing entry barrier, along with complex code and the
> use of Maven, which like it or not, did not achieve Ant widespread
> usage and mindshare.
>
> Long story short, I feel that moving to git would be natural for the core
> developers, but would actually hamper potential contributors
> of community modules with one more steep learning curve
> to overcome.
>
> That said, I'm not against moving to git if others feel like it would
> be an improvement for the wider community.
>
> > Second concern perhaps of a more immediate solution is there seems to
> > ~43 folders under community/ some of them look like empty (control-flow,
> > performanceChecker), some may be obsolete, so we might want to go
> > through some sort of clean up round?
>
> Fully agree, we could simply do a "raise your hand" call and see if there
> is anyone still caring about any of the modules in community, and delete
> those that do not get any vote.
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
