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

[Bruce Momjian]

On Wed, Jan  6, 2016 at 03:18:49PM -0500, Robert Haas wrote:
> On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob  wrote:
> > I also think a list of small things suitable for new contributors
> > would help attracting them. Not all would stick and go on to larger
> > items but hopefully at least some would.
> 
> I agree with this.  Curating such a list is a fair amount of work that
> somebody's got to do, though.  The TODO list is full of an awful lot
> of things that don't matter and missing an awful lot of things that
> do.

So, if that is true, and people are not improving the TODO list
situation, how likely will a bug tracker be at improving or
deteriorating the situation?

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +


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

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

[Magnus Hagander]

On Mon, Jan 11, 2016 at 4:31 AM, Joshua D. Drake 
wrote:

> On 01/10/2016 06:19 PM, Robert Haas wrote:
>
> [snip]
>
> No arguments with what was written above.


+1. Very well written.



>
>
> If we had an "issue" tracker rather than a bug tracker, I'd expect a
>> lot more unproductive bickering.
>>
>
> This I disagree with. It wouldn't be any worse than we have now. An issue
> tracker (if it is a good one) becomes the forum, whether you use an email
> or web interface. So expect at least as much banter as there is on lists
> but with a much easier management interface.
>
>
We can argue about if it's actually an easier management interface ;)

I'd agree with Robert in that it will cause some more such bickering -- but
only because the discussions become visible to a new group of people as
well. That's not necessarily a bad thing. But thinking that having such an
issue tracker is actually going to help *get rid of* the pointless part of
things is a nice dream, but just a dream. The only advantage I can see of
it is to increase the visibility of them.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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

[Joshua D. Drake]

On 01/11/2016 03:31 AM, Magnus Hagander wrote:



We can argue about if it's actually an easier management interface ;)


(as long as it is manageable via email as well as web?)



I'd agree with Robert in that it will cause some more such bickering --
but only because the discussions become visible to a new group of people
as well. That's not necessarily a bad thing. But thinking that having
such an issue tracker is actually going to help *get rid of* the
pointless part of things is a nice dream, but just a dream. The only
advantage I can see of it is to increase the visibility of them.


Oh, I think you are right there. My point is that we have the ability to 
better manage that inforomation. We can mark something as a bug, feature 
request, approved feature, feature in development etc... Things become 
much more contextually aware.


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

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

[Robert Haas]

On Fri, Jan 8, 2016 at 3:37 AM, Magnus Hagander  wrote:
>> /me waves hand
>>
>> There are quite a few contributing companies that likely have people that
>> could help out with this in an educated fashion but aren't coders.
>
> Sort of like how they could also have helped out with cf management?

I agree with this sentiment.  But let me also say this: managing a
CommitFest well is a Hard Job.  It takes a very sizable amount of
time, a fair amount of technical knowledge, and an awful lot of
emotional energy.  It's a completely thankless task: if you do it
well, some people are unhappy because their patches got bumped; if you
do it poorly, other people (or the same ones) are unhappy because the
CommitFest lasted too long.  If you use the wrong tone in writing an
email to somebody, they will flame you as if you were trying to hurt
them rather than, as is actually the case, trying to help the
community.  And you can't make anybody do anything: if not enough
reviewers turn up, or not enough committers turn up, you will fail,
even if you do everything right.  Something under half of the attempts
to do this over the years have succeeded brilliantly (at least, IMHO);
many others have been indifferent successes or else failures, despite
the attempts having been made by community members of long standing.
It's just a really tough problem - you've got to be a combination
motivational speaker, technical whiz, diplomat, and organizational
guru to succeed.

It's unclear to me whether administering the bug tracker would be an
easier job or not.  I think it would probably be somewhat easier.
There's probably not a lot that's real subjective about deciding which
bugs we fixed and which ones we're not gonna fix.  I think the biggest
problem would likely be that we might occasionally have cases where
somebody submits something and somebody from the community replies to
say "we don't really care" and then the bug gets closed and the
submitter gets an email and goes ballistic, and unproductive arguing
ensues.  It will be important to have an understanding that the person
updating the tracker is merely trying to make it reflect the expressed
will of the community, not trying to determine that will.  If somebody
disagrees with the status applied to the bug, they should argue with
the community members who said "we don't care", not the person who set
the status to won't-fix.

If we had an "issue" tracker rather than a bug tracker, I'd expect a
lot more unproductive bickering.  The consensus around which features
are worth having changes frequently, and a lot of features that nobody
desperately objects to are nevertheless awfully low-value and not
worth tracking until somebody comes up with a patch.  Development of
feature X often changes the perceived value of feature Y, sometimes in
a positive way and sometimes in a negative way.  I don't really have
any use for a system that's just a random collection of things
somebody wanted at some point, which is basically what the TODO list
is.  A list of unfixed bugs, though, sounds like it might have real
utility, particularly if we got some volunteers to apply tags to them
so we could search for "multixact" or whatever.

-- 
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

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

[Joshua D. Drake]

On 01/10/2016 06:19 PM, Robert Haas wrote:

[snip]

No arguments with what was written above.


If we had an "issue" tracker rather than a bug tracker, I'd expect a
lot more unproductive bickering.


This I disagree with. It wouldn't be any worse than we have now. An 
issue tracker (if it is a good one) becomes the forum, whether you use 
an email or web interface. So expect at least as much banter as there is 
on lists but with a much easier management interface.


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

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

[Merlin Moncure]

On Fri, Jan 8, 2016 at 7:12 AM, Greg Stark  wrote:
> This really sounds like you're looking for leverage to fix one problem
> by finding other problems that you hope to solve with the same hammer.
> That's a recipe for a tool that solves neither problem well and gets
> ignored by the both sets of users.

+1

merlin


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

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

[Magnus Hagander]

On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake 
wrote:

> On 01/07/2016 12:32 PM, Jim Nasby wrote:
>
>> On 1/7/16 1:49 PM, Josh Berkus wrote:
>>
>>> Yeah, we could also get rid of this conversation:
>>>
>>> "Here's a patch for X, which is on the TODO list"
>>>
>>> "Oh, we've obsolesced that, that was added to the TODO before we had Y"
>>>
>>> ... by auto-closing TODO items at a certain age.
>>>
>>
>> Even if not auto-closed at least it'd be easy to find old items.
>>
>> Bonus points if we attract some volunteer project managers that will
>> keep tabs of all those kinds of things...
>>
>
> /me waves hand
>
> There are quite a few contributing companies that likely have people that
> could help out with this in an educated fashion but aren't coders.


Sort of like how they could also have helped out with cf management?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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

[Jim Nasby]

On 1/8/16 9:07 AM, Tom Lane wrote:

Dunno about that.  While a CF manager doesn't necessarily have to have
a commit bit, I think he/she probably does have to be someone who is known
and respected on the -hackers list.  Otherwise, nagging to finish patches
is likely to be ignored or even counterproductive.


IMHO that touches on the core issue here. JD and anyone else can offer 
up all the resources under the sun, but *it's up to the community to 
decide to use them*. In this specific case, if the community agrees that 
someone that's not a code contributor will be the CFM for a specific CF 
then I think it would work fine. Short of that, your observation might 
be very accurate.


I feel a bit bad about some of the emails I've sent on this and related 
topics because it feels hand-wavy, but I don't know what else to do. I 
can promote these ideas that I think will be very helpful, but without a 
strong consensus in the community that it's desirable any efforts will 
probably fail.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Greg Stark]

On Thu, Jan 7, 2016 at 6:30 PM, Jeff Janes  wrote:
> I don't completely agree with that.  I have often wanted to know when
> a specific item was added to the TODO page, and/or its individual edit
> history.

Sure, there might be other things it would be better at. But my point
is that it would have the same problem as the wiki in that it would
accumulate vague ideas that someone thought was a good idea once but
didn't have a good idea how to implement or a compelling argument that
convinced others to work on it.

The wiki is the lowest overhead and highest visibility way of
maintaining communal information. Bug trackers exist to impose extra
structure to match an intended workflow. That's fine for bugs or a
closely managed project but it's the last thing you want if you're
trying to get more people to contribute. The whole selling points of
wikis is that they draw in contributors because anyone can edit
easily.

This really sounds like you're looking for leverage to fix one problem
by finding other problems that you hope to solve with the same hammer.
That's a recipe for a tool that solves neither problem well and gets
ignored by the both sets of users.

-- 
greg


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

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

[Tom Lane]

Magnus Hagander  writes:
> On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake 
>> There are quite a few contributing companies that likely have people that
>> could help out with this in an educated fashion but aren't coders.

> Sort of like how they could also have helped out with cf management?

Dunno about that.  While a CF manager doesn't necessarily have to have
a commit bit, I think he/she probably does have to be someone who is known
and respected on the -hackers list.  Otherwise, nagging to finish patches
is likely to be ignored or even counterproductive.

regards, tom lane


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

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

[Magnus Hagander]

On Fri, Jan 8, 2016 at 4:07 PM, Tom Lane  wrote:

> Magnus Hagander  writes:
> > On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake 
> >> There are quite a few contributing companies that likely have people
> that
> >> could help out with this in an educated fashion but aren't coders.
>
> > Sort of like how they could also have helped out with cf management?
>
> Dunno about that.  While a CF manager doesn't necessarily have to have
> a commit bit, I think he/she probably does have to be someone who is known
> and respected on the -hackers list.  Otherwise, nagging to finish patches
> is likely to be ignored or even counterproductive.
>

I realize now that I caught JDs response slightly out of context. I thought
we were talking issue/bugtracker, in which case I think that is needed just
as much as it is for a CF manager. As it's basically the same thing just at
a different stage.

But that one seems to be more about keeping the todo list on the wiki up to
date, in which case I agree, not as much is needed. Because it's more
reflecting what's happened, rather than trying to manage process.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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

[Joshua D. Drake]

On 01/06/2016 04:18 PM, Greg Stark wrote:

On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby  wrote:

Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
An issue tracker would make maintaining items like this a lot more
reasonable, but it certainly wouldn't be free.


Eh, a bug tracker that tracks actual bugs would be useful, I don't
think anyone would argue with that. A vague "issue" tracker that just
collects ideas people have had that seemed like a good idea at some
time in history would suffer exactly the same problem the TODO has.


Not if it was probably integrated it wouldn't. The problem with the TODO 
is that it is in no mans land of the wiki and there is ZERO structure to it.


The wiki is the nosql of the postgresql community. ;)

With an issue tracker you can say:

This is a IN PROGRESS TODO
This is an APPROVED TODO
This is a ISSUE
-> BUG CONFIRMED
-> USER ERROR

etc

And if the right software is used, it can all be done via email AND can 
be tracked a hell of a lot easier than the way we track everything 
(literally) now. It is a hell of a lot easier to say:


See #53466

Than every alternative we currently have.

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

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

[Jim Nasby]

On 1/7/16 1:49 PM, Josh Berkus wrote:

Yeah, we could also get rid of this conversation:

"Here's a patch for X, which is on the TODO list"

"Oh, we've obsolesced that, that was added to the TODO before we had Y"

... by auto-closing TODO items at a certain age.


Even if not auto-closed at least it'd be easy to find old items.

Bonus points if we attract some volunteer project managers that will 
keep tabs of all those kinds of things...

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Jeff Janes]

On Wed, Jan 6, 2016 at 4:18 PM, Greg Stark  wrote:
> On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby  wrote:
>> Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
>> An issue tracker would make maintaining items like this a lot more
>> reasonable, but it certainly wouldn't be free.
>
> Eh, a bug tracker that tracks actual bugs would be useful, I don't
> think anyone would argue with that. A vague "issue" tracker that just
> collects ideas people have had that seemed like a good idea at some
> time in history would suffer exactly the same problem the TODO has.

I don't completely agree with that.  I have often wanted to know when
a specific item was added to the TODO page, and/or its individual edit
history.  With only a unified history of the entire TODO page, and
with no wiki equivalent of "git blame", figuring this out is extremely
tedious.  A tracker would precisely solve this problem, if nothing
else.  And when I edit the wiki and forget to make a coherent edit
summary, there is no way to fix that, while presumably an issue
tracker would be more tolerant of people's imperfections.

It could also be ameliorated without a tracker by people being more
disciplined about linking to the email archives, but evidently we are
not disciplined enough to do that reliably enough.  I think we are
better about that recently than we were in the past, but without the
ability to readily see when an item was added, it is hard to go back
and find the emails to fix the past mistakes.

But, if we want a list of projects for beginners, I think it has to be
explicitly that.  A list of things an experienced expert could do
trivially, but are consciously refraining from doing so that a
beginner can do them instead.  It would need to be separate from a "we
can't decide if we want this or can't decide how to do it or don't
have the time to do it" list.  There is no reason we have to have an
issue tracker in order to create that separation, but it could help.

Cheers,

Jeff


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

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

[Josh Berkus]

On 01/07/2016 10:30 AM, Jeff Janes wrote:
> I don't completely agree with that.  I have often wanted to know when
> a specific item was added to the TODO page, and/or its individual edit
> history.  With only a unified history of the entire TODO page, and
> with no wiki equivalent of "git blame", figuring this out is extremely
> tedious.  A tracker would precisely solve this problem, if nothing
> else.  And when I edit the wiki and forget to make a coherent edit
> summary, there is no way to fix that, while presumably an issue
> tracker would be more tolerant of people's imperfections.

Yeah, we could also get rid of this conversation:

"Here's a patch for X, which is on the TODO list"

"Oh, we've obsolesced that, that was added to the TODO before we had Y"

... by auto-closing TODO items at a certain age.

-- 
Josh Berkus
Red Hat OSAS
(opinions are my own)


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

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

[Joshua D. Drake]

On 01/07/2016 12:32 PM, Jim Nasby wrote:

On 1/7/16 1:49 PM, Josh Berkus wrote:

Yeah, we could also get rid of this conversation:

"Here's a patch for X, which is on the TODO list"

"Oh, we've obsolesced that, that was added to the TODO before we had Y"

... by auto-closing TODO items at a certain age.


Even if not auto-closed at least it'd be easy to find old items.

Bonus points if we attract some volunteer project managers that will
keep tabs of all those kinds of things...


/me waves hand

There are quite a few contributing companies that likely have people 
that could help out with this in an educated fashion but aren't coders.



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

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

[Catalin Iacob]

On Wed, Jan 6, 2016 at 3:11 AM, Jim Nasby  wrote:
> Which doesn't help anyone, because neither of those provide a list of "hey,
> here's stuff you could do to contribute". The closest we come to that is the
> TODO, which isn't well known and has almost no items for newbies (and the
> newbie items that are there don't offer much advice).
>
> The reason I this matters is because yesterday I posted a task for a new
> hacker with simple guidelines and 24 hours later it was completed[1]. That
> tells me there's people that would love to contribute but don't know how or
> what to contribute.

Jim,

I want to explicitly thank you for your post about that task, I would
like to see more of that. I share the sentiment that there are more
people wanting to contribute but finding it rather hard to find a
starting point. I was (am?) in that position and so far found two ways
out:

1. I looked at the commit fest patches as a list of things to
contribute to (by doing a review which is currently in progress)
2. Robert at some point mentioned in an email "someone could improve
the docs in this patch" so I did that

