R: R: [Geotools-devel] Re: [Geoserver-devel] GeoServer and GeoToo ls versions

GeoServer GeoServer Developer
1

If at all possible I'd like to encourage you to not go this route.
Ultimately it's up to David though, and in the past I've
always offered
people the option of doing gt2 work directly in geoserver.
But I would
recommend against it.

I know it's not the best option, but it would only be a temporarily
solution,
and it also has some advantages.
It'll may come out that part of our code is of interest to others but maybe
not,
so we could leave it in GeoServer until the GeoTools PMC or whoever else has
reviewed it
and decided if and how to integrate it.
For package names, it's speedier for us to leave them as they're,
until someone tell us how to call them, otherwise we risk to have to rename
them several times.
Also there're things that may or may not be suited to go inside GeoTools.
For example we want to factor-out TransactionReponse to make it usable
even outside GeoServer. The resulting code will let you operate against
a group of DataStores as a whole inside a transaction but without passing
through WFS/HTTP. We always thought that the resulting code should go
inside GeoTools, but maybe that's not the case.
In a sense it will act as a service for client code, even if it won't have
anything to do with WFS, so why not let it stay inside GeoServer???
Put it another way, should GeoServer only be a Web interface upon GeoTools
or may it contain non Web functionalities as well???

I guess the main thing we could do for you is to quickly get geoserver
trunk working against 2.2.x. That's our plan, and we want to do it
soon, we've just been held up doing docs, making 1.3.0 super tight.
Perhaps we could consider branching into a 1.3.0 now, and we
could have
geoserver trunk working against 2.2.x, so you guys wouldn't
be the ones
doing all the bug fixing. Jody says udig is going to go to 2.2.x soon
as well.

Basically we're transitioning to a model where any RnD work
should go on
a geotools branch, and you'd have the parallel GeoServer
branch going.

I'm sorry, I really didn't want to push anybody to do anything...!!!
Anyway, it would be great to have GeoServer on 2.2.x, but what about
stability???
Having two coordinated branches to work upon sounds good,
but I'm not really a CVS/SVN guru, so I can't tell what the best option
is...

It will start to be the case where bugs are fixed on trunk first, and
then maybe backported to the older branches. But if you are
staying on
2.1.x you will start to miss out on more and more bug fixes as time
goes on, and upgrading to the latest will be more painful.

Yes, in fact I don't like to remain still on 2.1.x but, if I din't
misunderstood,
it seems that David did bug fixing inside 2.1.x only, so that 2.2.x will
contain
things missing from 2.1.x and viceversa. If this is really the case I have
to stay
where GeoServer is.

What is your time frame on this?

We're quite time-tight by now, we must produce something as soon as
possible...

And is your end product going to be
maintained, or just left after it's done? Like if you're just doing
this for a couple months, need some results, and don't
necessarily need
a future-proof system, then what you're proposing makes sense. But if
the system is to go through upgrade cycles, I really don't think you
want to have it just live on 2.1.x.

We have both needs. We must have something working as soon as possible,
but then it must be upgraded with all the new functionalities.
So the decision to stay with 2.1.x would be temporarily, maybe for the
remaining months of 2005 or so.
Anyway once the system is working and functional-complete,
we may have no need to mantain it much...

But I do understand
deadlines, and
that you must evaluate the risks for yourself. And my bias is
obviously towards getting as much in geotools as possible - but its
benefits over the long term have also been proven time and again by
personal experience. But at the very least I'm glad you're
doing it on
a geoserver branch, it does increase the chances of someone coming
along later and learning from what you will have done.

Yes, in fact this would be a minimal but better than nothing solution.
At least it would all be public and available for others to see, review
and eventually decide if and how to integrate.

Chris

      Bye Paolo

P.S: I tried creating the branch from
  https://svn.codehaus.org/geoserver/trunk/geoserver
to
  https://svn.codehaus.org/geoserver/branches/sis-branch
using TortoiseSVN and the same commit credentials I have for GeoTools,
but it said I'm not authorized. I remember you voted my commit rights
for GeoServer, but maybe they hadn't been put in place.

2

Quoting "P.Rizzi Ag.Mobilità Ambiente" <paolo.rizzi@anonymised.com>:

> If at all possible I'd like to encourage you to not go this route.
> Ultimately it's up to David though, and in the past I've
> always offered
> people the option of doing gt2 work directly in geoserver.
> But I would
> recommend against it.
I know it's not the best option, but it would only be a temporarily
solution,
and it also has some advantages.
It'll may come out that part of our code is of interest to others but
maybe
not,
so we could leave it in GeoServer until the GeoTools PMC or whoever
else has
reviewed it
and decided if and how to integrate it.
For package names, it's speedier for us to leave them as they're,
until someone tell us how to call them, otherwise we risk to have to
rename
them several times.

