[Geoserver-users] Proposed Issues List Module

Cory_Horner · August 15, 2006, 6:32pm

Hi guys,

As per the GeoServer Improvement Proposal guidelines, Richard, Pablo, and myself are proposing a module to provide a client service for a shared issues list. An "issue" can be a task or geographical feature which requires attention, but other uses are possible too. uDig will be taking advantage of this service very soon. The implementation will use hibernate to back the list onto a database. Some preliminary details are available (and will be expanded) here:

http://docs.codehaus.org/display/GEOS/GSIP+3+-+Issues+List+Module

Comments and questions are welcome.

Cheers,
Cory.

Justin_Deoliveira · August 15, 2006, 6:56pm

Hi Cory,

This idea sounds great. I added a comment at the bottom of the page.

Cory Horner wrote:

Hi guys,

As per the GeoServer Improvement Proposal guidelines, Richard, Pablo,
and myself are proposing a module to provide a client service for a
shared issues list. An "issue" can be a task or geographical feature
which requires attention, but other uses are possible too. uDig will be
taking advantage of this service very soon. The implementation will use
hibernate to back the list onto a database. Some preliminary details
are available (and will be expanded) here:

http://docs.codehaus.org/display/GEOS/GSIP+3+-+Issues+List+Module

Comments and questions are welcome.

Cheers,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44e21419280852207481331!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

jive · August 16, 2006, 7:57am

Very Nice Cory

I am going to take a run at the page, based on the IRC discussion we need define this in a very specific manner.

How ever some quick answers:
- this is not a new service
- makes no use of feature model, or GML
- defines an API to access the same Issue Model used by uDig (based on the shared validation code with GeoServer Transactions)
- the API is made available to client code via Spring remoting
- the API is available to other geoserver modules via Spring
- the first implementation uses hibernate for persistence

I had not thought of story integrating this module with the default GeoServer install (as this is not the point).
The possibility of generating out a list of validation errors from transactions, or listing the validation errors present
in the dataset both sound good.

What I would like this module to do is get people comfortable working together, and explore using the GeoServer
module system as a platform. Doing this using a community module that is available for public review makes this process
easier.

I will be making plenty of commercial modules using GeoServer 1.4.0 as a base, since this is the smallest one of public utility we
can work on from the get go.

Jody

Hi guys,

As per the GeoServer Improvement Proposal guidelines, Richard, Pablo, and myself are proposing a module to provide a client service for a shared issues list. An "issue" can be a task or geographical feature which requires attention, but other uses are possible too. uDig will be taking advantage of this service very soon. The implementation will use hibernate to back the list onto a database. Some preliminary details are available (and will be expanded) here:

http://docs.codehaus.org/display/GEOS/GSIP+3+-+Issues+List+Module

Comments and questions are welcome.

Cheers,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
geoserver-devel List Signup and Options

jive · August 16, 2006, 9:09am

Hey Cory,

Now that I have gone over the page I can have some useful feedback. It seems most of the confusion was in the IRC meeting.
I have added a bit of text to the proposal talking about the motivation for the proposal.

But I think it is time to ask Andrea for some feedback on the IssueList interface itself, since the API is used for Spring Remoting
we need to think about "deep" or "shallow" copy issues. You have this mostly covered with the list of issues (ie shallow) vs individual
issue (deep) accessor methods.

Andrea is there any "traditional" naming conventions we should be following here? Can you run over the page and provide us with
feedback? The only one I can spot right now is the use of a long ID rather then a string, and some note about the horrible equals
method implementation needed for remote api use.

Cheers,
Jody

Hi guys,

As per the GeoServer Improvement Proposal guidelines, Richard, Pablo, and myself are proposing a module to provide a client service for a shared issues list. An "issue" can be a task or geographical feature which requires attention, but other uses are possible too. uDig will be taking advantage of this service very soon. The implementation will use hibernate to back the list onto a database. Some preliminary details are available (and will be expanded) here:

http://docs.codehaus.org/display/GEOS/GSIP+3+-+Issues+List+Module

Comments and questions are welcome.

Cheers,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
geoserver-devel List Signup and Options

Chris_Holmes1 · August 19, 2006, 6:02pm

Sounds great. Community module makes a lot of sense, and yeah, no GSIP
should be needed.

I could see this eventually evolving to something that could be quite
useful for more than just uDig. My vision for GeoServer is 'cvs for the
geospatial web', and it'd be great if this could turn in to something
like 'bugzilla for the geospatial web'.

