[Geoserver-users] Tomorrow's IRC meeting - all developers must attend

GeoServer GeoServer User
1

Hello GeoServer community,

Tomorrow we will be holding our regular IRC meeting, but this time the topics will have some more weight to them. We need to discuss the future of GeoServer and how everything will tie together.

Right now we have several branches of development going on, and they all need to be merged to a final result with a common goal. This meeting we need to decide what that goal is and how we are going to get there.

One of the other things I would like to accomplish in the meeting is opening up development a little more. Right now with the branches, much of the development has been closed and developers left in the dark. Lets fix this.

Here is the agenda thus far. Please look it over and add more topics via email to me/list or propose them before the meeting starts:
1) The current status of GeoServer: who is working on what, and where do they need to go with it
2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")
3) Steps needed to reach that goal (project planning)
4) Tyeing in the new framework (1.4 development), FROGS
5) How we are going to open up development
6) Maintenance and new development

The meeting will be one hour long, so please be punctual. I will make sure topics are limited in time so we can cover everything. This meeting is just a first of several, so don't worry if we don't get to fully discuss everything.

The first meeting time will be on *Tuesday, 5:00-UTC:* http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=7&min=0&sec=0&p1=141
Check your location and what time it is.

Not everyone will be able to attend, so there is the second meeting on *Tuesday, 19:00-UTC:*
http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=21&min=0&sec=0&p1=141

The same topics will be discussed in the second meeting and minutes from the previous meeting will be shared.

--
Brent Owens
(The Open Planning Project)

2

I'll be a few moments late for the first meeting.

As someone actively involved in trying to pull Geoserver towards a direction where a particular class of users can deploy it (government agencies with need to conform to standard schemas for certain data) I'd like to kick off with a few comments, to save time in the meetings..

1) Its been a massive pain having a functionality improvement, a branch reorganisation, a code reorganisation and a build system reorganisation happening simultaneously. Resources seem to be diverted to improving the old stable branch at the same time. If the new build, framework etc was so important, it needs full attention to get over the hurdles ASAP. I've now lost track of how many branches are being worked on "complex features" , "FM" , "1.4" and "WCS" all seem to be variously discussed, when the original plan was a fairly simple milestone release plan. This seems to have occured as a result of new maven build and Spring framework insertion, but its difficult to trace. Possibly Maven 2 is yet another track. If the decision is to make the next release dependent on all these, then I hope that there is a good game plan for stitching them together again! The nature of the agenda suggests that this is not such a foregone conclusion though!

2) Geoserver needs better ability to trace the implementation classes that get instantiated behind interfaces when an operation is invoked. At the moment, this seems to need the skills to attach a debugger - and I for one have found the changing nature of the beast difficult to keep working in environments like Eclipse - so I keep giving up on it and using unit tests - usually after a lot of pain tracking down where these need to be created. Again, this seems to be a function of many resources being spent in

3) I think a range of practical goals needs to be established (sort of like "buy-in" acceptability unit tests)
  * A build system that is working, well documented and used by the all the main developers, with clear deployment and debugging strategies
  * deployment to major Tomcat versions (4.1.x, 5.5.x)
  * deployment against a core list of data stores (I'd suggest PostGIS, Oracle spatial, shapefile, Geometyrless (Generic JDBC), a set of raster formats for WCS ) should have unit tests
  * A set of functionality unit tests for Read-only access - WFS, WMS, WMS with SLD, WMS GetFeature should all work against each single data store
  * A set of tests for WFS-T (I'd imagine this would be certified against fewer data stores)
  * CITE tests

use this approach to make the trunk more robust instead of splitering into lots of branches.

4) the config directory thing is a big step forward. Being able to bundle demo as unit tests against a data configuration is great.

5) Development is not "open" enough in practice because too much important stuff has been left on branches for too long, and they now behave very differently, and its probably too hard to work out what works and what doesnt. Maybe there we should narrow down a few obvious extension points (new renderer, new functions in WFS call, new data stores, fix or extend an existing data store etc) and provide clear guidance. To do this, probably needs a big effort to bring all the major upheavals together into a new build, and some way of helping the experimental branches to move to this.

6) As someone trying to make a contribution by bringing the user needs to the developers, the product to the users and maintain some small parts, I cant conceive of trying to support that functionality across branches built off parts of the tree that dont support to key functions. So maybe, we need to look at what the potential users need, then work backwards to how we need to behave as developers.
Brent Owens wrote:

Hello GeoServer community,

Tomorrow we will be holding our regular IRC meeting, but this time the topics will have some more weight to them. We need to discuss the future of GeoServer and how everything will tie together.

Right now we have several branches of development going on, and they all need to be merged to a final result with a common goal. This meeting we need to decide what that goal is and how we are going to get there.

One of the other things I would like to accomplish in the meeting is opening up development a little more. Right now with the branches, much of the development has been closed and developers left in the dark. Lets fix this.

Here is the agenda thus far. Please look it over and add more topics via email to me/list or propose them before the meeting starts:
1) The current status of GeoServer: who is working on what, and where do they need to go with it
2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")
3) Steps needed to reach that goal (project planning)
4) Tyeing in the new framework (1.4 development), FROGS
5) How we are going to open up development
6) Maintenance and new development

The meeting will be one hour long, so please be punctual. I will make sure topics are limited in time so we can cover everything. This meeting is just a first of several, so don't worry if we don't get to fully discuss everything.

The first meeting time will be on *Tuesday, 5:00-UTC:* http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=7&min=0&sec=0&p1=141

Check your location and what time it is.

Not everyone will be able to attend, so there is the second meeting on *Tuesday, 19:00-UTC:*
http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=21&min=0&sec=0&p1=141

The same topics will be discussed in the second meeting and minutes from the previous meeting will be shared.

3

Hello Geoserver Community,

I will be here for the first meeting but I have to go and see my someone off at the airport, he is emigrating, so depending on what time his flight is, I will do my best to be here for the 2nd one.

Regards
Clint Lewis

Brent Owens wrote:

Hello GeoServer community,

Tomorrow we will be holding our regular IRC meeting, but this time the topics will have some more weight to them. We need to discuss the future of GeoServer and how everything will tie together.

Right now we have several branches of development going on, and they all need to be merged to a final result with a common goal. This meeting we need to decide what that goal is and how we are going to get there.

One of the other things I would like to accomplish in the meeting is opening up development a little more. Right now with the branches, much of the development has been closed and developers left in the dark. Lets fix this.

Here is the agenda thus far. Please look it over and add more topics via email to me/list or propose them before the meeting starts:
1) The current status of GeoServer: who is working on what, and where do they need to go with it
2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")
3) Steps needed to reach that goal (project planning)
4) Tyeing in the new framework (1.4 development), FROGS
5) How we are going to open up development
6) Maintenance and new development

The meeting will be one hour long, so please be punctual. I will make sure topics are limited in time so we can cover everything. This meeting is just a first of several, so don't worry if we don't get to fully discuss everything.

The first meeting time will be on *Tuesday, 5:00-UTC:* http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=7&min=0&sec=0&p1=141

Check your location and what time it is.

Not everyone will be able to attend, so there is the second meeting on *Tuesday, 19:00-UTC:*
http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=21&min=0&sec=0&p1=141

The same topics will be discussed in the second meeting and minutes from the previous meeting will be shared.

4

Excellent points Rob. Comments in-line.

Brent Owens
(The Open Planning Project)

Rob Atkinson wrote:

I'll be a few moments late for the first meeting.

As someone actively involved in trying to pull Geoserver towards a direction where a particular class of users can deploy it (government agencies with need to conform to standard schemas for certain data) I'd like to kick off with a few comments, to save time in the meetings..

1) Its been a massive pain having a functionality improvement, a branch reorganisation, a code reorganisation and a build system reorganisation happening simultaneously. Resources seem to be diverted to improving the old stable branch at the same time. If the new build, framework etc was so important, it needs full attention to get over the hurdles ASAP. I've now lost track of how many branches are being worked on "complex features" , "FM" , "1.4" and "WCS" all seem to be variously discussed, when the original plan was a fairly simple milestone release plan. This seems to have occured as a result of new maven build and Spring framework insertion, but its difficult to trace. Possibly Maven 2 is yet another track. If the decision is to make the next release dependent on all these, then I hope that there is a good game plan for stitching them together again! The nature of the agenda suggests that this is not such a foregone conclusion though!

