Sorry for the delay, busy.
The python client is here: https://github.com/ischneider/gsimporter
Please don't consider this the permanent home :)
My 2.3 branch of the community importer is here:
https://github.com/ischneider/geoserver/tree/importer-2.3.x
This contains a number of fixes. Apologies for not having time for branch
maintenance.
I have a laundry list of things that should be revisited, modified, or
added :)
Best place to put that for discussion?
Regards,
On Mon, Nov 4, 2013 at 8:10 AM, Andrea Aime <[email protected]>wrote:
> On Mon, Nov 4, 2013 at 3:57 PM, Justin Deoliveira <
> [email protected]> wrote:
>
>> Indeed, i found a couple of these issues last week and fixed them, wasn't
>> aware of the mosaic issue though.
>>
>> I definitely appreciate your patience with the importer module, but I a
>> little confused about what our extension policy is these days. One of the
>> requirements states usage by at least 3 users? What sort of usage does that
>> imply? Does simply trying out the module once qualify?
>>
>
> Should be at least 3 people having interest in it, hard to get anyone to
> truly use a module that is not supported nor tested.
> I believe the criteria was there to avoid putting into extension modules
> that nobody cares about.
> That said, isn't the importer already being used by many (all?) of the
> OpenGeo Suite users? I thought the "3 users" criteria
> was in the clear already with this module.
>
>
>> If we simply want to build the module and run the tests it might be a
>> little less heavy handed to simply set up a build job for it (or perhaps
>> state that nightly community modules must pass tests).
>>
>
> Yes, that would also be a way. Generally speaking, I prefer the current
> setup, it offers a "quid pro quo" setup: someone gets charged to be
> maintainer, but
> in exchange, other devs breaking his/her module need to fix the breakages.
> Modules (and poeole behind them) imho need incentive to get out of
> community land.
>
>
>>
>> That said my reservation in pushing on its status in the past has been
>> due to Ian's work on a client for the rest api and not wanting to release
>> that api until its stable. I think that work is starting to stabilize now
>> ian? Any chance you point us at those sources so folks can try it out?
>>
>> So, how is this for a plan:
>>
>> 1. Get an update from Ian
>> 2. Add the module to the community nightlies (and run the tests)
>> 3. If all goes well we start working on the module status? Maybe a blog
>> post about it might help to drum up some interest.
>>
>
> Works for me.
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
Ian Schneider
Software Engineer | Boundless
[email protected]
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