I'd ideally like to see it available as WFS/WFS-T - though forcing that
as _the_ design is obviously not the right call, especially since
complex features aren't yet available. But ideally we could expose an
interface to viewing and updating the issues through WFS. Then any WFS
client could look to see where there are marked issues on the area of
the map that they care about. It's sort of the flip side of using WFS to
expose a version table/history, in that case you're seeing what's been
modified recently, in the issue case it's to see what needs to be modified.

Would also be very cool to build it in to a transaction workflow - as an
optional plug-in to a transaction. Some users would only have
permission to report an issue, and perhaps attach a 'fix'. It'd then
live in the issue database until someone with commit rights can review
and close the issue. And automatic validation could happen before or
after.

Jody, what's the status with the Hibernate datastore? Wasn't that one
of your work items? Perhaps that could be used just to expose this in a
naive way?

But yes, it's great to see a community module so soon. Also, an
interesting post on small packages:
http://blog.ianbicking.org/why-small-packages-matter.html We should
perhaps start distributing a 'geoserver-core' download, indeed I'd
eventually like to see such a thing as it's own project.

Chris

Jody Garnett wrote:

Very Nice Cory

I am going to take a run at the page, based on the IRC discussion we need define this in a very specific manner.

How ever some quick answers:
- this is not a new service
- makes no use of feature model, or GML
- defines an API to access the same Issue Model used by uDig (based on the shared validation code with GeoServer Transactions)
- the API is made available to client code via Spring remoting
- the API is available to other geoserver modules via Spring
- the first implementation uses hibernate for persistence

I had not thought of story integrating this module with the default GeoServer install (as this is not the point).
The possibility of generating out a list of validation errors from transactions, or listing the validation errors present
in the dataset both sound good.

What I would like this module to do is get people comfortable working together, and explore using the GeoServer
module system as a platform. Doing this using a community module that is available for public review makes this process
easier.

I will be making plenty of commercial modules using GeoServer 1.4.0 as a base, since this is the smallest one of public utility we
can work on from the get go.

Jody

Hi guys,

As per the GeoServer Improvement Proposal guidelines, Richard, Pablo, and myself are proposing a module to provide a client service for a shared issues list. An "issue" can be a task or geographical feature which requires attention, but other uses are possible too. uDig will be taking advantage of this service very soon. The implementation will use hibernate to back the list onto a database. Some preliminary details are available (and will be expanded) here:

http://docs.codehaus.org/display/GEOS/GSIP+3+-+Issues+List+Module

Comments and questions are welcome.

Cheers,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44e2d0817911665516417!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Cory_Horner · August 18, 2006, 11:45pm

Cory Horner wrote:

http://docs.codehaus.org/display/GEOS/GSIP+3+-+Issues+List+Module

By the sounds of it, we can just go ahead and write our module -- it is in the community space and does not require approval, unless one day it wants to be part of the official build. Can Pablo get commit access so he can work on it? It would be handy for myself and Richard to be able to commit as well.

Thanks,
Cory.

jive · August 21, 2006, 2:51pm

Chris Holmes wrote:

Sounds great. Community module makes a lot of sense, and yeah, no GSIP
should be needed.

I could see this eventually evolving to something that could be quite
useful for more than just uDig. My vision for GeoServer is 'cvs for the
geospatial web', and it'd be great if this could turn in to something
like 'bugzilla for the geospatial web'.

cholmes ++

Chris can we have some page constructed please on the care and feeding of community modules? Basically I would like a policy in place
where we accept community modules, and offer svn access for developers building up stuff around GeoServer.

uDig has a very simple policy of "please email the list", and "make a page on the wiki", I see no reason to suggest otherwise for GeoServer. Since this is a project policy does it need a GSIP number?

Would also be very cool to build it in to a transaction workflow - as an
optional plug-in to a transaction. Some users would only have
permission to report an issue, and perhaps attach a 'fix'. It'd then
live in the issue database until someone with commit rights can review
and close the issue. And automatic validation could happen before or
after.

Now you are thinking

Jody, what's the status with the Hibernate datastore? Wasn't that one
of your work items? Perhaps that could be used just to expose this in a
naive way?

Andrea will be taking it to the geotools community the moment he is off critical path But it works pretty darn well right now, although we have focused on read only access right now (and obviously only map content into flat features).

But yes, it's great to see a community module so soon. Also, an
interesting post on small packages:

Chris we are actually going to have three community proposals "in the pipe" these represent modules needed for our commercial application but are of general interested to the community. So we can "prime the pump" with some well defined (despite email confusion) modules and figure out how to handle such things as svn access, documentation requirements, etc...