But I can see that 1. is intimidating to do for new people that might
think "how can you review without ever having looked at the code
before?". Turns out you can and the wiki mentions it explicitly but
it's probably still intimidating for some. And 2. required noticing
Robert's sentence in the middle of a long email thread.

I also think a list of small things suitable for new contributors
would help attracting them. Not all would stick and go on to larger
items but hopefully at least some would.


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

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

[Joshua D. Drake]

On 01/06/2016 03:57 PM, Jim Nasby wrote:

On 1/6/16 5:51 PM, Tom Lane wrote:

Having said that, it occurs to me that one way to contribute without
actually writing C code would be to try to drive those unfinished
discussions to consensus, and come up with specs for features that people
agree are well-thought-out.  Conversely, establishing a consensus that a
proposal is a bad idea and it should go away from the list would be a
useful activity.


+1.

Somewhat related to that, I don't believe there's any reason why commit
fest managers need to be committers; it seems like the job is really
just about reading through email activity to see where things are at.


Agreed. That is a great way for people to contribute that aren't "hackers".

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

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

[Tom Lane]

Jim Nasby  writes:
> Somewhat related to that, I don't believe there's any reason why commit 
> fest managers need to be committers; it seems like the job is really 
> just about reading through email activity to see where things are at.

They don't need to be.  Michael Paquier did a fine job with the last CF.

regards, tom lane


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

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

[Peter Geoghegan]

On Wed, Jan 6, 2016 at 3:51 PM, Tom Lane  wrote:
> Yeah.  The other problem is that stuff that's actually small doesn't tend
> to hang around undone for long, so there's not really a broad array of
> stuff just waiting for someone to have a little time.  If we had a more
> actively maintained TODO list, it would largely contain (a) stuff that
> there's insufficient consensus on, and (b) stuff that's just big mean and
> nasty to implement.

I think that some friendly advice to less experienced contributors
about a good project for them to work on is enormously valuable, which
is why I try to do that whenever I can. Unfortunately, and perversely,
the TODO list is pretty far from that. Things go on the todo list
because they don't have a favorable cost/benefit ratio. I wouldn't
suggest a project to anyone that I would not be willing to work on
myself, which excludes most items on the TODO list.

-- 
Peter Geoghegan


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

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

[Michael Paquier]

On Thu, Jan 7, 2016 at 9:28 AM, Tom Lane  wrote:
> Jim Nasby  writes:
>> Somewhat related to that, I don't believe there's any reason why commit
>> fest managers need to be committers; it seems like the job is really
>> just about reading through email activity to see where things are at.
>
> They don't need to be.

More thoughts on that. I would even think the contrary, someone who
has just monitored for 1/2 years -hackers and knowing how things are
handled would be able to do this job as well, the only issue being to
juggle with many threads at the same time, to be sure that each patch
status is correct, and to not lose motivation during the CF. The last
one is the hardest by far.
-- 
Michael


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

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

[Jim Nasby]

On 1/6/16 9:22 PM, Michael Paquier wrote:

On Thu, Jan 7, 2016 at 9:28 AM, Tom Lane  wrote:

Jim Nasby  writes:

Somewhat related to that, I don't believe there's any reason why commit
fest managers need to be committers; it seems like the job is really
just about reading through email activity to see where things are at.


They don't need to be.


More thoughts on that. I would even think the contrary, someone who
has just monitored for 1/2 years -hackers and knowing how things are
handled would be able to do this job as well, the only issue being to
juggle with many threads at the same time, to be sure that each patch
status is correct, and to not lose motivation during the CF. The last
one is the hardest by far.


Sorry, I inadvertently used 'committer' when I should have said 'coder'. 
There's nothing code related about CFM, and I think it's a dis-service 
to the community to have coders serving that role.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Jim Nasby]

On 1/6/16 6:18 PM, Greg Stark wrote:

On Wed, Jan 6, 2016 at 11:42 PM, Jim Nasby  wrote:

Right. Personally, I feel the TODO has pretty much outlived it's usefulness.
An issue tracker would make maintaining items like this a lot more
reasonable, but it certainly wouldn't be free.


Eh, a bug tracker that tracks actual bugs would be useful, I don't
think anyone would argue with that. A vague "issue" tracker that just
collects ideas people have had that seemed like a good idea at some
time in history would suffer exactly the same problem the TODO has.


I think one of the biggest hurdles people face is getting the community 
to agree that something is a desired feature. So if there was a list of 
things that the community had agreed would be good I think that itself 
would be useful. Even better if items had a rough outline of the work 
necessary.


Obviously that won't do too much for really big features. But if our 
experienced hackers focused less on coding and more on design and 
creating smaller tasks that people could work on, more people could 
potentially be put to work.


ISTM that the design work needs to be done and documented no matter 
what, so there shouldn't be much overhead there. The overhead would be 
in maintaining the tracker and making sure folks were actively getting 
stuff done. That can be done by a non-coder. That means it shouldn't 
really cost the community much in terms of current resources, as long as 
we attract new people to take on these new tasks.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Jim Nasby]

On 1/6/16 2:18 PM, Robert Haas wrote:

On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob  wrote:

I also think a list of small things suitable for new contributors
would help attracting them. Not all would stick and go on to larger
items but hopefully at least some would.


I agree with this.  Curating such a list is a fair amount of work that
somebody's got to do, though.  The TODO list is full of an awful lot
of things that don't matter and missing an awful lot of things that
do.


Right. Personally, I feel the TODO has pretty much outlived it's 
usefulness. An issue tracker would make maintaining items like this a 
lot more reasonable, but it certainly wouldn't be free.


Something else to consider though: I sent one email and the task was 
done in 24 hours. For things that can be well defined and are fairly 
mechanical, I suspect an email to hackers with a big [NEW HACKER] banner 
would do wonders.


Related to that is JD's offer to donate staff time to infrastructure 
work. There's probably a fair amount of things that could be "farmed 
out" that way. Some folks in the community proper would still need to 
keep tabs on things, but they wouldn't have to do the gruntwork. If, 
say, the Ops teams at 2nd Quadrant, CMD, and EDB wanted to work together 
on improving infrastructure, that's pretty much community at that point, 
and not a dependence on a single external entity.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Tom Lane]

Robert Haas  writes:
> On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob  wrote:
>> I also think a list of small things suitable for new contributors
>> would help attracting them. Not all would stick and go on to larger
>> items but hopefully at least some would.

> I agree with this.  Curating such a list is a fair amount of work that
> somebody's got to do, though.  The TODO list is full of an awful lot
> of things that don't matter and missing an awful lot of things that
> do.

Yeah.  The other problem is that stuff that's actually small doesn't tend
to hang around undone for long, so there's not really a broad array of
stuff just waiting for someone to have a little time.  If we had a more
actively maintained TODO list, it would largely contain (a) stuff that
there's insufficient consensus on, and (b) stuff that's just big mean and
nasty to implement.

Having said that, it occurs to me that one way to contribute without
actually writing C code would be to try to drive those unfinished
discussions to consensus, and come up with specs for features that people
agree are well-thought-out.  Conversely, establishing a consensus that a
proposal is a bad idea and it should go away from the list would be a
useful activity.

regards, tom lane


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

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

[Robert Haas]

On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob  wrote:
> I also think a list of small things suitable for new contributors
> would help attracting them. Not all would stick and go on to larger
> items but hopefully at least some would.

I agree with this.  Curating such a list is a fair amount of work that
somebody's got to do, though.  The TODO list is full of an awful lot
of things that don't matter and missing an awful lot of things that
do.

-- 
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

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

[Alvaro Herrera]

Joshua D. Drake wrote:
> On 01/05/2016 04:53 PM, Michael Paquier wrote:
> >On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake  
> >wrote:

> >>linuxhiker:  git interface! Bug tracker for this anywhere?
> >
> >Potential answer: Yes. As of now, pgsql-docs for doc issues, and
> >pgsql-bugs for actual bugs :)
> 
> Yes but that is a horrible answer.

I wouldn't even call that an answer actually.  To me, that just means
"no, we don't have one", which is kinda sad.

-- 
Álvaro Herrerahttp://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

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

[Joshua D. Drake]

Hello,

So I was on #postgresql today. I convinced a newer user that they could 
easily contribute to PostgreSQL even if it was just doc patches. I 
described the basic workflow and the individual was excited.


His first question?

linuxhiker:  git interface! Bug tracker for this anywhere?

Joshua D. Drake

--
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

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

[Michael Paquier]

On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake  wrote:
> Hello,
>
> So I was on #postgresql today. I convinced a newer user that they could
> easily contribute to PostgreSQL even if it was just doc patches. I described
> the basic workflow and the individual was excited.
>
> His first question?
>
> linuxhiker:  git interface! Bug tracker for this anywhere?

Potential answer: Yes. As of now, pgsql-docs for doc issues, and
pgsql-bugs for actual bugs :)
-- 
Michael


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

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

[Jim Nasby]

On 1/5/16 6:53 PM, Michael Paquier wrote:

On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake  wrote:

So I was on #postgresql today. I convinced a newer user that they could
easily contribute to PostgreSQL even if it was just doc patches. I described
the basic workflow and the individual was excited.

His first question?

linuxhiker:  git interface! Bug tracker for this anywhere?


Potential answer: Yes. As of now, pgsql-docs for doc issues, and
pgsql-bugs for actual bugs :)


Which doesn't help anyone, because neither of those provide a list of 
"hey, here's stuff you could do to contribute". The closest we come to 
that is the TODO, which isn't well known and has almost no items for 
newbies (and the newbie items that are there don't offer much advice).


The reason I this matters is because yesterday I posted a task for a new 
hacker with simple guidelines and 24 hours later it was completed[1]. 
That tells me there's people that would love to contribute but don't 
know how or what to contribute.


I realize a tracker *by itself* won't solve that, but it is the first 
place anyone that wants to contribute code is likely to look. So having 
one makes it more likely that new people will contribute.


On a related note, anyone interested in growing the community should 
take a look at [2]. tl;dr: best way to grow the community is to attract 
some folks that will make growing it their priority.


[1] http://www.postgresql.org/message-id/568ada20.7090...@bluetreble.com
[2] http://www.postgresql.org/message-id/568c6e6d.1040...@bluetreble.com
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Joshua D. Drake]

On 01/05/2016 04:53 PM, Michael Paquier wrote:

On Wed, Jan 6, 2016 at 7:32 AM, Joshua D. Drake  wrote:

Hello,

So I was on #postgresql today. I convinced a newer user that they could
easily contribute to PostgreSQL even if it was just doc patches. I described
the basic workflow and the individual was excited.

His first question?

linuxhiker:  git interface! Bug tracker for this anywhere?


Potential answer: Yes. As of now, pgsql-docs for doc issues, and
pgsql-bugs for actual bugs :)


Yes but that is a horrible answer.

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

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

[Stephen Frost]

Jim, all,

* Jim Nasby (jim.na...@bluetreble.com) wrote:
> Which doesn't help anyone, because neither of those provide a list
> of "hey, here's stuff you could do to contribute". The closest we
> come to that is the TODO, which isn't well known and has almost no
> items for newbies (and the newbie items that are there don't offer
> much advice).

Agreed.  I've not given up on the bugs.p.o project, but I've gotten
wrapped up in migrating the buildfarm server on to our infrastructure.
Hopefully that will be completed as early as this week and I'll be able
to refocus my infra time to finishing bugs.p.o.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[YUriy Zhuravlev]

On Wednesday 30 September 2015 14:41:34 you wrote:
> On Tue, Sep 29, 2015 at 12:08:56PM +1300, Gavin Flower wrote:
> > Linux kernel project uses bugzilla (https://bugzilla.kernel.org)
> 
> AIUI this is not mandatory for kernel hackers, and more opt-in from a
> some/many/a few(?) subsystem maintainers.  Some parts use it more, some
> less or not at all.
> 
> > and so does LibreOffice (https://bugs.documentfoundation.org)
> 
> Thas is true, however.
> 
> Same for freedesktop.org and the Gnome project, I believe.
> 
> 
> Michael

What about Trac? http://trac.edgewall.org/wiki/TracUsers


-- 
YUriy Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


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

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

[Oleg Bartunov]

On Mon, Oct 5, 2015 at 3:08 AM, Nathan Wagner  wrote:

> On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> > That would be the key part, wouldn't it?  Nice that you have [code to
> > store and parse email messages].
>
> Yeah.  It actually made most of the work pretty easy.  It's available
> with a bunch of other code at https://pd.if.org/git/ if anyone wants it.
> I did find a bug in my header processing though, so I'll need to commit
> that fix.
>
> > We'd also want a way to link a bug fix to a commit, and probably a way
> > to give the bug a list of searchable keywords (and add to that list).
>
> I've been thinking of hooking it up to the fti machinery and providing
> a search box.  I've never really used fti before, so this might be a
> good opportunity to learn it for real.
>

Nathan, there are many options in our fts, which can be useful, so +1 to
help you.



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

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

[Magnus Hagander]

On Mon, Oct 5, 2015 at 2:08 AM, Nathan Wagner  wrote:

> On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> > That would be the key part, wouldn't it?  Nice that you have [code to
> > store and parse email messages].
>
> Yeah.  It actually made most of the work pretty easy.  It's available
> with a bunch of other code at https://pd.if.org/git/ if anyone wants it.
> I did find a bug in my header processing though, so I'll need to commit
> that fix.
>

Note that we already have all the emails in a database, as parsed out for
archives.postgresql.org. There is also an API for this, but it's only
available internally. This one is used for example by the commitfest app,
which is in many ways doing things that are very similar to this one. If we
were to proceed down this road, I would strongly suggest that we utilize
this API (at least then we will have a consistent set of MIME parsing
bugs..)



> > We'd also want a way to link a bug fix to a commit, and probably a way
> > to give the bug a list of searchable keywords (and add to that list).
>
> I've been thinking of hooking it up to the fti machinery and providing
> a search box.  I've never really used fti before, so this might be a
> good opportunity to learn it for real.
>


Again, we already have an API for searching the archives that can do this
for us. No need to re-invent the wheel there. (And it's based on the
PostgreSQL fts functionality - of course)