Agreed. There is *much* to merge together. Tomorrow we should start to think of a game plan to make it happen. Possibly start with the new framework (with a working build system) and merge from there.

2) Geoserver needs better ability to trace the implementation classes that get instantiated behind interfaces when an operation is invoked. At the moment, this seems to need the skills to attach a debugger - and I for one have found the changing nature of the beast difficult to keep working in environments like Eclipse - so I keep giving up on it and using unit tests - usually after a lot of pain tracking down where these need to be created. Again, this seems to be a function of many resources being spent in

Ah, I think what you are describing is the lack of an overall model of the system. Diagrams would help tremendously here: "I want to do this_____, what do I extend?"

3) I think a range of practical goals needs to be established (sort of like "buy-in" acceptability unit tests)
* A build system that is working, well documented and used by the all the main developers, with clear deployment and debugging strategies

Of course, #1

* deployment to major Tomcat versions (4.1.x, 5.5.x)
* deployment against a core list of data stores (I'd suggest PostGIS, Oracle spatial, shapefile, Geometyrless (Generic JDBC), a set of raster formats for WCS ) should have unit tests

Many of these datastores have major issues that prevent usability for a production system. This is part of the maintenance I want to discuss

* A set of functionality unit tests for Read-only access - WFS, WMS, WMS with SLD, WMS GetFeature should all work against each single data store

Cite tests cover a some of this already, but more is needed.

* A set of tests for WFS-T (I'd imagine this would be certified against fewer data stores)
* CITE tests

use this approach to make the trunk more robust instead of splitering into lots of branches.

4) the config directory thing is a big step forward. Being able to bundle demo as unit tests against a data configuration is great.

5) Development is not "open" enough in practice because too much important stuff has been left on branches for too long, and they now behave very differently, and its probably too hard to work out what works and what doesnt. Maybe there we should narrow down a few obvious extension points (new renderer, new functions in WFS call, new data stores, fix or extend an existing data store etc) and provide clear guidance. To do this, probably needs a big effort to bring all the major upheavals together into a new build, and some way of helping the experimental branches to move to this.

This is going to be one of the hardest parts and will take some good planning to accomplish. Hopefully with a plug-in framework we will have an easier time. Or it will give everyone a common ground to merge into.

6) As someone trying to make a contribution by bringing the user needs to the developers, the product to the users and maintain some small parts, I cant conceive of trying to support that functionality across branches built off parts of the tree that dont support to key functions. So maybe, we need to look at what the potential users need, then work backwards to how we need to behave as developers.

This is a good way to think about the 'goals' of GeoServer. One goal should definitely limit the number of branches out there, and limit the time they remain branches.

Thanks for the excellent input Rob.

Brent Owens wrote:

Hello GeoServer community,

Tomorrow we will be holding our regular IRC meeting, but this time the topics will have some more weight to them. We need to discuss the future of GeoServer and how everything will tie together.

Right now we have several branches of development going on, and they all need to be merged to a final result with a common goal. This meeting we need to decide what that goal is and how we are going to get there.

One of the other things I would like to accomplish in the meeting is opening up development a little more. Right now with the branches, much of the development has been closed and developers left in the dark. Lets fix this.

Here is the agenda thus far. Please look it over and add more topics via email to me/list or propose them before the meeting starts:
1) The current status of GeoServer: who is working on what, and where do they need to go with it
2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")
3) Steps needed to reach that goal (project planning)
4) Tyeing in the new framework (1.4 development), FROGS
5) How we are going to open up development
6) Maintenance and new development

The meeting will be one hour long, so please be punctual. I will make sure topics are limited in time so we can cover everything. This meeting is just a first of several, so don't worry if we don't get to fully discuss everything.

