Re: No Issue Tracker - Say it Ain't So!

On 24 September 2015 at 12:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I promised myself I'd stay out of this discussion, but ...
>
> Josh Berkus <josh(at)agliodbs(dot)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/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services