[Geoserver-devel] GSIP 12 - Mock Test Support

[Justin_Deoliveira]

Hi all,

I have been working on porting ows4 changes to trunk. The wms and wcs issue has me halted for the time being so I thought i would continue with another GSIP, this one having to do with mock unit testing.

http://docs.codehaus.org/display/GEOS/GSIP+12+-+Mock+Test+Support

This task would be made substantially easier with some changes regarding the new config GSIP. Details can be found here.

http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System#GSIP8-NewConfigurationSystem-configapi

Feedback appreciated. Thanks.

-Justin

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

[Jody_Garnett]

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).

Cheers,
Jody

[Justin_Deoliveira]

Jody Garnett wrote:

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).

Again I disagree, the result of a discussion such as this on the email is often a hugely unorganized thread of people dumping there thoughts. The GSIP is supposed to be a place to capture the implementation details and peoples concerns ( much of which is generated from email discussion ) in a single coherent place.

-Justin

Cheers,
Jody

!DSPAM:1004,45be4f0993842223018498!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

[Brent_Owens1]

My impression is if the change is something that will effect the direction of geoserver (the users) or if it will change up how developers develop, then it needs to be a GSIP.
For GSIP 12 (testing) I think if we had a testing framework in place then we definitely need a GSIP in place (or at least a vote of some sort) in order to change it. But since we have no real testing framework in place I think just discussion on the mailing list is fine.

But, I like the visibility of the GSIPs. The attached wiki pages allow us to see the status of the discussion and also it lets us discuss it over a long period of time without getting lost and forgetting what was previously discussed.

Should we make a GSIP on GSIPs?

Brent Owens
(The Open Planning Project)

Justin Deoliveira wrote:

Jody Garnett wrote:
  

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).
    

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.
  

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).
    

Again I disagree, the result of a discussion such as this on the email is often a hugely unorganized thread of people dumping there thoughts. The GSIP is supposed to be a place to capture the implementation details and peoples concerns ( much of which is generated from email discussion ) in a single coherent place.

-Justin
  

Cheers,
Jody

!DSPAM:1004,45be4f0993842223018498!

[Jody_Garnett]

Interesting; is our development list going to be reduced to GSIP conversations then? (and bug reports...)

For some of these subjects (that I am trying to catch up on); I would actually like to see considerable effort put into the proposal; class diagrams - formal document etc.. both the catalog, config and web ui fall into this category. While we do not need an entire site such as vwfs.refractions.net; something on the scale of the design documents there is called for.

For something like Mock Test Support it should be easier; it is a best practice that would suit our project well. Do we need to make it a policy (and write up instructions in the developers guide? Or will a few good examples work well ...).

Jody

Jody Garnett wrote:

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).

Again I disagree, the result of a discussion such as this on the email is often a hugely unorganized thread of people dumping there thoughts. The GSIP is supposed to be a place to capture the implementation details and peoples concerns ( much of which is generated from email discussion ) in a single coherent place.

-Justin

Cheers,
Jody

!DSPAM:1004,45be4f0993842223018498!

[Chris_Holmes1]

Brent Owens wrote:

My impression is if the change is something that will effect the direction of geoserver (the users) or if it will change up how developers develop, then it needs to be a GSIP.
For GSIP 12 (testing) I think if we had a testing framework in place then we definitely need a GSIP in place (or at least a vote of some sort) in order to change it. But since we have no real testing framework in place I think just discussion on the mailing list is fine.

But, I like the visibility of the GSIPs. The attached wiki pages allow us to see the status of the discussion and also it lets us discuss it over a long period of time without getting lost and forgetting what was previously discussed.

Yeah, my thoughts exactly - the visibility and history in one place is really nice.

Should we make a GSIP on GSIPs?

Well, we do have this: http://docs.codehaus.org/display/GEOSDOC/2+GeoServer+Improvement+Proposal

It includes:

