[Geoserver-devel] GSIP 31 restart

[jive]

Hi Justin,

I am going to restart the conversation on just this point - the proposal needs to be more explicit in order for anyone to vote on it. What level of detail are we looking for in this proposal; if this was design work we could ask for nice class diagrams as per your catalog proposal. This would be fine Ben could spend a week and bang up a proposal for us to review.

I think my mistake was in starting with Gabriel’s email and diagram; when I next see Ben online I will try and help him revise this page into his own words and with a series of tasks covering the classes that need to be modified.

You stated that you would rather see a patch for a small section of the code base ported to the new api. Would the standard BEFORE/AFTER code examples do this for you … or is that too trivial?

The approach of working bottom up to my mind seems a good one; for every call that is changed to return a DataAccess; modules further down the chain can cast to a DataStore until that section of code is updated.

Ben highlighted a few problem classes such as RetypingDataStore; I actually suspect he will need to create a second RetypingDataAccess and choose what class to instantiate based on an instanceof check of the origional.

Is this the kind of detail you are expecting?

Jody

[Justin_Deoliveira]

Hey Jody,

Up front I want to say that I realize we are putting this proposal though many more hoops we do the standard proposal. But given 1) the order of magnitude of the change and 2) the history of this topic, I think the extra hoops are warranted.

So in terms of what I think the proposal needs I think class diagrams and system diagrams are of not much value here, what it needs is to outline the nuts and bolts of what needs to be changed.

A BEFORE/AFTER would be better, but I think too trivial to be useful. I mean for myself and some others, we already know the api before and after, so it is not of much value. What is of value is specing out the real problems that will arise, that can only be flushed out during implementation.

So I would say pick a spike, and work though porting it over. I would say either WFS GetFeature or WMS GetMap. And work down figuring out what need to be changed and how. With that information in hand this proposal will have enough weight to make it though.

And one last note, an iterative approach is mandatory in my opinion. This effort will yet again fail if it has to be a one shot thing, and far too risky.

-Justin

Jody Garnett wrote:

Hi Justin,

I am going to restart the conversation on just this point - the proposal needs to be more explicit in order for anyone to vote on it. What level of detail are we looking for in this proposal; if this was design work we could ask for nice class diagrams as per your catalog proposal. This would be fine Ben could spend a week and bang up a proposal for us to review.

I think my mistake was in starting with Gabriel's email and diagram; when I next see Ben online I will try and help him revise this page into his own words and with a series of tasks covering the classes that need to be modified.

You stated that you would rather see a patch for a small section of the code base ported to the new api. Would the standard BEFORE/AFTER code examples do this for you ... or is that too trivial?

The approach of working bottom up to my mind seems a good one; for every call that is changed to return a DataAccess; modules further down the chain can cast to a DataStore until that section of code is updated.

Ben highlighted a few problem classes such as RetypingDataStore; I actually suspect he will need to create a second RetypingDataAccess and choose what class to instantiate based on an instanceof check of the origional.

Is this the kind of detail you are expecting?

Jody

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

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

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

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[jive]

Understood; we also need to balance this with helping Ben through the hoops

I had a good skype session with Rob and Ben yesterday and I will try and assist Ben as he documents what he intends to do.

Let us both try to review this page as it takes shape; I worry that we have many different parties each imagining a different amount of work.

Jody

On Wed, Jan 21, 2009 at 10:36 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey Jody,

Up front I want to say that I realize we are putting this proposal though many more hoops we do the standard proposal. But given 1) the order of magnitude of the change and 2) the history of this topic, I think the extra hoops are warranted.

So in terms of what I think the proposal needs I think class diagrams and system diagrams are of not much value here, what it needs is to outline the nuts and bolts of what needs to be changed.

A BEFORE/AFTER would be better, but I think too trivial to be useful. I mean for myself and some others, we already know the api before and after, so it is not of much value. What is of value is specing out the real problems that will arise, that can only be flushed out during implementation.

So I would say pick a spike, and work though porting it over. I would say either WFS GetFeature or WMS GetMap. And work down figuring out what need to be changed and how. With that information in hand this proposal will have enough weight to make it though.

