>>> -- 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 use
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.
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 r
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
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
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
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 term
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 s
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 syst
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
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
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
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 reaso
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 fr
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
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 th
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_
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 rig
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 curr
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 a
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, to
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 com
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 current
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
>>> collab
-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
-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 volunte
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 to
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 ke
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,
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 b
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
>
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
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 manag
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
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 i
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 admi
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? Pa
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 clari
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.
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 in
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 wh
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 exactl
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, gro
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 t
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 comp
twoch, 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 wort
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
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 s
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
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 ab
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_toa
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 wort
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
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
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-patte
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 thin
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 respectful
-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
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 exte
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 t
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
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
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
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.
Eve
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 wi
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
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
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.
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
>
> 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
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...
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 is
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 requ
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
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 t
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,
76 matches
Mail list logo