'A GSIP - GeoServer Improvement Proposal is the formal mechanism used to perform any sort of major change in the GeoServer project. Examples may include major new features, process improvements for the functioning of the community, re-architectures, intellectual property, and timing of releases and merges.'

and

'Q: When do I make a GSIP?

A: Generally you will make a GSIP when you want something major done in GeoServer and need feedback from others. GSIPs are needed for things that will have an impact on other community members, and thus should be talked about.

A GSIP is not needed to start work on GeoServer, indeed one can easily get a branch or a community svn area to experiment. When still kicking around ideas and gathering momentum potential proposers are encouraged to use the GEOS:RnD space in an informal manner. Once the idea is formalized it can be turned in to a more offical proposal. There is no requirement to put things in to the RnD section, it's just there as a resource.

GSIP's should also have appropriate momentum behind them, people who will see it through to the end, not just something that is desired. There's no reason for the PSC to vote on something that no one is excited enough to actually implement.'

This reads as more than just affecting the GeoServer product. It's more or less anything that will impact others. I think testing policies and frameworks and the like fall in to this. I agree that we shouldn't make a GSIP for minor changes, or for RnD. But if it's a change that will affect others, that changes the codebase, I'd say we should do one.

Though I do agree that the gsips on catalog, config and web UI need a lot more substance to them. But I don't know that it doesn't mean we shouldn't start them? They probably should be started when you need a coherent place to put docs and class diagrams and the like? But yeah, I think they can incubate in an RnD page until the resources are available to work on them and they will happen soon. I personally wouldn't have put the catalog and web UI changes in yet.

Chris

Brent Owens
(The Open Planning Project)

Justin Deoliveira wrote:

Jody Garnett wrote:
  

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).
    

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.
  

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).
    

Again I disagree, the result of a discussion such as this on the email is often a hugely unorganized thread of people dumping there thoughts. The GSIP is supposed to be a place to capture the implementation details and peoples concerns ( much of which is generated from email discussion ) in a single coherent place.

-Justin
  

Cheers,
Jody

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45be53c6101381527717022!

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

[Andrea_Aime3]

Jody Garnett ha scritto:

Interesting; is our development list going to be reduced to GSIP conversations then? (and bug reports...)

For some of these subjects (that I am trying to catch up on); I would actually like to see considerable effort put into the proposal; class diagrams - formal document etc.. both the catalog, config and web ui fall into this category. While we do not need an entire site such as vwfs.refractions.net; something on the scale of the design documents there is called for.

For something like Mock Test Support it should be easier; it is a best practice that would suit our project well. Do we need to make it a policy (and write up instructions in the developers guide? Or will a few good examples work well ...).

Mock test support is something which is made especially hard due to
our current architecture. To really enable it we need significant
changes in the way the code is structured.
We're not here to say mock testing is nice, but about making those
significant changes.

Chers
Andrea

[Jody_Garnett]

Brent Owens wrote:

But, I like the visibility of the GSIPs. The attached wiki pages allow us to see the status of the discussion and also it lets us discuss it over a long period of time without getting lost and forgetting what was previously discussed.

We can have (and should have) visibility without GSIP. I understand that Release notes capture changes per release; I would hope the developers guide captures the current state of play for GeoServer development policies, QA standards and so on.

I am more worried that Justin's last GISP was stalled based on GeoTools 2.3 discipline, I would rather see an full scale panic then Justin hitting the next GSIP on his list. Something for the meeting today I guess.

Should we make a GSIP on GSIPs?

I am sure a discussion will be fine Sounds like the correct path is somewhere in the middle.

Cheers,
Jody

[Justin_Deoliveira]

Jody Garnett wrote:

Interesting; is our development list going to be reduced to GSIP conversations then? (and bug reports...)

Of course not. As you said the development list is hte medium for such discussions, and the GSIP the medium to capture the details, summing up email discussion in a sence. This can be done on another wiki page if you would like, and not called a "GSIP" until its more formal.