And one last note, an iterative approach is mandatory in my opinion. This effort will yet again fail if it has to be a one shot thing, and far too risky.

-Justin

Jody Garnett wrote:

Hi Justin,

I am going to restart the conversation on just this point - the proposal needs to be more explicit in order for anyone to vote on it. What level of detail are we looking for in this proposal; if this was design work we could ask for nice class diagrams as per your catalog proposal. This would be fine Ben could spend a week and bang up a proposal for us to review.

I think my mistake was in starting with Gabriel’s email and diagram; when I next see Ben online I will try and help him revise this page into his own words and with a series of tasks covering the classes that need to be modified.

You stated that you would rather see a patch for a small section of the code base ported to the new api. Would the standard BEFORE/AFTER code examples do this for you … or is that too trivial?

The approach of working bottom up to my mind seems a good one; for every call that is changed to return a DataAccess; modules further down the chain can cast to a DataStore until that section of code is updated.

Ben highlighted a few problem classes such as RetypingDataStore; I actually suspect he will need to create a second RetypingDataAccess and choose what class to instantiate based on an instanceof check of the origional.

Is this the kind of detail you are expecting?

Jody

---

---

This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

---

---

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

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[Rob_Atkinson1]

And in the meantime it sounds like Ben will have completed a local
spike and be ready with the patch

If the GSIP process takes so long, maybe we should have a single one
"fix everything" - seriously the effort that goes into breaking down
the big picture into small, regression testable changes needs to be
supported by a far more efficient GSIP process.

Perhaps we need a GSIP-lite for backwards compatible changes that just
require minor adaptions, and another one for new functionality that
requires (or enables) throwing the old stuff away - like a new UI.

Rob

On Wed, Jan 21, 2009 at 4:09 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Understood; we also need to balance this with helping Ben through the hoops

I had a good skype session with Rob and Ben yesterday and I will try and
assist Ben as he documents what he intends to do.
Let us both try to review this page as it takes shape; I worry that we have
many different parties each imagining a different amount of work.
Jody

On Wed, Jan 21, 2009 at 10:36 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Hey Jody,

Up front I want to say that I realize we are putting this proposal though
many more hoops we do the standard proposal. But given 1) the order of
magnitude of the change and 2) the history of this topic, I think the extra
hoops are warranted.

So in terms of what I think the proposal needs I think class diagrams and
system diagrams are of not much value here, what it needs is to outline the
nuts and bolts of what needs to be changed.

A BEFORE/AFTER would be better, but I think too trivial to be useful. I
mean for myself and some others, we already know the api before and after,
so it is not of much value. What is of value is specing out the real
problems that will arise, that can only be flushed out during
implementation.

So I would say pick a spike, and work though porting it over. I would say
either WFS GetFeature or WMS GetMap. And work down figuring out what need to
be changed and how. With that information in hand this proposal will have
enough weight to make it though.

And one last note, an iterative approach is mandatory in my opinion. This
effort will yet again fail if it has to be a one shot thing, and far too
risky.

-Justin

Jody Garnett wrote:

Hi Justin,

I am going to restart the conversation on just this point - the proposal
needs to be more explicit in order for anyone to vote on it. What level of
detail are we looking for in this proposal; if this was design work we could
ask for nice class diagrams as per your catalog proposal. This would be fine
Ben could spend a week and bang up a proposal for us to review.

I think my mistake was in starting with Gabriel's email and diagram; when
I next see Ben online I will try and help him revise this page into his own
words and with a series of tasks covering the classes that need to be
modified.

You stated that you would rather see a patch for a small section of the
code base ported to the new api. Would the standard BEFORE/AFTER code
examples do this for you ... or is that too trivial?

The approach of working bottom up to my mind seems a good one; for every
call that is changed to return a DataAccess; modules further down the chain
can cast to a DataStore until that section of code is updated.

Ben highlighted a few problem classes such as RetypingDataStore; I
actually suspect he will need to create a second RetypingDataAccess and
choose what class to instantiate based on an instanceof check of the
origional.

Is this the kind of detail you are expecting?

Jody

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

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

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

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Justin_Deoliveira]

Rob Atkinson wrote:

And in the meantime it sounds like Ben will have completed a local
spike and be ready with the patch