>
> > > it probably makes sense to just close up front bugs that are marked
> > > against unsupported pg versions, or haven't had any activity for too
> > > long, perhaps two years.
>
> > I'm reluctant to close all of those unexamined, since part of the
> > purpose of this is to find bugs which were never fixed.  Probably we
> > should organize a posse to comb trhough all of the old bugs and
> > hand-close them.
>
> I'm doing some of that as I poke at the bugs pages.  Perhaps it would
> make sense to have a closed status of 'stale' or the like (perhaps
> that's what you meant by 'timed out') which could be used to get bugs
> out of the main list but still be marked as 'not human reviewed'.  These
> could then be reviewed by the posse.
>


I think this is definitely a state that's needed, no matter what it's
called.  In particular in the beginning.

But if looking at the bugtrackers at other projects, this is a state that
often holds a *lot* of bugs. And having an explicit one like that would
make it easier for all the volunteers to know what to look at immediately -
it would be a good goal for such a group to ensure that no bugs remain in
that state.




> > Yeah, fixing this [email's without a bug id] would probably be tied to
> > the possible change to mailman.  Unless someone already has a way to
> > get majordomo to append a bug ID.
>
> How are bug ids assigned now?  From the evidence, I assume there is a
> sequence in a database that the web submission form queries to format a
> resulting email to the bugs mailing list.  Do the mailing lists live on
> the same server?  If so, perhaps it would be easy to assign a new bug id
> to a new thread on -bugs.  But perhaps that's too aggressive in creating
> bugs.
>


Correct, that's exactly what it does.

I don't think we want to assign a new bug id to a new thread immediately.
Given how many people post a new thread referencing an old one.

I think we'd want an interface that lets you either pick an existing thread
on bugs that has no bug id and create one for it, or pick a thread and
attach it to an existing thread. Note that we also need to cover things
like threads on hackers (it's very common that a thread is opened on
hackers about the same point), as well as the enentual commit message.

Again, this is fairly similar to what the commitfest app does, by allowing
you to attach multiple threads.

I'm not saying it's a good idea to use the CF app as-is, but the fact is
that much of what it does is very similar - it adds a bunch of metadata to
mailthreads and tracks that metadata. Which is pretty much what this tool
would/should do. But it's an almost completely different set of metadata,
so I don't think merging them is a good idea.




>
> > > 5: How can we use email to update the status of a bug?
> > >
> > > I suggest using email headers to do this.  'X-PGBug-Fixed:
> > > ' and the like.  I assume here that everyone who might
> > > want to do such a thing uses an MUA that would allow this, and they
> > > know how.
> >
> > I guess that depends on who we expect to use this, at least for
> > closing stuff.
>
> I could certainly support more than one mechanism.  A web interface for
> those who would prefer such and emails would seem to be the basic
> requirements.
>

Using email headers I think is a no-go. Way too many of the people who
would be doing it don' use MUAs that let them do that. I think the way to
go is in-message keywords at the start of a line. And in that case
everybody should use those, to make things 

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

[Magnus Hagander]

On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner 
wrote:

> I don't have the original message for this thread, so I arbitrarily picked
> a
> message to reply to.
>
> Since what has been asked for is a bug *tracker*, and we already have a
> bugs
> mailing list, I put together something.
>


FWIW, I think this is a good approach in general. This makes it a  bug
*tracker*, rather than a "workflow enforcer". That depends on what we want
of course, but those are two very different things and many of the other
tools suggested are more workflow enforcers.

Something like debbugs falls in the same category though, I think, as being
mainly a tracker. Keeping the mailinglists as the first-class way of
communications, which is what we prefer.

It's dirt simple.  If the system sees a message with 'Bug #(\d+)' in the
> subject line, it creates an entry in a bugs table with that bug number (if
> needed), and then marks the message as belonging to that bug.  If there
> seems
> to be metadata about the bug in the format of the (unquoted)
>
> Bug reference:
> Logged by:
> Email address:
> PostgreSQL version:
> Operating system:
> Description:
> Details:
>


FWIW, if we end up going with this method and it makes things easier, we
could easily add such metadata as X- headers to the original bug email,
thereby making it even easier (and safer) to parse out.


4: What should I do with emails that don't reference a bug id but seem to be
> talking about a bug?
>
> I suggest we do nothing with them as far as the bug tracker is concerned.
> If
> people want to mark their message as pertaining to a bug, they can put
> that in
> the subject line.  However, I don't think a bug id can be assigned via
> email,
> that is, I think you have to use a web form to create a bug report with a
> bug
> id.  Presumably that could change if whoever runs the bug counter wants it
> to.
>

It cannot now, but we can fix that. And if we want to use a tool like this,
we should fix it. Using something like submit...@postgresql.org. But we
should also make it possible to assign a bug post-email. Someone might
email -general with a bug report, and it's a lot more friendly to just
assign ita bug than to say "hey take this thing you just wrote and re-paste
it into a form over here instead", just to get a duplicate posted into our
archivse.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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

[Merlin Moncure]

On Mon, Oct 5, 2015 at 5:32 AM, Magnus Hagander  wrote:
>
>
> On Mon, Oct 5, 2015 at 12:42 AM, Nathan Wagner 
> wrote:
>>
>> I don't have the original message for this thread, so I arbitrarily picked
>> a
>> message to reply to.
>>
>> Since what has been asked for is a bug *tracker*, and we already have a
>> bugs
>> mailing list, I put together something.
>
> FWIW, I think this is a good approach in general. This makes it a  bug
> *tracker*, rather than a "workflow enforcer". That depends on what we want
> of course, but those are two very different things and many of the other
> tools suggested are more workflow enforcers.

+1

The key points is how people interact with the tool; as long as the
interaction is basically "one way" from email to the tracking tool
(either debbugs or something hand rolled) it should work as long as it
provides value.  The main output of the tool is to do thing like
making qualified searches of bug fixes by version easier and perhaps
supporting release note generation.

Personally I think a hand-rolled tool is a better choice for this
project given that the requirements are so specific; it can be thought
of as an extension of the commit fest framework.

merlin


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

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

[Nathan Wagner]

I don't have the original message for this thread, so I arbitrarily picked a
message to reply to.

Since what has been asked for is a bug *tracker*, and we already have a bugs
mailing list, I put together something.

I downloaded the archives for pgsql-bugs, and fed them into a database.  This
part was easy, since I have already written a pg backed usenet server and had
the code hand for storing and parsing out bits of rfc 2822 messages.

It's dirt simple.  If the system sees a message with 'Bug #(\d+)' in the
subject line, it creates an entry in a bugs table with that bug number (if
needed), and then marks the message as belonging to that bug.  If there seems
to be metadata about the bug in the format of the (unquoted)

Bug reference:
Logged by:  
Email address:
PostgreSQL version:
Operating system:
Description:
Details:

it pulls that out and puts it in the bugs table.  There's also an "open"
boolean in the table, defaulting to true.

The results can be found at https://granicus.if.org/pgbugs/

Ok.  So now we have a bug tracker, but...

Some open questions that I don't think have really been addressed, with my
commentary interspersed:

1: Can a bug be more than "open" or "closed"?

I think yes.  At least we probably want to know why a bug is closed.  Is it not
a bug at all, not our bug, a duplicate submission, a duplicate of another bug,
something we won't fix for some reason (e.g. a bug against version 7)

2: Who can declare a bug closed.

Ugh.  I'm going to close some of them if it seems obvious to me that they
should be closed.  But what if it's not obvious?  I could probably maintain it
to some extent, but I don't know how much time that would actually take.

Related to the next point, it probably makes sense to just close up front
bugs that are marked against unsupported pg versions, or haven't had
any activity for too long, perhaps two years.  Just closing bugs with no
mailing list activity for two years closes 5280 of 6376 bugs.

3: How far back should I actually import data from the bugs list?

I have imported each archived month from December of 1998.  It looks like the
bug sequence was started at 1000 in December of 2003.  Emails with no bug id in
the subject line don't get associated with any bug, they're in the DB bug not
really findable.

4: What should I do with emails that don't reference a bug id but seem to be
talking about a bug?

I suggest we do nothing with them as far as the bug tracker is concerned.  If
people want to mark their message as pertaining to a bug, they can put that in
the subject line.  However, I don't think a bug id can be assigned via email,
that is, I think you have to use a web form to create a bug report with a bug
id.  Presumably that could change if whoever runs the bug counter wants it to.

5: How can we use email to update the status of a bug?

I suggest using email headers to do this.  'X-PGBug-Fixed: ' and the
like.  I assume here that everyone who might want to do such a thing uses an
MUA that would allow this, and they know how.

6: Does there need to be any security on updating the status?

Probably not.  I don't think it's the sort of thing that would attract
malicious adjustments.  If I'm wrong, I'd need to rethink this.  I realize I'm
making security an afterthought, which makes my teeth itch, but I think layers
of security would make it much less likely to be actually adopted.

Just to be clear, this is both a work in progress and a proof of concept.  It's
slow, it's ugly.  I haven't created any indexes, written any css or javascript,
or implemented any caching.  I may work on that before you read this though.

Comments are welcome, and no, I don't really expect that this will be what gets
adopted, mainly I wanted to show that we can probably just build something
rather effective off our existing infrastructure, and I had Saturday free (as
of this writing, I've got maybe 5 hours into it total, albeit with lots of
code re-use from other projects).  There are some obvious todo items,
filtering and searching being the most salient.

Some data import issues:

March 10, 2003, bad Date header, looked like junk anyway, so I deleted it.

Time zone offsets of --0400 and -0500 (at least), I took these as being -0400
(or whathaveyou).

Date header of Sat, 31 May 2008 12:12:18 +1930, judging by the name on the
email, this is probably posted from Venezuela, which switched to time one -0430
in 2007, which could also be thought of as +1930 if you ignore the implied date
change.

And, by way of some statistics, since I've got the archives in a database:

Emails: 43870
Bugs: 6376
Distinct 'From' headers: 10643

The bugs have 3.5 messages each on average, with 2 being the most common
number, and 113 at the most, for bug 12990.  1284 bugs have only one message
associated with them.

-- 
nw


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

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

[Alvaro Herrera]

Nathan Wagner wrote:

> 1: Can a bug be more than "open" or "closed"?
> 
> I think yes.  At least we probably want to know why a bug is closed.  Is it 
> not
> a bug at all, not our bug, a duplicate submission, a duplicate of another bug,
> something we won't fix for some reason (e.g. a bug against version 7)

Not only that -- is the bug closed in all branches or only some of them?
If there's also some data about when a bug appeared (commit ID), then
it's easy to get a report of which minor releases have the bug.  For
instance, see bug #8470 which I fixed by commits in 9.5 and master, but
is yet unfixed in 9.3 and 9.4.  At least one other multixact bug was
fixed in 9.5/master only.


What debbugs allows you to do, is that you write to the bug address and
in the first few lines of the body it looks for commands such as
"close", "merge", "reassign".  I for one am open fo commandeering a bug
tracker in this way, as well as adding fixed-format tags to commit
messages indicating "Fixes: #xyz" so that it can be picked up
automatically.

One of our policies in backpatching fixes is that we use the same commit
in all branches so that they become grouped as a single element in the
output of the src/tools/git_changelog script.  Maybe that can be useful
to the bug tracker as well, in some form.

> 2: Who can declare a bug closed.
> 
> Ugh.  I'm going to close some of them if it seems obvious to me that they
> should be closed.  But what if it's not obvious?  I could probably maintain it
> to some extent, but I don't know how much time that would actually take.

I think at least committers should be able to close bugs.

-- 
Álvaro Herrerahttp://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

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

[Nathan Wagner]

On Sun, Oct 04, 2015 at 04:30:49PM -0700, Josh Berkus wrote:
> That would be the key part, wouldn't it?  Nice that you have [code to
> store and parse email messages].

Yeah.  It actually made most of the work pretty easy.  It's available
with a bunch of other code at https://pd.if.org/git/ if anyone wants it.
I did find a bug in my header processing though, so I'll need to commit
that fix.

> We'd also want a way to link a bug fix to a commit, and probably a way
> to give the bug a list of searchable keywords (and add to that list).

I've been thinking of hooking it up to the fti machinery and providing
a search box.  I've never really used fti before, so this might be a
good opportunity to learn it for real.

> > it probably makes sense to just close up front bugs that are marked
> > against unsupported pg versions, or haven't had any activity for too
> > long, perhaps two years.
 
> I'm reluctant to close all of those unexamined, since part of the
> purpose of this is to find bugs which were never fixed.  Probably we
> should organize a posse to comb trhough all of the old bugs and
> hand-close them.

I'm doing some of that as I poke at the bugs pages.  Perhaps it would
make sense to have a closed status of 'stale' or the like (perhaps
that's what you meant by 'timed out') which could be used to get bugs
out of the main list but still be marked as 'not human reviewed'.  These
could then be reviewed by the posse.

> Yeah, fixing this [email's without a bug id] would probably be tied to
> the possible change to mailman.  Unless someone already has a way to
> get majordomo to append a bug ID.

How are bug ids assigned now?  From the evidence, I assume there is a
sequence in a database that the web submission form queries to format a
resulting email to the bugs mailing list.  Do the mailing lists live on
the same server?  If so, perhaps it would be easy to assign a new bug id
to a new thread on -bugs.  But perhaps that's too aggressive in creating
bugs.

> > 5: How can we use email to update the status of a bug?
> > 
> > I suggest using email headers to do this.  'X-PGBug-Fixed:
> > ' and the like.  I assume here that everyone who might
> > want to do such a thing uses an MUA that would allow this, and they
> > know how.
> 
> I guess that depends on who we expect to use this, at least for
> closing stuff.

I could certainly support more than one mechanism.  A web interface for
those who would prefer such and emails would seem to be the basic
requirements.

> > 6: Does there need to be any security on updating the status?
> > 
> > Probably not.  I don't think it's the sort of thing that would
> > attract malicious adjustments.  If I'm wrong, I'd need to rethink
> > this.  I realize I'm making security an afterthought, which makes my
> > teeth itch, but I think layers of security would make it much less
> > likely to be actually adopted.
> 
> I think there needs to be some kind of administrative access which
> allows, for example, an issue to be closed so that it can't be
> reopened.

I guess technically we have that now since I'm the only one who can
close or open a bug in the db I've set up :)

Seriously though, I think it probably makes the most sense to tie the
system in with the existing pg community accounts if it goes that far.

> Anyway, I'm not convinced we want to reinvent this particular wheel, but
> if we do, you've done a yeoman's job.

Thank you.  (Assuming I've interpreted the phrase correctly, I'm not
familiar with it, and a web search was only semi-enlightening).

-- 
nw


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

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

[Josh Berkus]

On 10/04/2015 03:42 PM, Nathan Wagner wrote:
> I downloaded the archives for pgsql-bugs, and fed them into a database.  This
> part was easy, since I have already written a pg backed usenet server and had
> the code hand for storing and parsing out bits of rfc 2822 messages.

That would be the key part, wouldn't it?  Nice that you have that.

So this would be the other option if adopting debbugs doesn't work out.
 I think it's likely that we'll end up recreating most of debbugs in the
process (or bugzilla or something else) but whatever.  As long as we
have some kind of bug tracker, I'm happy.

> It's dirt simple.  If the system sees a message with 'Bug #(\d+)' in the
> subject line, it creates an entry in a bugs table with that bug number (if
> needed), and then marks the message as belonging to that bug.  If there seems
> to be metadata about the bug in the format of the (unquoted)
> 
> Bug reference:
> Logged by:  
> Email address:
> PostgreSQL version:
> Operating system:
> Description:
> Details:
> 
> it pulls that out and puts it in the bugs table.  There's also an "open"
> boolean in the table, defaulting to true.
> 
> The results can be found at https://granicus.if.org/pgbugs/
> 
> Ok.  So now we have a bug tracker, but...
> 
> Some open questions that I don't think have really been addressed, with my
> commentary interspersed:
> 
> 1: Can a bug be more than "open" or "closed"?
> 
> I think yes.  At least we probably want to know why a bug is closed.  Is it 
> not
> a bug at all, not our bug, a duplicate submission, a duplicate of another bug,
> something we won't fix for some reason (e.g. a bug against version 7)

We'd want the usual statuses:

* fixed
* duplicate
* unreproduceable
* timed out
* not a bug
* won't fix
* reopened

We'd also want a way to link a bug fix to a commit, and probably a way
to give the bug a list of searchable keywords (and add to that list).

> 2: Who can declare a bug closed.
> 
> Ugh.  I'm going to close some of them if it seems obvious to me that they
> should be closed.  But what if it's not obvious?  I could probably maintain it
> to some extent, but I don't know how much time that would actually take.
> 
> Related to the next point, it probably makes sense to just close up front
> bugs that are marked against unsupported pg versions, or haven't had
> any activity for too long, perhaps two years.  Just closing bugs with no
> mailing list activity for two years closes 5280 of 6376 bugs.

I'm reluctant to close all of those unexamined, since part of the
purpose of this is to find bugs which were never fixed.  Probably we
should organize a posse to comb trhough all of the old bugs and
hand-close them.

> 3: How far back should I actually import data from the bugs list?
> 
> I have imported each archived month from December of 1998.  It looks like the
> bug sequence was started at 1000 in December of 2003.  Emails with no bug id 
> in
> the subject line don't get associated with any bug, they're in the DB bug not
> really findable.
> 
> 4: What should I do with emails that don't reference a bug id but seem to be
> talking about a bug?
> 
> I suggest we do nothing with them as far as the bug tracker is concerned.  If
> people want to mark their message as pertaining to a bug, they can put that in
> the subject line.  However, I don't think a bug id can be assigned via email,
> that is, I think you have to use a web form to create a bug report with a bug
> id.  Presumably that could change if whoever runs the bug counter wants it to.

Yeah, fixing this would probably be tied to the possible change to
mailman.  Unless someone already has a way to get majordomo to append a
bug ID.

> 5: How can we use email to update the status of a bug?
> 
> I suggest using email headers to do this.  'X-PGBug-Fixed: ' and the
> like.  I assume here that everyone who might want to do such a thing uses an
> MUA that would allow this, and they know how.

I guess that depends on who we expect to use this, at least for closing
stuff.

> 6: Does there need to be any security on updating the status?
> 
> Probably not.  I don't think it's the sort of thing that would attract
> malicious adjustments.  If I'm wrong, I'd need to rethink this.  I realize I'm
> making security an afterthought, which makes my teeth itch, but I think layers
> of security would make it much less likely to be actually adopted.

I think there needs to be some kind of administrative access which
allows, for example, an issue to be closed so that it can't be reopened.

Anyway, I'm not convinced we want to reinvent this particular wheel, but
if we do, you've done a yeoman's job.

-- 
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

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

[Nathan Wagner]

I don't have the original message for this thread, so I arbitrarily picked a
message to reply to.

Since what has been asked for is a bug *tracker*, and we already have a bugs
mailing list, I put together something.

I downloaded the archives for pgsql-bugs, and fed them into a database.  This
part was easy, since I have already written a pg backed usenet server and had
the code hand for storing and parsing out bits of rfc 2822 messages.

It's dirt simple.  If the system sees a message with 'Bug #(\d+)' in the
subject line, it creates an entry in a bugs table with that bug number (if
needed), and then marks the message as belonging to that bug.  If there seems
to be metadata about the bug in the format of the (unquoted)

Bug reference:
Logged by:  
Email address:
PostgreSQL version:
Operating system:
Description:
Details:

it pulls that out and puts it in the bugs table.  There's also an "open"
boolean in the table, defaulting to true.

The results can be found at https://granicus.if.org/pgbugs/

Ok.  So now we have a bug tracker, but...

Some open questions that I don't think have really been addressed, with my
commentary interspersed:

1: Can a bug be more than "open" or "closed"?

I think yes.  At least we probably want to know why a bug is closed.  Is it not
a bug at all, not our bug, a duplicate submission, a duplicate of another bug,
something we won't fix for some reason (e.g. a bug against version 7)

2: Who can declare a bug closed.

Ugh.  I'm going to close some of them if it seems obvious to me that they
should be closed.  But what if it's not obvious?  I could probably maintain it
to some extent, but I don't know how much time that would actually take.

Related to the next point, it probably makes sense to just close up front
bugs that are marked against unsupported pg versions, or haven't had
any activity for too long, perhaps two years.  Just closing bugs with no
mailing list activity for two years closes 5280 of 6376 bugs.

3: How far back should I actually import data from the bugs list?

I have imported each archived month from December of 1998.  It looks like the
bug sequence was started at 1000 in December of 2003.  Emails with no bug id in
the subject line don't get associated with any bug, they're in the DB bug not
really findable.

4: What should I do with emails that don't reference a bug id but seem to be
talking about a bug?

I suggest we do nothing with them as far as the bug tracker is concerned.  If
people want to mark their message as pertaining to a bug, they can put that in
the subject line.  However, I don't think a bug id can be assigned via email,
that is, I think you have to use a web form to create a bug report with a bug
id.  Presumably that could change if whoever runs the bug counter wants it to.

5: How can we use email to update the status of a bug?

I suggest using email headers to do this.  'X-PGBug-Fixed: ' and the
like.  I assume here that everyone who might want to do such a thing uses an
MUA that would allow this, and they know how.

6: Does there need to be any security on updating the status?

Probably not.  I don't think it's the sort of thing that would attract
malicious adjustments.  If I'm wrong, I'd need to rethink this.  I realize I'm
making security an afterthought, which makes my teeth itch, but I think layers
of security would make it much less likely to be actually adopted.

Just to be clear, this is both a work in progress and a proof of concept.  It's
slow, it's ugly.  I haven't created any indexes, written any css or javascript,
or implemented any caching.  I may work on that before you read this though.

Comments are welcome, and no, I don't really expect that this will be what gets
adopted, mainly I wanted to show that we can probably just build something
rather effective off our existing infrastructure, and I had Saturday free (as
of this writing, I've got maybe 5 hours into it total, albeit with lots of
code re-use from other projects).  There are some obvious todo items,
filtering and searching being the most salient.

Some data import issues:

March 10, 2003, bad Date header, looked like junk anyway, so I deleted it.

Time zone offsets of --0400 and -0500 (at least), I took these as being -0400
(or whathaveyou).

Date header of Sat, 31 May 2008 12:12:18 +1930, judging by the name on the
email, this is probably posted from Venezuela, which switched to time one -0430
in 2007, which could also be thought of as +1930 if you ignore the implied date
change.

And, by way of some statistics, since I've got the archives in a database:

Emails: 43870
Bugs: 6376
Distinct 'From' headers: 10643

The bugs have 3.5 messages each on average, with 2 being the most common
number, and 113 at the most, for bug 12990.  1284 bugs have only one message
associated with them.

-- 
nw


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

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

[Oleg Bartunov]

On Tue, Sep 29, 2015 at 5:55 PM, Steve Crawford <
scrawf...@pinpointresearch.com> wrote:

> On Tue, Sep 29, 2015 at 7:16 AM, David Fetter  wrote:
>
>> ...What we're not fine with is depending on a proprietary system, no
>> matter what type of license, as infrastructure...
>>
>>
> Exactly. Which is why I was warning about latching onto features only
> available in the closed enterprise version.
>
> Cheers,
> Steve
>
>


If we have consensus of what we want, why not just hire some company to
develop it for us ? I'm sure we could find such a company in Russia and
even would sponsor postgres community and pay for the development.  There
are other postgres companies, which may join us.  Or better,  pay through
pg foundation.

Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Joshua D. Drake]

Hello,

I believe it is pretty obvious we are moving in the direction of having 
a tracker at this point. The problem is exactly which direction. Stephen 
has offered some resources for his ideas and now I am offering some 
resources for mine.


I am proposing to setup a redmine instance on a VM. I am happy to do a 
lot of the legwork and should be able to get most of it done before EU. 
This is what I think I need from my fellows:


1. At least two committers
2. At least three hackers (preferably that are different from the 
committers but not required)

3. At least two users

I think we have reached a point where everyone has ideas of what they do 
and don't want but none of it matters if we don't have a proof of 
concept to determine what we do and don't know or want.


Thoughts? Volunteers?

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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Dave Page]

> On 2 Oct 2015, at 17:28, Joshua D. Drake  wrote:
> 
> Hello,
> 
> I believe it is pretty obvious we are moving in the direction of having a 
> tracker at this point. The problem is exactly which direction. Stephen has 
> offered some resources for his ideas and now I am offering some resources for 
> mine.
> 
> I am proposing to setup a redmine instance on a VM. I am happy to do a lot of 
> the legwork and should be able to get most of it done before EU. This is what 
> I think I need from my fellows:
> 
> 1. At least two committers
> 2. At least three hackers (preferably that are different from the committers 
> but not required)
> 3. At least two users
> 
> I think we have reached a point where everyone has ideas of what they do and 
> don't want but none of it matters if we don't have a proof of concept to 
> determine what we do and don't know or want.
> 
> Thoughts? Volunteers?

I swore to myself that I'd stay out of this bikeshed, but... we already have a 
Redmine instance.

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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Joshua D. Drake]