That's fine. And I'm fine with you using geotools packages on the
geoserver branch. It should just stay on the branch, for integration
we should put them in gt2.

Also there're things that may or may not be suited to go inside
GeoTools.
For example we want to factor-out TransactionReponse to make it
usable
even outside GeoServer. The resulting code will let you operate
against
a group of DataStores as a whole inside a transaction but without
passing
through WFS/HTTP. We always thought that the resulting code should go
inside GeoTools, but maybe that's not the case.
In a sense it will act as a service for client code, even if it won't
have
anything to do with WFS, so why not let it stay inside GeoServer???
Put it another way, should GeoServer only be a Web interface upon
GeoTools
or may it contain non Web functionalities as well???

I think David's plan is to for GeoServer to truly be web only, do
everything else in GeoTools. I support this as well. If there is some
super unique functionality, or some untested stuff that geotools
doesn't want, then it can live in geoserver. But we've always strived
to get as much as possible into gt2. At the time we made our global
classes, like Repository, it wasn't clear how much they'd be needed in
gt2. But with udig we now have diverse requirements, and the time is
definitely due.

>
> I guess the main thing we could do for you is to quickly get
geoserver
> trunk working against 2.2.x. That's our plan, and we want to do it
> soon, we've just been held up doing docs, making 1.3.0 super tight.
> Perhaps we could consider branching into a 1.3.0 now, and we
> could have
> geoserver trunk working against 2.2.x, so you guys wouldn't
> be the ones
> doing all the bug fixing. Jody says udig is going to go to 2.2.x
soon
> as well.
>
> Basically we're transitioning to a model where any RnD work
> should go on
> a geotools branch, and you'd have the parallel GeoServer
> branch going.
I'm sorry, I really didn't want to push anybody to do anything...!!!
Anyway, it would be great to have GeoServer on 2.2.x, but what about
stability???
Having two coordinated branches to work upon sounds good,
but I'm not really a CVS/SVN guru, so I can't tell what the best
option
is...

The big movement I've been trying to promote for awhile is to have trunk
(which will start as 2.2.x) _always_ be stable, and to do RnD stuff
only on branches. When too much RnD stuff happens all at once we get
nasty situations. It's not totally sure this will work better, there
are other risks. But we'd like to have trunk be nice and stable, any
RnD work must get their branch totally stable, and when it rolls in
there should just be a day or less of instability. Other RnD branches
may experience instability longer, since it may take them longer to
align. But that's our current plan.

> It will start to be the case where bugs are fixed on trunk first,
and
> then maybe backported to the older branches. But if you are
> staying on
> 2.1.x you will start to miss out on more and more bug fixes as time
> goes on, and upgrading to the latest will be more painful.
Yes, in fact I don't like to remain still on 2.1.x but, if I din't
misunderstood,
it seems that David did bug fixing inside 2.1.x only, so that 2.2.x
will
contain
things missing from 2.1.x and viceversa.

Yeah, that was a mistake. We're hoping to correct it soon. But it's
tough given all the constraints.

If this is really the case I

have
to stay
where GeoServer is.

>
> What is your time frame on this?
We're quite time-tight by now, we must produce something as soon as
possible...

> And is your end product going to be
> maintained, or just left after it's done? Like if you're just
doing
> this for a couple months, need some results, and don't
> necessarily need
> a future-proof system, then what you're proposing makes sense. But
if
> the system is to go through upgrade cycles, I really don't think
you
> want to have it just live on 2.1.x.
We have both needs. We must have something working as soon as
possible,
but then it must be upgraded with all the new functionalities.
So the decision to stay with 2.1.x would be temporarily, maybe for
the
remaining months of 2005 or so.
Anyway once the system is working and functional-complete,
we may have no need to mantain it much...

Cool.

> But I do understand
> deadlines, and
> that you must evaluate the risks for yourself. And my bias is
> obviously towards getting as much in geotools as possible - but its
> benefits over the long term have also been proven time and again by
> personal experience. But at the very least I'm glad you're
> doing it on
> a geoserver branch, it does increase the chances of someone coming
> along later and learning from what you will have done.
Yes, in fact this would be a minimal but better than nothing
solution.
At least it would all be public and available for others to see,
review
and eventually decide if and how to integrate.

Sounds good.

P.S: I tried creating the branch from
  https://svn.codehaus.org/geoserver/trunk/geoserver
to
  https://svn.codehaus.org/geoserver/branches/sis-branch
using TortoiseSVN and the same commit credentials I have for
GeoTools,
but it said I'm not authorized. I remember you voted my commit rights
for GeoServer, but maybe they hadn't been put in place.

You'll have to ask David or James. I'm not up on svn, I still haven't
figured out checking out.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/