Three modules:
- preference module (jesse)
- status module (richard)
- issues module (corey & pablo)

Cheers,
Jody

Justin_Deoliveira · August 21, 2006, 3:29pm

Hi Jody,

I think your right, we need a process in place. At the same time we
don't want to have people jump through too many hoops. One thing I am
concerned about is just giving people a community module and never
hearing from them again. An example is the preferences store, it was
created and has been inactive for the last month or so, with no docs on
how to use it so it really isn't all that useful to geoserver at the moment.

It would be nice to come up with a way to keep community module
maintainers as close to everyone else as possible. One possible solution
is including community modules in the build bye default. Anyone else
have any ideas.

As for official process, how about having the community module
maintainer do :

1. A GSIP
2. A wiki page with some overview background information

One thing I found when the issues list was proposed is that there was no
information about it, so I was a little reluctant to just say yes. It
doesn't have to be much, I would say perhaps a quick few notes about the
design, and perhaps some of the more interesting implementation details.

-Justin

Jody Garnett wrote:

Chris Holmes wrote:

Sounds great. Community module makes a lot of sense, and yeah, no GSIP
should be needed.

I could see this eventually evolving to something that could be quite
useful for more than just uDig. My vision for GeoServer is 'cvs for the
geospatial web', and it'd be great if this could turn in to something
like 'bugzilla for the geospatial web'.

cholmes ++

Chris can we have some page constructed please on the care and feeding
of community modules? Basically I would like a policy in place
where we accept community modules, and offer svn access for developers
building up stuff around GeoServer.

uDig has a very simple policy of "please email the list", and "make a
page on the wiki", I see no reason to suggest otherwise for GeoServer.
Since this is a project policy does it need a GSIP number?

Would also be very cool to build it in to a transaction workflow - as an
optional plug-in to a transaction. Some users would only have
permission to report an issue, and perhaps attach a 'fix'. It'd then
live in the issue database until someone with commit rights can review
and close the issue. And automatic validation could happen before or
after.

Now you are thinking

Jody, what's the status with the Hibernate datastore? Wasn't that one
of your work items? Perhaps that could be used just to expose this in a
naive way?

Andrea will be taking it to the geotools community the moment he is off
critical path But it works pretty darn well right now, although we
have focused on read only access right now (and obviously only map
content into flat features).

But yes, it's great to see a community module so soon. Also, an
interesting post on small packages:

Chris we are actually going to have three community proposals "in the
pipe" these represent modules needed for our commercial application but
are of general interested to the community. So we can "prime the pump"
with some well defined (despite email confusion) modules and figure out
how to handle such things as svn access, documentation requirements, etc...

Three modules:
- preference module (jesse)
- status module (richard)
- issues module (corey & pablo)

Cheers,
Jody

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44e9c91b71311410093335!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Brent_Owens1 · August 21, 2006, 3:38pm

Justin Deoliveira wrote:

Hi Jody,

I think your right, we need a process in place. At the same time we
don't want to have people jump through too many hoops. One thing I am
concerned about is just giving people a community module and never
hearing from them again. An example is the preferences store, it was
created and has been inactive for the last month or so, with no docs on
how to use it so it really isn't all that useful to geoserver at the moment.

It would be nice to come up with a way to keep community module
maintainers as close to everyone else as possible. One possible solution
is including community modules in the build bye default. Anyone else
have any ideas.

My concern here would be if the maintainer doesn't maintain and the build gets broken. Also, half finished modules as part of the build.

As for official process, how about having the community module
maintainer do :

1. A GSIP
2. A wiki page with some overview background information

3. Once it is finished, a 'how-to' and more documentation
4. Test cases?

One thing I found when the issues list was proposed is that there was no
information about it, so I was a little reluctant to just say yes. It
doesn't have to be much, I would say perhaps a quick few notes about the
design, and perhaps some of the more interesting implementation details.

Use-cases for the module would help a lot too.

-Justin

Brent Owens
(The Open Planning Project)

Jody Garnett wrote:


Chris Holmes wrote:


Sounds great. Community module makes a lot of sense, and yeah, no GSIP
should be needed.

I could see this eventually evolving to something that could be quite
useful for more than just uDig. My vision for GeoServer is 'cvs for the
geospatial web', and it'd be great if this could turn in to something
like 'bugzilla for the geospatial web'.


cholmes ++