On 10/02/2015 11:36 AM, Robert Haas wrote:


I don't know what this has to do with anything Andres said.



I am sorry if I wasn't clear.

Put succinctly, I am willing to put resources into testing Redmine for 
our needs. I will need help to do so because I am not a 
committer/hacker. Andres thinks that isn't worth while. I think he is 
wrong. If he doesn't want to help, he doesn't have to, thus the call for 
volunteers.


I am not expecting that redmine will be chosen over debbugs. I am 
expecting that we make an educated decision about which one suits our 
needs. If we only review debbugs, we are making a decision in a vacuum.


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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Joshua D. Drake]

On 10/02/2015 09:34 AM, Dave Page wrote:


Thoughts? Volunteers?


I swore to myself that I'd stay out of this bikeshed, but... we already have a 
Redmine instance.


I know but I didn't want to dogfood in an installation that was 
production. I am not going to put up vanilla redmine, I actually planned 
on configuring in a way that could be used by -hackers which could 
(possibly?) cause issues with the install .Org has.


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

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

[Jeff Janes]

On Thu, Oct 1, 2015 at 7:48 AM, Magnus Hagander  wrote:

> On Thu, Oct 1, 2015 at 4:35 PM, Robert Haas  wrote:
>
>>
>> - Bug numbers are sometimes preserved in commit messages, but they
>> never make it into release notes.  This actually seems like something
>> we could improve pretty easily and without a lot of extra work (and
>> also without a bug tracker).  If every committer makes a practice of
>> putting the bug number into the commit message, and the people who
>> write the release notes then transcribe the information there, I bet
>> that would be pretty useful to a whole lotta people.
>>
>
> That would require people to actually use the bug form to submit the
> initial thread as well of course - which most developers don't do
> themselves today. But there is in itself nothing that prevents them from
> doing that, of course - other than a Small Amount Of Extra Work.
>

It is not always clear to me where I am supposed to report bugs.  I
generally use -hackers if it is in code which is committed but not yet been
released, or if I've tracked it down to source code or a backtrace or
something like that, or if it is theoretical concern that I am not sure is
actually a bug.

Of course if I error on the side of sending it to -hackers when it should
be -bugs, someone could always forward it there, or tell me to do so.

It is also a bit awkward to send a patch on the bugs form, so if we want to
people to use the bugs form even when they are also submitting a patch to
fix the bug, we should explicitly state what it is we want them to.  Two
separate submissions, one to -bugs, one to -hackers?  An email to -bugs
(rather than using the form, which doesn't allow attachments) with an
attachment?

Cheers,

Jeff

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Andres Freund]

Hi,

On 2015-10-02 09:28:02 -0700, Joshua D. Drake wrote:
> I am proposing to setup a redmine instance on a VM. I am happy to do a lot
> of the legwork and should be able to get most of it done before EU. This is
> what I think I need from my fellows:

-1. This thread has already cost disproportionally much time and
motiviation. Let's not wase more in doing two evaluations at the same
time, when we might already be happy with one of them. We came pretty
close to agreeing on debbugs in a couple past discussions so that seems
the least unlikely choice to actually get adopted.

Greetings,

Andres Freund


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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Joshua D. Drake]

On 10/02/2015 09:41 AM, Andres Freund wrote:

Hi,

On 2015-10-02 09:28:02 -0700, Joshua D. Drake wrote:

I am proposing to setup a redmine instance on a VM. I am happy to do a lot
of the legwork and should be able to get most of it done before EU. This is
what I think I need from my fellows:


-1. This thread has already cost disproportionally much time and
motiviation. Let's not wase more in doing two evaluations at the same
time, when we might already be happy with one of them. We came pretty
close to agreeing on debbugs in a couple past discussions so that seems
the least unlikely choice to actually get adopted.


I once drove a manual all the time. I swore by the manual. I loved the 
control, the feeling (ridiculously) that I was a race car driver on the 
Urban track.


Then I got an automatic and realized how damn nice it was to not be in 
control or have to worry about whether or not I should shift at 3k RPMS 
or 4k RPMS. (Then I drove a manual on the wrong side of the road in 
Ireland and was even happier that I prefer automatics)


We can't just point at something and say, "Oh that will work" because we 
haven't tried to see how it is going to work with our requirements.


I wouldn't expect any customer to use postgresql because it has an 
Elephant as a mascot. I expect them to use it because it is the best 
choice for their requirements.


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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Robert Haas]

On Fri, Oct 2, 2015 at 12:50 PM, Joshua D. Drake  wrote:
> I once drove a manual all the time. I swore by the manual. I loved the
> control, the feeling (ridiculously) that I was a race car driver on the
> Urban track.
>
> Then I got an automatic and realized how damn nice it was to not be in
> control or have to worry about whether or not I should shift at 3k RPMS or
> 4k RPMS. (Then I drove a manual on the wrong side of the road in Ireland and
> was even happier that I prefer automatics)
>
> We can't just point at something and say, "Oh that will work" because we
> haven't tried to see how it is going to work with our requirements.
>
> I wouldn't expect any customer to use postgresql because it has an Elephant
> as a mascot. I expect them to use it because it is the best choice for their
> requirements.

I don't know what this has to do with anything Andres said.

-- 
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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Robert Haas]

On Fri, Oct 2, 2015 at 2:43 PM, Joshua D. Drake  wrote:
> I am sorry if I wasn't clear.
>
> Put succinctly, I am willing to put resources into testing Redmine for our
> needs. I will need help to do so because I am not a committer/hacker. Andres
> thinks that isn't worth while. I think he is wrong. If he doesn't want to
> help, he doesn't have to, thus the call for volunteers.
>
> I am not expecting that redmine will be chosen over debbugs. I am expecting
> that we make an educated decision about which one suits our needs. If we
> only review debbugs, we are making a decision in a vacuum.

OK.  My reading of the thread is that the hackers who expressed an
opinion mostly preferred debbugs and the people less involved in the
project wanted something more like GitHub/GitLab.  Some people also
argued for and against Bugzilla and JIRA.  I didn't really see anybody
agitating for Redmine, so I'm not sure how far you're going to get
with that.

But I'm not really arguing against it.  We use it here at
EnterpriseDB, and it's very helpful, though it is undeniably a
[expletive]-ton of work to maintain.

