No Issue Tracker - Say it Ain't So!

Kam Lasater wrote:

I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.

If you install debbugs and feed it from our lists, maybe enough of us
would jump into the bandwagon enough to get it off the ground. I'm
unsure that it would work to maintain something that's too removed from
the mailing lists.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.

If you install debbugs and feed it from our lists, maybe enough of us
would jump into the bandwagon enough to get it off the ground. I'm
unsure that it would work to maintain something that's too removed from
the mailing lists.

Alvaro,

Thanks for the suggestion. However, an issue tracker is not a
replacement for mailing list(s) and vice versa. They are both
necessary for success.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Kam Lasater wrote:

I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.

If you install debbugs and feed it from our lists, maybe enough of us
would jump into the bandwagon enough to get it off the ground. I'm
unsure that it would work to maintain something that's too removed from
the mailing lists.

The difficulty with this is that someone has to actually offer up to
maintain it. Bug trackers do not maintain themselves.

Personally, I do like debbugs and it would likely be the least offensive
approch to those who ike the current mailing list. I don't know offhand
how much effort it would be to set up, perhaps I'll ask around.

Further, the distributions which most of our users use do have their own
bug trackers (Debian, Ubuntu, RedHat) which include tracking bugs in
PostgreSQL.

Thanks!

Stephen

On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater <ckl@seekayel.com> wrote:

Thanks for the suggestion. However, an issue tracker is not a
replacement for mailing list(s) and vice versa. They are both
necessary for success.

I venture to say that we are succeeding as it is, although of course
we might have more success if we did some things better, including
this. However, as Stephen says, the problem with an issue tracker is
that, unless some person or persons committed to keep it up to date,
it would just fill up with crap. We have an issue tracker for database
server issues here at EnterpriseDB, and keeping it up to date is a ton
of work. If nobody's volunteering to do that work in the PostgreSQL
community, an issue tracker is going to end up not being useful,
because it will just be wrong all the time.

If somebody does do the work, then we get to the next question: if we
had an accurate list of open bugs, would anybody who currently doesn't
work on fixing those bugs step up to help fix them? I hope so, but I
don't know. If not, we might not feel that the effort of maintaining
the bug tracker paid much of a dividend.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/23/2015 11:23 AM, Alvaro Herrera wrote:

Kam Lasater wrote:

I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.

If you install debbugs and feed it from our lists, maybe enough of us
would jump into the bandwagon enough to get it off the ground. I'm
unsure that it would work to maintain something that's too removed from
the mailing lists.

There needs to be community buy in on this idea else it is just a waste
of resources. The hackers need say, "Hey... you know, all those other
projects may be on to something. Perhaps we should learn from them and
do better by our users." This is more than just an issue/bug tracker
discussion. It is a ideology shift.

Until that happens asking anyone to put resources into this idea is just
not worth it.

Sincerely,

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/23/2015 11:33 AM, Stephen Frost wrote:

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:

Kam Lasater wrote:

I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also work.

If you install debbugs and feed it from our lists, maybe enough of us
would jump into the bandwagon enough to get it off the ground. I'm
unsure that it would work to maintain something that's too removed from
the mailing lists.

The difficulty with this is that someone has to actually offer up to
maintain it. Bug trackers do not maintain themselves.

If we integrate it into the process it gets easier. This is especially
true if we use a bug tracker that can be managed via email as well as a
web interface.

Sincerely,

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/23/2015 11:18 AM, Kam Lasater wrote:

At this point not having one is borderline negligent. I'd suggest:
Github Issues, Pivotal Tracker or Redmine (probably in that order).
There are tens to hundreds of other great ones out there, I'm sure one
of them would also work.

First, understand that the Postgres project was created before bug
trackers existed. And people are very slow to change their habits,
especially since not having a bug tracker was actually a benefit up
until around 2005. It's not anymore, but I'm sure people will argue
with my statement on that.

We have to use something OSS; open source projects depending on
closed-source infra is bad news. Out of what's available, I'd actually
choose Bugzilla; as much as BZ frustrates the heck out of me at times,
it's the only OSS tracker that's at all sophisticated.