The first meeting time will be on *Tuesday, 5:00-UTC:* http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=7&min=0&sec=0&p1=141

Check your location and what time it is.

Not everyone will be able to attend, so there is the second meeting on *Tuesday, 19:00-UTC:*
http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=21&min=0&sec=0&p1=141

The same topics will be discussed in the second meeting and minutes from the previous meeting will be shared.

5

Hi guys,

Not sure if i can make this one, its at 7:00 and I dont have an alarm clock :). I know its a lame excuse and I will see if i can get one at the hostel but if i am not there you know why.

-Justin

Brent Owens wrote:

Excellent points Rob. Comments in-line.

Brent Owens
(The Open Planning Project)

Rob Atkinson wrote:

I'll be a few moments late for the first meeting.

As someone actively involved in trying to pull Geoserver towards a direction where a particular class of users can deploy it (government agencies with need to conform to standard schemas for certain data) I'd like to kick off with a few comments, to save time in the meetings..

1) Its been a massive pain having a functionality improvement, a branch reorganisation, a code reorganisation and a build system reorganisation happening simultaneously. Resources seem to be diverted to improving the old stable branch at the same time. If the new build, framework etc was so important, it needs full attention to get over the hurdles ASAP. I've now lost track of how many branches are being worked on "complex features" , "FM" , "1.4" and "WCS" all seem to be variously discussed, when the original plan was a fairly simple milestone release plan. This seems to have occured as a result of new maven build and Spring framework insertion, but its difficult to trace. Possibly Maven 2 is yet another track. If the decision is to make the next release dependent on all these, then I hope that there is a good game plan for stitching them together again! The nature of the agenda suggests that this is not such a foregone conclusion though!

Agreed. There is *much* to merge together. Tomorrow we should start to think of a game plan to make it happen. Possibly start with the new framework (with a working build system) and merge from there.

2) Geoserver needs better ability to trace the implementation classes that get instantiated behind interfaces when an operation is invoked. At the moment, this seems to need the skills to attach a debugger - and I for one have found the changing nature of the beast difficult to keep working in environments like Eclipse - so I keep giving up on it and using unit tests - usually after a lot of pain tracking down where these need to be created. Again, this seems to be a function of many resources being spent in

Ah, I think what you are describing is the lack of an overall model of the system. Diagrams would help tremendously here: "I want to do this_____, what do I extend?"

3) I think a range of practical goals needs to be established (sort of like "buy-in" acceptability unit tests)
* A build system that is working, well documented and used by the all the main developers, with clear deployment and debugging strategies

Of course, #1

* deployment to major Tomcat versions (4.1.x, 5.5.x)
* deployment against a core list of data stores (I'd suggest PostGIS, Oracle spatial, shapefile, Geometyrless (Generic JDBC), a set of raster formats for WCS ) should have unit tests

Many of these datastores have major issues that prevent usability for a production system. This is part of the maintenance I want to discuss

* A set of functionality unit tests for Read-only access - WFS, WMS, WMS with SLD, WMS GetFeature should all work against each single data store

Cite tests cover a some of this already, but more is needed.

* A set of tests for WFS-T (I'd imagine this would be certified against fewer data stores)
* CITE tests

use this approach to make the trunk more robust instead of splitering into lots of branches.

4) the config directory thing is a big step forward. Being able to bundle demo as unit tests against a data configuration is great.

5) Development is not "open" enough in practice because too much important stuff has been left on branches for too long, and they now behave very differently, and its probably too hard to work out what works and what doesnt. Maybe there we should narrow down a few obvious extension points (new renderer, new functions in WFS call, new data stores, fix or extend an existing data store etc) and provide clear guidance. To do this, probably needs a big effort to bring all the major upheavals together into a new build, and some way of helping the experimental branches to move to this.

This is going to be one of the hardest parts and will take some good planning to accomplish. Hopefully with a plug-in framework we will have an easier time. Or it will give everyone a common ground to merge into.

6) As someone trying to make a contribution by bringing the user needs to the developers, the product to the users and maintain some small parts, I cant conceive of trying to support that functionality across branches built off parts of the tree that dont support to key functions. So maybe, we need to look at what the potential users need, then work backwards to how we need to behave as developers.