If the GSIP process takes so long, maybe we should have a single one
"fix everything" - seriously the effort that goes into breaking down
the big picture into small, regression testable changes needs to be
supported by a far more efficient GSIP process.

I am curious to hear your ideas about "more efficient".

Perhaps we need a GSIP-lite for backwards compatible changes that just
require minor adaptions, and another one for new functionality that
requires (or enables) throwing the old stuff away - like a new UI.

Perhaps, maybe we could add a sort of rating to a GSIP. Although I don't know much it would change things. Currently "minor" proposals tend to go through quite quickly, while "major" ones tend to be much more details and receive much scrutiny.

Rob

On Wed, Jan 21, 2009 at 4:09 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Understood; we also need to balance this with helping Ben through the hoops

I had a good skype session with Rob and Ben yesterday and I will try and
assist Ben as he documents what he intends to do.
Let us both try to review this page as it takes shape; I worry that we have
many different parties each imagining a different amount of work.
Jody

On Wed, Jan 21, 2009 at 10:36 AM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Hey Jody,

Up front I want to say that I realize we are putting this proposal though
many more hoops we do the standard proposal. But given 1) the order of
magnitude of the change and 2) the history of this topic, I think the extra
hoops are warranted.

So in terms of what I think the proposal needs I think class diagrams and
system diagrams are of not much value here, what it needs is to outline the
nuts and bolts of what needs to be changed.

A BEFORE/AFTER would be better, but I think too trivial to be useful. I
mean for myself and some others, we already know the api before and after,
so it is not of much value. What is of value is specing out the real
problems that will arise, that can only be flushed out during
implementation.

So I would say pick a spike, and work though porting it over. I would say
either WFS GetFeature or WMS GetMap. And work down figuring out what need to
be changed and how. With that information in hand this proposal will have
enough weight to make it though.

And one last note, an iterative approach is mandatory in my opinion. This
effort will yet again fail if it has to be a one shot thing, and far too
risky.

-Justin

Jody Garnett wrote:

Hi Justin,

I am going to restart the conversation on just this point - the proposal
needs to be more explicit in order for anyone to vote on it. What level of
detail are we looking for in this proposal; if this was design work we could
ask for nice class diagrams as per your catalog proposal. This would be fine
Ben could spend a week and bang up a proposal for us to review.

I think my mistake was in starting with Gabriel's email and diagram; when
I next see Ben online I will try and help him revise this page into his own
words and with a series of tasks covering the classes that need to be
modified.

You stated that you would rather see a patch for a small section of the
code base ported to the new api. Would the standard BEFORE/AFTER code
examples do this for you ... or is that too trivial?

The approach of working bottom up to my mind seems a good one; for every
call that is changed to return a DataAccess; modules further down the chain
can cast to a DataStore until that section of code is updated.

Ben highlighted a few problem classes such as RetypingDataStore; I
actually suspect he will need to create a second RetypingDataAccess and
choose what class to instantiate based on an instanceof check of the
origional.

Is this the kind of detail you are expecting?

Jody

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

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword

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

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

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

[Ben_Caradoc-Davies]

Justin Deoliveira wrote:

Rob Atkinson wrote:

If the GSIP process takes so long, maybe we should have a single one
"fix everything" - seriously the effort that goes into breaking down
the big picture into small, regression testable changes needs to be
supported by a far more efficient GSIP process.

I am curious to hear your ideas about "more efficient".

Efficient as in "making the trains run on time", perhaps? :->

Efficiency is the antithesis of democracy ...

Perhaps we need a GSIP-lite for backwards compatible changes that just
require minor adaptions, and another one for new functionality that
requires (or enables) throwing the old stuff away - like a new UI.

Perhaps, maybe we could add a sort of rating to a GSIP. Although I don't know much it would change things. Currently "minor" proposals tend to go through quite quickly, while "major" ones tend to be much more details and receive much scrutiny.

This is also problematic, as we now have another layer of process: the rating of proposals. All the old problems remain.

As the main protagonist in the GSIP under discussion, I can say that, while the process has consumed some time, it has clarified the scope of the work, led to a considerable improvement in transparency, and has given the community an opportunity to give their informed consent. I am not uncomfortable with the process as it stands.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia