[postgis-devel] proliferation of trac components
chodgson at refractions.net
Wed Feb 29 10:44:59 PST 2012
I think the key that if someone says we have a bug in postgis, and
enters it in the postgis trac, and it turns out to be totally dependent
on a 3rd-party library, we still need to keep trac of the issue on our
side (so that we can ensure that it is resolved). A bug would still be
filed in the 3rd party's bug tracker. The question is whether we should
keep our trac bug in the component to which it belongs, or have a
separate place to put these sort of bugs.
Since the real use of trac components is the ability to assign a user as
the custodian for each component, it seems to me that it would make
sense to leave gdal bugs that cause raster problems, in the raster
component, because it is the raster custodian who will eventually make
sure that they are resolved. But I can also see why you might like to be
able to clear your plate of such issues which you can't resolve, putting
them aside in their own "3rd-party" component. We probably don't need
3rd-party compeonents for EACH 3rd party, though.
On 12-02-29 10:35 AM, Sandro Santilli wrote:
> On Wed, Feb 29, 2012 at 11:52:49AM -0500, Pierre Racine wrote:
>> > Is it worth having a "gdal" component ?
>>> And a "third party" one ?
>>> What are they for, exactly ?
>>> This is the postgis trac, bugs in other packages should be somewhere else, no ?
>> Yes but maybe we want to "trac" some in our database. No? Probably you haven't got the need to do it for geos because you have much control over it, but it is not the case for GDAL and QGIS.
>> I would be happy with the more general 'dependencies' instead of 'gdal'...
> Note that both GDAL and QGIS use the same authentication that PostGIS
> uses (the OSGEO LDAP) so you should be able to file tickets there w/out
> much hassle. GDAL is also based on the same version of trac, while QGIS
> is a bit more fancy (redmine).
> | __/ | Delivering high quality PostGIS 2.0 !
> | / 2.0 | http://strk.keybit.net - http://vizzuality.com
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
More information about the postgis-devel