We had a semi productive meeting today, but it is obvious we need more discussion. I am proposing having another meeting this Thursday Dec 14, same time or maybe 1 hour later. Please tell me what works for you (I know Gabriel may have a hard time attending).
There are several items that are starting development that need a place to live, and there is some development wrapping up that we want to go live:
- Versioning WFS: needs a home. What version of geotools should it be developed in, assuming we want this as a live feature in GeoServer (I think we definitely do want it)
- New config system: where do we want to start developing this
- New UI (Wicket): Definitely desired and needed if we want to be fully modular and plugable; where do we want to start developing it.
- OWS4: has several parts that might come online: new dispatch system, new resource handling / data_dir, new wfs and wfs 1.1, catalog interface, set up for easy unit testing.
- Geoserver trunk using Geotools trunk: we will need good tests set up for this
Notes:
1) OWS4 is very experimental, but it has many features that would be very beneficial to have on geoserver trunk. It is also a new and clean environment that is ideal for introducing full re-writes of features such as the UI and config system.
2) OWS4 is essentially made up of several modules that can come onto trunk separately, and not all at once.
3) OWS4 is wrapping up at the end of january and needs documentation and QA.
4) OWS4 needs heavy QA and probably regression tests before it comes onto trunk.
5) Versioning WFS needs a home soon, in both geotools and geoserver.
6) A better way to unit test. OWS4 currently supports this. Having this could will be a pre-requisite for bringing in other features.
7) People have deadlines. Can we write down what they are?
Possible goals for the short term:
1) Evaluate and test new UI and new config system by end of January.
2) Bring back testability by end of January. Not necessarily implement all the tests, but set up the environment.
3) QA OWS4 and start bringing it over to trunk end of January
4) Have a place for Versioning WFS by mid-January (ideally asap)
Please add your own notes, concerns, comments, requirements, priorities, availability to contribute.
We had a semi productive meeting today, but it is obvious we need more discussion. I am proposing having another meeting this Thursday Dec 14, same time or maybe 1 hour later. Please tell me what works for you (I know Gabriel may have a hard time attending).
I would like to see the goals of each "team", if we can do that on email before the meeting cool. If not would really like two agenda items (one to gather the goals, and another to try and organize). Having both discussions at once is hard, and not productive (as we get stuck with people hearing what they want to hear, or getting confused over work that sounds similar to their own needs etc...).
My preference would be to organize goals via email, and have a meeting ant the usual time next week. Goals is probably the wrong word, I would really like "acceptance tests" .. that is i.e. specifics.
There are several items that are starting development that need a place to live, and there is some development wrapping up that we want to go live:
- Versioning WFS: needs a home. What version of geotools should it be developed in, assuming we want this as a live feature in GeoServer (I think we definitely do want it)
- New config system: where do we want to start developing this
- New UI (Wicket): Definitely desired and needed if we want to be fully modular and plugable; where do we want to start developing it.
- OWS4: has several parts that might come online: new dispatch system, new resource handling / data_dir, new wfs and wfs 1.1, catalog interface, set up for easy unit testing.
- Geoserver trunk using Geotools trunk: we will need good tests set up for this
We had a semi productive meeting today, but it is obvious we need more discussion. I am proposing having another meeting this Thursday Dec 14, same time or maybe 1 hour later. Please tell me what works for you (I know Gabriel may have a hard time attending).
Ouch, I know I won't be able to attend unless the meeting takes place
at least two hours eary (three to make sure I can attend).
- Versioning WFS: needs a home. What version of geotools should it be developed in, assuming we want this as a live feature in GeoServer (I think we definitely do want it)
Indeed. For the moment its home is my own hard disk, but it's a lonely
and cold place, dangerous too since I don't know where to put it in a
svn server... If things keep on going like this I'll be forced to switch
trunk to gt2 trunk and work there, if you have alternative
suggestions I'm all ears.
- New config system: where do we want to start developing this
And how. Wiki page to design the config system is needed.
- New UI (Wicket): Definitely desired and needed if we want to be fully modular and plugable; where do we want to start developing it.
Wiki page needed here too.
- OWS4: has several parts that might come online: new dispatch system, new resource handling / data_dir, new wfs and wfs 1.1, catalog interface, set up for easy unit testing.
- Geoserver trunk using Geotools trunk: we will need good tests set up for this
Which means we need to back port the secret sauce of testability from
OWS4.
Possible goals for the short term:
1) Evaluate and test new UI and new config system by end of January.
2) Bring back testability by end of January. Not necessarily implement all the tests, but set up the environment.
3) QA OWS4 and start bringing it over to trunk end of January
4) Have a place for Versioning WFS by mid-January (ideally asap)
Agree for all of these. Unfortunately it seems that if I want to land
it somewhere, I need geoserver trunk on gt2 trunk soon (very soon).
This does not mean it has to become the rule, it may well be the
exception and switch back to a stable branch as soon as gt2 branches
off 2.4.x
Both are the things we need to work with NOW.
Waiting for the decision about new UI system, me and Simone now will work hard on Coverage nD part.
GeoServer trunk on GeoTools trunk could be done ONLY after gt 2.3.x changes will be ported on trunk, otherwise we need to move our work on a GeoServer branch again. Speak with Simone and GeoTools team about that and let me know!
We had a semi productive meeting today, but it is obvious we need more
discussion. I am proposing having another meeting this Thursday Dec
14, same time or maybe 1 hour later. Please tell me what works for you
(I know Gabriel may have a hard time attending).
Time does not work for me … sorry.
Ok, now onto the meeting summary and discussion. What I want to get
from this is some sort of an agenda for the next meeting, and some
questions we can discuss. IRC logs:
(http://docs.codehaus.org/display/GEOS/2006/12/12/IRC+logs+Dec+12 )
I would like to see the goals of each “team”, if we can do that on email
before the meeting cool. If not would really like two agenda items (one
to gather the goals, and another to try and organize). Having both
discussions at once is hard, and not productive (as we get stuck with
people hearing what they want to hear, or getting confused over work
that sounds similar to their own needs etc…).
My preference would be to organize goals via email, and have a meeting
ant the usual time next week. Goals is probably the wrong word, I would
really like “acceptance tests” … that is i.e. specifics.
There are several items that are starting development that need a
place to live, and there is some development wrapping up that we want
to go live:
Versioning WFS: needs a home. What version of geotools should it be
developed in, assuming we want this as a live feature in GeoServer (I
think we definitely do want it)
New config system: where do we want to start developing this
New UI (Wicket): Definitely desired and needed if we want to be
fully modular and plugable; where do we want to start developing it.
OWS4: has several parts that might come online: new dispatch system,
new resource handling / data_dir, new wfs and wfs 1.1, catalog
interface, set up for easy unit testing.
Geoserver trunk using Geotools trunk: we will need good tests set up
for this
Please look here for other goals:
Please add your own notes, concerns, comments, requirements,
priorities, availability to contribute.
Need to communicate with Simboss concerning WCS plans (see GTSteering
document for research goals setting up further WCS development).
We had a semi productive meeting today, but it is obvious we need more
discussion. I am proposing having another meeting this Thursday Dec
14, same time or maybe 1 hour later. Please tell me what works for you
(I know Gabriel may have a hard time attending).
Ouch, I know I won't be able to attend unless the meeting takes place
at least two hours eary (three to make sure I can attend).
- Versioning WFS: needs a home. What version of geotools should it be
developed in, assuming we want this as a live feature in GeoServer (I
think we definitely do want it)
Indeed. For the moment its home is my own hard disk, but it's a lonely
and cold place, dangerous too since I don't know where to put it in a
svn server... If things keep on going like this I'll be forced to switch
trunk to gt2 trunk and work there, if you have alternative
suggestions I'm all ears.
- New config system: where do we want to start developing this
And how. Wiki page to design the config system is needed.
- New UI (Wicket): Definitely desired and needed if we want to be
fully modular and plugable; where do we want to start developing it.
Wiki page needed here too.
- OWS4: has several parts that might come online: new dispatch system,
new resource handling / data_dir, new wfs and wfs 1.1, catalog
interface, set up for easy unit testing.
- Geoserver trunk using Geotools trunk: we will need good tests set up
for this
Which means we need to back port the secret sauce of testability from
OWS4.
Possible goals for the short term:
1) Evaluate and test new UI and new config system by end of January.
2) Bring back testability by end of January. Not necessarily implement
all the tests, but set up the environment.
3) QA OWS4 and start bringing it over to trunk end of January
4) Have a place for Versioning WFS by mid-January (ideally asap
Agree for all of these. Unfortunately it seems that if I want to land
it somewhere, I need geoserver trunk on gt2 trunk soon (very soon).
This does not mean it has to become the rule, it may well be the
exception and switch back to a stable branch as soon as gt2 branches
off 2.4.x
For the case of 2.4.x I can agree, *if* 2.5 involves development of the
new feature model. Otherwise, I think having GeoServer trunk on Geotools
trunk is a rule we should shoot for. I think it has benefits to both
projects. I know it is a bit of overhead for GeoServer to have to keep
up with geotools trunk, but on the same token, it is necessary for us to
manage what is going on geotools trunk, or it could quickly spin out of
control and become unusable for GeoServer.
Let me be clear, the point of getting "Trunk on Trunk" for GeoServer (and for uDig as well) is so that
the change to the new feature model does not go ahead until you are ready.
So far we have talked about a few safety controls on the GeoTools codebase (a proposal system using jira, or a GTIP etc...).
Additional requirements are possible - say migration instructions (see wiki for examples of what has been done thus far). But
the balance will be better accomplished keeping the community in mind - and GeoServer is the majority of the community right now.
Cheers,
Jody
PS. I know some people are fond of technology: I also have contact with developer who put together the "play refactoring transformations as a script" project - who is interested in using GeoTools as a test subject. But in the spirit of no silver bullet I would rather treat such things as an experiment for whomever is interested.
ree for all of these. Unfortunately it seems that if I want to land
it somewhere, I need geoserver trunk on gt2 trunk soon (very soon).
This does not mean it has to become the rule, it may well be the
exception and switch back to a stable branch as soon as gt2 branches
off 2.4.x
For the case of 2.4.x I can agree, *if* 2.5 involves development of the
new feature model. Otherwise, I think having GeoServer trunk on Geotools
trunk is a rule we should shoot for. I think it has benefits to both
projects. I know it is a bit of overhead for GeoServer to have to keep
up with geotools trunk, but on the same token, it is necessary for us to
manage what is going on geotools trunk, or it could quickly spin out of
control and become unusable for GeoServer.
Let me be clear, the point of getting "Trunk on Trunk" for GeoServer (and for uDig as well) is so that
the change to the new feature model does not go ahead until you are ready.
So far we have talked about a few safety controls on the GeoTools codebase (a proposal system using jira, or a GTIP etc...).
Additional requirements are possible - say migration instructions (see wiki for examples of what has been done thus far).
Indeed, good idea. Once the gt2 PMC has voted some process rules that
need to be followed in order to accept "bigger" changes, I'm all
for having geoserver trunk against geotools trunk.
PS. I know some people are fond of technology: I also have contact with developer who put together the "play refactoring transformations as a script" project - who is interested in using GeoTools as a test subject. But in the spirit of no silver bullet I would rather treat such things as an experiment for whomever is interested.
Do you mean the Eclipse refactoring scripts? Isn't it a problem that some gt2 developers do use Netbeans?
GeoServer trunk on GeoTools trunk could be done ONLY after gt 2.3.x changes will be ported on trunk, otherwise we need to move our work on a GeoServer branch again. Speak with Simone and GeoTools team about that and let me know!
It seems a recurring problem is that functionality _intended_ to be part of the trunk (i.e. not intended to be thrown away after the current branch) has not been ported to trunk already. Maybe this is the GT process we need to improve. Surely any sane person would want to move to trunk to ensure they get _all_ the key functionality from previous stable versions, _except_ where these have been _deprecated_ for a release cycle.
Rob
On 12/13/06, *Jody Garnett* <jgarnett@anonymised.com <mailto:jgarnett@anonymised.com>> wrote:
Brent Owens wrote:
> We had a semi productive meeting today, but it is obvious we
need more
> discussion. I am proposing having another meeting this Thursday Dec
> 14, same time or maybe 1 hour later. Please tell me what works
for you
> (I know Gabriel may have a hard time attending).
Time does not work for me ... sorry.
> Ok, now onto the meeting summary and discussion. What I want to get
> from this is some sort of an agenda for the next meeting, and some
> questions we can discuss. IRC logs:
>
(http://docs.codehaus.org/display/GEOS/2006/12/12/IRC+logs+Dec+12
<http://docs.codehaus.org/display/GEOS/2006/12/12/IRC+logs+Dec+12>\)
I would like to see the goals of each "team", if we can do that on
email
before the meeting cool. If not would really like two agenda items
(one
to gather the goals, and another to try and organize). Having both
discussions at once is hard, and not productive (as we get stuck with
people hearing what they want to hear, or getting confused over work
that sounds similar to their own needs etc...).
My preference would be to organize goals via email, and have a
meeting
ant the usual time next week. Goals is probably the wrong word, I
would
really like "acceptance tests" .. that is i.e. specifics.
> There are several items that are starting development that need a
> place to live, and there is some development wrapping up that we
want
> to go live:
> - Versioning WFS: needs a home. What version of geotools should
it be
> developed in, assuming we want this as a live feature in
GeoServer (I
> think we definitely do want it)
> - New config system: where do we want to start developing this
> - New UI (Wicket): Definitely desired and needed if we want to be
> fully modular and plugable; where do we want to start developing
it.
> - OWS4: has several parts that might come online: new dispatch
system,
> new resource handling / data_dir, new wfs and wfs 1.1, catalog
> interface, set up for easy unit testing.
> - Geoserver trunk using Geotools trunk: we will need good tests
set up
> for this
Please look here for other goals:
- http://docs.codehaus.org/display/GEOS/Roadmap+for+support+of+Observations+and+Measurements+patterns+in+WFS+and+WCS
<http://docs.codehaus.org/display/GEOS/Roadmap+for+support+of+Observations+and+Measurements+patterns+in+WFS+and+WCS>
- http://docs.codehaus.org/display/GEOS/RnD
- etc...
> Please add your own notes, concerns, comments, requirements,
> priorities, availability to contribute.
Need to communicate with Simboss concerning WCS plans (see GTSteering
document for research goals setting up further WCS development).
GeoServer trunk on GeoTools trunk could be done ONLY after gt 2.3.x changes will be ported on trunk, otherwise we need to move our work on a GeoServer branch again. Speak with Simone and GeoTools team about that and let me know!
It seems a recurring problem is that functionality _intended_ to be part of the trunk (i.e. not intended to be thrown away after the current branch) has not been ported to trunk already. Maybe this is the GT process we need to improve. Surely any sane person would want to move to trunk to ensure they get _all_ the key functionality from previous stable versions, _except_ where these have been _deprecated_ for a release cycle.
Rob, the problem here is that people are maxed out and try to take
shortcuts to have their job done anyways.
One of such shortcuts is not to forward port changes. Doing so takes
time, quite a bit of it, because patches do not usually apply completely
cleanly, then you have to do a full build again to check you did not
break anything, and only after that you can commit.
So, a forward port of a patch can take from 15 minutes to up to an
hour or more depending on the case.
Having a faster build may help, or trusting cc to spot full build
errors and do only a local check, but I hope you can see the process
is inherently slow.