Re: [HACKERS] Bug tracker tool we need
>>> -- Bug Submitter: easy-access way for users to submit bugs and check on >>> their status later. > >> Not sure how to handle the first two. Bug submission is always a pita and >> although we could use the fix-bug-later app, it would clutter it as we were >> trying to determine real bugs vs user error. > > And whatever you/we do, be *VERY* aware of the > "pile-of-...-in-the-bugtracker problem". I just happend to have Joel > Spolsky's post come through my RSS reader, where he talked about about > bugtrackers, and suggested: Well, frankly, I don't think we really want to make it easier for the *general public* to submit bugs than it already is. We're already getting enough quality bug reports to keep us busy. And I'm all-too-familiar with the failings of a "bug-losing system"; check the number of bugs I have filed against Thunderbird sometime. Where bug submission is broken that we care about is in two areas: 1. it's very difficult for the existing bug submitters to check status of their bugs after submission, or even find out if they went anywhere (if using the webform). 2. we don't have an API for downstream projects and products to submit bugs, which makes those projects think we don't care about bugs. Note that both of the above could be solved without having a public bugzilla instance. -- 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] Bug tracker tool we need
On Mon, Jul 9, 2012 at 3:26 PM, Joshua D. Drake wrote: > > On 07/09/2012 12:02 PM, Josh Berkus wrote: >> >> >> Hackers, >> >> So I want to repeat this because I think we are conflating several uses >> for a "bug tracker" which aren't the same, and which really need to be >> dealt with seperately. >> >> -- Better CF App: to track feature submissions, discussion, revisions >> and reviews. >> >> -- Bug Submitter: easy-access way for users to submit bugs and check on >> their status later. > Not sure how to handle the first two. Bug submission is always a pita and > although we could use the fix-bug-later app, it would clutter it as we were > trying to determine real bugs vs user error. And whatever you/we do, be *VERY* aware of the "pile-of-...-in-the-bugtracker problem". I just happend to have Joel Spolsky's post come through my RSS reader, where he talked about about bugtrackers, and suggested: - Do not allow more than two weeks (in fix time) of bugs to get into the bug database. - If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back. The biggest problem of whatever tool is used for anything, is making sure tool is useful enough to people that need to use it to make it worth their while. A tracker (of any type) that is even *insanely* useful for users, but that doesn't give *developpers* (note, that's developpers, not managers, or cat-herders, or cheer-leaders) any extra value is bound to fill and soon become un-usefull for even uses.. If you want the develops to use it, it has to be worth their time *to them* to use it. Witness the hundreds of graves that are he thousands bugzilla bugs out there filed against even active open-source projects. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- 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] Bug tracker tool we need
On 07/09/2012 12:02 PM, Josh Berkus wrote: Hackers, So I want to repeat this because I think we are conflating several uses for a "bug tracker" which aren't the same, and which really need to be dealt with seperately. -- Better CF App: to track feature submissions, discussion, revisions and reviews. -- Bug Submitter: easy-access way for users to submit bugs and check on their status later. === -- Fix-Bug-Later Bug Tracker: a place to track bugs which are not immediately fixable due to complexity/breakage/external dependancies/priority. -- Fix Tracker: way for users to search if a particular issue was fixed, and what release it was fixed in. === These two should be able to be the same piece of sotware. -- Testing Tracker: tool for user-testers to submit test reports for development and beta releases. This might be able to be the same piece as fix-bug-later... with a different front end. The above are 5 different tasks with different requirements, and it's far from clear that we want a new tool for all of them (or even want all of them). Not sure how to handle the first two. Bug submission is always a pita and although we could use the fix-bug-later app, it would clutter it as we were trying to determine real bugs vs user error. Sincerely, jD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579 -- 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] Bug tracker tool we need
Hackers, So I want to repeat this because I think we are conflating several uses for a "bug tracker" which aren't the same, and which really need to be dealt with seperately. -- Better CF App: to track feature submissions, discussion, revisions and reviews. -- Bug Submitter: easy-access way for users to submit bugs and check on their status later. -- Fix-Bug-Later Bug Tracker: a place to track bugs which are not immediately fixable due to complexity/breakage/external dependancies/priority. -- Fix Tracker: way for users to search if a particular issue was fixed, and what release it was fixed in. -- Testing Tracker: tool for user-testers to submit test reports for development and beta releases. The above are 5 different tasks with different requirements, and it's far from clear that we want a new tool for all of them (or even want all of them). -- 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] Bug tracker tool we need
On Sat, Jul 7, 2012 at 4:48 PM, Bruce Momjian wrote: > On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote: >> >> That's not to say it's a horrible idea, it's just to say that things >> >> are never as easy as they first look. >> >> >> >> BTW, the *bigger* issue with this path is that now we suddenly have >> >> different kinds of identifiers for different things. So you have a bug >> >> id, and a cf id, and they are different things. So you're going to end >> >> up tagging things with multiple id's. etc. That part goes to show that >> >> we cannot just "solve" this in one part of the workflow. We can put in >> >> useful workarounds that go pretty far - like the cf app - but we >> >> cannot get the "complete solution". OTOH, maybe we never can get the >> >> complete solution, but we should work hard at not locking into >> >> something else. >> > >> > Yes, we would almost need to number each incoming email, and use that >> > reference all the way through to the release note item text. or at least >> > a searchable git log of the release note commits. >> >> Which we in a lot of ways have - we have the messageid. But we need a >> nicer interface for people to use than that... But that serves pretty >> well as an underlying identifier. > > Imagine a case where a single message-id could show all emails before > and after that refer to it, and all commits and release note text > associated with it. I think there are going to be cases where multiple > email threads all represent the same item, of course, and might not be > linked via email references. Yes, that's the part that has to be taken care of by that "thin overlay over email". Some way of grouping multiple threads together,and somehow keep the end-status of them (rejected/comitted/wontfix/whatevryouwantocallthestatus). But not actually keeping a copy of the information anywhere else. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote: > >> That's not to say it's a horrible idea, it's just to say that things > >> are never as easy as they first look. > >> > >> BTW, the *bigger* issue with this path is that now we suddenly have > >> different kinds of identifiers for different things. So you have a bug > >> id, and a cf id, and they are different things. So you're going to end > >> up tagging things with multiple id's. etc. That part goes to show that > >> we cannot just "solve" this in one part of the workflow. We can put in > >> useful workarounds that go pretty far - like the cf app - but we > >> cannot get the "complete solution". OTOH, maybe we never can get the > >> complete solution, but we should work hard at not locking into > >> something else. > > > > Yes, we would almost need to number each incoming email, and use that > > reference all the way through to the release note item text. or at least > > a searchable git log of the release note commits. > > Which we in a lot of ways have - we have the messageid. But we need a > nicer interface for people to use than that... But that serves pretty > well as an underlying identifier. Imagine a case where a single message-id could show all emails before and after that refer to it, and all commits and release note text associated with it. I think there are going to be cases where multiple email threads all represent the same item, of course, and might not be linked via email references. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
On Sat, Jul 7, 2012 at 4:42 PM, Bruce Momjian wrote: > On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote: >> On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout >> wrote: >> > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: >> >> I've never thought of it in terms of "friction", but I think that term >> >> makes a lot of sense. And it sums up pretty much one of the things >> >> that I find the most annoying with the commitfest app - in the end it >> >> boils down to the same thing. I find it annoying that whenever someone >> >> posts a new review or new comments, one has to *also* go into the CF >> >> app and add them there. Which leads to a lot of friction, which in >> >> turn leads to people not actually putting their comments in there, >> >> which decreases the value of the tool. >> >> >> >> Don't get me wrong - the cf app is a huge step up from no app at all. >> >> But it's just not done yet. >> > >> > Well, if that's the issue then there are well known solutions to that. >> > Give each commitfest entry a tag, say, CF#8475 and add a bot to the >> > mail server that examines each email for this tag and if found adds it >> > to the CF app. >> >> So now you moved the friction over to the initial submitter instead, >> because he/she how has to get this tag before posting the patch in the >> first place. And this would need to happen before it's even known if >> this needs to go on a CF or will just be approved/rejected directly >> without even getting there. >> >> That's not to say it's a horrible idea, it's just to say that things >> are never as easy as they first look. >> >> BTW, the *bigger* issue with this path is that now we suddenly have >> different kinds of identifiers for different things. So you have a bug >> id, and a cf id, and they are different things. So you're going to end >> up tagging things with multiple id's. etc. That part goes to show that >> we cannot just "solve" this in one part of the workflow. We can put in >> useful workarounds that go pretty far - like the cf app - but we >> cannot get the "complete solution". OTOH, maybe we never can get the >> complete solution, but we should work hard at not locking into >> something else. > > Yes, we would almost need to number each incoming email, and use that > reference all the way through to the release note item text. or at least > a searchable git log of the release note commits. Which we in a lot of ways have - we have the messageid. But we need a nicer interface for people to use than that... But that serves pretty well as an underlying identifier. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote: > On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout > wrote: > > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: > >> I've never thought of it in terms of "friction", but I think that term > >> makes a lot of sense. And it sums up pretty much one of the things > >> that I find the most annoying with the commitfest app - in the end it > >> boils down to the same thing. I find it annoying that whenever someone > >> posts a new review or new comments, one has to *also* go into the CF > >> app and add them there. Which leads to a lot of friction, which in > >> turn leads to people not actually putting their comments in there, > >> which decreases the value of the tool. > >> > >> Don't get me wrong - the cf app is a huge step up from no app at all. > >> But it's just not done yet. > > > > Well, if that's the issue then there are well known solutions to that. > > Give each commitfest entry a tag, say, CF#8475 and add a bot to the > > mail server that examines each email for this tag and if found adds it > > to the CF app. > > So now you moved the friction over to the initial submitter instead, > because he/she how has to get this tag before posting the patch in the > first place. And this would need to happen before it's even known if > this needs to go on a CF or will just be approved/rejected directly > without even getting there. > > That's not to say it's a horrible idea, it's just to say that things > are never as easy as they first look. > > BTW, the *bigger* issue with this path is that now we suddenly have > different kinds of identifiers for different things. So you have a bug > id, and a cf id, and they are different things. So you're going to end > up tagging things with multiple id's. etc. That part goes to show that > we cannot just "solve" this in one part of the workflow. We can put in > useful workarounds that go pretty far - like the cf app - but we > cannot get the "complete solution". OTOH, maybe we never can get the > complete solution, but we should work hard at not locking into > something else. Yes, we would almost need to number each incoming email, and use that reference all the way through to the release note item text. or at least a searchable git log of the release note commits. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: > >> I do basically agree with this. I was reflecting on the bug tracker > >> issue (or lack thereof) for unrelated reasons earlier today and I > >> think there are some very nice things to recommend the current > >> email-based system, which are the reasons you identify above. Perhaps > >> the area where it falls down is structured searches (such as for > >> "closed" or "wontfix") and tracking progress of related, complex, or > >> multi-part issues that span multiple root email messages. > > > > I normally assume "friction" is just something that slows you down from > > attaining a goal, but open source development is only _possible_ because > > of the low friction communication available via the Internet. It isn't > > that open source development would be slower --- it would probably not > > exist in its current form (think shareware diskettes for an > > alternative). > > I've never thought of it in terms of "friction", but I think that term > makes a lot of sense. And it sums up pretty much one of the things > that I find the most annoying with the commitfest app - in the end it > boils down to the same thing. I find it annoying that whenever someone > posts a new review or new comments, one has to *also* go into the CF > app and add them there. Which leads to a lot of friction, which in > turn leads to people not actually putting their comments in there, > which decreases the value of the tool. For me, we can't just say that our process is the the way it is because we have always done it that way, or because we are too lazy to change it. I think most of us have a gut feeling that our process is good, but we have to have some logic behind why we are doing things differently than most other projects, I think "friction" does explain a lot of it. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout wrote: > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: >> I've never thought of it in terms of "friction", but I think that term >> makes a lot of sense. And it sums up pretty much one of the things >> that I find the most annoying with the commitfest app - in the end it >> boils down to the same thing. I find it annoying that whenever someone >> posts a new review or new comments, one has to *also* go into the CF >> app and add them there. Which leads to a lot of friction, which in >> turn leads to people not actually putting their comments in there, >> which decreases the value of the tool. >> >> Don't get me wrong - the cf app is a huge step up from no app at all. >> But it's just not done yet. > > Well, if that's the issue then there are well known solutions to that. > Give each commitfest entry a tag, say, CF#8475 and add a bot to the > mail server that examines each email for this tag and if found adds it > to the CF app. So now you moved the friction over to the initial submitter instead, because he/she how has to get this tag before posting the patch in the first place. And this would need to happen before it's even known if this needs to go on a CF or will just be approved/rejected directly without even getting there. That's not to say it's a horrible idea, it's just to say that things are never as easy as they first look. BTW, the *bigger* issue with this path is that now we suddenly have different kinds of identifiers for different things. So you have a bug id, and a cf id, and they are different things. So you're going to end up tagging things with multiple id's. etc. That part goes to show that we cannot just "solve" this in one part of the workflow. We can put in useful workarounds that go pretty far - like the cf app - but we cannot get the "complete solution". OTOH, maybe we never can get the complete solution, but we should work hard at not locking into something else. > This could then easily track commit messages, emails on mailing list > and even bug reports. (For example, someone replys to a bug report > with "See CF#8484" and then a reference to the bug thread gets pushed > into the CF app.) All of these things are already "emails on mailing lists", after all... > It's also a searchable identifier, which is also useful for google. Yes, I agree that having a searchable and *referencable* identifier is a good thing. In fact, one of the main reasons to do something like this. Right now we just tell people "look in the archives", and that doesn't work. Heck, *I* search them quite often and I still don't understand how some people can find things so quickly :) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: > I've never thought of it in terms of "friction", but I think that term > makes a lot of sense. And it sums up pretty much one of the things > that I find the most annoying with the commitfest app - in the end it > boils down to the same thing. I find it annoying that whenever someone > posts a new review or new comments, one has to *also* go into the CF > app and add them there. Which leads to a lot of friction, which in > turn leads to people not actually putting their comments in there, > which decreases the value of the tool. > > Don't get me wrong - the cf app is a huge step up from no app at all. > But it's just not done yet. Well, if that's the issue then there are well known solutions to that. Give each commitfest entry a tag, say, CF#8475 and add a bot to the mail server that examines each email for this tag and if found adds it to the CF app. This could then easily track commit messages, emails on mailing list and even bug reports. (For example, someone replys to a bug report with "See CF#8484" and then a reference to the bug thread gets pushed into the CF app.) It's also a searchable identifier, which is also useful for google. We do this at my work, it's a very low barrier method of linking different systems. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer signature.asc Description: Digital signature
Re: [HACKERS] Bug tracker tool we need
On Sat, Jul 7, 2012 at 1:46 AM, Bruce Momjian wrote: > On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote: >> On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian wrote: >> > I think our big gap is in integrating these sections. There is no easy >> > way for a bug reporter to find out what happens to his report unless the >> > patch is applied in the same email thread as the report. It is hard for >> > users to see _all_ the changes made in a release because the release >> > notes are filtered. >> > >> > Our current system is designed to have very limited friction of action, >> > and this give us a high-quality user experience and release quality, but >> > it does have limits in how well we deal with complex cases. >> >> I do basically agree with this. I was reflecting on the bug tracker >> issue (or lack thereof) for unrelated reasons earlier today and I >> think there are some very nice things to recommend the current >> email-based system, which are the reasons you identify above. Perhaps >> the area where it falls down is structured searches (such as for >> "closed" or "wontfix") and tracking progress of related, complex, or >> multi-part issues that span multiple root email messages. > > I normally assume "friction" is just something that slows you down from > attaining a goal, but open source development is only _possible_ because > of the low friction communication available via the Internet. It isn't > that open source development would be slower --- it would probably not > exist in its current form (think shareware diskettes for an > alternative). I've never thought of it in terms of "friction", but I think that term makes a lot of sense. And it sums up pretty much one of the things that I find the most annoying with the commitfest app - in the end it boils down to the same thing. I find it annoying that whenever someone posts a new review or new comments, one has to *also* go into the CF app and add them there. Which leads to a lot of friction, which in turn leads to people not actually putting their comments in there, which decreases the value of the tool. Don't get me wrong - the cf app is a huge step up from no app at all. But it's just not done yet. >> Maybe just using the message-ids to cross reference things (or at >> least morally: perhaps a point of indirection as to collapse multiple >> bug reports about the same thing, or to provide a place to add more >> annotation would be good, not unlike the CommitFest web application in >> relation to emails) is enough. Basically, perhaps an overlay >> on-top-of email might be a more supple way to figure out what process >> improvements work well without committing to a whole new tool chain >> and workflow all at once. > > I know there is work to allow cross-month email archive threading, and > that might help. Yup, it's being worked on. FWIW, somewhere there's a piece of bugtracker code in a dusty corner that I once wrote that was intended as a prototype for something sitting as this "thin overlay on top of email". It worked reasonably well, and then crashed and burned when it came to the cross-month thread splitting. Once that is fixed (and unlike most times before (yes, there are exceptions) it's being actively worked on right now), it could be dusted off again - or something else could be built on top of that capability. > I feel we have to be honest in what our current development process does > poorly. +1. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Fri, Jul 6, 2012 at 6:41 PM, Daniel Farina wrote: > I do basically agree with this. I was reflecting on the bug tracker > issue (or lack thereof) for unrelated reasons earlier today and I > think there are some very nice things to recommend the current > email-based system, which are the reasons you identify above. Perhaps > the area where it falls down is structured searches (such as for > "closed" or "wontfix") and tracking progress of related, complex, or > multi-part issues that span multiple root email messages. > > Maybe just using the message-ids to cross reference things (or at > least morally: perhaps a point of indirection as to collapse multiple > bug reports about the same thing, or to provide a place to add more > annotation would be good, not unlike the CommitFest web application in > relation to emails) is enough. Basically, perhaps an overlay > on-top-of email might be a more supple way to figure out what process > improvements work well without committing to a whole new tool chain > and workflow all at once. +1. This is almost word-for-word how I feel about it myself. -- 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] Bug tracker tool we need
On Fri, Jul 06, 2012 at 08:44:13PM -0400, Christopher Browne wrote: > I wonder if maybe the nearest step towards "better bug tracker" is a more > readily referenceable mail archive. > > Clearly, one of our "frictions" is searching for relevant messages, so > improved > mail archive == lowered friction, no? > > There's a very particular use case; people keep rueing that indexes get cut > off > on a monthly basis. That's doubtless not the only pain, but it keeps getting > mentioned, so solving it seems valuable. Agreed. I think Magnus is working on having the threads span months. The big question is what are we going to do with this ability once we get it. > Having a correlation between commits, commitfest entries, and associated email > seems like another valuable addition. Yep. > Perhaps there are more... I'm not yet poking at anything that would suggest > "email database", either. > > A lot of the analysis would be more network-oriented; putting more of a Prolog > hat on, not so much tabular / relational ... To put a finer point on this, I think projects that interact with users via a bug tracker have much poorer user/developer communication, and also less impetus to fix bugs quickly, because it is already recorded in the tracker. And after not dealing with bugs immediately for a while, the bug database becomes huge, and developers can only triage the database, fixing commonly-reported bugs, and leaving the rest for later, which effectively means never. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
I wonder if maybe the nearest step towards "better bug tracker" is a more readily referenceable mail archive. Clearly, one of our "frictions" is searching for relevant messages, so improved mail archive == lowered friction, no? There's a very particular use case; people keep rueing that indexes get cut off on a monthly basis. That's doubtless not the only pain, but it keeps getting mentioned, so solving it seems valuable. Having a correlation between commits, commitfest entries, and associated email seems like another valuable addition. Perhaps there are more... I'm not yet poking at anything that would suggest "email database", either. A lot of the analysis would be more network-oriented; putting more of a Prolog hat on, not so much tabular / relational ...
Re: [HACKERS] Bug tracker tool we need
On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote: > On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian wrote: > > I think our big gap is in integrating these sections. There is no easy > > way for a bug reporter to find out what happens to his report unless the > > patch is applied in the same email thread as the report. It is hard for > > users to see _all_ the changes made in a release because the release > > notes are filtered. > > > > Our current system is designed to have very limited friction of action, > > and this give us a high-quality user experience and release quality, but > > it does have limits in how well we deal with complex cases. > > I do basically agree with this. I was reflecting on the bug tracker > issue (or lack thereof) for unrelated reasons earlier today and I > think there are some very nice things to recommend the current > email-based system, which are the reasons you identify above. Perhaps > the area where it falls down is structured searches (such as for > "closed" or "wontfix") and tracking progress of related, complex, or > multi-part issues that span multiple root email messages. I normally assume "friction" is just something that slows you down from attaining a goal, but open source development is only _possible_ because of the low friction communication available via the Internet. It isn't that open source development would be slower --- it would probably not exist in its current form (think shareware diskettes for an alternative). So, while it is hopeful to think of a bug trackers as just slowing us down, it might really alter our ability to develop software. Yes, I know most other projects use bug trackers, but I doubt their development and user interactions are the same quality as ours. On the flip side, for complex cases, some of our user interactions are terrible. > Maybe just using the message-ids to cross reference things (or at > least morally: perhaps a point of indirection as to collapse multiple > bug reports about the same thing, or to provide a place to add more > annotation would be good, not unlike the CommitFest web application in > relation to emails) is enough. Basically, perhaps an overlay > on-top-of email might be a more supple way to figure out what process > improvements work well without committing to a whole new tool chain > and workflow all at once. I know there is work to allow cross-month email archive threading, and that might help. I feel we have to be honest in what our current development process does poorly. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian wrote: > I think our big gap is in integrating these sections. There is no easy > way for a bug reporter to find out what happens to his report unless the > patch is applied in the same email thread as the report. It is hard for > users to see _all_ the changes made in a release because the release > notes are filtered. > > Our current system is designed to have very limited friction of action, > and this give us a high-quality user experience and release quality, but > it does have limits in how well we deal with complex cases. I do basically agree with this. I was reflecting on the bug tracker issue (or lack thereof) for unrelated reasons earlier today and I think there are some very nice things to recommend the current email-based system, which are the reasons you identify above. Perhaps the area where it falls down is structured searches (such as for "closed" or "wontfix") and tracking progress of related, complex, or multi-part issues that span multiple root email messages. Maybe just using the message-ids to cross reference things (or at least morally: perhaps a point of indirection as to collapse multiple bug reports about the same thing, or to provide a place to add more annotation would be good, not unlike the CommitFest web application in relation to emails) is enough. Basically, perhaps an overlay on-top-of email might be a more supple way to figure out what process improvements work well without committing to a whole new tool chain and workflow all at once. -- fdr -- 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 10:29:26AM -0400, Robert Haas wrote: > >> IME, bug trackers typically work best when used by a tightly > >> integrated team. > > > > Well, very many loosely distributed open-source projects use bug > > trackers quite successfully. > > > >> So I think Greg has exactly the right idea: we shouldn't try to > >> incorporate one of these systems that aims to manage workflow; > > > > Um, isn't half of the commitfest app about workflow? Patch is waiting > > for review, who is the reviewer, patch is waiting for author, who is the > > author, patch is ready for committer, who is the committer? And every > > week or so the commitfest manager (if any) produces a report on patch > > progress. Isn't that exactly what these "workflow management" systems > > provide? > > Yeah, but I thought we'd veered off into a digression about tracking > bug reports. Here's our workflow for bugs: > > 1. If they seem interesting, Tom fixes them. > 2. Or occasionally someone else fixes them. > 3. Otherwise, they drift forever in the bleakness of space. > > I've been conducting the experiment for a year or two now of leaving > unresolved bug reports unread in my mailbox. I've got over 100 such > emails now... and some of them may not really be bugs, but nobody's > put in the work to figure that out. It would be useful to have a I saved this email from April and have given it some thought. I decided to approach it by looking at our current workflow, then deciding what the problems were, rather than approaching it with "we need a bug tracker". I started by drawing a diagram of our current development process: http://momjian.us/main/writings/pgsql/work_flow.pdf I did this so I could see the weaknesses. First, the left and right sides are what our users see, and the middle is controlled by developers. Looking at the chart, the three sections, left, middle, and right, seem to work fine in isolation. Our interaction with bug reporters is very good, our development flow seems fine, and people are certainly happy with the quality of our releases. Yes, there are problems, like the ability of patches to get lost, but in general, things are good. I think our big gap is in integrating these sections. There is no easy way for a bug reporter to find out what happens to his report unless the patch is applied in the same email thread as the report. It is hard for users to see _all_ the changes made in a release because the release notes are filtered. Our current system is designed to have very limited friction of action, and this give us a high-quality user experience and release quality, but it does have limits in how well we deal with complex cases. OK, now for the question about a bug tracker. A bug tracker would provide a track-able contact for everyone reporting a bug, and allow them to see exactly what release fixes the bug (in an ideal world). It also allows for more detailed reporting of what is each release. For me, the big problem with a bug trackers is that it adds so much friction to the development process, meaning fewer people are involved and less work gets done. If you have company-sponsored development, you can just hire more people to overcome that friction, but for volunteer development, I am not sure a bug tracker really works well, and given the chaotic content in almost every bug tracker database, I think that is true. So, my question is, what can we do to better integrate these sections? Assign a bug number on email that gets stamped on the commit and release note item? Add email notification of commits somehow? Should we publish the entire git log for each release? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 05:08:06PM +0300, Peter Eisentraut wrote: > On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote: > > Maybe I'm confused - Magnus et al, are we talking spammy issues/issue > > comments/etc, or are we talking more about exposed email addresses? > > My github.com account currently has 4264 notifications in the inbox. > Almost all of those are spam, growing constantly. Because of that, the > platform is currently fairly useless to me for actually communicating or > collaborating on code. FYI, I just looked and my notification counter brown popup box has an infinity symbol in it: https://github.com/inbox/notifications -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Bug tracker tool we need
On 04/19/2012 03:05 PM, Tom Lane wrote: Andrew Dunstan writes: At any rate, I found that my spam went to nil by turning off notifications for comments on my commits and comments that mention me. The first part of that seems like it would destroy most of the point of having the mechanism at all? Yes, the notification piece is pretty much useless, because of the spammers. I use github as a convenient place to stash public repositories (e.g. buildfarm code), and PostgreSQL Experts uses it for both public and private repos, but if people want me to get their comments they need to go to the trouble of emailing me. 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] Bug tracker tool we need
Andrew Dunstan writes: > At any rate, I found that my spam went to nil by turning off > notifications for comments on my commits and comments that mention me. The first part of that seems like it would destroy most of the point of having the mechanism at all? 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] Bug tracker tool we need
On 04/19/2012 11:25 AM, Christopher Browne wrote: The vast majority of the spam I have originates in the postgresql git repository. You don't have any commits there... But I would've assumed it should hit equally hard on other repositories that's been around a long time. I have plenty of commits on the Slony Git repo, which has had clones at github for about as long as PostgreSQL has. And I don't get any noticeable amounts of spam at github. Not all notifications are hugely interesting, but I don't see anything that's not reasonably related to things I have commented on. So I think there has to be some other effect in play. The spammers pick certain well known projects, I believe. At any rate, I found that my spam went to nil by turning off notifications for comments on my commits and comments that mention me. 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] Bug tracker tool we need
On Thu, Apr 19, 2012 at 10:49 AM, Magnus Hagander wrote: > On Thu, Apr 19, 2012 at 16:45, Greg Sabino Mullane wrote: >> My github.com account currently has 4264 notifications in the inbox. Almost all of those are spam, growing constantly. �Because of that, the platform is currently fairly useless to me for actually communicating or collaborating on code. >>> >>> That's about the same amount that I have. >> >> I have no spam at all, despite being a fairly early github adopter. >> Wonder what the difference is? > > The vast majority of the spam I have originates in the postgresql git > repository. You don't have any commits there... > > But I would've assumed it should hit equally hard on other > repositories that's been around a long time. I have plenty of commits on the Slony Git repo, which has had clones at github for about as long as PostgreSQL has. And I don't get any noticeable amounts of spam at github. Not all notifications are hugely interesting, but I don't see anything that's not reasonably related to things I have commented on. So I think there has to be some other effect in play. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- 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] Bug tracker tool we need
On Thu, Apr 19, 2012 at 16:45, Greg Sabino Mullane wrote: > >>> My github.com account currently has 4264 notifications in the inbox. >>> Almost all of those are spam, growing constantly. �Because of that, the >>> platform is currently fairly useless to me for actually communicating or >>> collaborating on code. >> >> That's about the same amount that I have. > > I have no spam at all, despite being a fairly early github adopter. > Wonder what the difference is? The vast majority of the spam I have originates in the postgresql git repository. You don't have any commits there... But I would've assumed it should hit equally hard on other repositories that's been around a long time. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> My github.com account currently has 4264 notifications in the inbox. >> Almost all of those are spam, growing constantly. �Because of that, the >> platform is currently fairly useless to me for actually communicating or >> collaborating on code. > > That's about the same amount that I have. I have no spam at all, despite being a fairly early github adopter. Wonder what the difference is? - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201204191044 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAk+QJO4ACgkQvJuQZxSWSsg7OgCggq2MVw10W2+XxCyoDSdbjTYP JOAAoLVJeX/V5j1h8r0dpvyJAw9/O+BU =puT/ -END PGP SIGNATURE- -- 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] Bug tracker tool we need
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > So I think Greg has exactly the right idea: we shouldn't try to > incorporate one of these systems that aims to manage workflow; we > should just design something really simple that tracks what happened > and lets people who wish to volunteer to do so help keep that tracking > information up to date. Note: the above is the other Greg :) If we are serious about building this ourselves, and we feel it is important, maybe we should sponsor it via our group funds or some other means? Seems like everyone here has lots of ideas but little free time. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201204191031 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAk+QIeUACgkQvJuQZxSWSsi5NACg4ruX3jvuQ5zKnxbBPu2Kc9wW C+EAoPsIt2n0bbYau/aPhPbVdm+JPHj3 =j1XN -END PGP SIGNATURE- -- 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] Bug tracker tool we need
Excerpts from Tom Lane's message of mié abr 18 03:12:09 -0300 2012: > > Magnus Hagander writes: > > I think this cleraly outlines that we need to remember that there are > > *two* different patterns that people are trying tosolve with the > > bugtracker. > > Yeah, remember we drifted to this topic from discussion of management of > CF patches, which might be yet a third use-case. It's not obvious that > it's the same as tracking unfixed bugs, at least; though maybe the > requirements end up the same. > > > Any tool we'd go for should aim to cover *both* usecases. > > Not convinced that we should expect one tool to be good at both > (or all three) things. So maybe we need more than one tool to present the information to different kinds of users, but we need only *one* database backing them all, right? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Bug tracker tool we need
Am 18.04.2012 14:28, schrieb Robert Haas: So I think Greg has exactly the right idea: we shouldn't try to incorporate one of these systems that aims to manage workflow; we should just design something really simple that tracks what happened and lets people who wish to volunteer to do so help keep that tracking information up to date. I tested a lot tools for bug / issue tracking and I figured out that almost all of them either have had too much overhead or not really were made for database business. Additionally more often the sentence "we support PostgreSQL" just was a marketing trap. Means I figured out that the PostgreSQL support totally sucked. My opinion is that a tool should mirror your business and not that you build your business around the given tool. Looking for a bug tracking too - there are some points that are mandatory for us: 1. it should run on PostgreSQL 2. it should be open source - if possible BSD license - if possible there shouldn't be a single company behind it 3. it should be user friendly - no need to click here and there to get all informations 4. It should be able to communicate with our version control system - when we get the idea to move away from git to something else - it should be able by just a few changes that the tool will communicate with the new system 5. it should be possible to do almost all via email My personal dream would be that it would be possible to do almost all via irc bot but that is fiction. I think a tool should be slim and simple. It should exactly do what you want to do. You should be able to change the tool code that way that it exactly is doing what you want to do. Let me give you an example: bugs.mysql.com might be far away from being perfect. It is slim - and on developer side it has had all that the development needed. My information is that originally they took the code from the php bug tracking system and recoded it / implemented features so that it was doing a good job on database bugs. When the developers needed tool changes or additionally features then they just were coded. I never heard a developer saying that he hates the system. There just were lots of ideas how this or that could be solved better. That is normal - when you are working with the tool every day - of course you will get ideas what could be solved better. So yes - I think Greg is right. We should design something really simple that exactly is doing what we need. With some luck we might not need to start from scratch. Maybe there is a tool outside that is slim and good enough to deliver the base code on which we can start recoding. Just my 2ct, Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 1:48 PM, Magnus Hagander wrote: > The problem I've found with most tools is that they work reasonably > well if you let them control the entire workflow. But when you want to > do things your own way, and it doesn't match up with what they were > originally designed to do, it all comes falling down quickly... That's pretty much characteristic of the average SAP R/3 project. If you can change the organization's business processes to follow SAP's defined "best practices," then it's easy to install and use R/3. But that normally not being the case, every "SAP project" winds up having hideous customization costs to kludge the practices towards one another. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- 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] Bug tracker tool we need
On 04/18/2012 01:26 PM, Robert Haas wrote: On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus wrote: BTW, given our heavy reliance on email, let me put a word in here for RT, which is 100% email-driven. RT has other limitations, but if your goal is to never log into a web interface, it's hard to beat. If your goal is to never log into a good web interface, it's even harder to beat. I actually don't mind logging into a web interface to update information. That doesn't slow me down much, as long as I can still also email *without* using the web interface. Now, RT's web interface is poor. But, if that's what everyone else likes, I could tolerate it. I think it's just frightful, TBH. And I do use the web for tracker interaction. 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 19:17, Stefan Kaltenbrunner wrote: > On 04/17/2012 11:29 PM, Andrew Dunstan wrote: >> >> >> On 04/17/2012 04:38 PM, Tom Lane wrote: >>> Jay Levitt writes: Greg Smith wrote: > Tracking when and how a bug is backported to older versions is one > hard part > of the problem here. That's a great point. Both GitHub and git itself have no real concept of releases, and can't tell you when a commit made it in. >>> We do actually have a somewhat-workable solution for that, see >>> src/tools/git_changelog. It relies on cooperation of the committers >>> to commit related patches with the same commit message and more or >>> less the same commit time, but that fits fairly well with our practices >>> anyway. If we did have an issue tracker I could see expecting commit >>> messages to include a reference to the issue number, and then it would >>> not be hard to adapt this program to key on that instead of matching >>> commit message texts. >>> >>> >> >> >> Yeah, that would be good. >> >> BTW, since we're discussing trackers yet again, let me put in a plug for >> Bugzilla, which has mature Postgres support, is written in Perl (which a >> large number of hackers are familiar with and which we use extensively), >> has a long history and a large organization behind it (Mozilla) and last >> but not least has out of the box support for creating updating and >> closing bugs via email (I just set up an instance of the latest release >> with this enabled to assure myself that it works, and it does.) It also >> has XML-RPC and JSON-RPC interfaces, as well as standard browser >> support, although I have not tested the RPC interfaces. > > years ago when I did the PoC install for PostgreSQL i used the > RPC-Interface for replacing the bug-reporting form on the main website, > it was prett ylimited back then (especially around authentication and a > way to actually make the report show up with the reporters name (which > very likely does not have a BZ account), but all those were solvable. BZ > really has the drawback that it is kind of a monster on the featureside > and you need to invest some significant time to make the UI > understandable before you can actually present it to a wider audience. What I saw from it, it would take more time and work to make the UI understandable and workable, and to get it to adapt to *our* process and workflow than to design a whole new tool from scratch... The problem I've found with most tools is that they work reasonably well if you let them control the entire workflow. But when you want to do things your own way, and it doesn't match up with what they were originally designed to do, it all comes falling down quickly... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 16:08, Peter Eisentraut wrote: > On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote: >> Maybe I'm confused - Magnus et al, are we talking spammy issues/issue >> comments/etc, or are we talking more about exposed email addresses? > > My github.com account currently has 4264 notifications in the inbox. > Almost all of those are spam, growing constantly. Because of that, the > platform is currently fairly useless to me for actually communicating or > collaborating on code. That's about the same amount that I have. And yeah, it works great for hosting git repos. And it works great for browsing git repos and viewing differences and networks. But anything to do with pull requests, issues, comments or anything like that is completely useless these days. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 08:12, Tom Lane wrote: > Magnus Hagander writes: >> I think this cleraly outlines that we need to remember that there are >> *two* different patterns that people are trying tosolve with the >> bugtracker. > > Yeah, remember we drifted to this topic from discussion of management of > CF patches, which might be yet a third use-case. It's not obvious that > it's the same as tracking unfixed bugs, at least; though maybe the > requirements end up the same. > >> Any tool we'd go for should aim to cover *both* usecases. > > Not convinced that we should expect one tool to be good at both > (or all three) things. True. That means that it's more important than ever that whatever tools are used "plays well with others". Which in my experience very few of the existing trackers out there actually do. That can of course have changed since I last looked, but I have been very discouraged previously when looking, both for in the postgresql context and in others. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus wrote: > BTW, given our heavy reliance on email, let me put a word in here for > RT, which is 100% email-driven. RT has other limitations, but if your > goal is to never log into a web interface, it's hard to beat. If your goal is to never log into a good web interface, it's even harder to beat. I actually don't mind logging into a web interface to update information. That doesn't slow me down much, as long as I can still also email *without* using the web interface. Now, RT's web interface is poor. But, if that's what everyone else likes, I could tolerate it. -- 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] Bug tracker tool we need
On 04/17/2012 11:29 PM, Andrew Dunstan wrote: > > > On 04/17/2012 04:38 PM, Tom Lane wrote: >> Jay Levitt writes: >>> Greg Smith wrote: Tracking when and how a bug is backported to older versions is one hard part of the problem here. >>> That's a great point. Both GitHub and git itself have no real concept of >>> releases, and can't tell you when a commit made it in. >> We do actually have a somewhat-workable solution for that, see >> src/tools/git_changelog. It relies on cooperation of the committers >> to commit related patches with the same commit message and more or >> less the same commit time, but that fits fairly well with our practices >> anyway. If we did have an issue tracker I could see expecting commit >> messages to include a reference to the issue number, and then it would >> not be hard to adapt this program to key on that instead of matching >> commit message texts. >> >> > > > Yeah, that would be good. > > BTW, since we're discussing trackers yet again, let me put in a plug for > Bugzilla, which has mature Postgres support, is written in Perl (which a > large number of hackers are familiar with and which we use extensively), > has a long history and a large organization behind it (Mozilla) and last > but not least has out of the box support for creating updating and > closing bugs via email (I just set up an instance of the latest release > with this enabled to assure myself that it works, and it does.) It also > has XML-RPC and JSON-RPC interfaces, as well as standard browser > support, although I have not tested the RPC interfaces. years ago when I did the PoC install for PostgreSQL i used the RPC-Interface for replacing the bug-reporting form on the main website, it was prett ylimited back then (especially around authentication and a way to actually make the report show up with the reporters name (which very likely does not have a BZ account), but all those were solvable. BZ really has the drawback that it is kind of a monster on the featureside and you need to invest some significant time to make the UI understandable before you can actually present it to a wider audience. 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus wrote: >> 3. Otherwise, they drift forever in the bleakness of space. Seems to me that this line, is pretty close to being T-shirt-worthy. > wontfix. We don't need a system to help us ignore bug reports; our >> existing process handles that with admirable efficiency. > > I think I have this year's pgCon T-Shirt quote. ;-) Not bad, sir, not bad... -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- 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] Bug tracker tool we need
Robert, Peter, all: >>> IME, bug trackers typically work best when used by a tightly >>> integrated team. >> >> Well, very many loosely distributed open-source projects use bug >> trackers quite successfully. ... most of them, actually. >> Um, isn't half of the commitfest app about workflow? Patch is waiting >> for review, who is the reviewer, patch is waiting for author, who is the >> author, patch is ready for committer, who is the committer? And every >> week or so the commitfest manager (if any) produces a report on patch >> progress. Isn't that exactly what these "workflow management" systems >> provide? > > Yeah, but I thought we'd veered off into a digression about tracking > bug reports. Here's our workflow for bugs: I think assuming we can use the *same* tool for the CommitFests as for tracking bug reports would be a mistake. The workflow for both things is very different. > 1. If they seem interesting, Tom fixes them. > 2. Or occasionally someone else fixes them. > 3. Otherwise, they drift forever in the bleakness of space. Well, that *is* a workflow, even if it's a very simple one. And it could (should) be handled by a very simple bug tracker with a very simple workflow; as much as it irritates me otherwise, Bugzilla does this with its 4-5 bug "statuses", although the whole "assignment" approach wouldn't really work for us. Frankly, the concept of "assignment" doesn't work very well for OSS projects, period, in my experience. Often as not, it simply means that one person is ignoring the bug instead of a whole group of people. So a simple bug tracker which has four statuses ( "Submitted","Verified","Fixed","Invalid") would describe our entire bug workflow. Pretty much every bugtracker available can do this minimal level of bug tracking. BTW, given our heavy reliance on email, let me put a word in here for RT, which is 100% email-driven. RT has other limitations, but if your goal is to never log into a web interface, it's hard to beat. > wontfix. We don't need a system to help us ignore bug reports; our > existing process handles that with admirable efficiency. I think I have this year's pgCon T-Shirt quote. ;-) -- 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] Bug tracker tool we need
On 04/18/2012 11:29 AM, Kevin Grittner wrote: Peter Eisentraut wrote: On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote: I wonder why do people keep complaining how their bug tracker of choice sucks, instead of doing something about that. Lack of time, and to some degree a lack of clarity of what they want out of the thing. (Most people are very clear on what they don't want.) Personally, I haven't worked with one which had the data organized in what I would consider a sensible and useful way. Part of the trouble is that the whole area is fuzzy. So any organization that imposes some sort of order on the data will not fit well in some cases. Most tracker systems have ended up either trying to cater for increasingly complex and varied circumstances, or staying simple and more or less throwing in the towel on the complexity problem. That doesn't necessarily mean that it's not worth having a tracker, just that we need to recognize the limitations. 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] Bug tracker tool we need
Peter Eisentraut wrote: > On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote: >> I wonder why do people keep complaining how their bug tracker of >> choice sucks, instead of doing something about that. > > Lack of time, and to some degree a lack of clarity of what they > want out of the thing. (Most people are very clear on what they > don't want.) Personally, I haven't worked with one which had the data organized in what I would consider a sensible and useful way. In my view there should be a *problem* report table, to describe the problem from a user perspective. What the user experienced, without any attempt to explain why. Error messages, steps to reproduce, environments in which it's been seen, independent confirmation of behavior, etc. This would be what you would primarily want to search when you hit a bug. There would be a separate table for an analysis of each contributing *cause* of the observed behavior. Describe why it caused or contributed to the observed behavior. There should be a list of these which exist independently of the problem statement, so that you can reference several causes for a problem report, and the cause can be linked from multiple reports. Each cause should include a separate section for user-oriented explanation of what to do when confronted by this issue -- limitations, workarounds, alternative approaches, documentation to read, etc. Each cause should maybe have a "Not a bug" check-box. Through a table linking problems to causes, not only could one easily look at all the contributing causes for a problem report, but all the problem reports with a given cause. In a field separate from the analysis, there could be a summary of what the community consensus on a solution is. Each cause should have a (possibly empty) *task* list describing what would need to be done by the community for resolution. Tasks would exist independently of problem statements or cause analysis and could be shared among various causes. (Of course, this being a relational database, one could easily find the related problem and cause rows that a to-do addressed.) I'm less clear on how work-flow management and resolution data would tie in, but it seems like there's plenty to attach that to. The muddling of problem description, cause analysis, solution design, tasks needed for correction, and assignments to tasks has been an insurmountable problem in the systems I've used so far (although there are a great many I've never seen, so maybe someone has this in what I would consider a reasonable structure). Any system which starts with a "problem description" and "solution description" as big text blobs and then jumps to a list of "assignments" (as one product I have to use) is hopelessly broken from the start, IMO. Now, possibly the problem is that other people think the above would be horrible for them, and that there *is* no design that works for everyone; but the above seems to me to model reality much better than any bug-tracking system I've used so far. And, as an aside, I think that calling an approach an anti-pattern is too often a cheap way to avoid serious thought about an issue which merits it, while pretending to the moral high ground. Better to leave that aside and stick to remarks with actual meaning and content. In other words, declaring something to be anti-pattern is, IMO, an anti-pattern. -Kevin -- 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 10:15 AM, Peter Eisentraut wrote: > On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote: >> It's very tempting to assume that the problem we're trying to solve >> must already have been well-solved by someone else, and therefore we >> ought to use their thing instead of inventing our own. But that >> presumes that our problem is exactly the same as other people's >> problem, which may not really be true. > > It's also very tempting to assume the opposite. ;-) Fair enough. >> IME, bug trackers typically work best when used by a tightly >> integrated team. > > Well, very many loosely distributed open-source projects use bug > trackers quite successfully. > >> So I think Greg has exactly the right idea: we shouldn't try to >> incorporate one of these systems that aims to manage workflow; > > Um, isn't half of the commitfest app about workflow? Patch is waiting > for review, who is the reviewer, patch is waiting for author, who is the > author, patch is ready for committer, who is the committer? And every > week or so the commitfest manager (if any) produces a report on patch > progress. Isn't that exactly what these "workflow management" systems > provide? Yeah, but I thought we'd veered off into a digression about tracking bug reports. Here's our workflow for bugs: 1. If they seem interesting, Tom fixes them. 2. Or occasionally someone else fixes them. 3. Otherwise, they drift forever in the bleakness of space. I've been conducting the experiment for a year or two now of leaving unresolved bug reports unread in my mailbox. I've got over 100 such emails now... and some of them may not really be bugs, but nobody's put in the work to figure that out. It would be useful to have a system that would keep track of which ones those are so people could look over them and maybe get inspired to go do some bug-fixing, or at least bug-analysis, but what good is workflow going to do us? We could "assign" all those bugs to people who are "supposed" to look at them, and maybe some of those people would actually do it, but a more likely outcome is that everybody's list of assigned issues would slowly converge to infinity, or they'd just start closing them as wontfix. We don't need a system to help us ignore bug reports; our existing process handles that with admirable efficiency. -- 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] Bug tracker tool we need
On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote: > I wonder why do people keep complaining how their bug tracker of > choice sucks, instead of doing something about that. Lack of time, and to some degree a lack of clarity of what they want out of the thing. (Most people are very clear on what they don't want.) -- 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] Bug tracker tool we need
On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote: > It's very tempting to assume that the problem we're trying to solve > must already have been well-solved by someone else, and therefore we > ought to use their thing instead of inventing our own. But that > presumes that our problem is exactly the same as other people's > problem, which may not really be true. It's also very tempting to assume the opposite. ;-) > IME, bug trackers typically work best when used by a tightly > integrated team. Well, very many loosely distributed open-source projects use bug trackers quite successfully. > So I think Greg has exactly the right idea: we shouldn't try to > incorporate one of these systems that aims to manage workflow; Um, isn't half of the commitfest app about workflow? Patch is waiting for review, who is the reviewer, patch is waiting for author, who is the author, patch is ready for committer, who is the committer? And every week or so the commitfest manager (if any) produces a report on patch progress. Isn't that exactly what these "workflow management" systems provide? -- 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] Bug tracker tool we need
On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote: > Maybe I'm confused - Magnus et al, are we talking spammy issues/issue > comments/etc, or are we talking more about exposed email addresses? My github.com account currently has 4264 notifications in the inbox. Almost all of those are spam, growing constantly. Because of that, the platform is currently fairly useless to me for actually communicating or collaborating on code. -- 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 1:38 AM, Magnus Hagander wrote: >> At the same time, I think we'd likely be a lot better off squirting this >> data into bugzilla or another standard tracker, instead of building our >> own infrastructure. > > I'm somewhat doubtful. Me, too. It's very tempting to assume that the problem we're trying to solve must already have been well-solved by someone else, and therefore we ought to use their thing instead of inventing our own. But that presumes that our problem is exactly the same as other people's problem, which may not really be true. IME, bug trackers typically work best when used by a tightly integrated team. For example, EnterpriseDB uses a bug-tracker-ish system for tracking bugs and feature requests and another one for support requests. Those systems get the job done and, certainly, are better designed than Bugzilla (it doesn't take much), but a lot of what they manage is workflow. Person A assigns a ticket to person B, and person B is then responsible for taking some action, and if they don't then someone will come along and run a report and grouse at person B for failing to take that action. If those reports weren't run and people didn't get groused at, the system would degenerate into utter chaos; and of course in a community setting it's hard to imagine that any such thing could possibly occur, since this is an all-volunteer effort. So I think Greg has exactly the right idea: we shouldn't try to incorporate one of these systems that aims to manage workflow; we should just design something really simple that tracks what happened and lets people who wish to volunteer to do so help keep that tracking information up to date. -- 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] Bug tracker tool we need
Robert Haas writes: > On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander wrote: >> That's probably one reason people aren't jumping on this. Because >> there is no tracker out there that people actually *like*... > > I think this is a point worth serious thought. I wonder why do people keep complaining how their bug tracker of choice sucks, instead of doing something about that. I can see a few possible factors: a) people do like to complain, and it's easier than submitting meaningful bug reports or feature requests, patches :-) b) the developers don't listen to their users, which happens far too often unfortunately c) (I had yet another idea here, but I forgot what it was :-p) d) a wild mix of the above However, this doesn't imply existing tracker software cannot be improved and more of that must be written from scratch (unless the code is cryptic and/or is written, probably poorly, in some rarely used programming language, and is unmaintainable.) Also, the reasons outlined above do not pertain only to bug tracker software somehow: any piece of software could suffer from that and I believe many of us have seen it. So maybe there's something fundamentally wrong with every existing bug tracker (e.g. they don't fix bugs for you?) Well, just kidding. ;-) -- Alex -- 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] Bug tracker tool we need
First of all I think a bug tracker will never be a system that is somehow "loved". Bugs are things which developers hate. Bugs in a cute nice small bug house aren't nice, are they? Question: Is there a reasonable chance from may be Tom Lane's idea of a wiki to an improved (define improvements) version which PG developers think may be useful? Wolfgang Von: Robert Haas An: Magnus Hagander CC: Jay Levitt ; Alex ; Dimitri Fontaine ; Alvaro Herrera ; Peter Eisentraut ; Tom Lane ; Greg Smith ; Pg Hackers Gesendet: 3:07 Mittwoch, 18.April 2012 Betreff: Re: [HACKERS] Bug tracker tool we need On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander wrote: > That's probably one reason people aren't jumping on this. Because > there is no tracker out there that people actually *like*... I think this is a point worth serious thought. The bug trackers I've used have been mostly terrible; saying that they are to bug tracking what CVS is to version control is insulting CVS. They're more like what editing RCS files in vi is to version control - i.e. worse than not having version control. To put that in practical terms, I think everyone (including people like Tom and I) who (a) are old curmudgeons or anyway middle-aged curmudgeons and (b) would spend much more time in bed with any system that we adopted than the average hacker would agree that the current system is kind of a pain. But there is no point in replacing it with something else unless that new thing is going to be significantly better than what we are doing now. And it's not entirely clear that such a thing exists. There are certainly people out there, and even on this list, who will tell you that system ABC is great. But for any given ABC there are also people who will tell you that it's got significant problems. We don't need to change anything to get a system that's got significant problems; we already have one. -- 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] Bug tracker tool we need
Magnus Hagander writes: > I think this cleraly outlines that we need to remember that there are > *two* different patterns that people are trying tosolve with the > bugtracker. Yeah, remember we drifted to this topic from discussion of management of CF patches, which might be yet a third use-case. It's not obvious that it's the same as tracking unfixed bugs, at least; though maybe the requirements end up the same. > Any tool we'd go for should aim to cover *both* usecases. Not convinced that we should expect one tool to be good at both (or all three) things. 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 07:52, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Apr 18, 2012 at 04:30, Tom Lane wrote: >>> So when I read Andrew's recent suggestion that we use >>> Bugzilla, my immediate reaction was "egad, can't we do better?". >>> Maybe we can't :-(. > >> Personally, I'd say we *already* do better than that... > > Just meditating a little ... one of my big beefs with Bugzilla is that > it shows basically a historical record of how a bug was discovered and > dealt with. While that surely has, er, historical value, it's not that > useful to read when you want to know which bug matches your symptoms, > what the possible consequences are, which versions it was fixed in, > etc. One particularly nasty point is that (AFAIK) it's impossible to > delete or edit incorrect comments, only to add new ones. > > I wonder whether a better model would be a wiki page per bug, with > an editable description and some links to reports, commits, etc. > Not but what I hate every wiki I've ever used too ... but at least > they let you fix the information when it's wrong or unhelpful. There's no reason why a bugtracker couldn't and shoulldn't make it possible to do that. I think the reason Bugzilla doesn't goes back to the "all comments are concatenated into a huge text field", which means you'd have to prase that text field to get the actual data back, instead of having it easily available... The discussion should in that case be about whether history shoudl be kept for each individual comment, or just thrown away... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
Magnus Hagander writes: > On Wed, Apr 18, 2012 at 04:30, Tom Lane wrote: >> So when I read Andrew's recent suggestion that we use >> Bugzilla, my immediate reaction was "egad, can't we do better?". >> Maybe we can't :-(. > Personally, I'd say we *already* do better than that... Just meditating a little ... one of my big beefs with Bugzilla is that it shows basically a historical record of how a bug was discovered and dealt with. While that surely has, er, historical value, it's not that useful to read when you want to know which bug matches your symptoms, what the possible consequences are, which versions it was fixed in, etc. One particularly nasty point is that (AFAIK) it's impossible to delete or edit incorrect comments, only to add new ones. I wonder whether a better model would be a wiki page per bug, with an editable description and some links to reports, commits, etc. Not but what I hate every wiki I've ever used too ... but at least they let you fix the information when it's wrong or unhelpful. 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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 05:44, Tom Lane wrote: > Greg Smith writes: >> Rather than talk about adopting one of the available torture devices, >> I'd happily consider the simplest thing possible that would be useful >> here instead. Here's my proposed tiny tracker: > > Wasn't Jay just muttering about "writing your own bug tracker" being an > anti-pattern? But still, there's something in what you say, because ... The caes where it would work to do that is if we agreed it'd be a "tiny tracker". And not actually try to do too much. As in basicaly a neater frontend over the mailinglist archives. I actually started on a demo of that at one point. Currently blocked behind the fact that we have to fix the mailinglist archives as well, in particular the break-on-month-boundary kills any attempt to do such a thing. Which is also being worked on, but backlogged as usual :S I'll admit that one reason it's been sitting fairly low on the prio list is the guaranteed months of bikeshedding that it would bring along ;) >> -Make commits that fix a bug reference it in one of the standard ways >> that's done by every one of these bug trackers. Just throw "Fixes >> #6596" into the commit message. These will probably work if a more >> serious tool is adopted, too. > > ... I think you'll find a lot of that data could be mined out of our > historical commit logs already. I know I make a practice of mentioning > "bug #" whenever there is a relevant bug number, and I think other > committers do too. It wouldn't be 100% coverage, but still, if we could > bootstrap the tracker with a few hundred old bugs, we might have > something that was immediately useful, instead of starting from scratch > and hoping it would eventually contain enough data to be useful. I have always considered that a *requirement*, not a neat addon. > At the same time, I think we'd likely be a lot better off squirting this > data into bugzilla or another standard tracker, instead of building our > own infrastructure. I'm somewhat doubtful. As a first step, we should at least stick in a tracker with a reasonable SQL schema so it's possible to extract and do smomething with the data. IIRC, bugzilla (and others) at least used to just concatenate all comments into a single text field, and not even keep them apart, for example. Because clearly this whole JOIN thing is evil and difficult. They may have fixed that by now, but what i've seen from most trackers shows signs of people who have never seen a database beyond an Excel sheet... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Tue, Apr 17, 2012 at 19:59, Greg Smith wrote: > On 04/17/2012 09:20 AM, Jay Levitt wrote: > Let's pick a real example from the last week of my life, where having a bug > tracker would have helped me out. This appears in a log: > > ERROR: missing chunk number 0 for toast value 1167375 in pg_toast_2619 > > What I should be able to do here is search the bug tracker for these words > and have it spit out an issue that looks like this I'm snipping the actual usecase, because it's nice and deatailed, but. I think this cleraly outlines that we need to remember that there are *two* different patterns that people are trying tosolve with the bugtracker. One is the simple "someone reported a bug. track until someone fixes it to make sure we don't miss it. Possibly even flag who is currently working on/responsible for this bug". The other one is for the *outsider* (sorry, Greg, in this scenario you get to represent an outsider for once). Who comes in and wants to know if the problem he/she has exists before, if it's fixed, and in which versions it's fixed in. There is some overlap, but the general usecase is drastically different. And we do a decent enough job of the first one today, partially because we have a few people who are very good at remembering these things and then finding them in the list archives. It works. However, we do very bad on the second one, IMHO. Any tool we'd go for should aim to cover *both* usecases. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On Wed, Apr 18, 2012 at 04:30, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander wrote: >>> That's probably one reason people aren't jumping on this. Because >>> there is no tracker out there that people actually *like*... > >> I think this is a point worth serious thought. > > Indeed. The only one I've got extensive experience with is Bugzilla > (because Red Hat uses it) and I do cordially hate it. At least some > of that is due to bureaucratic practices RH has evolved, like cloning > bugs N times for N affected releases, but I think the tool encourages > such things. So when I read Andrew's recent suggestion that we use > Bugzilla, my immediate reaction was "egad, can't we do better?". > Maybe we can't :-(. Personally, I'd say we *already* do better than that... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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] Bug tracker tool we need
On 18 April 2012 13:44, Tom Lane wrote: > ... I think you'll find a lot of that data could be mined out of our > historical commit logs already. I know I make a practice of mentioning > "bug #" whenever there is a relevant bug number, and I think other > committers do too. It wouldn't be 100% coverage, but still, if we could > bootstrap the tracker with a few hundred old bugs, we might have > something that was immediately useful, instead of starting from scratch > and hoping it would eventually contain enough data to be useful. Just as a data point, git tells me that there are 387 commits where the commit log message matches '#\d+', and 336 where it matches 'bug #\d+'. Cheers, BJ -- 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] Bug tracker tool we need
On 04/17/2012 11:44 PM, Tom Lane wrote: At the same time, I think we'd likely be a lot better off squirting this data into bugzilla or another standard tracker, instead of building our own infrastructure. Perhaps. It just struck me that a lot of the custom bits needed here regardless could be built/added to the usual workflow bottom-up. You don't have to assume that either a full tracker or something like my simple POC idea will show up at the end to get started. Making goal #1 involve just mining for the data that's already around and squirting it onto a web page would be a useful exercise, one that's likely to benefit any tracker adoption. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.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] Bug tracker tool we need
Greg Smith writes: > Rather than talk about adopting one of the available torture devices, > I'd happily consider the simplest thing possible that would be useful > here instead. Here's my proposed tiny tracker: Wasn't Jay just muttering about "writing your own bug tracker" being an anti-pattern? But still, there's something in what you say, because ... > -Make commits that fix a bug reference it in one of the standard ways > that's done by every one of these bug trackers. Just throw "Fixes > #6596" into the commit message. These will probably work if a more > serious tool is adopted, too. ... I think you'll find a lot of that data could be mined out of our historical commit logs already. I know I make a practice of mentioning "bug #" whenever there is a relevant bug number, and I think other committers do too. It wouldn't be 100% coverage, but still, if we could bootstrap the tracker with a few hundred old bugs, we might have something that was immediately useful, instead of starting from scratch and hoping it would eventually contain enough data to be useful. At the same time, I think we'd likely be a lot better off squirting this data into bugzilla or another standard tracker, instead of building our own infrastructure. 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] Bug tracker tool we need
On 04/17/2012 10:30 PM, Tom Lane wrote: Indeed. The only one I've got extensive experience with is Bugzilla (because Red Hat uses it) and I do cordially hate it. At least some of that is due to bureaucratic practices RH has evolved, like cloning bugs N times for N affected releases, but I think the tool encourages such things. That's along the same lines as my comments toward Jay Levitt, that bugs where the fixes span multiple releases are the part nobody seems to handle very well. Rather than talk about adopting one of the available torture devices, I'd happily consider the simplest thing possible that would be useful here instead. Here's my proposed tiny tracker: -If a bug is found in a released version, but it didn't originate on pgsql-bugs, send a message to that list so it gets assigned a bug id. -Write something that consumes pgsql-bugs and dumps all bug numbers and their subject lines into a database. Start them with a state of "Unconfirmed". -Make commits that fix a bug reference it in one of the standard ways that's done by every one of these bug trackers. Just throw "Fixes #6596" into the commit message. These will probably work if a more serious tool is adopted, too. -Update src/tools/git_changelog to understand these messages and produce a delimited file about every bug fix discovered. Import new entries into another table with the bug id as the foreign key. -Provide a command line tool to change bug state, basically a thin wrapper around an UPDATE statement. Make it easy to change ranges that are currently "Unconfirmed" to "Not a bug", for the bug reports that weren't really bugs. -When point release tagging happens, run another script that looks for bug fix commits since the last one, and then save that version number into a "fixed in" table. -Generate a web page out of the database. I think I've outlined that in a way that would make useful steps toward adopting one of the full packages, too. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.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] Bug tracker tool we need
On Tue, Apr 17, 2012 at 11:07 PM, Greg Sabino Mullane wrote: > Let's not let perfect be the enemy of good. In this case, *anything* > that actually tracks bugs (and they are all quite good at that, > if nothing else) is an improvement over what we have now, and thus, > quite good. :) I respectfully disagree. I would rather be chained to an angry cat for a day than have to use Bugzilla on a regular basis. RT is better, but the UI is still laughably bad. Try sticking a 74-email long thread into an RT ticket and then try to do anything with it. Now try in Gmail (even the new, revised, slightly-harder-to-use Gmail). It's not close. > Personally, I'm okay with, and have extensively hacked on, Bugzilla > and RT, but anything should be fine as long as we have someone > to take ownership. Therein lies another problem... -- 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] Bug tracker tool we need
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > But for any > given ABC there are also people who will tell you that it's got > significant problems. We don't need to change anything to get a > system that's got significant problems; we already have one. Let's not let perfect be the enemy of good. In this case, *anything* that actually tracks bugs (and they are all quite good at that, if nothing else) is an improvement over what we have now, and thus, quite good. :) Personally, I'm okay with, and have extensively hacked on, Bugzilla and RT, but anything should be fine as long as we have someone to take ownership. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201204172131 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAk+OL/0ACgkQvJuQZxSWSshMxACeJdr+WO4ttA2mkrGLv98PTTSH jSoAniKwQNPzokA3f0GYN8gB+hAOc0Hy =oPn6 -END PGP SIGNATURE- -- 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] Bug tracker tool we need
Robert Haas writes: > On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander wrote: >> That's probably one reason people aren't jumping on this. Because >> there is no tracker out there that people actually *like*... > I think this is a point worth serious thought. Indeed. The only one I've got extensive experience with is Bugzilla (because Red Hat uses it) and I do cordially hate it. At least some of that is due to bureaucratic practices RH has evolved, like cloning bugs N times for N affected releases, but I think the tool encourages such things. So when I read Andrew's recent suggestion that we use Bugzilla, my immediate reaction was "egad, can't we do better?". Maybe we can't :-(. 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] Bug tracker tool we need
On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander wrote: > That's probably one reason people aren't jumping on this. Because > there is no tracker out there that people actually *like*... I think this is a point worth serious thought. The bug trackers I've used have been mostly terrible; saying that they are to bug tracking what CVS is to version control is insulting CVS. They're more like what editing RCS files in vi is to version control - i.e. worse than not having version control. To put that in practical terms, I think everyone (including people like Tom and I) who (a) are old curmudgeons or anyway middle-aged curmudgeons and (b) would spend much more time in bed with any system that we adopted than the average hacker would agree that the current system is kind of a pain. But there is no point in replacing it with something else unless that new thing is going to be significantly better than what we are doing now. And it's not entirely clear that such a thing exists. There are certainly people out there, and even on this list, who will tell you that system ABC is great. But for any given ABC there are also people who will tell you that it's got significant problems. We don't need to change anything to get a system that's got significant problems; we already have one. -- 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] Bug tracker tool we need
On Tue, Apr 17, 2012 at 4:15 PM, Jay Levitt wrote: > That's a great point. Both GitHub and git itself have no real concept of > releases, and can't tell you when a commit made it in. Those factors likely play together in this. Git is a tool, not a workflow, and intentionally allows its users to use it in a variety of ways. (Which includes some very interesting pathologies visible with stuff like git-annex, git-mail.) It's not a bug that git can do things differently than the Postgres project wants things done. Likewise, it's not a bug that github, which intends to support all kinds of users using git, does not enforce the preferred Postgres workflow. I think it's pretty *normal* that we'd need tooling that won't be identical to (say) GitHub, and we shouldn't get too exercised about this. I wonder if our "fix" instead involves: a) Adding an ArchiveOpteryx instance to archive mailing list traffic; http://archiveopteryx.org/ b) A bit more tooling to make it easier to link to threads in that instance c) Perhaps some management tools based on debbugs to ease scripting of issues being tracked That's not prescriptive; just ideas. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- 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] Bug tracker tool we need
On 04/17/2012 04:38 PM, Tom Lane wrote: Jay Levitt writes: Greg Smith wrote: Tracking when and how a bug is backported to older versions is one hard part of the problem here. That's a great point. Both GitHub and git itself have no real concept of releases, and can't tell you when a commit made it in. We do actually have a somewhat-workable solution for that, see src/tools/git_changelog. It relies on cooperation of the committers to commit related patches with the same commit message and more or less the same commit time, but that fits fairly well with our practices anyway. If we did have an issue tracker I could see expecting commit messages to include a reference to the issue number, and then it would not be hard to adapt this program to key on that instead of matching commit message texts. Yeah, that would be good. BTW, since we're discussing trackers yet again, let me put in a plug for Bugzilla, which has mature Postgres support, is written in Perl (which a large number of hackers are familiar with and which we use extensively), has a long history and a large organization behind it (Mozilla) and last but not least has out of the box support for creating updating and closing bugs via email (I just set up an instance of the latest release with this enabled to assure myself that it works, and it does.) It also has XML-RPC and JSON-RPC interfaces, as well as standard browser support, although I have not tested the RPC interfaces. 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] Bug tracker tool we need
Jay Levitt writes: > Greg Smith wrote: >> Tracking when and how a bug is backported to older versions is one hard part >> of the problem here. > That's a great point. Both GitHub and git itself have no real concept of > releases, and can't tell you when a commit made it in. We do actually have a somewhat-workable solution for that, see src/tools/git_changelog. It relies on cooperation of the committers to commit related patches with the same commit message and more or less the same commit time, but that fits fairly well with our practices anyway. If we did have an issue tracker I could see expecting commit messages to include a reference to the issue number, and then it would not be hard to adapt this program to key on that instead of matching commit message texts. 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] Bug tracker tool we need
Greg Smith wrote: On 04/17/2012 09:20 AM, Jay Levitt wrote: Antispam is (in the large) a technically unsolvable problem; even in the '90s, we'd see hackers start poking at our newest countermeasures within the hour. GitHub is a giant target, and PG probably benefits here from NOT being one. Everyone who deals with list moderation and spam issues around PostgreSQL just got a belly laugh from that comment. Hint: the PostgreSQL lists had already been around and therefore were being targeted by spammers for over ten years before GitHub even existed. Hehe. OK, we will have to battle this out over drinks if I ever make it to PGCon.. but teaser: I've bankrupted Sanford Wallace and taught the DOJ what spam was. Pedantic note/fun fact: There was no email antispam in 1994 I like it when Magnus really gets the details perfect when making a deadpan joke. Dammit. I *fail*. Anyway, back to serious talk, I believe GitHub is a dead end here because the "primary key" as it were for issues is a repo. A bug tracker for PostgreSQL would need to have issues broken down per branch and include information similar to the release notes for each minor point release. Tracking when and how a bug is backported to older versions is one hard part of the problem here. That's a great point. Both GitHub and git itself have no real concept of releases, and can't tell you when a commit made it in. Although.. there's some sort of new release-note functionality. Maybe I'll play and see if it'd be applicable here. Jay -- 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] Bug tracker tool we need
On 04/17/2012 09:20 AM, Jay Levitt wrote: Antispam is (in the large) a technically unsolvable problem; even in the '90s, we'd see hackers start poking at our newest countermeasures within the hour. GitHub is a giant target, and PG probably benefits here from NOT being one. Everyone who deals with list moderation and spam issues around PostgreSQL just got a belly laugh from that comment. Hint: the PostgreSQL lists had already been around and therefore were being targeted by spammers for over ten years before GitHub even existed. Pedantic note/fun fact: There was no email antispam in 1994 I like it when Magnus really gets the details perfect when making a deadpan joke. Anyway, back to serious talk, I believe GitHub is a dead end here because the "primary key" as it were for issues is a repo. A bug tracker for PostgreSQL would need to have issues broken down per branch and include information similar to the release notes for each minor point release. Tracking when and how a bug is backported to older versions is one hard part of the problem here. For example, Trac, Redmine, and Github all have ways to make a commit message reference an issue, something like "fixes #X". That's fine for projects that don't have a complicated backport policy, but I haven't been able to figure out how to make it work well enough for a PostgreSQL bug tracker, to end up saving any work here. In some cases, a bug shouldn't be closed until it's been backported to all supported releases. Others will only fix in relevant releases. Let's pick a real example from the last week of my life, where having a bug tracker would have helped me out. This appears in a log: ERROR: missing chunk number 0 for toast value 1167375 in pg_toast_2619 What I should be able to do here is search the bug tracker for these words and have it spit out an issue that looks like this === Bug: Fix race condition during toast table access from stale syscache entries Impact: Transient query failures Fixed in: 9.2.0: http://archives.postgresql.org/pgsql-committers/2011-11/msg00012.php 9.1.2: http://archives.postgresql.org/pgsql-committers/2011-11/msg00016.php 9.0.6: http://archives.postgresql.org/pgsql-committers/2011-11/msg00014.php 8.4.10: http://archives.postgresql.org/pgsql-committers/2011-11/msg00013.php 8.3.17: http://archives.postgresql.org/pgsql-committers/2011-11/msg00017.php 8.2.23: http://archives.postgresql.org/pgsql-committers/2011-11/msg00015.php === Note that the "fixed in" version information doesn't show up until some time *after* the bug fix is committed, because they normally get rolled into the next minor release in bulk. A bug tracking system for PostgreSQL will start looking attractive when it makes life easier for the people who do these backports and the associated release notes. Start looking at the problem from their perspective if you want to figure out how to make that happen. I don't have a good answer to that; I just know that Trac, Redmine, and GitHub haven't felt like a good fit, having used every one of that trio for multiple years now at some point. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.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] Bug tracker tool we need
Alex Shulgin wrote: Jay Levitt writes: (A quick Google shows redmine and especially Trac having spam issues of their own.) Ugh, redmine (or trac for that matters) has nothing to with handling spam. I believe a typical bug tracker doesn't handle spam itself, it lets the mailing system do that. Surely you can throw in some captcha plugins to try to reduce the spam posted from the web UI. Maybe I'm confused - Magnus et al, are we talking spammy issues/issue comments/etc, or are we talking more about exposed email addresses? I assumed we meant spammy issues, like blog comments - spammers post issues and comments with links, to get PageRank to their sites. Email defenses wouldn't help here. Captchas are fairly pointless nowadays, assuming you have someone dedicated enough to write a spambot against your bug tracker. Most of them (even reCAPTCHA!) can be >80% defeated by software - many 99% - and there are millions of humans hanging out on Mechanical Turk who'll solve them for you 100%. Modern anti-spam ends up being a machine learning and systems exercise.. but that's another mailing list :) I think Google gets more use out of reCAPTCHA for OCR tweaking than for anti-spam. Jay -- 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] Bug tracker tool we need
Jay Levitt writes: > > (A quick Google shows redmine and especially Trac having spam issues > of their own.) Ugh, redmine (or trac for that matters) has nothing to with handling spam. I believe a typical bug tracker doesn't handle spam itself, it lets the mailing system do that. Surely you can throw in some captcha plugins to try to reduce the spam posted from the web UI. -- Alex -- 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] Bug tracker tool we need
Magnus Hagander wrote: On Mon, Apr 16, 2012 at 23:48, Jay Levitt wrote: - Familiarity: Many developers already have a GitHub account and use it Most of the more senior developers don't use github. Other than possibly as a place to store a plain git repository. So that's not really relevant. I meant outside developers - the folks you'd like to see more involved in the process. - Patch commenting and git integration encourage actual review-resubmit cycles instead of "Here, look, I fixed it for you" reviews The amount of spam coming through that system, and the inability/unwillingness of github to even care about it is a killer argument *against* github. We have working antispam for email. The github antispam is somewhere around where email antispam was in 1994. Interesting; I haven't run into this but you're the second person to mention it here. Antispam is (in the large) a technically unsolvable problem; even in the '90s, we'd see hackers start poking at our newest countermeasures within the hour. GitHub is a giant target, and PG probably benefits here from NOT being one. (A quick Google shows redmine and especially Trac having spam issues of their own.) Pedantic note/fun fact: There was no email antispam in 1994; Canter & Siegel posted their infamous USENET Green Card spam that year, but it didn't really spread to email for another year or two. Once it did, there were fervent debates about whether it should be called "velveeta" to distinguish from the USENET variety. GitHub could well be a non-starter, but if third-party-dependence is really the holdup, I'd volunteer to write the tools - in fact, a google of [export issues from github] shows a few that might already suffice. It *is* a non-starter, because (a) it's a third party dependency, and (b) AFAIK they don't provide *data access* to the issue trackers. Sure they do: http://developer.github.com/v3/issues/ Jay -- 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] Bug tracker tool we need
On Mon, Apr 16, 2012 at 23:48, Jay Levitt wrote: > Alex wrote: >> >> I still fail to see how Redmine doesn't fit into requirements summarized >> at that wiki page[1], so that must be something other than formal >> requirement of being free/open software and running postgres behind >> (some sort of "feeling" maybe?) > > > Well, if those requirements are in fact requirements, Redmine could suit the > purpose (perhaps with some custom extensions). But yes, Redmine "feels" > wrong to me, though I have never been particularly happy with *any* > self-hosted bug tracker. That's probably one reason people aren't jumping on this. Because there is no tracker out there that people actually *like*... > Of those I've used - Redmine, Mantis, JIRA, Trac, Bugzilla, GForge, RT - > Redmine feels the least-worst to me; it's about equal to Trac, and it's in > Ruby so I could theoretically(!) improve it. It being in ruby is actually generally a liability in the postgresql.org world - we have very few people who actually know it. And some of those who know it no longer want to work with it. So if you're good with Ruby, and want to contribute, feel free to contact me off-list because we have some things we need help with :-) > I think the biggest missing pieces in Redmine aside from custom CF stuff > are: better search, single sign-on (it requires Yet Another Login), a better We already have redmine working with single password (though not single signon) for a limited number of projects such as pgweb. > UX (AJAX, syntax highlighting) and better git integration (a la pull > requests, where private git commits = patches). Those are some pretty big > pieces. I don't think Redmine out-of-the-box would improve either CFs or > community involvement. I think we can all agree on that :-) >> Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you >> please describe your ideal tool for the task? > > > My opinion isn't all that important, since I currently have an infinite > opinion-to-contribution ratio, but in my unicorniverse: We'd accept that > open source hasn't always produced great UX, we'd use GitHub's issue > tracker, allow volunteers to do "bug wrangling" triage via tags, use GitHub > hooks to integrate with the existing CF app, and write archiving tools that > would let us easily export everything off of GitHub for when (a) something > better comes along or (b) GitHub pops out of existence or adds egregious > licensing terms like BitKeeper. > > Reasons: > > - Familiarity: Many developers already have a GitHub account and use it Most of the more senior developers don't use github. Other than possibly as a place to store a plain git repository. So that's not really relevant. > - Discoverability: GitHub has great SEO I'm willing to bet that postgresql.org has better SEO when it comes to postgres. > - Tight integration of git with patch and issue management (pull requests, > fork networks, etc); eliminates ceremony rather than adding to it There are some things that help there, certainly. Pull requests is basically email, but fork network tracking and such can be darn useful sometimes. > - Readable UI with syntax highlighting, etc Yes, this part is very nice. > - Patch commenting and git integration encourage actual review-resubmit > cycles instead of "Here, look, I fixed it for you" reviews The amount of spam coming through that system, and the inability/unwillingness of github to even care about it is a killer argument *against* github. We have working antispam for email. The github antispam is somewhere around where email antispam was in 1994. > - Two-way email/web integration > - Meets Tom's "would be sort of neat" criteria[1] > - Could easily implement Simon's "pony" criteria[2] with tags and API > - Easily extensible with API and hooks > - Subjectively: Its design encourages better community and core interactions > than any I've seen in 25 years. > > GitHub could well be a non-starter, but if third-party-dependence is really > the holdup, I'd volunteer to write the tools - in fact, a google of [export > issues from github] shows a few that might already suffice. It *is* a non-starter, because (a) it's a third party dependency, and (b) AFAIK they don't provide *data access* to the issue trackers. If the actual issue trackers were stored in git, like the webpages are for example, it would be a different story...b >> Given that every other existing tool likely have pissed off someone >> already, I guess our best bet is writing one from scratch. > > ISTR there's a great "Writing your own bug tracker is an anti-pattern" blog, > but I can't find it anymore. I'm sure there's more than one :-) If it was that easy we would've written one already. But doing that is likely going to be a lot of work, and it needs to be maintained. (Not that picking another one means it doesn't need to be maintained - I've seen so many things broken by upgrading redmine or bugzilla that it's silly...) -- Magnus
Re: [HACKERS] Bug tracker tool we need
> > I believe the biggest hurdle for many hackers is that in redmine, > email is not a first class citizen. The majority of hackers are never > going to want to go into a web interface to get something done, they > live in VI/Emacs and the command line. > > One thing that redmine definitely breaks is proper handling of > attachments in email, thus the first thing moving to redmine would > break would be patch submission. Right. This is not too hard to fix, however, and I didn't suggest we move to vanilla Redmine. It's hackable, so we can just bash it into shape we need (and we need a few Ruby hackers, so there's always someone in the postgres community to fix it when it breaks, of course.) -- Alex -- 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] Bug tracker tool we need (was: Last gasp)
On Mon, Apr 16, 2012 at 06:29:47PM +0200, Magnus Hagander wrote: > FWIW, I think the closest thing we've found so far would be debbugs - > which IIRC doesn't have any kind of reasonable database backend, which > would be a strange choice for a project like ours :) And makes many > things harder... FWIW, Don Armstrong (the main debbugs hacker these days I believe) recently posted a blog post about a more obscure feature of debuugs (forcemerge), where he finishs with "so we can eventually keep a postgresql database updated in addition to the flatfile database.": http://www.donarmstrong.com/posts/debbugs_forcemerge/ I don't know whether this implies a full PostgreSQL backend or just a helper DB for some part of the functionality, but it might be something to keep watching. Regards, 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] Bug tracker tool we need
On 04/16/2012 09:24 AM, Alex wrote: Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you please describe your ideal tool for the task? Given that every other existing tool likely have pissed off someone already, I guess our best bet is writing one from scratch. Or maybe there isn't really a need for a tracker? The core team have managed to live without one for so long after all... I believe the biggest hurdle for many hackers is that in redmine, email is not a first class citizen. The majority of hackers are never going to want to go into a web interface to get something done, they live in VI/Emacs and the command line. One thing that redmine definitely breaks is proper handling of attachments in email, thus the first thing moving to redmine would break would be patch submission. JD -- Regards, Alex [1] http://wiki.postgresql.org/wiki/TrackerDiscussion -- 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] Bug tracker tool we need
Alex wrote: I still fail to see how Redmine doesn't fit into requirements summarized at that wiki page[1], so that must be something other than formal requirement of being free/open software and running postgres behind (some sort of "feeling" maybe?) Well, if those requirements are in fact requirements, Redmine could suit the purpose (perhaps with some custom extensions). But yes, Redmine "feels" wrong to me, though I have never been particularly happy with *any* self-hosted bug tracker. Of those I've used - Redmine, Mantis, JIRA, Trac, Bugzilla, GForge, RT - Redmine feels the least-worst to me; it's about equal to Trac, and it's in Ruby so I could theoretically(!) improve it. I think the biggest missing pieces in Redmine aside from custom CF stuff are: better search, single sign-on (it requires Yet Another Login), a better UX (AJAX, syntax highlighting) and better git integration (a la pull requests, where private git commits = patches). Those are some pretty big pieces. I don't think Redmine out-of-the-box would improve either CFs or community involvement. Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you please describe your ideal tool for the task? My opinion isn't all that important, since I currently have an infinite opinion-to-contribution ratio, but in my unicorniverse: We'd accept that open source hasn't always produced great UX, we'd use GitHub's issue tracker, allow volunteers to do "bug wrangling" triage via tags, use GitHub hooks to integrate with the existing CF app, and write archiving tools that would let us easily export everything off of GitHub for when (a) something better comes along or (b) GitHub pops out of existence or adds egregious licensing terms like BitKeeper. Reasons: - Familiarity: Many developers already have a GitHub account and use it - Discoverability: GitHub has great SEO - Tight integration of git with patch and issue management (pull requests, fork networks, etc); eliminates ceremony rather than adding to it - Readable UI with syntax highlighting, etc - Patch commenting and git integration encourage actual review-resubmit cycles instead of "Here, look, I fixed it for you" reviews - Two-way email/web integration - Meets Tom's "would be sort of neat" criteria[1] - Could easily implement Simon's "pony" criteria[2] with tags and API - Easily extensible with API and hooks - Subjectively: Its design encourages better community and core interactions than any I've seen in 25 years. GitHub could well be a non-starter, but if third-party-dependence is really the holdup, I'd volunteer to write the tools - in fact, a google of [export issues from github] shows a few that might already suffice. Given that every other existing tool likely have pissed off someone already, I guess our best bet is writing one from scratch. ISTR there's a great "Writing your own bug tracker is an anti-pattern" blog, but I can't find it anymore. Or maybe there isn't really a need for a tracker? The core team have managed to live without one for so long after all... As an end-user, I've reported exactly one bug in a release version of Postgres, and it was fixed (and back-ported!) the next day. So I really can't complain about the tracking of actual bugs. Sounds like we do need something better for CF/patch workflow, tho. Jay [1] Tom wrote: Now what would be sort of neat is if we had a way to keep all the versions of patch X plus author and reviewer information, links to reviews and discussion, etc. in some sort of centralized place [2] Simon wrote: My I-Want-a-Pony idea is some kind of rating system that allows us all to judge patches in terms of importance/popularity, complexity and maturity. I guess a Balanced Scorecard for the development process. So we can all see whats going on. -- 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] Bug tracker tool we need
Magnus Hagander writes: > One thing to note is that the referenced wiki page is over a year old. > And that many more things have been said on email lists than are > actually in that page. Yeah, I went through it briefly and rather important concern seem to have been raised by Tom Lane in this msg: http://archives.postgresql.org/pgsql-hackers/2011-05/msg01480.php This paragraph: > The real question is, who is going to keep it up to date? GSM has the > right point of view here: we need at least a couple of people who are > willing to invest substantial amounts of time, or it's not going to go > anywhere. Seeing that we can barely manage to keep the mailing list > moderator positions staffed, I'm not hopeful. > But as one note - I don't believe you can drive redmine completely > from email, which is certainly a requirement that has been discussed, > but is not entirely listed on that page. Ugh, what do you mean by that? You can change any attribute (like status, priority, assigned person, etc.) of a ticket via email. Anything else? > FWIW, I think the closest thing we've found so far would be debbugs - > which IIRC doesn't have any kind of reasonable database backend, which > would be a strange choice for a project like ours :) And makes many > things harder... What stops us from writing a postgres backend for debbugs if it is so brilliant on handing email and stuff? -- Alex -- 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] Bug tracker tool we need (was: Last gasp)
On Mon, Apr 16, 2012 at 18:24, Alex wrote: > > Dimitri Fontaine writes: > >> Alvaro Herrera writes: >>> I've used Redmine a lot, as you know, and I only keep using it because >>> it's a requirement at work. It is certainly not close to usable for >>> general pgsql stuff. (Trac, which we used to use prior to Redmine, was >>> certainly much worse, though). >> >> Same story here, still using redmine a lot, all with custom reports etc. >> >>> I can't say that it's all that slow, or that there's a problem with the >>> code, or that the search doesn't work right (and I've never had a wiki >>> edit disappear, either, and I've used that a lot). It's just the wrong >>> tool altogether. >> >> It's indeed slow here, and I agree that's not the problem. Not the tool >> we need, +1. > > I still fail to see how Redmine doesn't fit into requirements summarized > at that wiki page[1], so that must be something other than formal > requirement of being free/open software and running postgres behind > (some sort of "feeling" maybe?) One thing to note is that the referenced wiki page is over a year old. And that many more things have been said on email lists than are actually in that page. But as one note - I don't believe you can drive redmine completely from email, which is certainly a requirement that has been discussed, but is not entirely listed on that page. > Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you > please describe your ideal tool for the task? > > Given that every other existing tool likely have pissed off someone > already, I guess our best bet is writing one from scratch. FWIW, I think the closest thing we've found so far would be debbugs - which IIRC doesn't have any kind of reasonable database backend, which would be a strange choice for a project like ours :) And makes many things harder... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Bug tracker tool we need (was: Last gasp)
Dimitri Fontaine writes: > Alvaro Herrera writes: >> I've used Redmine a lot, as you know, and I only keep using it because >> it's a requirement at work. It is certainly not close to usable for >> general pgsql stuff. (Trac, which we used to use prior to Redmine, was >> certainly much worse, though). > > Same story here, still using redmine a lot, all with custom reports etc. > >> I can't say that it's all that slow, or that there's a problem with the >> code, or that the search doesn't work right (and I've never had a wiki >> edit disappear, either, and I've used that a lot). It's just the wrong >> tool altogether. > > It's indeed slow here, and I agree that's not the problem. Not the tool > we need, +1. I still fail to see how Redmine doesn't fit into requirements summarized at that wiki page[1], so that must be something other than formal requirement of being free/open software and running postgres behind (some sort of "feeling" maybe?) Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you please describe your ideal tool for the task? Given that every other existing tool likely have pissed off someone already, I guess our best bet is writing one from scratch. Or maybe there isn't really a need for a tracker? The core team have managed to live without one for so long after all... -- Regards, Alex [1] http://wiki.postgresql.org/wiki/TrackerDiscussion -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