Some process is needed. Especially for bringing R&D like ows4 home. It needs to be done in a controlled manner. Sorry if the GSIP is too "in your face" but without it the result would be mayhem as I simply dump my work on trunk. It needs feedback, and having the GSIP to make the PSC vote on such things seems like a good way to get that feedback.

For some of these subjects (that I am trying to catch up on); I would actually like to see considerable effort put into the proposal; class diagrams - formal document etc.. both the catalog, config and web ui fall into this category. While we do not need an entire site such as vwfs.refractions.net; something on the scale of the design documents there is called for.

For something like Mock Test Support it should be easier; it is a best practice that would suit our project well. Do we need to make it a policy (and write up instructions in the developers guide? Or will a few good examples work well ...).

Jody

Jody Garnett wrote:

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).

Again I disagree, the result of a discussion such as this on the email is often a hugely unorganized thread of people dumping there thoughts. The GSIP is supposed to be a place to capture the implementation details and peoples concerns ( much of which is generated from email discussion ) in a single coherent place.

-Justin

Cheers,
Jody

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,45be548e102301116498154!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

[Jody_Garnett]

Thanks for the clarification Chris; the change to Mock objects seems almost too low level to be worth a GSIP. This is more an incremental change towards actually having unit tests in place. Following an industry best practice etc...

Jody

[Jody_Garnett]

Okay cool - I stand corrected (and heck I started a discussion).

I was not aware that massive changes were needed to make Mock objects available to test against - apparently it does have enough scope for a GSIP.Can I clarify that these are still unit tests and not integration tests? Your example seemed to indicate you were stubbing a GetMap request ...

Jody

Jody Garnett wrote:

Interesting; is our development list going to be reduced to GSIP conversations then? (and bug reports...)

Of course not. As you said the development list is hte medium for such discussions, and the GSIP the medium to capture the details, summing up email discussion in a sence. This can be done on another wiki page if you would like, and not called a "GSIP" until its more formal.

Some process is needed. Especially for bringing R&D like ows4 home. It needs to be done in a controlled manner. Sorry if the GSIP is too "in your face" but without it the result would be mayhem as I simply dump my work on trunk. It needs feedback, and having the GSIP to make the PSC vote on such things seems like a good way to get that feedback.

For some of these subjects (that I am trying to catch up on); I would actually like to see considerable effort put into the proposal; class diagrams - formal document etc.. both the catalog, config and web ui fall into this category. While we do not need an entire site such as vwfs.refractions.net; something on the scale of the design documents there is called for.

For something like Mock Test Support it should be easier; it is a best practice that would suit our project well. Do we need to make it a policy (and write up instructions in the developers guide? Or will a few good examples work well ...).

Jody

Jody Garnett wrote:

I think we have to take a look at what needs to have a GSIP process started (and what does not). I do not want GSIP to be taken as a "please pay attention" - we can always have an "IMPORTANT' in the subject line for that.

I am hoping that GSIP is used for decisions that effect GeoServer as a product. I understand that some design decisions qualify (choice of web ui technology, decisions about how to persist configuration, interaction between GeoServer and other communities, .. and perhaps Market positioning around FOSS4G etc...).

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.

Let's sort out things like use of svn, testing standards on the development list (these are development concerns). These items only effect GeoServer as a product if they impact us acquiring new and additional developers.

Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

In short the GSIP process (and the PSC as a group) is not where the bulk of decisions made on geoserver-devel should come from; this is a development list and suitable for development questions and decisions. Occasionally we will need to ask the user list for feedback or priorities, and the PSC for strategy; but let's make code decisions as developers (for developers).

Again I disagree, the result of a discussion such as this on the email is often a hugely unorganized thread of people dumping there thoughts. The GSIP is supposed to be a place to capture the implementation details and peoples concerns ( much of which is generated from email discussion ) in a single coherent place.

-Justin

Cheers,
Jody

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

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

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

!DSPAM:1004,45be548e102301116498154!

[Chris_Holmes1]

Jody Garnett wrote:

Thanks for the clarification Chris; the change to Mock objects seems almost too low level to be worth a GSIP. This is more an incremental change towards actually having unit tests in place. Following an industry best practice etc...

Yeah, I agree it's on the line. And thanks for your feedback, I too don't want to see GSIP's get out of control. But it makes sense that we have a bit of a flood of them right now, as Justin is coming home from 6 months of RnD work. I don't think that we'll normally be having so many GSIPs. And yes, if we're just discussing ideas, it should go in to RnD, not a GSIP.

Chris

Jody

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,45be570a106611194215290!

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

[Rob_Atkinson]

Justin Deoliveira wrote:

Perhaps others can pipe up but this was not my impression. My impression was that it was a controlled process for people to make changes to the code base. Instead of a developer just making changes, or explaining a change without much detail on the list, and then making it.
  
Mailing the list is part of it. But I cant really capture code examples and diagrams that I need to outline a proposal on the list. If you would like these things moved elsewhere on the wiki before they become GSIP i can see that.

Sounds to me like this is a documentation issue - I'm a little concerned that using GSIPs this way may have two drawbacks - one is discriminating the things the PSC has to take specific notice of, and the other is attaching the design documentation to the actual codebase.

[Andrea_Aime3]

Jody Garnett ha scritto:

Okay cool - I stand corrected (and heck I started a discussion).

I was not aware that massive changes were needed to make Mock objects available to test against - apparently it does have enough scope for a GSIP.Can I clarify that these are still unit tests and not integration tests? Your example seemed to indicate you were stubbing a GetMap request ...

He was, we are using the junit framework to do (almost) integration testing indeed, the almost being that we do mock out a few classes
to allow the test be run wihtout starting geoserver.
You can call it a "geoserver inner cite testing".
What's wrong with that?
Cheers
Andrea

[Jody_Garnett]

Andrea Aime wrote:

I was not aware that massive changes were needed to make Mock objects available to test against - apparently it does have enough scope for a GSIP.Can I clarify that these are still unit tests and not integration tests? Your example seemed to indicate you were stubbing a GetMap request ...

He was, we are using the junit framework to do (almost) integration testing indeed, the almost being that we do mock out a few classes
to allow the test be run wihtout starting geoserver. You can call it a "geoserver inner cite testing".

Fun In some of these cases I would like to move the "inner cite" (sounds like paranormal thrid-eye testing behavior) over to GeoTools and catch things earlier.

What's wrong with that?

Nothing wrong just trying to get the scope of this proposal sorted out in my head

Cheers,
Jody

[pramsey]

Brent Owens wrote:

But, I like the visibility of the GSIPs. The attached wiki pages allow us to see the status of the discussion and also it lets us discuss it over a long period of time without getting lost and forgetting what was previously discussed.

I am quite fond of how Mapserver has done their RFC process, with the RFC files right in the CVS repository. It's a nice reminder that design is part of the coding process, and a way to keep the history intact with the code.

--

   Paul Ramsey
   Refractions Research
   http://www.refractions.net
   pramsey@anonymised.com
   Phone: 250-383-3022
   Cell: 250-885-0632

[Jody_Garnett]

So now that I have caught up? It is time for me to revisit these statements ... I was concerned at the time that the volume of improvement requests was obscuring development.
1- Several of the GSIP requests were "low level" improvements to the development process and procedures - we can evaulate their success by reading the documentation when the items are closed.
2- The other GSIP proposals were a bit more difficult. It was hard (or impossible) to evaluate these without the entire context
3- The last couple were simply incomplete, perhaps updating the pages with the results of email discussion would help .. I know class diagrams did.

So at the end of this catch up I am left with only one concern, those that fell into the "need more context" picture. To help these specific items along I suspect a design cycle is needed here. Or at least a design goal that we can gradually work and refactor towards ... (since we all learned from Netscape's mistake). This could be handled as a GSIP in itself (and adopting a design goal/target would be a good use of our time).

Cheers,
Jody