Re: No Issue Tracker - Say it Ain't So! - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: No Issue Tracker - Say it Ain't So!
Date
Msg-id CAHyXU0zPLbMEF7yT=hHtfpWVpb2cHYaTAJb_BeLvNBorydsFVA@mail.gmail.com
Whole thread Raw
In response to Re: No Issue Tracker - Say it Ain't So!  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Thu, Oct 1, 2015 at 12:09 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 10/01/2015 07:55 AM, Tom Lane wrote:
>> Playing devil's advocate ... would this really do much other than bloat
>> the release notes?  The entire assumption of this thread is that people
>> don't, or don't want to, use the release notes to find out what got fixed;
>> they'd rather search a tracker.
>
> It's not a question of "rather", it's a question of how searchable the
> release notes are, which is "not really at all".  Yes, you can scan the
> release notes for the latest update, but consider users who have an
> issue and are running 9.2.7.  Reasonably enough, they want to know that
> their issue is fixed in 9.2.13 (or in 9.4 if it turns out to be a
> feature, not a bug) before they ask their boss for a downtime.  Figuring
> that out now is really hard.

Yeah -- so maybe it's the wrong path.  The bugs/commits list are very
parse-able for important elements and should be able to be slurped
into a database for tracking and further insertion of metadata.  A
'commit tracker' if you will; it would organize commits and relevant
bug reports (so long as they could be linked by certain conventions).It's a read only system except for what other
humaninputs you'd want
 
to arrange for other processes (such as generating release notes which
might require cleaned up language).

merlin



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [DOCS] max_worker_processes on the standby
Next
From: Jeff Janes
Date:
Subject: Re: Potential GIN vacuum bug