The alternative would be someone building a sophisticated system on top
of RequestTracker, which would also let us have tight mailing list
integration given RT's email-driven model. However, that would require
someone with the time to build a custom workflow system and web UI on
top of RT. It's quite possible that Best Practical would be willing to
help here.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 09/23/2015 11:43 AM, Robert Haas wrote:

If somebody does do the work, then we get to the next question: if we
had an accurate list of open bugs, would anybody who currently doesn't
work on fixing those bugs step up to help fix them? I hope so, but I
don't know. If not, we might not feel that the effort of maintaining
the bug tracker paid much of a dividend.

I don't anticipate that getting additional bug fixers would be a benefit
of having a bug tracker, at least not in the first year. In fact, I
would say that we don't need a bug tracker to fix most significant bugs
at all. We're pretty good at that.

What we need a bug tracker for is:

1. so users and downstream projects know where to report bugs (and no,
our idiosyncratic bug form doesn't fit into anyone's workflow).

2. so that users know when a bug is fixed, and what release it's fixed
in, rather than depending on "ask someone on IRC".

3. so that we don't completely lose track of low-importance, hard-to-fix
bugs and trivial bugs, which we currently certainly do.

4. so that we can have a clearer idea more immediately that we've fixed
all known bugs in upcoming postgresql releases, instead of depending on
Bruce catching up on his email.

5. so that we have a place to track bugs which require hard, multi-step
fixes and don't lose track of some of the steps like we did with Multixact.

Those are the main reasons to have a BT. Offering a place for new
hackers to get started with trivial code fixes might be a side benefit,
but isn't a good enough reason to have one.

Obviously, everything said about "who's going to maintain this" is
completely valid.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* Josh Berkus (josh@agliodbs.com) wrote:

On 09/23/2015 11:18 AM, Kam Lasater wrote:

At this point not having one is borderline negligent. I'd suggest:
Github Issues, Pivotal Tracker or Redmine (probably in that order).
There are tens to hundreds of other great ones out there, I'm sure one
of them would also work.

First, understand that the Postgres project was created before bug
trackers existed. And people are very slow to change their habits,
especially since not having a bug tracker was actually a benefit up
until around 2005. It's not anymore, but I'm sure people will argue
with my statement on that.

We have to use something OSS; open source projects depending on
closed-source infra is bad news. Out of what's available, I'd actually
choose Bugzilla; as much as BZ frustrates the heck out of me at times,
it's the only OSS tracker that's at all sophisticated.

The alternative would be someone building a sophisticated system on top
of RequestTracker, which would also let us have tight mailing list
integration given RT's email-driven model. However, that would require
someone with the time to build a custom workflow system and web UI on
top of RT. It's quite possible that Best Practical would be willing to
help here.

Yeah, even if we got past the "do we want a bug tracker?" question, any
project would probably end up stalling indefinitely on "well then, which
one?"

In the end, we should probably just throw something up based on whatever
the folks who are going to be actually maintaining it want and call it a
'beta' and see what happens with it. The above-referenced individuals
would be the bug tracking system curators, of course. Unless it's got
serious technical issues, the infrastructure team will do our best to
support the choice. On the other hand, some of us would likely be
involved in bug curation also.

Thanks!

Stephen

We have to use something OSS; open source projects depending on
closed-source infra is bad news. Out of what's available, I'd actually
choose Bugzilla; as much as BZ frustrates the heck out of me at times,
it's the only OSS tracker that's at all sophisticated.

There are several OSS projects that use closed-source trackers.
I (personally) don't see a real problem with that. Atlassian offers free
hosting
for open source projects (I'm sure Postgres would qualify) and Confluence
Jira
is one of the best trackers I have worked with. I does have a mail gateway
were
issues can be created and maintained by sending emails (rather than editing
them in
the web front end)

They also support Postgres as their backend (and you do find hints here and
there
that it is the recommended open source DBMS for them - but they don't
explicitly state it like that). We are using Jira at the company I work for
and
all Jira installations run on Postgres there.

https://www.atlassian.com/software/views/open-source-license-request

Thomas

--
View this message in context: http://postgresql.nabble.com/No-Issue-Tracker-Say-it-Ain-t-So-tp5867020p5867046.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote:

Until that happens asking anyone to put resources into this idea is just not
worth it.

I wonder if you still have this conversation archived:

Date: Thu, 10 May 2007 11:30:55 -0400
From: Andrew Dunstan <andrew@dunslane.net>
To: "Joshua D. Drake", Magnus Hagander, Alvaro Herrera, Robert Treat, Lukas Smith, Andrew Sullivan, David Fetter
Subject: tracker

There was some very good input there -- it would be a shame to have to
repeat that all over again. Hey, it's only been 8 years ...

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

We have to use something OSS; open source projects depending on
closed-source infra is bad news. Out of what's available, I'd actually
choose Bugzilla; as much as BZ frustrates the heck out of me at times,
it's the only OSS tracker that's at all sophisticated.

Josh,

I'm not sure I agree here on the BT needing to be OSS. That said not
sure its my call :)

... The above-referenced individuals
would be the bug tracking system curators, of course. Unless it's got
serious technical issues, the infrastructure team will do our best to
support the choice. On the other hand, some of us would likely be
involved in bug curation also.

Stephen,

In digging around more I found this wiki page that seems to be the
closest thing to a BT: https://wiki.postgresql.org/wiki/Todo

Is the curation already being done? If the contents of that wiki page
were injected into a BT, would that be enough of a start?

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Kam,

* Kam Lasater (ckl@seekayel.com) wrote:

... The above-referenced individuals
would be the bug tracking system curators, of course. Unless it's got
serious technical issues, the infrastructure team will do our best to
support the choice. On the other hand, some of us would likely be
involved in bug curation also.

Stephen,

In digging around more I found this wiki page that seems to be the
closest thing to a BT: https://wiki.postgresql.org/wiki/Todo

Is the curation already being done? If the contents of that wiki page
were injected into a BT, would that be enough of a start?

If you look at what happens on the -bugs mailing list, you'll see very
quickly that a bug tracker and the Todo wiki page are very different.
Perhaps the Todo could be squeezed into a bug tracker, but many of the
items on there might well end up as 'wontfix' (to use the debbugs
lingo).

That is certainly not the same curation as what a BT would require.

Thanks!

Stephen

On Wed, Sep 23, 2015 at 11:43 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater <ckl@seekayel.com> wrote:

Thanks for the suggestion. However, an issue tracker is not a
replacement for mailing list(s) and vice versa. They are both
necessary for success.

I venture to say that we are succeeding as it is, although of course
we might have more success if we did some things better, including
this.

For whatever it is worth, one of the frustrations I've had with projects
(other than PostgreSQL) of which I am a casual users is that reporting a
single bug meant signing up for yet another account on yet another site and
learning yet another bug tracking system.

I think the email based system is more friendly for the casual user. You
don't even have to sign up for the bugs mail list as long as people keep
you CC'ed. I don't think that having a tracker just for the sake of having
one is going to attract new contributors.

I'd rather, say, put some more work into cleaning the kruft out of the
To-Do list, then put that effort into migrating the kruft to a fancier
filing cabinet.

Cheers,

Jeff

On 23 September 2015 at 22:07, Stephen Frost <sfrost@snowman.net> wrote:

* Josh Berkus (josh@agliodbs.com) wrote:

On 09/23/2015 11:18 AM, Kam Lasater wrote:

At this point not having one is borderline negligent. I'd suggest:
Github Issues, Pivotal Tracker or Redmine (probably in that order).
There are tens to hundreds of other great ones out there, I'm sure one
of them would also work.

First, understand that the Postgres project was created before bug
trackers existed. And people are very slow to change their habits,
especially since not having a bug tracker was actually a benefit up
until around 2005. It's not anymore, but I'm sure people will argue
with my statement on that.

We have to use something OSS; open source projects depending on
closed-source infra is bad news. Out of what's available, I'd actually
choose Bugzilla; as much as BZ frustrates the heck out of me at times,
it's the only OSS tracker that's at all sophisticated.