This is a good way to think about the 'goals' of GeoServer. One goal should definitely limit the number of branches out there, and limit the time they remain branches.

Thanks for the excellent input Rob.

Brent Owens wrote:

Hello GeoServer community,

Tomorrow we will be holding our regular IRC meeting, but this time the topics will have some more weight to them. We need to discuss the future of GeoServer and how everything will tie together.

Right now we have several branches of development going on, and they all need to be merged to a final result with a common goal. This meeting we need to decide what that goal is and how we are going to get there.

One of the other things I would like to accomplish in the meeting is opening up development a little more. Right now with the branches, much of the development has been closed and developers left in the dark. Lets fix this.

Here is the agenda thus far. Please look it over and add more topics via email to me/list or propose them before the meeting starts:
1) The current status of GeoServer: who is working on what, and where do they need to go with it
2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")
3) Steps needed to reach that goal (project planning)
4) Tyeing in the new framework (1.4 development), FROGS
5) How we are going to open up development
6) Maintenance and new development

The meeting will be one hour long, so please be punctual. I will make sure topics are limited in time so we can cover everything. This meeting is just a first of several, so don't worry if we don't get to fully discuss everything.

The first meeting time will be on *Tuesday, 5:00-UTC:* http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=7&min=0&sec=0&p1=141

Check your location and what time it is.

Not everyone will be able to attend, so there is the second meeting on *Tuesday, 19:00-UTC:*
http://timeanddate.com/worldclock/fixedtime.html?month=4&day=4&year=2006&hour=21&min=0&sec=0&p1=141

The same topics will be discussed in the second meeting and minutes from the previous meeting will be shared.

6

Hi Rob your questions are interesting and I am breaking out a separate response for each.

I'll be a few moments late for the first meeting.

As someone actively involved in trying to pull Geoserver towards a direction where a particular class of users can deploy it (government agencies with need to conform to standard schemas for certain data) I'd like to kick off with a few comments, to save time in the meetings..

1) Its been a massive pain having a functionality improvement, a branch reorganisation, a code reorganisation and a build system reorganisation happening simultaneously.

I think the only thing you needed was to pay attention to the *fm* branch, I have stopped doing geotools community work in order to help Justin on this.
I am surprised to see the complex-feature branch still being used by you? Everything else you mention is basically is noise from the other projects that are also working at the same time....

Resources seem to be diverted to improving the old stable branch at the same time.

- 2.2.x is not released yet, GeoServer 1.3.1 and uDig 1.1 are to be based it

If the new build, framework etc was so important, it needs full attention to get over the hurdles ASAP.

- it is more that our old build system has not been maintained and we are without the ability to make a release of geotools at all right now, I have spoken to both Refractions and TOPP about helping with this situation (as Maritn is obviously maxed out) and am glad to see progress being made.

I've now lost track of how many branches are being worked on "complex features" , "FM" , "1.4" and "WCS" all seem to be variously discussed, when the original plan was a fairly simple milestone release plan.

I share your confusion - here is the deal:
- 1.4.x and FM are on your milestone plan - we have never recieved a strong endorcement from TOPP that this is the way forward
- I am starting up a team that needs to work from 1.4.x as it stands right now (aka we need a module system, pojo datastore and some direction so we know our effort is not wasted), this is currently not on any timeline and we will probably start up a branch
- WCS is a long term branch (aka over a year) and has a associated branch in geotools - I have no idea when they are coming home, but it will not be until after the "fm" branch is merged back in (as they need a complete feature model.)

This seems to have occured as a result of new maven build and Spring framework insertion, but its difficult to trace.

The noise about Spring and Maven is due to my project in South Africa starting up and the fact that 1.4.x is not quite set up read for biz yet, it does run, it does compile. It does not use spring modules yet. given the fact that geotools maven 1 is broken we are trying to help out by getting maven 2 working on both sides of the fence.
Note these are not volunteer developers and their research should only be of assistance.