-- 
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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Joshua D. Drake]

On 10/02/2015 12:52 PM, Robert Haas wrote:


OK.  My reading of the thread is that the hackers who expressed an
opinion mostly preferred debbugs and the people less involved in the
project wanted something more like GitHub/GitLab.  Some people also
argued for and against Bugzilla and JIRA.  I didn't really see anybody
agitating for Redmine, so I'm not sure how far you're going to get
with that.


Right, thus call for Volunteers. If I can get a few to help me, I am 
willing to put my resources behind it. If I can't then I won't. I guess 
what I am really saying here is, "If I am going to bitch about the lack 
of a tracker, I better damn well be willing to put resources into fixing 
the problem".


So I am putting my money where my mouth is.



But I'm not really arguing against it.  We use it here at
EnterpriseDB, and it's very helpful, though it is undeniably a
[expletive]-ton of work to maintain.


Yeah, and that is any issue tracker (the ton of work to maintain).

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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Alvaro Herrera]

Joshua D. Drake wrote:

> Put succinctly, I am willing to put resources into testing Redmine for our
> needs. I will need help to do so because I am not a committer/hacker. Andres
> thinks that isn't worth while. I think he is wrong. If he doesn't want to
> help, he doesn't have to, thus the call for volunteers.

Nobody asked, but here's my opinion on Redmine.  I worked pretty heavily
with it during my time at Command Prompt.  I have to say that with the
customizations that CMD had at the time, it wasn't that bad -- I was
pretty happy that I could interact with it via email, and most of the
time it wouldn't do anything too stupid.  I could also interact with it
using the web, and it worked pretty well there.  Most other Redmine
installations I've used don't have the email interface at all.

However, the contact surface between these two options wasn't really
well polished.  Formatting would be lost very frequently: I could write
a nice email, and the customer would get a nice email, but if you looked
at it in the web, it was very ugly.  If you used the web form to reply,
the resulting email looked pretty stupid in some cases.  I eventually
learned to use the right {{{ }}} markers in my email replies so that
code would look right in the web.  But if you made a single mistake, you
were fscked and there was no way at all to fix it.

As far as I remember, the main reason for this pain was that it didn't
try to consider an email as an email: instead, what it did was grab the
text and cram it into the comment box.  Same thing in the other
direction, where the text from the comment would be crammed as an email
in output.  All that was needed was for it to store emails in the
rfc/2822 format in the database, and then render them as emails in the
web form, instead of trying to do the conversion in the process.


If you look at the debbugs interface, it is pretty clear that all that
it does is keep track of emails -- which, let it be said, is the soul of
this community's communication, so it seems to me that that is what we
need.  Metadata changes are kept visually separate from actual
commentary, which is convenient; and you can always get the mbox
involving that bug, or look at minute details of it using the web
interface if you need that sort of thing.

-- 
Álvaro Herrerahttp://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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Robert Haas]

On Fri, Oct 2, 2015 at 4:26 PM, Alvaro Herrera  wrote:
> Joshua D. Drake wrote:
>> Put succinctly, I am willing to put resources into testing Redmine for our
>> needs. I will need help to do so because I am not a committer/hacker. Andres
>> thinks that isn't worth while. I think he is wrong. If he doesn't want to
>> help, he doesn't have to, thus the call for volunteers.
>
> Nobody asked, but here's my opinion on Redmine.  I worked pretty heavily
> with it during my time at Command Prompt.  I have to say that with the
> customizations that CMD had at the time, it wasn't that bad -- I was
> pretty happy that I could interact with it via email, and most of the
> time it wouldn't do anything too stupid.  I could also interact with it
> using the web, and it worked pretty well there.  Most other Redmine
> installations I've used don't have the email interface at all.
>
> However, the contact surface between these two options wasn't really
> well polished.  Formatting would be lost very frequently: I could write
> a nice email, and the customer would get a nice email, but if you looked
> at it in the web, it was very ugly.  If you used the web form to reply,
> the resulting email looked pretty stupid in some cases.  I eventually
> learned to use the right {{{ }}} markers in my email replies so that
> code would look right in the web.  But if you made a single mistake, you
> were fscked and there was no way at all to fix it.
>
> As far as I remember, the main reason for this pain was that it didn't
> try to consider an email as an email: instead, what it did was grab the
> text and cram it into the comment box.  Same thing in the other
> direction, where the text from the comment would be crammed as an email
> in output.  All that was needed was for it to store emails in the
> rfc/2822 format in the database, and then render them as emails in the
> web form, instead of trying to do the conversion in the process.
>
>
> If you look at the debbugs interface, it is pretty clear that all that
> it does is keep track of emails -- which, let it be said, is the soul of
> this community's communication, so it seems to me that that is what we
> need.  Metadata changes are kept visually separate from actual
> commentary, which is convenient; and you can always get the mbox
> involving that bug, or look at minute details of it using the web
> interface if you need that sort of thing.

Thanks for this very thoughtful email.

-- 
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

Re: Request for dogfood volunteers (was [HACKERS] No Issue Tracker - Say it Ain't So!)

[Joshua D. Drake]

On 10/02/2015 01:26 PM, Alvaro Herrera wrote:


However, the contact surface between these two options wasn't really
well polished.  Formatting would be lost very frequently: I could write
a nice email, and the customer would get a nice email, but if you looked
 at it in the web, it was very ugly.


Newer versions are much better at this from what I can tell.


 If you used the web form to reply,
the resulting email looked pretty stupid in some cases.  I eventually
learned to use the right {{{ }}} markers in my email replies so that
code would look right in the web.  But if you made a single mistake, you
were fscked and there was no way at all to fix it.


I don't know anything about the brackets but I do know one thing that is 
unfortunate about redmine is that it assumes plain text unless you tell 
it something different. What does that mean?


If you want to use a preformatted (text based) entry:


psql -U postgres


Will do exactly the same thing in the web interface. Of course in the 
web interface it gets formatted so it looks great. In email, you get 
HTML code.


I find is that as long as you are working in just text, everything is 
kosher. If you try to do any formatting (so it looks nice on the web), 
you run into problems.




If you look at the debbugs interface, it is pretty clear that all that
it does is keep track of emails -- which, let it be said, is the soul of
this community's communication, so it seems to me that that is what we
need.  Metadata changes are kept visually separate from actual
commentary, which is convenient; and you can always get the mbox
involving that bug, or look at minute details of it using the web
interface if you need that sort of thing.


It is true (I believe roundup doesn't something similar to debbugs) that 
Redmine considers email a business class citizen, not coach but 
certainly not first class.


My main issue with debbugs is that it appears very limited and is yet 
another piece of infrastructure that only provides that infrastructure 
and thus will continue to cause more heartache than is needed. That 
isn't to say it is a bad piece of software but that it is very specific 
in what it does.


We seem to need more than that. As another person (I don't recall who) 
mentioned, Redmine gives us an infrastructure to many things including 
proper mapping between issues and GIT. Perhaps we don't use that now but 
do we want to be in a position a year from now where we want it but now 
we have pitched our tent with a more limited piece of software?


I do appreciate the feedback on it and I am in no way suggesting that 
Redmine is perfect only that it "might" be the solution.


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

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

[Torsten Zuehlsdorff]

On 01.10.2015 00:27, Tom Lane wrote:

Josh Berkus  writes:

On 09/30/2015 03:10 PM, Tom Lane wrote:

I'd be feeling a lot more positive about this whole thread if any people
had stepped up and said "yes, *I* will put in a lot of grunt-work to make
something happen here".  The lack of any volunteers suggests strongly
that this thread is a waste of time, just as the several similar ones
before it have been.



Hmmm?  Frost volunteered to stand up debbugs.


So he did, and did anyone volunteer to put data into it, or to do ongoing
curation of said data?


Yes, i did.

Greetings,
Torsten



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

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

[Tom Lane]

Robert Haas  writes:
> - Bug numbers are sometimes preserved in commit messages, but they
> never make it into release notes.  This actually seems like something
> we could improve pretty easily and without a lot of extra work (and
> also without a bug tracker).  If every committer makes a practice of
> putting the bug number into the commit message, and the people who
> write the release notes then transcribe the information there, I bet
> that would be pretty useful to a whole lotta people.

The main reason bug numbers don't go into release notes is that only a
fraction of our bugs actually have bug numbers.  Very many problem reports
show up via ordinary email traffic.  If we had a mail-aware tracker and
there were curators making sure that every problem-reporting thread got
into the tracker, then it might become reasonable to cite bug numbers in
the release notes.

Personally I do make a practice of citing bug numbers in commit messages,
but if you go through my commits, you'll soon agree that the coverage is
too spotty to be useful in release notes.  So I have not bothered to
pester other committers to do likewise.  Also, I suspect it will not be
uncommon for tracker entries to appear only after the related commits,
particularly for security bugs; so expecting the commit messages to be the
links may be impractical anyway.

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.

regards, tom lane


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

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

[Andrew Dunstan]

On 10/01/2015 10:35 AM, Robert Haas wrote:

On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure  wrote:

I'm not trolling in any way.  I'm just challenging you to back up your
blanket assertions with evidence.  For example, you're assertion that
mailing lists are insufficient is simply stated and expected to be
taken on faith: *How* is it insufficient and *what* do things like in
the new world?  Be specific: glossing over these details doesn't
really accomplish anything and avoids the careful examination that may
suggest small tweaks to the current processes that could get similar
results with a lot less effort.  In this entire massive thread, so far
only Josh has come up with what I'd consider to be actionable problem
cases.

I think that the mailing list is pretty much just as good as a bug
tracker would be for finding the discussion about some particular bug.
I mean, our web site has all the mails from the email thread, and
that's where the discussion is, and if that discussion were in a bug
tracker it wouldn't have any more information than what is on the
email thread.  The email thread also usually contains a message
indicating whether a fix was committed.

Where the mailing list is less adequate is:

- If you want to see a list of all the bugs by status, you have to
review every thread individually.  It would be useful to have a way to
filter out the bug reports that turn out not to be really bugs vs. the
ones that are real bugs which have been fixed vs. the ones that are
real bugs that have not been fixed.  Associating status with each bug
number would make this easier.

- Bug numbers are sometimes preserved in commit messages, but they
never make it into release notes.  This actually seems like something
we could improve pretty easily and without a lot of extra work (and
also without a bug tracker).  If every committer makes a practice of
putting the bug number into the commit message, and the people who
write the release notes then transcribe the information there, I bet
that would be pretty useful to a whole lotta people.




A lot of errors get fixed without a bug ever being raised. If we want a 
tracker to represent some sort of historical record, all commits, or all 
non-feature commits if we don't want to track features, should be 
against tracker items. (In my former life I once had to send out a memo 
to developers that said "If you're not working on items in the tracker 
you're not doing your job.")


cheers

andrew


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

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

[Andres Freund]

On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote:
> That would require people to actually use the bug form to submit the
> initial thread as well of course - which most developers don't do
> themselves today. But there is in itself nothing that prevents them from
> doing that, of course - other than a Small Amount Of Extra Work.

It'd be cool if there were a newbug@ or similar mail address that
automatically also posted to -bugs or so.

> I think when a patch is directly related to a specific bug as reported
> through the webform, don't most committers already refer to that bug
> number? Maybe not every time, but at least most of the time? It's the many
> discussions that don't actually have a bug number and yet result in a patch
> that don't?

I think it's mentioned somewhere in the commit message most of the time
- but not in an easy to locate way. If we'd agree on putting something like:
Bug: #XXX
Affected-Versions: 9.5-
Fixed-Versions: 9.3-
in commit messages that'd be a fair bit easier to get into the release notes..

Greetings,

Andres Freund


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

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

[Magnus Hagander]

On Thu, Oct 1, 2015 at 4:35 PM, Robert Haas  wrote:

> On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure 
> wrote:
> > I'm not trolling in any way.  I'm just challenging you to back up your
> > blanket assertions with evidence.  For example, you're assertion that
> > mailing lists are insufficient is simply stated and expected to be
> > taken on faith: *How* is it insufficient and *what* do things like in
> > the new world?  Be specific: glossing over these details doesn't
> > really accomplish anything and avoids the careful examination that may
> > suggest small tweaks to the current processes that could get similar
> > results with a lot less effort.  In this entire massive thread, so far
> > only Josh has come up with what I'd consider to be actionable problem
> > cases.
>
> I think that the mailing list is pretty much just as good as a bug
> tracker would be for finding the discussion about some particular bug.
> I mean, our web site has all the mails from the email thread, and
> that's where the discussion is, and if that discussion were in a bug
> tracker it wouldn't have any more information than what is on the
> email thread.  The email thread also usually contains a message
> indicating whether a fix was committed.
>
> Where the mailing list is less adequate is:
>
> - If you want to see a list of all the bugs by status, you have to
> review every thread individually.  It would be useful to have a way to
> filter out the bug reports that turn out not to be really bugs vs. the
> ones that are real bugs which have been fixed vs. the ones that are
> real bugs that have not been fixed.  Associating status with each bug
> number would make this easier.
>

I think that's a pretty good summary.

A bug tracker can be used to add metadata about a bug, which can be very
useful. Such as which versions are affected, and when it was fixed (or if
it wasn't), which platforms it breaks, etc.

But using the bugtracker for the discussion itself is usually not a win. In
fact, I'd say in most cases it's counterproductive because it forces a
single tool upon everybody, instead of email which allows each person to
pick their own favourite tool. Using a bugtracker where all discussion
happens in email removes that downside, and moves it back to the state
where it doesn't help but also doesn't hinder the communication.


>
> - Bug numbers are sometimes preserved in commit messages, but they
> never make it into release notes.  This actually seems like something
> we could improve pretty easily and without a lot of extra work (and
> also without a bug tracker).  If every committer makes a practice of
> putting the bug number into the commit message, and the people who
> write the release notes then transcribe the information there, I bet
> that would be pretty useful to a whole lotta people.
>

That would require people to actually use the bug form to submit the
initial thread as well of course - which most developers don't do
themselves today. But there is in itself nothing that prevents them from
doing that, of course - other than a Small Amount Of Extra Work.

I think when a patch is directly related to a specific bug as reported
through the webform, don't most committers already refer to that bug
number? Maybe not every time, but at least most of the time? It's the many
discussions that don't actually have a bug number and yet result in a patch
that don't?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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

[Tom Lane]

Andres Freund  writes:
> On 2015-10-01 11:07:12 -0400, Tom Lane wrote:
>> As one of the people who do most of the gruntwork for release notes,
>> I can tell you that that sort of fixed-format annotation is useless
>> and usually annoying.  I can see what branches you fixed the bug in
>> anyway, from git_changelog's output.

> I know that I very frequently wish that information were in the commit
> messages in a easily discernible way.

I'm inclined to think that commit messages are not really the right medium
for that at all.  Commit messages ought to be primarily text for
consumption by humans.  If we had a tracker, I think that it would be the
place for fixed-format metadata, such as "fixed in version(s) x,y,z" and
"fixed by commit(s) aaa,bbb,ccc".  Expecting the tracker to link to the
commit rather than vice versa would also solve a bunch of other problems
like assigned-after-the-fact bug numbers.  Not to mention plain old
mistakes: once committed, a log message is immutable, but a tracker could
be updated as needed.

If this process actually works, I could see the tracker becoming the
source material for generating release notes, at least for bug-fix
notes.  We do it off the commit log now because that's all we've got,
but the log isn't really ideal source material.

regards, tom lane


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

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

[Robert Haas]

On Wed, Sep 30, 2015 at 10:44 AM, Merlin Moncure  wrote:
> I'm not trolling in any way.  I'm just challenging you to back up your
> blanket assertions with evidence.  For example, you're assertion that
> mailing lists are insufficient is simply stated and expected to be
> taken on faith: *How* is it insufficient and *what* do things like in
> the new world?  Be specific: glossing over these details doesn't
> really accomplish anything and avoids the careful examination that may
> suggest small tweaks to the current processes that could get similar
> results with a lot less effort.  In this entire massive thread, so far
> only Josh has come up with what I'd consider to be actionable problem
> cases.

I think that the mailing list is pretty much just as good as a bug
tracker would be for finding the discussion about some particular bug.
I mean, our web site has all the mails from the email thread, and
that's where the discussion is, and if that discussion were in a bug
tracker it wouldn't have any more information than what is on the
email thread.  The email thread also usually contains a message
indicating whether a fix was committed.

Where the mailing list is less adequate is:

- If you want to see a list of all the bugs by status, you have to
review every thread individually.  It would be useful to have a way to
filter out the bug reports that turn out not to be really bugs vs. the
ones that are real bugs which have been fixed vs. the ones that are
real bugs that have not been fixed.  Associating status with each bug
number would make this easier.

- Bug numbers are sometimes preserved in commit messages, but they
never make it into release notes.  This actually seems like something
we could improve pretty easily and without a lot of extra work (and
also without a bug tracker).  If every committer makes a practice of
putting the bug number into the commit message, and the people who
write the release notes then transcribe the information there, I bet
that would be pretty useful to a whole lotta people.

-- 
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

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

[Stephen Frost]

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus  writes:
> > On 09/30/2015 03:10 PM, Tom Lane wrote:
> >> I'd be feeling a lot more positive about this whole thread if any people
> >> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
> >> something happen here".  The lack of any volunteers suggests strongly
> >> that this thread is a waste of time, just as the several similar ones
> >> before it have been.
> 
> > Hmmm?  Frost volunteered to stand up debbugs.
> 
> So he did, and did anyone volunteer to put data into it, or to do ongoing
> curation of said data?  If we simply connect it up to the mailing lists,
> and then stand back and wait for magic to happen, we will not ever have
> anything that's any more useful than the existing mailing list archives.

I'm still planning to stand up debbugs, but as I said earlier on in the
thread, it's lower priority than the current work around getting beta
out the door (and, generally, 9.5 into good shape).  I've been following
the thread and don't see any reason to stray from that plan.

Once it's up, I'll provide information about how it gets populated, how
to interact with it, etc.  Based on the responses on this thread, it
looks like we've got quite a few people who are willing to help manage
it, once it's up and running.  I'll also be involved (either directly or
by bringing in other resources) in the ongoing curation and management.

Thanks!

Stephen


signature.asc
Description: Digital signature

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

[Andres Freund]

On 2015-10-01 11:07:12 -0400, Tom Lane wrote:
> Andres Freund  writes:
> > On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote:
> >> That would require people to actually use the bug form to submit the
> >> initial thread as well of course - which most developers don't do
> >> themselves today. But there is in itself nothing that prevents them from
> >> doing that, of course - other than a Small Amount Of Extra Work.
> 
> > It'd be cool if there were a newbug@ or similar mail address that
> > automatically also posted to -bugs or so.
> 
> I believe that's spelled pgsql-b...@postgresql.org.

The point is that newbug would automatically assign a bug id, without
going through the form.

> > I think it's mentioned somewhere in the commit message most of the time
> > - but not in an easy to locate way. If we'd agree on putting something like:
> > Bug: #XXX
> > Affected-Versions: 9.5-
> > Fixed-Versions: 9.3-
> > in commit messages that'd be a fair bit easier to get into the release 
> > notes..
> 
> As one of the people who do most of the gruntwork for release notes,
> I can tell you that that sort of fixed-format annotation is useless
> and usually annoying.  I can see what branches you fixed the bug in
> anyway, from git_changelog's output.

I know that I very frequently wish that information were in the commit
messages in a easily discernible way.

> Actually useful information of that sort would be commentary along the
> lines of "The bug exists back to 8.4, but I only fixed it in 9.2 and
> up because ."

That should definitely be there as well, agreed.

Greetings,

Andres Freund


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

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

[Tom Lane]

Andres Freund  writes:
> On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote:
>> That would require people to actually use the bug form to submit the
>> initial thread as well of course - which most developers don't do
>> themselves today. But there is in itself nothing that prevents them from
>> doing that, of course - other than a Small Amount Of Extra Work.

> It'd be cool if there were a newbug@ or similar mail address that
> automatically also posted to -bugs or so.

I believe that's spelled pgsql-b...@postgresql.org.

> I think it's mentioned somewhere in the commit message most of the time
> - but not in an easy to locate way. If we'd agree on putting something like:
> Bug: #XXX
> Affected-Versions: 9.5-
> Fixed-Versions: 9.3-
> in commit messages that'd be a fair bit easier to get into the release notes..

As one of the people who do most of the gruntwork for release notes,
I can tell you that that sort of fixed-format annotation is useless
and usually annoying.  I can see what branches you fixed the bug in
anyway, from git_changelog's output.  Actually useful information
of that sort would be commentary along the lines of "The bug exists
back to 8.4, but I only fixed it in 9.2 and up because ."
Without the , you're just adding bloat to what's already
a pretty large file.

regards, tom lane


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

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

[Joshua D. Drake]

On 10/01/2015 07:48 AM, Magnus Hagander wrote:


But using the bugtracker for the discussion itself is usually not a win.


I know you said usually but:


In fact, I'd say in most cases it's counterproductive because it forces
a single tool upon everybody, instead of email which allows each person
to pick their own favourite tool. Using a bugtracker where all
discussion happens in email removes that downside, and moves it back to
the state where it doesn't help but also doesn't hinder the communication.


This doesn't seem correct, roundup, debbugs, redmine, and rt all support 
email as the primary form of communication.




That would require people to actually use the bug form to submit the
initial thread as well of course - which most developers don't do
themselves today. But there is in itself nothing that prevents them from
doing that, of course - other than a Small Amount Of Extra Work.


It requires using a tracker somewhere within the email chain which would 
automatically assign an issue number to the email.


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

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

[Merlin Moncure]

On Thu, Oct 1, 2015 at 10:18 AM, Tom Lane  wrote:
> Andres Freund  writes:
>> On 2015-10-01 11:07:12 -0400, Tom Lane wrote:
>>> As one of the people who do most of the gruntwork for release notes,
>>> I can tell you that that sort of fixed-format annotation is useless
>>> and usually annoying.  I can see what branches you fixed the bug in
>>> anyway, from git_changelog's output.
>
>> I know that I very frequently wish that information were in the commit
>> messages in a easily discernible way.
>
> I'm inclined to think that commit messages are not really the right medium
> for that at all.  Commit messages ought to be primarily text for
> consumption by humans.  If we had a tracker, I think that it would be the
> place for fixed-format metadata, such as "fixed in version(s) x,y,z" and
> "fixed by commit(s) aaa,bbb,ccc".  Expecting the tracker to link to the
> commit rather than vice versa would also solve a bunch of other problems
> like assigned-after-the-fact bug numbers.  Not to mention plain old
> mistakes: once committed, a log message is immutable, but a tracker could
> be updated as needed.
>
> If this process actually works, I could see the tracker becoming the
> source material for generating release notes, at least for bug-fix
> notes.  We do it off the commit log now because that's all we've got,
> but the log isn't really ideal source material.

At least some of that information could be generated by crawling and
parsing commit emails, I think.  The missing link FWICT is reliably
tying the bug resolution to the relevant commit.   Maybe we could
teach the tracker to watch for "fixed by commit ABCDEF"  in the bug
list (and maybe hackers, too), identifying the commit as a bug fix and
associating it to the release branches.  That gets crawled and
rendered to a database for collection and reporting.

merlin


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

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

[Joshua D. Drake]

On 10/01/2015 08:18 AM, Tom Lane wrote:

Andres Freund  writes:

On 2015-10-01 11:07:12 -0400, Tom Lane wrote:



I'm inclined to think that commit messages are not really the right medium
for that at all.  Commit messages ought to be primarily text for
consumption by humans.  If we had a tracker, I think that it would be the
place for fixed-format metadata, such as "fixed in version(s) x,y,z" and
"fixed by commit(s) aaa,bbb,ccc".  Expecting the tracker to link to the
commit rather than vice versa would also solve a bunch of other problems
like assigned-after-the-fact bug numbers.  Not to mention plain old
mistakes: once committed, a log message is immutable, but a tracker could
be updated as needed.


What I imagined was this:

TGL commits foo, part of the commit message says: Status: Committed. 
Then a commit hook is fired from git to the tracker from a fixed 
address, That message would say:


Git commit $hash
Status: Committed

Which would not only link to the specific commit but also automatically 
close the ticket with a status of Committed. Does that make sense for 
-hackers? It seems like it would take a load off but I am not the one in 
it every day.





If this process actually works, I could see the tracker becoming the
source material for generating release notes, at least for bug-fix
notes.  We do it off the commit log now because that's all we've got,
but the log isn't really ideal source material.



Yep.



regards, tom lane




--
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

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

[Josh Berkus]

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.

I tried to tackle this three or four years ago, by writing a tool which
would slurp the release notes and put them into a full-text search
database.  This turned out to be very hard to do; our formatting for the
release notes makes it very difficult for an automated import program to
interpret (SGML doesn't help), especially on point releases to old
versions.  It also turned out that the resulting database was useful
mostly to me, because you had to figure out what terms to search on
based on the bug report in front of you.  As a result, it never went online.

So today, the only time the release notes are useful for a "is this
issue fixed or not" is when a release note message mentions the specific
error message the user is getting, which is a minority of the time.

So in addition to what Haas mentions, I think we want to be able to link
the release notes to the original issues for our hypothetical bug tracker.

-- 
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

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

[Stefan Kaltenbrunner]

On 10/01/2015 05:10 PM, Andres Freund wrote:
> On 2015-10-01 11:07:12 -0400, Tom Lane wrote:
>> Andres Freund  writes:
>>> On 2015-10-01 16:48:32 +0200, Magnus Hagander wrote:
 That would require people to actually use the bug form to submit the
 initial thread as well of course - which most developers don't do
 themselves today. But there is in itself nothing that prevents them from
 doing that, of course - other than a Small Amount Of Extra Work.
>>
>>> It'd be cool if there were a newbug@ or similar mail address that
>>> automatically also posted to -bugs or so.
>>
>> I believe that's spelled pgsql-b...@postgresql.org.
> 
> The point is that newbug would automatically assign a bug id, without
> going through the form.

if we only want that - we can trivially implement that on the mailserver
side by asking the backend database sequence for a bugid and rewriting
the subject...
But given debbugs is on the radar not sure we need it...


Stefan


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

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

[Merlin Moncure]

On Thu, Oct 1, 2015 at 12:09 PM, Josh Berkus  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 human inputs you'd want
to arrange for other processes (such as generating release notes which
might require cleaned up language).

merlin


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

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

[Amir Rohan]

> On 09/30/2015 03:27 PM, Tom Lane wrote:
>> Josh Berkus  writes:
>>> On 09/30/2015 03:10 PM, Tom Lane wrote:
 I'd be feeling a lot more positive about this whole thread if any people
 had stepped up and said "yes, *I* will put in a lot of grunt-work to make
 something happen here".  The lack of any volunteers suggests strongly
 that this thread is a waste of time, just as the several similar ones
 before it have been.
>> 
>>> Hmmm?  Frost volunteered to stand up debbugs.
>> 
>> So he did, and did anyone volunteer to put data into it, or to do ongoing
>> curation of said data?  If we simply connect it up to the mailing lists,
>> and then stand back and wait for magic to happen, we will not ever have
>> anything that's any more useful than the existing mailing list archives.

On 10/01/2015 01:49 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
> 
>> Well, it's hard for anyone to volunteer when we don't know what the
>> actual volunteer tasks are.  I certainly intend to do *something* to
>> support the bug tracker system, but I don't know yet what that something is.
> 
> I volunteer to do something too, as long as I don't have to click on
> endless web forms.
> 

I volunteer to help populate the new tracker from whatever from the
currently exists in, and will also put into action any reasonable
scraping/augmentation ideas put forth to make it a more productive tool.

Amir


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

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

[Félix GERZAGUET]

On Thu, Oct 1, 2015 at 9:50 AM, Torsten Zuehlsdorff <
mailingli...@toco-domains.de> wrote:

> On 01.10.2015 00:27, Tom Lane wrote:
>
>> Josh Berkus  writes:
>>
>>> On 09/30/2015 03:10 PM, Tom Lane wrote:
>>>
 I'd be feeling a lot more positive about this whole thread if any people
 had stepped up and said "yes, *I* will put in a lot of grunt-work to
 make
 something happen here".

>>>
>> Hmmm?  Frost volunteered to stand up debbugs.
>>>
>>
>> So he did, and did anyone volunteer to put data into it, or to do ongoing
>> curation of said data?
>>
>
> Yes, i did.
>
>
I am also volunteering for this kind of grunt-work.

Greetings,
Félix

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

[Andrew Dunstan]

On 09/30/2015 01:31 PM, Joshua D. Drake wrote:

On 09/30/2015 12:02 AM, Jim Nasby wrote:


If people are hell-bent on every tool being separate then fine, but I
get the distinct impression that everyone is discarding GitLab out of
hand based on completely bogus information.


Right, we need to stop thinking that every task is not interrelated. 
They all are. Although I am not a big fan of the gitlab idea but that 
is more out of ignorance of the software/service than anything else. 
My core focus on this discussion is to educate the -hackers that don't 
understand that all of this is related and to have a bug tracker, and 
a separate commitfest app, and a isolated git server that doesn't 
interact with any of them except through a commit message is broken.


If we can come to a solution that properly links the processes 
together (without outright throwing them out the window), that is the 
best solution. A "bug" tracker doesn't do that. It just adds another 
piece. An issue tracker (as everything including this discussion is an 
issue) works because an issue can be classified and tracked for its 
purpose.






Frankly, an insistence on moving to some integrated solution is likely 
to result in the adoption of nothing. And your "educating hackers who 
don't understand" is more than a little patronizing. What makes you 
think your experience in software development is better than others'?


cheers

andrew













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

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

[Joshua D. Drake]

On 09/30/2015 10:45 AM, Andrew Dunstan wrote:


Frankly, an insistence on moving to some integrated solution is likely
to result in the adoption of nothing. And your "educating hackers who
don't understand" is more than a little patronizing. What makes you
think your experience in software development is better than others'?


I wasn't being patronizing. I was stating a point. Is this discussion 
not educational (whether you agree with the points or not) or are you 
suggesting that somehow you already know everything?


That, was patronizing.

I believe myself (and someone like Nasby) do have a better core 
understanding of development because development is more than some guy 
sitting in a den pushing out code. The community already recognizes 
this, that is why we have the facilities we do now. All I (and others) 
am suggesting is that we make the facilities we have now, work better.


I would also iterate that my entire argument has been to essentially 
update/upgrade our workflow, not replace it. Filling the gaps as it were.


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

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

[Andrew Dunstan]

On 09/30/2015 02:16 PM, Joshua D. Drake wrote:

On 09/30/2015 10:45 AM, Andrew Dunstan wrote:


Frankly, an insistence on moving to some integrated solution is likely
to result in the adoption of nothing. And your "educating hackers who
don't understand" is more than a little patronizing. What makes you
think your experience in software development is better than others'?


I wasn't being patronizing. I was stating a point. Is this discussion 
not educational (whether you agree with the points or not) or are you 
suggesting that somehow you already know everything?


That, was patronizing.



Nonsense. There is a big difference between "stating a view" and 
"educating people who don't understand." The latter implies that your 
experience is to be preferred to theirs.




I believe myself (and someone like Nasby) do have a better core 
understanding of development because development is more than some guy 
sitting in a den pushing out code. The community already recognizes 
this, that is why we have the facilities we do now. All I (and others) 
am suggesting is that we make the facilities we have now, work better.



Who exactly is "some guy sitting in a den pushing out code"? And if 
that's not a patronizing put down I don't know what is. If you're 
referring to me you couldn't be more wrong. I have been a development 
director managing a couple of substantial teams, as well as having 
worked in numerous commercial environments.



cheers

andrew


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

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

[Joshua D. Drake]

On 09/30/2015 12:02 AM, Jim Nasby wrote:


If people are hell-bent on every tool being separate then fine, but I
get the distinct impression that everyone is discarding GitLab out of
hand based on completely bogus information.


Right, we need to stop thinking that every task is not interrelated. 
They all are. Although I am not a big fan of the gitlab idea but that is 
more out of ignorance of the software/service than anything else. My 
core focus on this discussion is to educate the -hackers that don't 
understand that all of this is related and to have a bug tracker, and a 
separate commitfest app, and a isolated git server that doesn't interact 
with any of them except through a commit message is broken.


If we can come to a solution that properly links the processes together 
(without outright throwing them out the window), that is the best 
solution. A "bug" tracker doesn't do that. It just adds another piece. 
An issue tracker (as everything including this discussion is an issue) 
works because an issue can be classified and tracked for its purpose.


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

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

[Josh Berkus]

On 09/30/2015 07:44 AM, Merlin Moncure wrote:
> I'm not trolling in any way.  I'm just challenging you to back up your
> blanket assertions with evidence.  For example, you're assertion that
> mailing lists are insufficient is simply stated and expected to be
> taken on faith: *How* is it insufficient and *what* do things like in
> the new world?  Be specific: glossing over these details doesn't
> really accomplish anything and avoids the careful examination that may
> suggest small tweaks to the current processes that could get similar
> results with a lot less effort.  In this entire massive thread, so far
> only Josh has come up with what I'd consider to be actionable problem
> cases.

I don't see any way to make small tweaks to the existing process which
would fix any of these problems.  I think if that were possible, we'd
already have done it.  Suggestions welcome, of course.

For example, "just use the wiki for this" has been mentioned as an
alternative.  But we've tried "just using the wiki" for a number of
things, and it doesn't really work.  For example, using the wiki as a
way of breaking down the various multixact issues manifestly didn't
work.  A big part of the problem there is that there's no good way for
the wiki to notify people when there's been an update; a smaller part is
that the formatting gets messed up and impossible to follow.

> Josh's point, "2. Not losing track of minor bugs." is an example of
> what's bugging (pun intended) me.  Do you think issues don't get lost
> in issue trackers? 

More accurately: losing track of *fewer* minor bugs.

> As I noted upthread google is incredibly efficient at tying up a
> observed issue with the relevant fix and commentary, all based on
> search engine integration with the mailing list that you've summarily
> dismissed (without any evidence whatsoever) as ineffective.

In my experience it has not been effective.  Generally when a client
asks me the question about which release a particular bug is fixed in,
it takes me 15-30 minutes to determine the answer using
google/list/commitlog.  The client would not be able to determine it for
themselves at all.  While I appreciate the billable hours, it doesn't
seem like a good use of the customer's money, you know?

> You're
> just assuming it's better without any examination of the costs
> involved.  For example, implementation and training aside, I expect
> one of the immediate downsides of moving away from google + mailing
> list is that you're going to be suffering from a deluge of duplicate
> issues.

As opposed to duplicate emails, which we already get?

> Note, I'm not picking on Josh here.   The points pertaining to
> querying issues are certainly better than wading through the release
> notes which I've always felt to be kind of a pain.  What I'm driving
> at is that you should identify actual pain points in the process and
> explain clearly how things would improve.  Also, consider low impact
> solutions first (for example what low tech method makes bug
> identification to release easier?) and move into a big tooling change
> only after discarding them.

Well, if you have suggestions that don't involve an email-driven bug
tracker, please make them.  I don't have any other ideas.

-- 
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

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

[Joshua D. Drake]

On 09/30/2015 11:23 AM, Christopher Browne wrote:


It's well and nice to think that an issue tracker resolves all of this,
and, if we
had tiny numbers of issues, we could doubtless construct a repository
indicating so.  (Seems to me that the bit of "fan service" for GitHub's
bug tracker fits into that perspective on things...)


CMD has over a 1000 customers. All of those that are active have a 
Redmine tracker. Our current ticket count is over 70k. Without it, we 
would never be able to service them correctly.


What you describe is not a tool problem, it is a people problem. That 
exists regardless of the tool. The tool is designed to (in theory) make 
the people problem, less.


In CMDs considerable experience while not only developing, consulting, 
writing docs, maintain repos, and confidential information... it would 
be impossible to achieve without Redmine at our core.


JD

(I am sure other tools provide the same level of service, it is just 
what we use)




--
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

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

[Joshua D. Drake]

On 09/30/2015 11:33 AM, Andrew Dunstan wrote:



Who exactly is "some guy sitting in a den pushing out code"? And if
that's not a patronizing put down I don't know what is. If you're
referring to me you couldn't be more wrong. I have been a development
director managing a couple of substantial teams, as well as having
worked in numerous commercial environments.


If I was referencing you, I would say so.

However, all that is off topic to the point of this thread

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

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

[Jim Nasby]

On 9/29/15 3:36 PM, Oleg Bartunov wrote:

 ...What we're not fine with is depending on a proprietary
system, no
 matter what type of license, as infrastructure...


Exactly. Which is why I was warning about latching onto features
only available in the closed enterprise version.

Like Tom, I more or less promised myself not to get terribly
involved in this discussion. Oh, well.


me too, but I have to mention one problem we should have in mind - it's
independency from political games (sanctions).  Think about developers
from Russia, who one day may be blocked by Github, for example.


No one is suggesting we depend on proprietary or closed anything.

Community GitLab is NOT a "free sample". There are literally hundreds[1] 
of people that have submitted code to it.


The only thing I did suggest is that the easiest way to kick the tires 
on it would probably be to just plug into their cloud service. If people 
like it then we'd run our own.


I wish people would at least consider this as an option because it 
integrates a ton of different features together. It has *the potential* 
to eliminate our need to keep maintaining CommitFest and buildfarm and 
could also replace mediawiki.


If people are hell-bent on every tool being separate then fine, but I 
get the distinct impression that everyone is discarding GitLab out of 
hand based on completely bogus information.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Jim Nasby]

On 9/29/15 12:46 PM, Tom Lane wrote:

Andres Freund  writes:

On 2015-09-29 13:40:28 -0400, Tom Lane wrote:

I think you missed my point: gitlab would then believe it's in charge of,
eg, granting write access to that repo.  We could perhaps whack it over
the head till it only does what we want and not ten other things, but
we'd be swimming upstream.



We today already have a github mirror, where exactly the same thing
exists, no?


Sure, there's a mirror out there somewhere.  It has nothing to do with
our core development processes.


There are APIs as well, so it could be driven that way. I suspect it's 
unnecessary though.


BTW, the docs are at http://doc.gitlab.com/ce/.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Josh Berkus]

On 09/30/2015 12:02 AM, Jim Nasby wrote:
> I wish people would at least consider this as an option because it
> integrates a ton of different features together. It has *the potential*
> to eliminate our need to keep maintaining CommitFest and buildfarm and
> could also replace mediawiki.
> 
> If people are hell-bent on every tool being separate then fine, but I
> get the distinct impression that everyone is discarding GitLab out of
> hand based on completely bogus information.

Well, Gitlab was introduced into this dicussion in the context of being
an OSS version of Github Issues.  If it's more than that, you're going
to have to explain.

-- 
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

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

[Alvaro Herrera]

Pavan Deolasee wrote:
> On Wed, Sep 30, 2015 at 2:16 AM, Alvaro Herrera 
> wrote:
> 
> > That's a very good point.  I think Github and other sites are already
> > blocked in countries like India and Cuba.
> 
> Github is not blocked in India and was never as far as I know. Well our
> government recently blocked some porn sites, but (thankfully) they went
> only that far.

This is what I remember:
http://www.zdnet.com/article/india-blocks-32-websites-including-github-internet-archive-pastebin-vimeo/

> But I see Oleg's point. Many things including Google are
> blocked in China for example.

Right.

-- 
Álvaro Herrerahttp://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

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

[Michael Banck]

On Tue, Sep 29, 2015 at 12:08:56PM +1300, Gavin Flower wrote:
> Linux kernel project uses bugzilla (https://bugzilla.kernel.org)

AIUI this is not mandatory for kernel hackers, and more opt-in from a
some/many/a few(?) subsystem maintainers.  Some parts use it more, some
less or not at all.

> and so does LibreOffice (https://bugs.documentfoundation.org)

Thas is true, however. 

Same for freedesktop.org and the Gnome project, I believe.


Michael


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

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

[Kam Lasater]

On Tue, Sep 29, 2015 at 6:39 PM, Josh Berkus  wrote:
> On 09/29/2015 03:08 PM, Merlin Moncure wrote:
>> I've read this email about three times now and it's not clear at all
>> to me what a issue/bug tracker brings to the table.
>
> Here are the problems I'd like to solve:
>
> 1. "Was this issue fixed in a Postgres update?  Which one?"
>
> 2. Not losing track of minor bugs.
>
> 3. Having a better way to track bugs which require multi-part solutions
> (e.g. multixact).
>
> 4. Having a place for downstream projects/packagers to report bugs.
>
> 5. Not answering this question ever again: "Why doesn't your project
> have a bug tracker?"

Merlin,

I'm not sure if you are trolling me/us. I'm going to assume not and
interpret the comment from the prospective of: "the current process
works for those currently using the process"

That may be true (I'll leave it to someone more familiar with the
process to address). What that comment doesn't address is the needs of
those who are not currently involved or those who are not on this
email list. Just as "read the code" is an insufficient answer to a
user who is looking to use a feature, "read the mailing list" is an
insufficient answer to a query from a user about the state of bugs
past and present.

Given that, in addition to Josh's five points from an insider's
perspective I would add some from an outsider's perspective:

1/ Is the issue I'm having a known bug that can be fixed by an upgrade
to a more recent version, if so, which one?

2/ This project must be disorganized and/or not truly mature w/o a
central tracker

3/ No hints or help on what might be an easier place to start contributing

Hope that helps.

-Kam Lasater
@seekayel


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

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

[Josh Berkus]

On 09/30/2015 03:27 PM, Tom Lane wrote:
> Josh Berkus  writes:
>> On 09/30/2015 03:10 PM, Tom Lane wrote:
>>> I'd be feeling a lot more positive about this whole thread if any people
>>> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
>>> something happen here".  The lack of any volunteers suggests strongly
>>> that this thread is a waste of time, just as the several similar ones
>>> before it have been.
> 
>> Hmmm?  Frost volunteered to stand up debbugs.
> 
> So he did, and did anyone volunteer to put data into it, or to do ongoing
> curation of said data?  If we simply connect it up to the mailing lists,
> and then stand back and wait for magic to happen, we will not ever have
> anything that's any more useful than the existing mailing list archives.

Well, it's hard for anyone to volunteer when we don't know what the
actual volunteer tasks are.  I certainly intend to do *something* to
support the bug tracker system, but I don't know yet what that something is.


-- 
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

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

[Tom Lane]

Josh Berkus  writes:
> On 09/30/2015 03:10 PM, Tom Lane wrote:
>> I'd be feeling a lot more positive about this whole thread if any people
>> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
>> something happen here".  The lack of any volunteers suggests strongly
>> that this thread is a waste of time, just as the several similar ones
>> before it have been.

> Hmmm?  Frost volunteered to stand up debbugs.

So he did, and did anyone volunteer to put data into it, or to do ongoing
curation of said data?  If we simply connect it up to the mailing lists,
and then stand back and wait for magic to happen, we will not ever have
anything that's any more useful than the existing mailing list archives.

regards, tom lane


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

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

[Joshua D. Drake]

On 09/30/2015 03:28 PM, Josh Berkus wrote:

On 09/30/2015 03:27 PM, Tom Lane wrote:

Josh Berkus  writes:

On 09/30/2015 03:10 PM, Tom Lane wrote:

I'd be feeling a lot more positive about this whole thread if any people
had stepped up and said "yes, *I* will put in a lot of grunt-work to make
something happen here".  The lack of any volunteers suggests strongly
that this thread is a waste of time, just as the several similar ones
before it have been.



Hmmm?  Frost volunteered to stand up debbugs.


So he did, and did anyone volunteer to put data into it, or to do ongoing
curation of said data?  If we simply connect it up to the mailing lists,
and then stand back and wait for magic to happen, we will not ever have
anything that's any more useful than the existing mailing list archives.


Well, it's hard for anyone to volunteer when we don't know what the
actual volunteer tasks are.  I certainly intend to do *something* to
support the bug tracker system, but I don't know yet what that something is.


Yep. Same here. I would be willing to help (as well as assign resources 
to it) if I knew what "it" was. We certainly would be more likely to 
help if it was on Redmine (due to expertise).


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

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

[Christopher Browne]

On 30 September 2015 at 14:31, Joshua D. Drake  wrote:
>
> On 09/30/2015 11:23 AM, Christopher Browne wrote:
>
>> It's well and nice to think that an issue tracker resolves all of this,
>> and, if we
>> had tiny numbers of issues, we could doubtless construct a repository
>> indicating so.  (Seems to me that the bit of "fan service" for GitHub's
>> bug tracker fits into that perspective on things...)
>
>
> CMD has over a 1000 customers. All of those that are active have a
Redmine tracker. Our current ticket count is over 70k. Without it, we would
never be able to service them correctly.
>
> What you describe is not a tool problem, it is a people problem. That
exists regardless of the tool. The tool is designed to (in theory) make the
people problem, less.
>
> In CMDs considerable experience while not only developing, consulting,
writing docs, maintain repos, and confidential information... it would be
impossible to achieve without Redmine at our core.
>
> JD
>
> (I am sure other tools provide the same level of service, it is just what
we use)

There's nothing there for me to disagree with, which presumably means that
we're somehow talking past each other.

And it's not just "presumably"; there's a clear place for there to be a
disconnect.

It's perfectly reasonable that CMD would (and presumably does) make the
proper curation of Redmine data an informal condition of employment.
People want to stay working at CMD?  They have to keep their issue tracking
data in good form.  At best, they'll experience the wrath of The Drake, and
I'll leave the worst to you!  :-)

That curation effort is entirely more challenging to impose for a project
like PostgreSQL.  If I decline to fill in the RT information (assuming RT
were chosen), there's no basis for someone "firing" me from the PostgreSQL
project.

I'd be entirely surprised to find a "curation-free" system; I've worked
with RT and Bugzilla, and both require some periodic efforts to go back and
make sure issues are kept in good order (for which "curation" is a very
good word).  It's pretty thankless work, which is why open source projects
that use such systems wind up with pretty messy sets of data.

It's not totally a tool problem, but once you've chosen a tool, there's
some concommittant people problems that fall out of the entropy of the
resulting system.  And I think it was reasonable for Merlin to question the
notion of the tool solving the problem.  For a tool to help requires
commitment to curation efforts.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

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

[Merlin Moncure]

On Wed, Sep 30, 2015 at 12:43 PM, Josh Berkus  wrote:
> On 09/30/2015 07:44 AM, Merlin Moncure wrote:
>> I'm not trolling in any way.  I'm just challenging you to back up your
>> blanket assertions with evidence.  For example, you're assertion that
>> mailing lists are insufficient is simply stated and expected to be
>> taken on faith: *How* is it insufficient and *what* do things like in
>> the new world?  Be specific: glossing over these details doesn't
>> really accomplish anything and avoids the careful examination that may
>> suggest small tweaks to the current processes that could get similar
>> results with a lot less effort.  In this entire massive thread, so far
>> only Josh has come up with what I'd consider to be actionable problem
>> cases.
>
> I don't see any way to make small tweaks to the existing process which
> would fix any of these problems.  I think if that were possible, we'd
> already have done it.  Suggestions welcome, of course.
>
> For example, "just use the wiki for this" has been mentioned as an
> alternative.  But we've tried "just using the wiki" for a number of
> things, and it doesn't really work.  For example, using the wiki as a
> way of breaking down the various multixact issues manifestly didn't
> work.  A big part of the problem there is that there's no good way for
> the wiki to notify people when there's been an update; a smaller part is
> that the formatting gets messed up and impossible to follow.

Agree that wiki are mainly suited for documentation.  But they can
also be used to prototype new processes in a hurry or at least sketch
them out.  This is BTW how the commit fest application spawned up more
or less (which I happen to think works quite well).

But this brings up a couple of points and more questions:
*) Every wiki software I've seen, including mediawiki, allows
subscription to pages for changes.  This is pretty much the same model
most issue trackers use BTW except maybe the automatic subscription
rules are a little different.

*) Given that, I'm not sure that issue trackers are really an
improvement on that point.  In fact, fragmentation of communication is
a central complaint I have with them, including JIRA since people have
to subscribe and/or search for things of interest.  Of course, you can
configure them to just always send an email upon every response, but
then I'm thinking, 'why not just use email?'.  Also, I find the
suggestion that any $tool has a better search facility better than
google's to be laughable, except for very structured searches like
'issue type X by version Y'.

*) I only followed the multi-xact saga very loosely, except to see a
lot of angst for a significant bug (or, set of bugs) slipping out.
Are we sure that this problem didn't in fact stem from insufficient
review and/or testing?  And if not, how did using the wiki and/or not
having individual subtasks run through a tracker contribute to the
problem or its handling?  In other words, what does "manifestly didn't
work" mean?

I guess I'm yammering on here, but between us I'd suck the honey out
of an active beehive to have a day job dev process that more closely
resembles what this project uses, and I frequently exclaim so to
whomever is unfortunate enough to walk by.  But the tool brandishing
zealots have taken over, and I spend a non-trivial of the day filling
out various forms and re-explaining things over and over  (and the
rules are even then much relaxed for me, because I'm, you know,
"special").

My take is that this project is pretty well run and has taught me the
credo, "people and processes first, tools second".  The gripes raised
so far seem awfully vague for the most part, TBH.

merlin


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

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

[Tom Lane]

Christopher Browne  writes:
> It may very well be *worse* than that; it seems quite likely to me that if
> an issue tracker is not being continually curated by substantially ALL of
> its users, then you don't get any of those things.  That *is* a lot more
> pessimistic, and considerably likely, as it's pretty certain that members
> of our email-loving community will decline to get involved in curating
> data in some web app.

I think this is really the issue that's being studiously ignored by a
number of participants in this thread.  Simply installing a tracker
accomplishes diddly-squat.  Getting to a point where the information in
the tracker is actually valid, well-organized, etc. will require a LARGE
amount of real work, both up-front and on a continuing basis, and I do not
see where that effort is going to come from.  Anybody who thinks it's just
going to happen is living in a dream world.  Anybody who thinks they can
tell other people to do it, and then it will happen, is living in an
entire fantasy universe (unless, perhaps, they are paying said people to
do what they want).

I'd be feeling a lot more positive about this whole thread if any people
had stepped up and said "yes, *I* will put in a lot of grunt-work to make
something happen here".  The lack of any volunteers suggests strongly
that this thread is a waste of time, just as the several similar ones
before it have been.

regards, tom lane


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

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

[Josh Berkus]

On 09/30/2015 03:10 PM, Tom Lane wrote:
> I'd be feeling a lot more positive about this whole thread if any people
> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
> something happen here".  The lack of any volunteers suggests strongly
> that this thread is a waste of time, just as the several similar ones
> before it have been.

Hmmm?  Frost volunteered to stand up debbugs.

-- 
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

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

[Alvaro Herrera]

Josh Berkus wrote:

> Well, it's hard for anyone to volunteer when we don't know what the
> actual volunteer tasks are.  I certainly intend to do *something* to
> support the bug tracker system, but I don't know yet what that something is.

I volunteer to do something too, as long as I don't have to click on
endless web forms.

-- 
Álvaro Herrerahttp://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

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

[Joshua D. Drake]

On 09/30/2015 03:49 PM, Alvaro Herrera wrote:

Josh Berkus wrote:


Well, it's hard for anyone to volunteer when we don't know what the
actual volunteer tasks are.  I certainly intend to do *something* to
support the bug tracker system, but I don't know yet what that something is.


I volunteer to do something too, as long as I don't have to click on
endless web forms.


I think we all agree (YAY!) that whatever solution that is chosen must 
adhere to the idea of issue management via email.


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

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

[Michael Paquier]

On Thu, Oct 1, 2015 at 7:10 AM, Tom Lane  wrote:
> Christopher Browne  writes:
>> It may very well be *worse* than that; it seems quite likely to me that if
>> an issue tracker is not being continually curated by substantially ALL of
>> its users, then you don't get any of those things.  That *is* a lot more
>> pessimistic, and considerably likely, as it's pretty certain that members
>> of our email-loving community will decline to get involved in curating
>> data in some web app.
>
> I think this is really the issue that's being studiously ignored by a
> number of participants in this thread.  Simply installing a tracker
> accomplishes diddly-squat.  Getting to a point where the information in
> the tracker is actually valid, well-organized, etc. will require a LARGE
> amount of real work, both up-front and on a continuing basis, and I do not
> see where that effort is going to come from.  Anybody who thinks it's just
> going to happen is living in a dream world.  Anybody who thinks they can
> tell other people to do it, and then it will happen, is living in an
> entire fantasy universe (unless, perhaps, they are paying said people to
> do what they want).
> I'd be feeling a lot more positive about this whole thread if any people
> had stepped up and said "yes, *I* will put in a lot of grunt-work to make
> something happen here".  The lack of any volunteers suggests strongly
> that this thread is a waste of time, just as the several similar ones
> before it have been.

Amen. +1.
-- 
Michael


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

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

[Jim Nasby]

On 9/30/15 4:31 PM, Josh Berkus wrote:

On 09/30/2015 12:02 AM, Jim Nasby wrote:

I wish people would at least consider this as an option because it
integrates a ton of different features together. It has *the potential*
to eliminate our need to keep maintaining CommitFest and buildfarm and
could also replace mediawiki.

If people are hell-bent on every tool being separate then fine, but I
get the distinct impression that everyone is discarding GitLab out of
hand based on completely bogus information.


Well, Gitlab was introduced into this dicussion in the context of being
an OSS version of Github Issues.  If it's more than that, you're going
to have to explain.


It started as an OSS version of *Github* (not just Github Issues). It 
appears to have all the major features of github (issues, code review, 
wiki) plus a CI framework.

--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


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

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

[Christopher Browne]

On 30 September 2015 at 12:26, Joshua D. Drake  wrote:
>
> On 09/30/2015 07:44 AM, Merlin Moncure wrote:
>
>> I'm not trolling in any way.  I'm just challenging you to back up your
>> blanket assertions with evidence.  For example, you're assertion that
>> mailing lists are insufficient is simply stated and expected to be
>> taken on faith: *How* is it insufficient and *what* do things like in
>> the new world?
>
>
> I am short on time today but I will take this specific one:
>
> Mailing lists are great for discourse however they do not:
>
> 1. Provide easy access to archived information
> Searching google isn't an answer it is a band-aid
> 2. Provide proper access to valid information
> Ever get an answer, check the link, find out the solution
references a 5 year old version of PostgreSQL and then find out the problem
is fixed in the 9.4 but not 9.3. You are running 9.3.
> (an issue tracker could track this, easily)
> 3. Provide properly linked information across threads
> My favourite is this:
> SUBJECT: Help (was no longer wanting help)
> Now nothing makes sense on the thread. It should be a new issue.
> 4. Using a recent submission as an example:
> j...@idealist.org just submitted 6 patches. They are all based
around making basebackups more useful (specifically pg_basebackup). This is
awesome, but he has created 6 different threads with different discussions
which will likely cause intercommunication between threads.
>
> Using an issue tracker the first patch would be a parent issue
and the subsequent patches would be child issues (that whole dependency
thing). A single click would provide all the information required to
correctly determine what is going on with the series of interrelated
patches. A mailing list does not provide that.
>
> I could go on for a long time with specific examples that our current
model does not serve.

It's well and nice to think that an issue tracker resolves all of this,
and, if we
had tiny numbers of issues, we could doubtless construct a repository
indicating so.  (Seems to me that the bit of "fan service" for GitHub's
bug tracker fits into that perspective on things...)

However, after having seen an RT system with tens of thousands of
tickets, it seems wishful thinking to me to imagine that simply adopting
an issue tracking system does much of anything to resolve these things.

It does not go without rather a lot more more than "mere assertion" that an
issue tracker directly improves those cases.

To the contrary, from what I have seen, if there's not rather a lot of
curation
work continually done on an issue tracking system, you *don't* get any of
those things.

I found with RT that if people were at all sloppy in how problems were
reported/reported on, that you get none of #1, #2, or #3.

It may very well be *worse* than that; it seems quite likely to me that if
an issue tracker is not being continually curated by substantially ALL of
its users, then you don't get any of those things.  That *is* a lot more
pessimistic, and considerably likely, as it's pretty certain that members
of our email-loving community will decline to get involved in curating
data in some web app.

It seems likely to me that there's some value in trying out debbugs,
as it may provide some useful improvements, however imperfect.

Going to something "way better", particularly if it requires widely
distributed curation efforts, won't be better; it'll probably be a waste
of efforts.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

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

[Merlin Moncure]

On Wed, Sep 30, 2015 at 7:17 AM, Kam Lasater  wrote:
> On Tue, Sep 29, 2015 at 6:39 PM, Josh Berkus  wrote:
>> On 09/29/2015 03:08 PM, Merlin Moncure wrote:
>>> I've read this email about three times now and it's not clear at all
>>> to me what a issue/bug tracker brings to the table.
>>
>> Here are the problems I'd like to solve:
>>
>> 1. "Was this issue fixed in a Postgres update?  Which one?"
>>
>> 2. Not losing track of minor bugs.
>>
>> 3. Having a better way to track bugs which require multi-part solutions
>> (e.g. multixact).
>>
>> 4. Having a place for downstream projects/packagers to report bugs.
>>
>> 5. Not answering this question ever again: "Why doesn't your project
>> have a bug tracker?"
>
> I'm not sure if you are trolling me/us. I'm going to assume not and
> interpret the comment from the prospective of: "the current process
> works for those currently using the process"
>
> That may be true (I'll leave it to someone more familiar with the
> process to address). What that comment doesn't address is the needs of
> those who are not currently involved or those who are not on this
> email list. Just as "read the code" is an insufficient answer to a
> user who is looking to use a feature, "read the mailing list" is an
> insufficient answer to a query from a user about the state of bugs
> past and present.
>
> Given that, in addition to Josh's five points from an insider's
> perspective I would add some from an outsider's perspective:
>
> 1/ Is the issue I'm having a known bug that can be fixed by an upgrade
> to a more recent version, if so, which one?
>
> 2/ This project must be disorganized and/or not truly mature w/o a
> central tracker
>
> 3/ No hints or help on what might be an easier place to start contributing

I'm not trolling in any way.  I'm just challenging you to back up your
blanket assertions with evidence.  For example, you're assertion that
mailing lists are insufficient is simply stated and expected to be
taken on faith: *How* is it insufficient and *what* do things like in
the new world?  Be specific: glossing over these details doesn't
really accomplish anything and avoids the careful examination that may
suggest small tweaks to the current processes that could get similar
results with a lot less effort.  In this entire massive thread, so far
only Josh has come up with what I'd consider to be actionable problem
cases.

Josh's point, "2. Not losing track of minor bugs." is an example of
what's bugging (pun intended) me.  Do you think issues don't get lost
in issue trackers?  They absolutely can, and do, even (where I work)
with a full time paid PM who spends her entire day in JIRA managing
this stuff.  Sure, you can do things like run aging reports and all
that but that immediately suggests the questions, 'who is running the
report?'  and 'what are the expected outputs of that report?'.  So I'm
putting it back on you: what "minor bugs" have been missed, and please
clearly explain how an issue tracker would improve the situation with
a little more detail than "Issue tracker, therefore, better".  This
would allow for objective examination of how things might look after
making major process changes.

As I noted upthread google is incredibly efficient at tying up a
observed issue with the relevant fix and commentary, all based on
search engine integration with the mailing list that you've summarily
dismissed (without any evidence whatsoever) as ineffective.  You're
just assuming it's better without any examination of the costs
involved.  For example, implementation and training aside, I expect
one of the immediate downsides of moving away from google + mailing
list is that you're going to be suffering from a deluge of duplicate
issues.

Note, I'm not picking on Josh here.   The points pertaining to
querying issues are certainly better than wading through the release
notes which I've always felt to be kind of a pain.  What I'm driving
at is that you should identify actual pain points in the process and
explain clearly how things would improve.  Also, consider low impact
solutions first (for example what low tech method makes bug
identification to release easier?) and move into a big tooling change
only after discarding them.

merlin


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