Chris can we have some page constructed please on the care and feeding of community modules? Basically I would like a policy in place
where we accept community modules, and offer svn access for developers building up stuff around GeoServer.

uDig has a very simple policy of "please email the list", and "make a page on the wiki", I see no reason to suggest otherwise for GeoServer. Since this is a project policy does it need a GSIP number?


Would also be very cool to build it in to a transaction workflow - as an
optional plug-in to a transaction. Some users would only have
permission to report an issue, and perhaps attach a 'fix'. It'd then
live in the issue database until someone with commit rights can review
and close the issue. And automatic validation could happen before or
after.


Now you are thinking


Jody, what's the status with the Hibernate datastore? Wasn't that one
of your work items? Perhaps that could be used just to expose this in a
naive way?


Andrea will be taking it to the geotools community the moment he is off critical path But it works pretty darn well right now, although we have focused on read only access right now (and obviously only map content into flat features).


But yes, it's great to see a community module so soon. Also, an
interesting post on small packages:


Chris we are actually going to have three community proposals "in the pipe" these represent modules needed for our commercial application but are of general interested to the community. So we can "prime the pump" with some well defined (despite email confusion) modules and figure out how to handle such things as svn access, documentation requirements, etc...

Three modules:
- preference module (jesse)
- status module (richard)
- issues module (corey & pablo)

Cheers,
Jody

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44e9c91b71311410093335!

jive · August 21, 2006, 3:46pm

Justin Deoliveira wrote:

Hi Jody,

I think your right, we need a process in place. At the same time we
don't want to have people jump through too many hoops. One thing I am
concerned about is just giving people a community module and never
hearing from them again. An example is the preferences store, it was
created and has been inactive for the last month or so, with no docs on
how to use it so it really isn't all that useful to geoserver at the moment.

Heh, well Jesse will be back from holiday / other projects. That module is on a deadline for early September

It would be nice to come up with a way to keep community module
maintainers as close to everyone else as possible. One possible solution
is including community modules in the build bye default. Anyone else
have any ideas.