The alternative would be someone building a sophisticated system on top
of RequestTracker, which would also let us have tight mailing list
integration given RT's email-driven model. However, that would require
someone with the time to build a custom workflow system and web UI on
top of RT. It's quite possible that Best Practical would be willing to
help here.

Yeah, even if we got past the "do we want a bug tracker?" question, any
project would probably end up stalling indefinitely on "well then, which
one?"

In the end, we should probably just throw something up based on whatever
the folks who are going to be actually maintaining it want and call it a
'beta' and see what happens with it. The above-referenced individuals
would be the bug tracking system curators, of course. Unless it's got
serious technical issues, the infrastructure team will do our best to
support the choice. On the other hand, some of us would likely be
involved in bug curation also.

Thanks!

Stephen

Hi,
a couple of days ago I was reading through the tickets in the Django bug
tracker. It was much easier to find any information about the things to
work on than currently for Postgres.

From my point of view, for Postgres, there is just a not updated too often
list of things to implement on the wiki. If I need to find some additional
information, then I can find there just some links to mails from the mail
groups.

Then I need to read through the emails. This is not user friendly too, as I
need to click through the email tree, and if an email has multiple replies,
it is usually hard not to omit some of them, as after going into a reply, I
need to click to get to the parent mail again.

What's more, there are some things on the wiki, and when I asked about
that, it turned out that "oh, there was some discussion long time ago, that
it is not doable".

It would be also worth storing the information that someone is working on
something, so the work won't be doubled.

Personally I'd also change sending patches in emails to github pull
requests :).

... or maybe the difference is more in the data structure, the email
discussion is a tree (with a horrible interface to the archive) while in a
bug tracker, the discussion is linear, and easier to follow.

--
regards Szymon Lipiński

Jeff Janes wrote:

For whatever it is worth, one of the frustrations I've had with projects
(other than PostgreSQL) of which I am a casual users is that reporting a
single bug meant signing up for yet another account on yet another site and
learning yet another bug tracking system.

Right.

I think the email based system is more friendly for the casual user. You
don't even have to sign up for the bugs mail list as long as people keep
you CC'ed. I don't think that having a tracker just for the sake of having
one is going to attract new contributors.

Yay, another vote for debbugs!

I'd rather, say, put some more work into cleaning the kruft out of the
To-Do list, then put that effort into migrating the kruft to a fancier
filing cabinet.

Casual users would need a community account in order to file bugs in the
Todo wiki page. I don't think a wiki page qualifies (by a long mile) as
a bug tracker, anyway.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Sep 23, 2015 at 5:00 PM, Stephen Frost <sfrost@snowman.net> wrote:

Kam,

* Kam Lasater (ckl@seekayel.com) wrote:

... The above-referenced individuals
would be the bug tracking system curators, of course. Unless it's got
serious technical issues, the infrastructure team will do our best to
support the choice. On the other hand, some of us would likely be
involved in bug curation also.

Stephen,

In digging around more I found this wiki page that seems to be the
closest thing to a BT: https://wiki.postgresql.org/wiki/Todo

Is the curation already being done? If the contents of that wiki page
were injected into a BT, would that be enough of a start?

If you look at what happens on the -bugs mailing list, you'll see very
quickly that a bug tracker and the Todo wiki page are very different.
Perhaps the Todo could be squeezed into a bug tracker, but many of the
items on there might well end up as 'wontfix' (to use the debbugs
lingo).

That is certainly not the same curation as what a BT would require.

​To put it a bit differently what kind of mechanism is going to exist to
ensure that the BT doesn't simply become a "wish list" of new features? It
will be much easier for people to simply post to it instead of adding an
entry on the Todo wiki page.

Instead of curation I'd be curious if others have tried to institute
gate-keeping such that end-users still have to post to -bugs and only
authorized persons can convert (forward?) those into actual bug reports.

David J.

Szymon Lipiński wrote:

Then I need to read through the emails. This is not user friendly too, as I
need to click through the email tree, and if an email has multiple replies,
it is usually hard not to omit some of them, as after going into a reply, I
need to click to get to the parent mail again.