Possibly Maven 2 is yet another track. If the decision is to make the next release dependent on all these, then I hope that there is a good game plan for stitching them together again! The nature of the agenda suggests that this is not such a foregone conclusion though!

I think the meeting hopes to give TOPP's representative enough information to form a game plan. We also have a competitor with an attractive API which we wish to integrate as a long term goal (although based on support that may be a medium term foal).

Cheers,
Jody

7

Rob Atkinson wrote:

2) Geoserver needs better ability to trace the implementation classes that get instantiated behind interfaces when an operation is invoked. At the moment, this seems to need the skills to attach a debugger - and I for one have found the changing nature of the beast difficult to keep working in environments like Eclipse - so I keep giving up on it and using unit tests - usually after a lot of pain tracking down where these need to be created. Again, this seems to be a function of many resources being spent in

I think you can accomplish the same thing using logging, turning on logging for the module that you are debugging. The log messages should also indicate which implementation was actually doing the work...

3) I think a range of practical goals needs to be established (sort of like "buy-in" acceptability unit tests)
* A build system that is working, well documented and used by the all the main developers, with clear deployment and debugging strategies

Hence our effort on maven 2, Justin origional considered maven 2 for 1.4.x and was waiting for some features to be improved, now that they have we are helping out by putting the build system in place. Justin kind of has his hands full with the fm work and is reduced to answering questions.

* deployment to major Tomcat versions (4.1.x, 5.5.x)

We recently tested 1.4.x with the latest Tomcat 5, Resin and JBoss.

* deployment against a core list of data stores (I'd suggest PostGIS, Oracle spatial, shapefile, Geometyrless (Generic JDBC), a set of raster formats for WCS ) should have unit tests

GeoServer depends on cite tests for the most part, leaving unit testing of data stores to the geotools project. Due to lack of maintenance many of these tests have not been run for some time. If TOPP had facilities to deploy against known data sources on a test server they could set up a series of HTTP unit tests to confirm functionality. Failing that the tests could be aranged based on the ability of the datasource on "localhost".

* A set of functionality unit tests for Read-only access - WFS, WMS, WMS with SLD, WMS GetFeature should all work against each single data store
* A set of tests for WFS-T (I'd imagine this would be certified against fewer data stores)
* CITE tests

Your suggestion of improving test case support is good, however you may wish to limit some of these to tests needed before commit.

use this approach to make the trunk more robust instead of splitering into lots of branches.

trunk is splintered into RnD branches, we have not ironed out what to do when they "come home". I would like to suggest that after we have a decent module system that much of this
RnD work could proceed based on a core geoserver from trunk tested with the addition of the RnD module.

4) the config directory thing is a big step forward. Being able to bundle demo as unit tests against a data configuration is great.

I would like to take this a step forward and persist the information into a database or something versionable.

5) Development is not "open" enough in practice because too much important stuff has been left on branches for too long, and they now behave very differently, and its probably too hard to work out what works and what doesnt. Maybe there we should narrow down a few obvious extension points (new renderer, new functions in WFS call, new data stores, fix or extend an existing data store etc) and provide clear guidance. To do this, probably needs a big effort to bring all the major upheavals together into a new build, and some way of helping the experimental branches to move to this.

This is the same goal as using spring to provide module support.

6) As someone trying to make a contribution by bringing the user needs to the developers, the product to the users and maintain some small parts, I cant conceive of trying to support that functionality across branches built off parts of the tree that dont support to key functions. So maybe, we need to look at what the potential users need, then work backwards to how we need to behave as developers.

I think we need to step in and provide some structure to your current project, it should be on a single geoserver branch matched to a single geotools branch. The delay in the feature model is more to blame then an error in the existing geoserver process. I say this even though I am not content with the existing geoserver process.

Cheers,
Jody

8

2) Geoserver needs better ability to trace the implementation classes that get instantiated behind interfaces when an operation is invoked. At the moment, this seems to need the skills to attach a debugger - and I for one have found the changing nature of the beast difficult to keep working in environments like Eclipse - so I keep giving up on it and using unit tests - usually after a lot of pain tracking down where these need to be created. Again, this seems to be a function of many resources being spent in