Ack, well having the build fail will keep them close (or will keep people from checking out the community modules (this is what happened with uDig).

As for official process, how about having the community module
maintainer do :

1. A GSIP

Chris just nicked that idea, hense this discussion on how to do a lite process. Note they would do a GSIP if they wanted to be included in the GeoServer release proper. (GSIP == formal GeoServer product as it were).

2. A wiki page with some overview background information

I like this idea, one other option is to set up a jira for them to track progress. Including the jira issues on the page would be a low effort way of reporting status.

One thing I found when the issues list was proposed is that there was no
information about it, so I was a little reluctant to just say yes. It
doesn't have to be much, I would say perhaps a quick few notes about the
design, and perhaps some of the more interesting implementation details

That is mostly my fault As an architect I did not have the "big picture" in place for Cory and Pablo to understand what
they were getting into. On the bright side as "guinea pigs" they are flushing out the basic needs the project needs to meet
for this whole idea to be a success.

Cheers,
Jody

Chris_Holmes1 · August 21, 2006, 6:43pm

Jody Garnett wrote:

Justin Deoliveira wrote:

Hi Jody,

I think your right, we need a process in place. At the same time we
don't want to have people jump through too many hoops. One thing I am
concerned about is just giving people a community module and never
hearing from them again. An example is the preferences store, it was
created and has been inactive for the last month or so, with no docs on
how to use it so it really isn't all that useful to geoserver at the moment.

Heh, well Jesse will be back from holiday / other projects. That module is on a deadline for early September

It would be nice to come up with a way to keep community module
maintainers as close to everyone else as possible. One possible solution
is including community modules in the build bye default. Anyone else
have any ideas.

Ack, well having the build fail will keep them close (or will keep people from checking out the community modules (this is what happened with uDig).

I do like the idea of a very low barrier for entry for community modules. I mean, the fact that people put their stuff in a community svn puts them much 'closer' than just developing on their own. And if there are too many requirements for a community module then they'll be more likely to just do it on their own.

So I don't so much like being part of the build as a requirement. But I think they could opt for it if they wanted.

As for official process, how about having the community module
maintainer do :

1. A GSIP

Chris just nicked that idea, hense this discussion on how to do a lite process. Note they would do a GSIP if they wanted to be included in the GeoServer release proper. (GSIP == formal GeoServer product as it were).

Yeah, and thus should definitely be part of the build. Perhaps we could have 'incubating' modules, that aren't formal GSIP's yet, aren't part of the formal product, but have an intention to be. They would be part of the build to 'prove' that the developers stay close and track what else is going on.

2. A wiki page with some overview background information

I like this idea, one other option is to set up a jira for them to track progress. Including the jira issues on the page would be a low effort way of reporting status.

+1 on JIRA. And I like the wiki stuff too. Perhaps people start with a child page of RnD, where their community module starts. This allows them to get feedback about fitting in to the overall architecture. Then they could advance to 'incubating', which would then place them somewhere on the roadmap (even if it's not at a scheduled date). Then it gets refined and gets a GSIP. And of course no modules are required to do this. But we should put a page on the benefits of getting included - attracting more developers, wider pool to help maintain, ect.

Chris

One thing I found when the issues list was proposed is that there was no
information about it, so I was a little reluctant to just say yes. It
doesn't have to be much, I would say perhaps a quick few notes about the
design, and perhaps some of the more interesting implementation details

That is mostly my fault As an architect I did not have the "big picture" in place for Cory and Pablo to understand what
they were getting into. On the bright side as "guinea pigs" they are flushing out the basic needs the project needs to meet
for this whole idea to be a success.

Cheers,
Jody

!DSPAM:1003,44e9d5ee177891804284693!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Cory_Horner · August 21, 2006, 6:48pm

Various people wrote:

1. A GSIP
2. A wiki page with some overview background information
3. Once it is finished, a 'how-to' and more documentation
4. Test cases?

Those are big hoops. Pseudo-reasonable if one expects to have the code in the build, but I don't think this should happen by default. Perhaps there should be 2 procedures: 1 for getting a space to work (commit access), and 1 for getting into the build?

Anyhow, this is interesting guys -- but we've got work to do... are we suitable for commit access?

Thanks,
Cory.

Chris_Holmes1 · August 21, 2006, 7:00pm

Cory Horner wrote:

Various people wrote:

1. A GSIP
2. A wiki page with some overview background information
3. Once it is finished, a 'how-to' and more documentation
4. Test cases?

Those are big hoops. Pseudo-reasonable if one expects to have the code in the build, but I don't think this should happen by default. Perhaps there should be 2 procedures: 1 for getting a space to work (commit access), and 1 for getting into the build?

Yeah, more or less what I proposed as well.

Anyhow, this is interesting guys -- but we've got work to do... are we suitable for commit access?

Well, policy in place for commit access is 3 +1's from committers, no -1's. And we can propose commit access for just an area of the code, reserving full commit rights for a later date.

So I'm +1 on Cory and Pablo for commit rights on a issues community module (based on Cory's work on uDig and the fact that they're limited to a community module that's not in the build).

Chris

Thanks,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44ea00b1282438365517736!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Justin_Deoliveira · August 21, 2006, 7:16pm

Fair enough, the GSIP is overkill. I would be happy with just the wiki page.

+1 on commit access.

So go and request to join the geoserver project on xircles.codehaus.org
and let me or jody know so we can accept.

-Justin

Cory Horner wrote:

Various people wrote:

1. A GSIP
2. A wiki page with some overview background information
3. Once it is finished, a 'how-to' and more documentation
4. Test cases?

Those are big hoops. Pseudo-reasonable if one expects to have the code
in the build, but I don't think this should happen by default. Perhaps
there should be 2 procedures: 1 for getting a space to work (commit
access), and 1 for getting into the build?

Anyhow, this is interesting guys -- but we've got work to do... are we
suitable for commit access?

Thanks,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44ea00b1282461116498154!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

jive · August 21, 2006, 7:32pm

I will second that +1, Cory has proved responsible on the geotools and uDig project. And we can get to known Pablo as he works on a community module.
Jody

Well, policy in place for commit access is 3 +1's from committers, no -1's. And we can propose commit access for just an area of the code, reserving full commit rights for a later date.

So I'm +1 on Cory and Pablo for commit rights on a issues community module (based on Cory's work on uDig and the fact that they're limited to a community module that's not in the build).

Chris

Thanks,
Cory.

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

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44ea00b1282438365517736!

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Brent_Owens1 · August 21, 2006, 7:35pm

+1

I agree that there should be a distinction between commit access for a module and for the main build.

Brent Owens
(The Open Planning Project)

Chris Holmes wrote:

Cory Horner wrote:

Various people wrote:

1. A GSIP
2. A wiki page with some overview background information
3. Once it is finished, a 'how-to' and more documentation
4. Test cases?

Those are big hoops. Pseudo-reasonable if one expects to have the code in the build, but I don't think this should happen by default. Perhaps there should be 2 procedures: 1 for getting a space to work (commit access), and 1 for getting into the build?

Yeah, more or less what I proposed as well.

Anyhow, this is interesting guys -- but we've got work to do... are we suitable for commit access?

Well, policy in place for commit access is 3 +1's from committers, no -1's. And we can propose commit access for just an area of the code, reserving full commit rights for a later date.

So I'm +1 on Cory and Pablo for commit rights on a issues community module (based on Cory's work on uDig and the fact that they're limited to a community module that's not in the build).

Chris

Thanks,
Cory.

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

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,44ea00b1282438365517736!

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Cory_Horner · August 22, 2006, 12:01am

Justin Deoliveira wrote:

So go and request to join the geoserver project on xircles.codehaus.org
and let me or jody know so we can accept.

hehe... now I understand what it is called xircles... I spent 5 minutes trying to find out where to sign up or log-in, but accomplished nothing. Could an esteemed veteran of the labyrinth offer a hint?

Thanks,
Cory.

Justin_Deoliveira · August 22, 2006, 12:36am

I will do you one better.

http://docs.codehaus.org/display/GEOSDEV/Getting+Commit+Status

It is still incomplete, as it doesn't state to contact the list first
for permission, etc..

Richard and Cory should now both have commiter status.

-Justin

Cory Horner wrote:

Justin Deoliveira wrote:

So go and request to join the geoserver project on xircles.codehaus.org
and let me or jody know so we can accept.

hehe... now I understand what it is called xircles... I spent 5 minutes
trying to find out where to sign up or log-in, but accomplished
nothing. Could an esteemed veteran of the labyrinth offer a hint?

Thanks,
Cory.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,44ea494f60111410093335!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Chris_Holmes1 · September 8, 2006, 11:23pm

Hey, sorry for the late response Jody, have been off and swamped since I've gotten back.

Is our current community stuff sufficient? Did this get resolved enough for you? Or is there more we need in place? Let me know, supporting community modules is a priority for us.

best regards,

Chris

Jody Garnett wrote:

Chris Holmes wrote:

Sounds great. Community module makes a lot of sense, and yeah, no GSIP
should be needed.

I could see this eventually evolving to something that could be quite
useful for more than just uDig. My vision for GeoServer is 'cvs for the
geospatial web', and it'd be great if this could turn in to something
like 'bugzilla for the geospatial web'.

cholmes ++

Chris can we have some page constructed please on the care and feeding of community modules? Basically I would like a policy in place
where we accept community modules, and offer svn access for developers building up stuff around GeoServer.

uDig has a very simple policy of "please email the list", and "make a page on the wiki", I see no reason to suggest otherwise for GeoServer. Since this is a project policy does it need a GSIP number?

Would also be very cool to build it in to a transaction workflow - as an
optional plug-in to a transaction. Some users would only have
permission to report an issue, and perhaps attach a 'fix'. It'd then
live in the issue database until someone with commit rights can review
and close the issue. And automatic validation could happen before or
after.

Now you are thinking

Jody, what's the status with the Hibernate datastore? Wasn't that one
of your work items? Perhaps that could be used just to expose this in a
naive way?

Andrea will be taking it to the geotools community the moment he is off critical path But it works pretty darn well right now, although we have focused on read only access right now (and obviously only map content into flat features).

But yes, it's great to see a community module so soon. Also, an
interesting post on small packages:

Chris we are actually going to have three community proposals "in the pipe" these represent modules needed for our commercial application but are of general interested to the community. So we can "prime the pump" with some well defined (despite email confusion) modules and figure out how to handle such things as svn access, documentation requirements, etc...

Three modules:
- preference module (jesse)
- status module (richard)
- issues module (corey & pablo)

Cheers,
Jody

!DSPAM:1003,44e9c90970111995013331!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

jive · September 9, 2006, 5:29pm

Chris Holmes wrote:

Hey, sorry for the late response Jody, have been off and swamped since I've gotten back.

Well I do not think we wrote it down as policy yet, we just kind of did it. People showed up for meetings, and or emailed the list - and we gave them svn access. Lets treat these first couple community modules as tests and see what we can learn.

Is our current community stuff sufficient? Did this get resolved enough for you? Or is there more we need in place? Let me know, supporting community modules is a priority for us.

I think we need a happy "how to hack" page, much like we have for geotools in the developers guide.
Chris are there any plans for an in person geoserver meeting next week? Or has adrian custer book us all up solid?
Jody