[postgis-devel] [postgis-users] where to report bugs?

[Regina Obe]

Jaime,

Sorry it took so long for you to get a mantra.  I think we are usually more responsive but I've personally been very busy the past few weeks.  
Seems Covid only added more work for me.

That said -- we are pretty open to getting pull requests from any of our code mirrors outlined below

https://trac.osgeo.org/postgis/wiki/CodeMirrors

Or as a Patch on our trac bug tracker.

For just issue reporting, we prefer that be done in Trac. 
https://trac.osgeo.org/postgis

If you have a pull request and didn't want to bother with trac, that's fine
, just will add a bit more work for us to assure it is noted in release.

Thanks,
Regina



> -----Original Message-----
> From: postgis-users [mailto:postgis-users-bounces at lists.osgeo.org] On
> Behalf Of Jaime Casanova
> Sent: Saturday, June 6, 2020 2:20 PM
> To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
> Subject: Re: [postgis-users] where to report bugs?
> 
> On Sat, 6 Jun 2020 at 11:34, Darafei "Kom?pa" Praliaskouski
> <me at komzpa.net> wrote:
> >
> > Hello,
> >
> > You followed the best practice to report it. Trac is officially a bug tracker.
> >
> > Best way to get it fixed is to stomp it into a Github pull request with
> minimized version of your case in regress suite.
> > Somewhere in here:
> https://github.com/postgis/postgis/tree/master/raster/test/regress - press
> "Edit" on a file and post a branch with that issue.
> > After that, commit it as a pull request. CI (Travis) will run it and produce a
> non-optimized backtrace. It usually helps a tiny bit more, letting you
> understand what went wrong through all the "optimized out"-s.
> >
> 
> interesting, you mean in addition to add it to trac? (i have received the
> mantra now)
> 
> > Reasons why your report is hanging for now are:
> >  - people have lives and postgis is a hobby;
> 
> maybe i'm just used to the response times in postgresql lists
> 
> >  - nobody really dug deep into raster codebase in last years, so you
> > have a perfect opportunity to become world's best expert;
> 
> sadly, i don't actually know to much about GIS. i'm doing this exercise by my
> own because some customers uses postgis and i prefer a system that doesn't
> crash in simple ways
> 
> >  - it's synthetic query by a tool designed to break stuff, meaning there's no
> human being that wrote that query who you can empathize with to get thing
> fixed.
> >
> 
> yes, you're right about the query being synthetic and sqlsmith being designed
> to break things in odd ways.
> 
> having said that, this normally results in finding spots that could result in hard
> to find errors.
> this example could have bite people that have nulls in a raster column.
> 
> > I've looked at your query and it looks like the whole report should have
> been just one line:
> >
> > select st_union(null::raster, 4);
> > server closed the connection unexpectedly
> >        This probably means the server terminated abnormally
> >        before or while processing the request.
> >
> 
> curious, i did try to simplify it more but when i removed the tablesample it
> didn't crash so i stoped there... but probably i had already made the change
> to check the null...
> 
> in my defense it was too late for me at the time ;)
> 
> 
> --
> Jaime Casanova                      www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-users