In my opinion community modules still have their place. For a few reasons.
1. While core developers are comfortable using git the learning curve is big
if you have never used it. I feel it might hinder contribution if we make
that the only option.
2. We build and publish some of the more mature community modules nightly,
and if we removed from the central svn repo it would be harder to integrate
them into the build.
That said... I fully agree that some community module cleanup is sorely. I
would vote we create some svn space outside of the main svn tree and move
modules that are obsolete there. Essentially archiving them.
As for moving to git for version control I am not so convinced it has many
benefits for us past the ones we (or more the developers who choose to use
git) already enjoy. We already get the nice benefits of branching, rebasing,
etc... while still keeping a central svn repository. Until we adopt a more
decentralized development model (and not saying that is the way we should go
by any means) I don't really see a major benefit to actually storing the
repository in git.
2c.
On Fri, May 13, 2011 at 12:41 PM, David Winslow <[email protected]>wrote:
> 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
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
