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
s
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 suppo
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
tru
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 object
switch 2.0.x (aka trunk) to geotools trunk
--
Key: GEOS-2128
URL: http://jira.codehaus.org/browse/GEOS-2128
Project: GeoServer
Issue Type: Task
Affects Versions: 2.0-alpha1
Reporter: Ga
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 swi
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
>
>
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
KML Reflector servlet not html-escaping cql filter clauses
--
Key: GEOS-2127
URL: http://jira.codehaus.org/browse/GEOS-2127
Project: GeoServer
Issue Type: Bug
Components: Goog
GML featureTypeCache does not qualify entries by namespace
--
Key: GEOS-2126
URL: http://jira.codehaus.org/browse/GEOS-2126
Project: GeoServer
Issue Type: Bug
Affects Versions: 1.7.
Hi Tom,
(can you keep your replies on the public list :)).
Thanks for sending the log, there is a problem occurring on startup that
is preventing geoserver from starting properly. It seems to be related
to the internal EPSG database. Can you perform the following steps:
1. Shut down GeoServer
Apologies, I removed the reference from applicationContext.xml but
forgot to commit the file last night :(
(Since it broke this part of the build I took the liberty of committing
this morning)
-Arne
Justin Deoliveira wrote:
> Hi Arne,
>
> I ran into issues trying to bundle geowebcache with th
Ciao Simone,
Thanks very much for this. Can I check that I've understood a few
things correctly?
* Do I understand correctly that you have three potential ways to read NetCDF:
- Flat plugins, no geospatial metadata (is this what GeoServer uses
right now?)
- "Smart" plugins, which wrap flat pl
13 matches
Mail list logo
