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

From Simon Riggs
Subject Re: No Issue Tracker - Say it Ain't So!
Date
Msg-id CANP8+j+5RyyzdgUrQqPnkeXg-w6RemRuULhBQA=-pPJuUkOtZw@mail.gmail.com
Whole thread Raw
In response to Re: No Issue Tracker - Say it Ain't So!  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: No Issue Tracker - Say it Ain't So!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 24 September 2015 at 12:16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I promised myself I'd stay out of this discussion, but ...

Josh Berkus <josh@agliodbs.com> writes:
> I know we're big on reinventing the wheel here, but it would really be a
> better idea to use an established product than starting over from
> scratch. Writing a bug tracker is a lot of work and maintenance.

Yeah; "let's write our own bug tracker" is a good way to make sure nothing
comes of this.  On the other hand, "let's get all the Postgres hackers to
change their habits" is an equally good way to make sure nothing comes of
this.  (We tried that once already, with I-forget-which tracker; the
results were, um, forgettable.)  I think the only approach that has any
chance of success is to connect up some existing tracker software to more
or less our existing work patterns.  So somebody who wants to make this
happen needs to sit down and do that.

FWIW, I concur with the opinions that it needs to be an OSS tracker.
This project has been around for twenty years and I have every expectation
that it will survive for another twenty.  I have no confidence in any
closed-source product still being available (and free) in 2035.  We need
something with an active development/support community, too, so it doesn't
end up being us supporting it on our ownsome ten years out.  Other than
that, I'm agnostic as to what gets picked.

Every application comes with its own presumed workflow. All implementations of third party software include tailoring to the specific workflow to meet the business requirement. (Which is...???)

I'm not at all concerned about what software we use for things, but I am not in favour of adopting a new workflow, especially one that carries with it certain presumptions that are not in fact true or even close, for us.

When a bug gets identified, the "assign to" function isn't going to work well here. Who has the right to assign? Who has the duty to be assigned? Especially when somebody starts talking about SLAs because then we'll be talking about clocking-in etc.. That looks like a long and unpleasant discussion to me, one that involves people that don't write code laying down the rules for people that do, driven by rules implicit within a particular package. Will we change our process every time the package version changes? What happens if our process changes and the package does not?

Writing or heavily adapting software that follows our way of working is actually the only way this can ever succeed, like it has for CF app.

I have frequently been the agent of change in matters of process, but I see no useful change here, just lots of wasted time. But then why are we even talking about change? What thing is broken that needs to be fixed? Why is adopting a new package a fix for that?

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: Less than ideal error reporting in pg_stat_statements
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Fix an O(N^2) problem in foreign key references.