Evidently, the "flat" link is easy to miss. Give it a try.

The bug tracker is not intended as a feature-request tracker, anyway.
Those two things are very different, even if many projects just conflate
the two things.

Personally I'd also change sending patches in emails to github pull
requests :).

That won't happen, at least not this decade.

... or maybe the difference is more in the data structure, the email
discussion is a tree (with a horrible interface to the archive) while in a
bug tracker, the discussion is linear, and easier to follow.

FWIW in my opinion our mailing list archives interface is the best there
is --- and I disagree that the linear discussion is easy to follow,
except for trivial discussions.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Sep 23, 2015 at 5:10 PM, Szymon Lipiński <mabewlun@gmail.com> wrote:

On 23 September 2015 at 22:07, Stephen Frost <sfrost@snowman.net> wrote:

* Josh Berkus (josh@agliodbs.com) wrote:

On 09/23/2015 11:18 AM, Kam Lasater wrote:

At this point not having one is borderline negligent. I'd suggest:
Github Issues, Pivotal Tracker or Redmine (probably in that order).
There are tens to hundreds of other great ones out there, I'm sure one
of them would also work.

First, understand that the Postgres project was created before bug
trackers existed. And people are very slow to change their habits,
especially since not having a bug tracker was actually a benefit up
until around 2005. It's not anymore, but I'm sure people will argue
with my statement on that.

We have to use something OSS; open source projects depending on
closed-source infra is bad news. Out of what's available, I'd actually
choose Bugzilla; as much as BZ frustrates the heck out of me at times,
it's the only OSS tracker that's at all sophisticated.

The alternative would be someone building a sophisticated system on top
of RequestTracker, which would also let us have tight mailing list
integration given RT's email-driven model. However, that would require
someone with the time to build a custom workflow system and web UI on
top of RT. It's quite possible that Best Practical would be willing to
help here.

Yeah, even if we got past the "do we want a bug tracker?" question, any
project would probably end up stalling indefinitely on "well then, which
one?"

In the end, we should probably just throw something up based on whatever
the folks who are going to be actually maintaining it want and call it a
'beta' and see what happens with it. The above-referenced individuals
would be the bug tracking system curators, of course. Unless it's got
serious technical issues, the infrastructure team will do our best to
support the choice. On the other hand, some of us would likely be
involved in bug curation also.

Thanks!

Stephen

Hi,
a couple of days ago I was reading through the tickets in the Django bug
tracker. It was much easier to find any information about the things to
work on than currently for Postgres.

​TBH, if you want to work on PostgreSQL and are not sure where to best
contribute you should actually two-way communicate​ with the people
actively involved. If you know what you want to work on you likewise
should propose something reasonably concrete for discussion. The other
resources are solid and do reflect past ideas and desires and while they do
make a good starting point unless you have a personal interest in the topic
putting the question out to the lists will gauge how necessary the
community deems the feature at this moment in time.

From my point of view, for Postgres, there is just a not updated too often

list of things to implement on the wiki. If I need to find some additional
information, then I can find there just some links to mails from the mail
groups.

Then I need to read through the emails. This is not user friendly too, as
I need to click through the email tree, and if an email has multiple
replies, it is usually hard not to omit some of them, as after going into a
reply, I need to click to get to the parent mail again.

​Yes, people are not particularly inclined to put a lot of effort into
organizing pure ideas. The emails that are out there are probably of more
use to the people that wrote and read them originally than to someone
coming in fresh. In many cases they were never written to be primary
sources.​

What's more, there are some things on the wiki, and when I asked about
that, it turned out that "oh, there was some discussion long time ago, that
it is not doable".

​So we should constantly manage the entire Todo list because occasionally
someone shows interest in a couple of items that appear on it that were
already declared "not doable" some time in the past? This doesn't seem
efficient or likely. The Todo list is an idea generator, not project
management.
​

It would be also worth storing the information that someone is working on
something, so the work won't be doubled.

The ​Commitfest interface, basically.​

​David J.​