Hey all,
since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools trunk? at
least that's what I remember we've talked about while preparing the release.
Gabriel
That's what I remember too.
-d
Gabriel Roldán wrote:
Hey all,
since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools trunk? at least that's what I remember we've talked about while preparing the release.
Gabriel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
ok so I'll make the switch (as soon as my current gt-trunk build finishes)
any objection anyone?
Gabriel
On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
That's what I remember too.
-dGabriel Roldán wrote:
> Hey all,
>
> since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
> trunk? at least that's what I remember we've talked about while preparing
> the release.
>
> Gabriel
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK &
> win great prizes Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Really? I thought we were going to stick to the same branch for the 2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're wanting to move pretty quickly to beta and rc, no?
Gabriel Roldán wrote:
ok so I'll make the switch (as soon as my current gt-trunk build finishes)
any objection anyone?
Gabriel
On Friday 15 August 2008 06:15:05 pm David Winslow wrote:That's what I remember too.
-dGabriel Roldán wrote:
Hey all,
since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
trunk? at least that's what I remember we've talked about while preparing
the release.Gabriel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
well we talked about this on this email thread [1] and a meeting. My
impression was pros and cons were balanced and there was general concensus
that it was a higher risk letting geotools trunk go wild (in the long run)
than following the policy the PSC decided about, which is that GeoServer
trunk shall follow GeoTools trunk.
Note I just made the switch to geotools trunk on my local checkout and it
_does not_ build, the WFS module breaks, so the concern is how more difficult
will it be to make the switch the longer we wait.
By the other side its true sticking to gt-2.5.x allows us to progress faster
on 2.0, working on geotools trunk is always a compromise when time counts.
opinions? should we call the PSC for a vote? does the PSC care or will they
just let us do whatever gets us to 2.0 faster?
Gabriel
[1]
<http://www.nabble.com/-PSC--Which-gt2-version-for-GeoServer-trunk--td18736329.html#a18736329>
On Friday 15 August 2008 07:17:47 pm Chris Holmes wrote:
Really? I thought we were going to stick to the same branch for the
2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're
wanting to move pretty quickly to beta and rc, no?Gabriel Roldán wrote:
> ok so I'll make the switch (as soon as my current gt-trunk build
> finishes)
>
> any objection anyone?
>
> Gabriel
>
> On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
>> That's what I remember too.
>> -d
>>
>> Gabriel Roldán wrote:
>>> Hey all,
>>>
>>> since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
>>> trunk? at least that's what I remember we've talked about while
>>> preparing the release.
>>>
>>> Gabriel
>>>
>>> -----------------------------------------------------------------------
>>>-- This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge Build the coolest Linux based applications with Moblin SDK &
>>> win great prizes Grand prize is a trip for two to an Open Source event
>>> anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK &
> win great prizes Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
No, you all should decide, and I guess OpenGeo is still deciding on the pace we want to push on 2.0.x. I'm coming from the product angle and I want to reduce risk in the short term. Though I was against it the community decided that geoserver trunk should be against geotools trunk. I suppose that policy should continue, I had just thought the decision to go against geotools 2.5 was for all of 2.0, not just for the alpha.
From a GeoServer perspective I don't think trunk of GeoTools really offers us anything, except more work. But I understand the argument that if we are on it and keeping it in check it could lead to less work in the long term. And I'd really like to not have to deal with getting GeoTools trunk to a stable release just to get a GeoServer 2.0 out the door, when we have no changes. But I'll go with what you all decide, I apologize I wasn't up with the original email thread.
Chris
Gabriel Roldán wrote:
well we talked about this on this email thread [1] and a meeting. My impression was pros and cons were balanced and there was general concensus that it was a higher risk letting geotools trunk go wild (in the long run) than following the policy the PSC decided about, which is that GeoServer trunk shall follow GeoTools trunk.
Note I just made the switch to geotools trunk on my local checkout and it _does not_ build, the WFS module breaks, so the concern is how more difficult will it be to make the switch the longer we wait.
By the other side its true sticking to gt-2.5.x allows us to progress faster on 2.0, working on geotools trunk is always a compromise when time counts.
opinions? should we call the PSC for a vote? does the PSC care or will they just let us do whatever gets us to 2.0 faster?
Gabriel
[1] <http://www.nabble.com/-PSC--Which-gt2-version-for-GeoServer-trunk--td18736329.html#a18736329>
On Friday 15 August 2008 07:17:47 pm Chris Holmes wrote:
Really? I thought we were going to stick to the same branch for the
2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're
wanting to move pretty quickly to beta and rc, no?Gabriel Roldán wrote:
ok so I'll make the switch (as soon as my current gt-trunk build
finishes)any objection anyone?
Gabriel
On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
That's what I remember too.
-dGabriel Roldán wrote:
Hey all,
since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
trunk? at least that's what I remember we've talked about while
preparing the release.Gabriel
-----------------------------------------------------------------------
-- This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Myh own feeling - keeping aligned with trunk seems to have meant that
we have released faster (1.7 came out pretty quick and 2.0 started on
without massive amounts of pain compared with what I saw around
pre-trunk-tracking policy)
A change of policy requires a discussion and a vote, otherwise we
should follow the policy. We need a concrete issue to initiate a
discussion, and a vague "it might take longer" doesnt convince me,
especially if the evidence seems to (me at least) to point to the
opposite.
I'd also like more clarity in the release roadmap, I think the
frequency of releases may actually risk being a little bit of a
problem to users - not sure there is sufficient clarity of reasons why
a user would upgrade across any specific version increment, and we
seem to be getting a few regression failures.
That said, exercising the regular release process and the skills and
energy of those involved is fantastic, so maybe its an opportunity for
better communication, and a fairly optimal development process.
My team is likely to skip the 1.7 branch and invest, starting in the
next few weeks, in community schema support for 2.0, and we'd prefer
it was on trunk, and we branch when we've done the port. It shouldnt
add a great deal of functionality to either geoserver or geotools -
but should exercise more of the internals and provide a lot more tests
e.g. for different data types. We are having a planning meeting on
Wednesday, we'd like to bring our plan to the table at that point for
discussion. If this fits in with other decision making it might be
easier for all of us,
Regards
Rob Atkinson
On Sat, Aug 16, 2008 at 8:49 AM, Chris Holmes <cholmes@anonymised.com> wrote:
No, you all should decide, and I guess OpenGeo is still deciding on the pace
we want to push on 2.0.x. I'm coming from the product angle and I want to
reduce risk in the short term. Though I was against it the community
decided that geoserver trunk should be against geotools trunk. I suppose
that policy should continue, I had just thought the decision to go against
geotools 2.5 was for all of 2.0, not just for the alpha.From a GeoServer perspective I don't think trunk of GeoTools really offers
us anything, except more work. But I understand the argument that if we are
on it and keeping it in check it could lead to less work in the long term.
And I'd really like to not have to deal with getting GeoTools trunk to a
stable release just to get a GeoServer 2.0 out the door, when we have no
changes. But I'll go with what you all decide, I apologize I wasn't up with
the original email thread.Chris
Gabriel Roldán wrote:
well we talked about this on this email thread [1] and a meeting. My
impression was pros and cons were balanced and there was general concensus
that it was a higher risk letting geotools trunk go wild (in the long run)
than following the policy the PSC decided about, which is that GeoServer
trunk shall follow GeoTools trunk.Note I just made the switch to geotools trunk on my local checkout and it
_does not_ build, the WFS module breaks, so the concern is how more
difficult will it be to make the switch the longer we wait.By the other side its true sticking to gt-2.5.x allows us to progress
faster on 2.0, working on geotools trunk is always a compromise when time
counts.opinions? should we call the PSC for a vote? does the PSC care or will
they just let us do whatever gets us to 2.0 faster?Gabriel
[1]
<http://www.nabble.com/-PSC--Which-gt2-version-for-GeoServer-trunk--td18736329.html#a18736329>On Friday 15 August 2008 07:17:47 pm Chris Holmes wrote:
Really? I thought we were going to stick to the same branch for the
2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're
wanting to move pretty quickly to beta and rc, no?Gabriel Roldán wrote:
ok so I'll make the switch (as soon as my current gt-trunk build
finishes)any objection anyone?
Gabriel
On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
That's what I remember too.
-dGabriel Roldán wrote:
Hey all,
since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
trunk? at least that's what I remember we've talked about while
preparing the release.Gabriel
-----------------------------------------------------------------------
-- This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I figure we went through this on the email list when Andrea brought it up. For me it come down to a decision on how long the 2.0 branch was going to last (ie how long until the wicket ui is ready? and can we keep the wicket ui as the *only* scope for 2.0?). If this is something that is wrapping up in September then I would vote to keep geoserver 2.0.x branch on 2.5.x for a few more weeks.
If it is going to take longer than that then I would really like the help on the 2.6.x branch of GeoTools. It looks like most of the planned changes for 2.6.x (ie Symbology Encoding) are going elsewhere (or at least on a timeframe I cannot predict). That leaves you with uDig driving development on 2.6.x and we are only planning on fixes - and have no new functionality planned at this time.
Jody
Sounds good. If we push fast on 2.0.x and community schema doesn't come on soon I might ask that we switch a stable branch to a previous geotools stable branch. Like we should operate trunk on trunk, but if we branch off for 2.0.x I'd like to consider being able to make that against GeoTools 2.5 instead of forcing GeoServer devs leading a charge to put out 2.6.0 even if there's no advantages for us. I believe this should be in line with the current policy - trunk would stay on trunk, it'd only go back to a stable release when we're looking to stabilize the GeoServer release. And obviously we could only do that if no one had any code in GeoServer that relied on new things on trunk. If there's valuable community schema code on trunk soon that would obviously be reason to push out 2.6.0 (though I really am hoping that people looking to do core work in that way are including budget to be taking the lead on at least GeoTools release stuff).
best regards,
Chris
Rob Atkinson wrote:
Myh own feeling - keeping aligned with trunk seems to have meant that
we have released faster (1.7 came out pretty quick and 2.0 started on
without massive amounts of pain compared with what I saw around
pre-trunk-tracking policy)A change of policy requires a discussion and a vote, otherwise we
should follow the policy. We need a concrete issue to initiate a
discussion, and a vague "it might take longer" doesnt convince me,
especially if the evidence seems to (me at least) to point to the
opposite.I'd also like more clarity in the release roadmap, I think the
frequency of releases may actually risk being a little bit of a
problem to users - not sure there is sufficient clarity of reasons why
a user would upgrade across any specific version increment, and we
seem to be getting a few regression failures.That said, exercising the regular release process and the skills and
energy of those involved is fantastic, so maybe its an opportunity for
better communication, and a fairly optimal development process.My team is likely to skip the 1.7 branch and invest, starting in the
next few weeks, in community schema support for 2.0, and we'd prefer
it was on trunk, and we branch when we've done the port. It shouldnt
add a great deal of functionality to either geoserver or geotools -
but should exercise more of the internals and provide a lot more tests
e.g. for different data types. We are having a planning meeting on
Wednesday, we'd like to bring our plan to the table at that point for
discussion. If this fits in with other decision making it might be
easier for all of us,Regards
Rob AtkinsonOn Sat, Aug 16, 2008 at 8:49 AM, Chris Holmes <cholmes@anonymised.com> wrote:
No, you all should decide, and I guess OpenGeo is still deciding on the pace
we want to push on 2.0.x. I'm coming from the product angle and I want to
reduce risk in the short term. Though I was against it the community
decided that geoserver trunk should be against geotools trunk. I suppose
that policy should continue, I had just thought the decision to go against
geotools 2.5 was for all of 2.0, not just for the alpha.From a GeoServer perspective I don't think trunk of GeoTools really offers
us anything, except more work. But I understand the argument that if we are
on it and keeping it in check it could lead to less work in the long term..
And I'd really like to not have to deal with getting GeoTools trunk to a
stable release just to get a GeoServer 2.0 out the door, when we have no
changes. But I'll go with what you all decide, I apologize I wasn't up with
the original email thread.Chris
Gabriel Roldán wrote:
well we talked about this on this email thread [1] and a meeting. My
impression was pros and cons were balanced and there was general concensus
that it was a higher risk letting geotools trunk go wild (in the long run)
than following the policy the PSC decided about, which is that GeoServer
trunk shall follow GeoTools trunk.Note I just made the switch to geotools trunk on my local checkout and it
_does not_ build, the WFS module breaks, so the concern is how more
difficult will it be to make the switch the longer we wait.By the other side its true sticking to gt-2.5.x allows us to progress
faster on 2.0, working on geotools trunk is always a compromise when time
counts.opinions? should we call the PSC for a vote? does the PSC care or will
they just let us do whatever gets us to 2.0 faster?Gabriel
[1]
<http://www.nabble.com/-PSC--Which-gt2-version-for-GeoServer-trunk--td18736329.html#a18736329>On Friday 15 August 2008 07:17:47 pm Chris Holmes wrote:
Really? I thought we were going to stick to the same branch for the
2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're
wanting to move pretty quickly to beta and rc, no?Gabriel Roldán wrote:
ok so I'll make the switch (as soon as my current gt-trunk build
finishes)any objection anyone?
Gabriel
On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
That's what I remember too.
-dGabriel Roldán wrote:
Hey all,
since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
trunk? at least that's what I remember we've talked about while
preparing the release.Gabriel
-----------------------------------------------------------------------
-- This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK &
win great prizes Grand prize is a trip for two to an Open Source event
anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
That's the point, if we want to release 2.0 asap that means it shall be over a
geotools release, and releasing gt-2.6 without funcionality changes makes no
sense, that would be a point release not a minor one (major.minor.point). If
it contains only bugfixes its a point release, isnt it?
So do we do this: align trunk to trunk for the time being, and when branching
out geoserver 2.0.x roll back to depend on geotools 2.5.x?
Gabriel
On Monday 18 August 2008 12:07:10 am Chris Holmes wrote:
Sounds good. If we push fast on 2.0.x and community schema doesn't come
on soon I might ask that we switch a stable branch to a previous
geotools stable branch. Like we should operate trunk on trunk, but if
we branch off for 2.0.x I'd like to consider being able to make that
against GeoTools 2.5 instead of forcing GeoServer devs leading a charge
to put out 2.6.0 even if there's no advantages for us. I believe this
should be in line with the current policy - trunk would stay on trunk,
it'd only go back to a stable release when we're looking to stabilize
the GeoServer release. And obviously we could only do that if no one
had any code in GeoServer that relied on new things on trunk. If
there's valuable community schema code on trunk soon that would
obviously be reason to push out 2.6.0 (though I really am hoping that
people looking to do core work in that way are including budget to be
taking the lead on at least GeoTools release stuff).best regards,
Chris
Rob Atkinson wrote:
> Myh own feeling - keeping aligned with trunk seems to have meant that
> we have released faster (1.7 came out pretty quick and 2.0 started on
> without massive amounts of pain compared with what I saw around
> pre-trunk-tracking policy)
>
> A change of policy requires a discussion and a vote, otherwise we
> should follow the policy. We need a concrete issue to initiate a
> discussion, and a vague "it might take longer" doesnt convince me,
> especially if the evidence seems to (me at least) to point to the
> opposite.
>
> I'd also like more clarity in the release roadmap, I think the
> frequency of releases may actually risk being a little bit of a
> problem to users - not sure there is sufficient clarity of reasons why
> a user would upgrade across any specific version increment, and we
> seem to be getting a few regression failures.
>
> That said, exercising the regular release process and the skills and
> energy of those involved is fantastic, so maybe its an opportunity for
> better communication, and a fairly optimal development process.
>
> My team is likely to skip the 1.7 branch and invest, starting in the
> next few weeks, in community schema support for 2.0, and we'd prefer
> it was on trunk, and we branch when we've done the port. It shouldnt
> add a great deal of functionality to either geoserver or geotools -
> but should exercise more of the internals and provide a lot more tests
> e.g. for different data types. We are having a planning meeting on
> Wednesday, we'd like to bring our plan to the table at that point for
> discussion. If this fits in with other decision making it might be
> easier for all of us,
>
> Regards
> Rob Atkinson
>
> On Sat, Aug 16, 2008 at 8:49 AM, Chris Holmes <cholmes@anonymised.com> wrote:
>> No, you all should decide, and I guess OpenGeo is still deciding on the
>> pace we want to push on 2.0.x. I'm coming from the product angle and I
>> want to reduce risk in the short term. Though I was against it the
>> community decided that geoserver trunk should be against geotools trunk.
>> I suppose that policy should continue, I had just thought the decision
>> to go against geotools 2.5 was for all of 2.0, not just for the alpha.
>>
>> From a GeoServer perspective I don't think trunk of GeoTools really
>> offers us anything, except more work. But I understand the argument
>> that if we are on it and keeping it in check it could lead to less work
>> in the long term.. And I'd really like to not have to deal with getting
>> GeoTools trunk to a stable release just to get a GeoServer 2.0 out the
>> door, when we have no changes. But I'll go with what you all decide, I
>> apologize I wasn't up with the original email thread.
>>
>> Chris
>>
>> Gabriel Roldán wrote:
>>> well we talked about this on this email thread [1] and a meeting. My
>>> impression was pros and cons were balanced and there was general
>>> concensus that it was a higher risk letting geotools trunk go wild (in
>>> the long run) than following the policy the PSC decided about, which is
>>> that GeoServer trunk shall follow GeoTools trunk.
>>>
>>> Note I just made the switch to geotools trunk on my local checkout and
>>> it _does not_ build, the WFS module breaks, so the concern is how more
>>> difficult will it be to make the switch the longer we wait.
>>>
>>> By the other side its true sticking to gt-2.5.x allows us to progress
>>> faster on 2.0, working on geotools trunk is always a compromise when
>>> time counts.
>>>
>>> opinions? should we call the PSC for a vote? does the PSC care or will
>>> they just let us do whatever gets us to 2.0 faster?
>>>
>>> Gabriel
>>>
>>> [1]
>>> <http://www.nabble.com/-PSC--Which-gt2-version-for-GeoServer-trunk--td1
>>>8736329.html#a18736329>
>>>
>>> On Friday 15 August 2008 07:17:47 pm Chris Holmes wrote:
>>>> Really? I thought we were going to stick to the same branch for the
>>>> 2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're
>>>> wanting to move pretty quickly to beta and rc, no?
>>>>
>>>> Gabriel Roldán wrote:
>>>>> ok so I'll make the switch (as soon as my current gt-trunk build
>>>>> finishes)
>>>>>
>>>>> any objection anyone?
>>>>>
>>>>> Gabriel
>>>>>
>>>>> On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
>>>>>> That's what I remember too.
>>>>>> -d
>>>>>>
>>>>>> Gabriel Roldán wrote:
>>>>>>> Hey all,
>>>>>>>
>>>>>>> since 2.0.0-alpha1 is out wouldn't it be time to switch to geotools
>>>>>>> trunk? at least that's what I remember we've talked about while
>>>>>>> preparing the release.
>>>>>>>
>>>>>>> Gabriel
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------
>>>>>>>---- -- This SF.Net email is sponsored by the Moblin Your Move
>>>>>>> Developer's challenge Build the coolest Linux based applications
>>>>>>> with Moblin SDK & win great prizes Grand prize is a trip for two to
>>>>>>> an Open Source event anywhere in the world
>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>> _______________________________________________
>>>>>>> Geoserver-devel mailing list
>>>>>>> Geoserver-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>---- This SF.Net email is sponsored by the Moblin Your Move
>>>>> Developer's challenge Build the coolest Linux based applications with
>>>>> Moblin SDK & win great prizes Grand prize is a trip for two to an
>>>>> Open Source event anywhere in the world
>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>> _______________________________________________
>>>>> Geoserver-devel mailing list
>>>>> Geoserver-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>> ------------------------------------------------------------------------
>>- This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge Build the coolest Linux based applications with Moblin SDK &
>> win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
FYI,
trunk is tied to geotools trunk as for rev #10046.
It was GEOT-1952 preventing the wfs module from building.
Cheers,
Gabriel
On Monday 18 August 2008 12:22:15 pm Gabriel Roldán wrote:
That's the point, if we want to release 2.0 asap that means it shall be
over a geotools release, and releasing gt-2.6 without funcionality changes
makes no sense, that would be a point release not a minor one
(major.minor.point). If it contains only bugfixes its a point release, isnt
it?So do we do this: align trunk to trunk for the time being, and when
branching out geoserver 2.0.x roll back to depend on geotools 2.5.x?Gabriel
On Monday 18 August 2008 12:07:10 am Chris Holmes wrote:
> Sounds good. If we push fast on 2.0.x and community schema doesn't come
> on soon I might ask that we switch a stable branch to a previous
> geotools stable branch. Like we should operate trunk on trunk, but if
> we branch off for 2.0.x I'd like to consider being able to make that
> against GeoTools 2.5 instead of forcing GeoServer devs leading a charge
> to put out 2.6.0 even if there's no advantages for us. I believe this
> should be in line with the current policy - trunk would stay on trunk,
> it'd only go back to a stable release when we're looking to stabilize
> the GeoServer release. And obviously we could only do that if no one
> had any code in GeoServer that relied on new things on trunk. If
> there's valuable community schema code on trunk soon that would
> obviously be reason to push out 2.6.0 (though I really am hoping that
> people looking to do core work in that way are including budget to be
> taking the lead on at least GeoTools release stuff).
>
> best regards,
>
> Chris
>
> Rob Atkinson wrote:
> > Myh own feeling - keeping aligned with trunk seems to have meant that
> > we have released faster (1.7 came out pretty quick and 2.0 started on
> > without massive amounts of pain compared with what I saw around
> > pre-trunk-tracking policy)
> >
> > A change of policy requires a discussion and a vote, otherwise we
> > should follow the policy. We need a concrete issue to initiate a
> > discussion, and a vague "it might take longer" doesnt convince me,
> > especially if the evidence seems to (me at least) to point to the
> > opposite.
> >
> > I'd also like more clarity in the release roadmap, I think the
> > frequency of releases may actually risk being a little bit of a
> > problem to users - not sure there is sufficient clarity of reasons why
> > a user would upgrade across any specific version increment, and we
> > seem to be getting a few regression failures.
> >
> > That said, exercising the regular release process and the skills and
> > energy of those involved is fantastic, so maybe its an opportunity for
> > better communication, and a fairly optimal development process.
> >
> > My team is likely to skip the 1.7 branch and invest, starting in the
> > next few weeks, in community schema support for 2.0, and we'd prefer
> > it was on trunk, and we branch when we've done the port. It shouldnt
> > add a great deal of functionality to either geoserver or geotools -
> > but should exercise more of the internals and provide a lot more tests
> > e.g. for different data types. We are having a planning meeting on
> > Wednesday, we'd like to bring our plan to the table at that point for
> > discussion. If this fits in with other decision making it might be
> > easier for all of us,
> >
> > Regards
> > Rob Atkinson
> >
> > On Sat, Aug 16, 2008 at 8:49 AM, Chris Holmes <cholmes@anonymised.com>
wrote:
> >> No, you all should decide, and I guess OpenGeo is still deciding on
> >> the pace we want to push on 2.0.x. I'm coming from the product angle
> >> and I want to reduce risk in the short term. Though I was against it
> >> the community decided that geoserver trunk should be against geotools
> >> trunk. I suppose that policy should continue, I had just thought the
> >> decision to go against geotools 2.5 was for all of 2.0, not just for
> >> the alpha.
> >>
> >> From a GeoServer perspective I don't think trunk of GeoTools really
> >> offers us anything, except more work. But I understand the argument
> >> that if we are on it and keeping it in check it could lead to less
> >> work in the long term.. And I'd really like to not have to deal with
> >> getting GeoTools trunk to a stable release just to get a GeoServer 2.0
> >> out the door, when we have no changes. But I'll go with what you all
> >> decide, I apologize I wasn't up with the original email thread.
> >>
> >> Chris
> >>
> >> Gabriel Roldán wrote:
> >>> well we talked about this on this email thread [1] and a meeting. My
> >>> impression was pros and cons were balanced and there was general
> >>> concensus that it was a higher risk letting geotools trunk go wild
> >>> (in the long run) than following the policy the PSC decided about,
> >>> which is that GeoServer trunk shall follow GeoTools trunk.
> >>>
> >>> Note I just made the switch to geotools trunk on my local checkout
> >>> and it _does not_ build, the WFS module breaks, so the concern is how
> >>> more difficult will it be to make the switch the longer we wait.
> >>>
> >>> By the other side its true sticking to gt-2.5.x allows us to progress
> >>> faster on 2.0, working on geotools trunk is always a compromise when
> >>> time counts.
> >>>
> >>> opinions? should we call the PSC for a vote? does the PSC care or
> >>> will they just let us do whatever gets us to 2.0 faster?
> >>>
> >>> Gabriel
> >>>
> >>> [1]
> >>> <http://www.nabble.com/-PSC--Which-gt2-version-for-GeoServer-trunk--t
> >>>d1 8736329.html#a18736329>
> >>>
> >>> On Friday 15 August 2008 07:17:47 pm Chris Holmes wrote:
> >>>> Really? I thought we were going to stick to the same branch for the
> >>>> 2.0.x releases as 1.7.x, so as to reduce our risk. I mean, we're
> >>>> wanting to move pretty quickly to beta and rc, no?
> >>>>
> >>>> Gabriel Roldán wrote:
> >>>>> ok so I'll make the switch (as soon as my current gt-trunk build
> >>>>> finishes)
> >>>>>
> >>>>> any objection anyone?
> >>>>>
> >>>>> Gabriel
> >>>>>
> >>>>> On Friday 15 August 2008 06:15:05 pm David Winslow wrote:
> >>>>>> That's what I remember too.
> >>>>>> -d
> >>>>>>
> >>>>>> Gabriel Roldán wrote:
> >>>>>>> Hey all,
> >>>>>>>
> >>>>>>> since 2.0.0-alpha1 is out wouldn't it be time to switch to
> >>>>>>> geotools trunk? at least that's what I remember we've talked
> >>>>>>> about while preparing the release.
> >>>>>>>
> >>>>>>> Gabriel
> >>>>>>>
> >>>>>>>
> >>>>>>> -----------------------------------------------------------------
> >>>>>>>-- ---- -- This SF.Net email is sponsored by the Moblin Your Move
> >>>>>>> Developer's challenge Build the coolest Linux based applications
> >>>>>>> with Moblin SDK & win great prizes Grand prize is a trip for two
> >>>>>>> to an Open Source event anywhere in the world
> >>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >>>>>>> _______________________________________________
> >>>>>>> Geoserver-devel mailing list
> >>>>>>> Geoserver-devel@lists.sourceforge.net
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >>>>>
> >>>>> -------------------------------------------------------------------
> >>>>>-- ---- This SF.Net email is sponsored by the Moblin Your Move
> >>>>> Developer's challenge Build the coolest Linux based applications
> >>>>> with Moblin SDK & win great prizes Grand prize is a trip for two to
> >>>>> an Open Source event anywhere in the world
> >>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >>>>> _______________________________________________
> >>>>> Geoserver-devel mailing list
> >>>>> Geoserver-devel@lists.sourceforge.net
> >>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >>
> >> ----------------------------------------------------------------------
> >>-- - This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge Build the coolest Linux based applications with Moblin SDK &
> >> win great prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Geoserver-devel mailing list
> >> Geoserver-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge Build the coolest Linux based applications with Moblin SDK & win
great prizes Grand prize is a trip for two to an Open Source event anywhere
in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel