Re: [HACKERS] No Issue Tracker - Say it Ain't So!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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. -- 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!
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!
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. -- 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!
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!
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!
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!
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!
On 01/05/2016 06:30 PM, Jim Nasby wrote: On 1/5/16 8:19 PM, Stephen Frost wrote: * 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. FWIW, I think that's a great example of why we'd be much better off with a focus on expanding the community beyond code contributors. There's a couple hundred people on the whole planet with your skill at expanding Postgres itself and probably millions of people that could work on infrastructure. Not a great allocation of resources... ;) I have excellent people right now I could (and would) assign to the task if the task had guidelines. 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!
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!
On 1/5/16 8:19 PM, Stephen Frost wrote: * 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. FWIW, I think that's a great example of why we'd be much better off with a focus on expanding the community beyond code contributors. There's a couple hundred people on the whole planet with your skill at expanding Postgres itself and probably millions of people that could work on infrastructure. Not a great allocation of resources... ;) -- 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, 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!
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!
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!
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!
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!
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!]
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!
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!]
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!]
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!]
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 consistent. > > > 6: Doe
Re: [HACKERS] No Issue Tracker - Say it Ain't So!]
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!]
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!]
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!]
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!
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: [HACKERS] No Issue Tracker - Say it Ain't So!
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.
Re: [HACKERS] No Issue Tracker - Say it Ain't So!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
* 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!
> 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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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!
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. 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!
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
Re: [HACKERS] No Issue Tracker - Say it Ain't So!
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!
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!
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!
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!
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!
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. But I see Oleg's point. Many things including Google are blocked in China for example. Thanks, Pavan -- Pavan Deolasee http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: [HACKERS] No Issue Tracker - Say it Ain't So!
On 09/29/2015 03:46 PM, Tom Lane wrote: Alvaro Herrera writes: 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. In my opinion, this thread is about a bug tracker, not a patch tracker. We already have a patch tracking system which works very well. Mumble ... the CF app works, but I'm not sure if it works "very well". There's some ease-of-use issues I think, though we've now damped them down to the point where the only really major stumbling block is getting a patch into the CF app initially. One thing to think about if we do adopt a bug tracker is how will it interact with the CF app. Ideally, patches that represent responses to issues in the BT would be tracked more or less automatically by both apps, if indeed we don't merge them altogether. That was kind of my point, although I obviously am not making it clear. The idea that we need just a bug tracker is flawed and narrow in thinking. We want something that will integrate into our entire development work flow with minimal disruption. Otherwise we are just building a lot of infrastructure in different places for no reason. Properly configured an issue tracker would service our existing work flow including enhancing the commitfest process as well as helping us track bugs. JD 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!
Alvaro Herrera writes: > 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. > In my opinion, this thread is about a bug tracker, not a patch tracker. > We already have a patch tracking system which works very well. Mumble ... the CF app works, but I'm not sure if it works "very well". There's some ease-of-use issues I think, though we've now damped them down to the point where the only really major stumbling block is getting a patch into the CF app initially. One thing to think about if we do adopt a bug tracker is how will it interact with the CF app. Ideally, patches that represent responses to issues in the BT would be tracked more or less automatically by both apps, if indeed we don't merge them altogether. 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!
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?" Note that all of the above requires a bug *tracker*, that is, a tool which tracks the bug activity which was happening anyway, just makes it more visible. Rather than an Issue Resolution System, which would be intended to remake our workflow. -- 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!
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. In my opinion, this thread is about a bug tracker, not a patch tracker. We already have a patch tracking system which works very well. (We are not able to process all the things we get, but that's a problem of workload, not tooling). Let's not mix things, as that only adds to the confusion. -- Á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!
On Tue, Sep 29, 2015 at 12:42 PM, Joshua D. Drake wrote: > On 09/29/2015 07:25 AM, Merlin Moncure wrote: >> >> On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater wrote: >>> >>> Hello, >>> >>> Last night I heard that Postgres had no issue/bug tracker. At first I >>> thought the guy was trolling me. Seriously, how could this be. Certainly >>> a >>> mature open source project that is the database for a measurable >>> percentage >>> of the internet would have an issue tracker. >>> >>> Sadly, I was not being trolled. I'm new around here so I will keep the >>> preaching to a minimum and cut right to the chase... >>> >>> ___It is time for an issue tracker___ >> >> >> This thread is depressing me. We use all these fancy tools at $work >> and I'm not sure they are much of an improvement over informal >> processes run by capable people. I regularly advocate, pretty much >> to the wind, to use JIRA less and email *more*. The main benefit of >> the system, various reports to corporate taskmasters, seems pretty >> much irrelevant here. If you're advocating introduction of new >> tooling with all the associated processes and complexities, can you >> point to specific breakdowns in the project and exactly how said >> tooling would have helped the situation? > > > From my perspective this is about more than bugs it is about development as > a whole. Here is a very simple problem we have: > > I come to hackers to discuss an idea > idea gets sign off > I submit a patch > *I am told to go over to this commitfest app thing and upload it there* > > Why? That's stupid. I should have submitted the patch to hackers and it > should have been automatically part of my existing thread. > > Someone reviews the patch, decides it needs to be pushed to the next > commitfest > > In theory, at some point I will be informed of that or I will see that it > was pushed to the next commitfest. > > If we were running a properly integrated tracker, I would know that > instantly because the issue would have been updated to the affect and marked > for the next commitfest. > > The next commitfest comes around, and I can't get to the patch changes in > time so it gets pushed to the next release. With a properly integrated issue > tracker, I would immediately see that, be able to comment on it and be able > to see the entire history of the patch. > > Oh... and this can be done all from email as long as the tracker is properly > integrated. > > Bugs can certainly be handled the same way and in some ways better. 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. First, I find it pretty hard to believe that a hypothetical patch author would not know that a patch was or was not submitted in the current framework. Putting that aside, if you insisted an automatic status change notifications, that could be worked into the current commit fest application, right? Note, once done, you'd get that notification with zero extra process effort beyond what we currently do. I also openly wonder how big this problem really is. I haven't submitted all that many patches, but for those I have it's never really been in doubt as to what status they've were in at the time. So, I'll repeat the question: if you want to accomplish with this thread, let's give *specific examples* of project breakdowns we're trying to solve with this tooling. Did a user lose status of a patch? If so, which user?...what patch? 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!
Oleg Bartunov wrote: > 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. That's a very good point. I think Github and other sites are already blocked in countries like India and Cuba. This becomes more pressing as commercial entities are formed in countries like Russia. Surely we do not want PostgresPro developers to be unable to interact with our bugtracker ... We've done an excellent job of keeping our servers far away from any individual jurisdictions, going back many years ago when Marc Fournier decided to host our stuff in Panama for precisely this reason. Nowadays for us it is reasonably simple to move stuff around in case there's trouble in any particular country. I have a very hard time believing we would tie ourselves down for a bug tracker; hosting whatever in our own infrastructure is probably the only reasonable option for us at this point. As Tom said, lesser projects cannot afford this luxury, but we're not giving that away in a jiffy. IANAL -- Á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