I think you can accomplish the same thing using logging, turning on logging for the module that you are debugging. The log messages should also indicate which implementation was actually doing the work...

Am raising the issue that there does not seem to be a consistent policy to make this happen. Many of the concrete classes dont actually report anything. I agree that there ought to be (and could be) a consistently implemented logging level that allows such tracing.

3) I think a range of practical goals needs to be established (sort of like "buy-in" acceptability unit tests)
* A build system that is working, well documented and used by the all the main developers, with clear deployment and debugging strategies

Hence our effort on maven 2, Justin origional considered maven 2 for 1.4.x and was waiting for some features to be improved, now that they have we are helping out by putting the build system in place. Justin kind of has his hands full with the fm work and is reduced to answering questions.

* deployment to major Tomcat versions (4.1.x, 5.5.x)

We recently tested 1.4.x with the latest Tomcat 5, Resin and JBoss.

I guess this just furthers my confusion about where the effort is and should be expended to make critical functionality part of the tool! Funds were sought precisely to move the complex features functions into 1.4, and now we have three branches. The only way I can see to reconcile these decisions is if the plan to merge fm and 1.4 is solid and achievable.

* deployment against a core list of data stores (I'd suggest PostGIS, Oracle spatial, shapefile, Geometyrless (Generic JDBC), a set of raster formats for WCS ) should have unit tests

GeoServer depends on cite tests for the most part, leaving unit testing of data stores to the geotools project. Due to lack of maintenance many of these tests have not been run for some time. If TOPP had facilities to deploy against known data sources on a test server they could set up a series of HTTP unit tests to confirm functionality. Failing that the tests could be aranged based on the ability of the datasource on "localhost".

Yeah - this raises another puzzling conundrum - I hear lots of "we cant do that because the data stores will be out of date" - but as far as I can see (and I have been deep in a fair few of them recently) most of them are in need of help anyway. It would be interesting to have a honest appraisal of how to get all the data stores passing unit tests against different branches. I think the answer would be thats its only possible to concentrate on one branch, obviously the future-proof option, and let anyone who cared badly enough a particular issue on the "stable branch" submit a patch.

* A set of functionality unit tests for Read-only access - WFS, WMS, WMS with SLD, WMS GetFeature should all work against each single data store
* A set of tests for WFS-T (I'd imagine this would be certified against fewer data stores)
* CITE tests

Your suggestion of improving test case support is good, however you may wish to limit some of these to tests needed before commit.

I think commit in a development vs a stable is different - commit in stable should pass ALL such tests surely?

Commit in development should note which work and which dont (yet!)

Hopefully this discussion is a stitch in time, not clasing the stable door after the horse has bolted. Any other old saws? Too many cooks spoil the broth :wink:

rob

9

Hi Justin (and Rob):

In this mornings meeting it was brought up that we need a breakout IRC inorder to figure out what is going on ...

We recently tested 1.4.x with the latest Tomcat 5, Resin and JBoss.

I guess this just furthers my confusion about where the effort is and should be expended to make critical functionality part of the tool! Funds were sought precisely to move the complex features functions into 1.4, and now we have three branches. The only way I can see to reconcile these decisions is if the plan to merge fm and 1.4 is solid and achievable.

RobA I am talking about a different project with different funds then yours (for the Tomcat testing). I too share your confusion about how to make plans for the future. Hopeful the meeting will straighten things out.

After the meeting now: it seems we need a breakout session with Justin to actually check on progress and planning for your project. We need to establish a low overhead method to check what is going on:
- brent asking questions was good - but Justin was not there and Chris had left already
- keeping issues in the tracker is good, but I have no evidence that it is helping you figure out what is going on (ie all the work is blocked on one issue)
- set up a feature component in geotools for Justin to track what he is actually doing may help
- following emails does not seem to cut it, they are low level and are hard to match up with the project plan.

I do like the idea in the meeting of setting up a page for this work where the different ideas can be brought together. But here is the rub all of the above ideas involve someone taking the time to update and provide a nice summary - this is where a project manager comes in.

Jody