Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > As for remarks about old school unix hackers not liking web interfaces,
> > I think Tom's recent remarks relating to the 21st century were more than
> > apposite.
>
> I don't see a big problem with using a web interface to search for
> information --- they're good at that. If you're thinking that the
> hackers community is willing to abandon email as a discussion medium
> for a web forum, however, you're going to be sadly disappointed ... and
> I don't see how it would help anyway: a pile of text is a pile of text,
> no matter where it came from.
>
> The hard part of this problem is finding a convenient way to capture
> status data out of the community's conversations. I think when you find
> a solution to that, you'll notice that email is not the problem.

And somehow binding threads of email together into bundles. That is
also something we can't do now. The only clean fix seems to require
manual work to attach them, and I doubt that is every going to happen
reliably.

And our email threads wander around quite a bit, with patches, ideas,
and bugs sometimes all thrown in --- see the interval
multiplication/division thread as a good example. How do you capture
that?

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

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Bruce Momjian <bruce@momjian.us> writes:
> Oh, so the bug is tracked by being part of the email reply list. That
> is a good idea. Now, how does that get assigned for non-bugs, like
> patches? Does any email sent to the lists that doesn't already have a
> bug number get one? That might be really valuable.

*Any* email? I hope not ... otherwise it's hard to see what you've got
that you don't get with a full-text search on a mailing list archive.

AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
to automate some obvious bits. But if we start with the assumption that
it's going to be mostly automated on day zero, I predict a resounding
failure.

It strikes me that the CERT CVE database might be a useful analogy.
AFAIK there is little or no automated entry into that database ---
every change has a human reviewer in front. Of course, they have some
darn good security reasons for wanting strong filters in front of their
database, but still it's a case worth thinking about. They have the
same problem of pulling status information from a lot of not-very-
well-standardized input sources.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian wrote:
> Oh, so the bug is tracked by being part of the email reply list. That
> is a good idea. Now, how does that get assigned for non-bugs, like
> patches? Does any email sent to the lists that doesn't already have a
> bug number get one? That might be really valuable.
>
>

It would just clog the bug tracker and make it unusable.

I spent months on a working party on these and similar issues a few
years back, in a commercial setting. One of the big issues is when you
start tracking something. Bugs are a pretty simple case. Features are
much harder to handle. Someone comes up with an idea. There is a lot of
discussion. a consensus is arrived at to go forward. I think that's the
point at which we start tracking, but it's a judgement call. What is we
decide not to go ahead? Do we capture that in the tracker (with a
resolution of "rejected")?

One useful idea, not implemented by any of the OSS tracking / SCM
systems that I know of, is to tie the two together, i.e every commit
relates to a tracker item which captures the major discussions
surrounding it. (If there isn't a bug, it prompts you to start one,
which you can immediately mark as fixed if necessary). That way you can
go backwards and forwards between the code and the discussion that led
to it easily. Trust me, once you have worked with such a system you
appreciate the benefits.

Anyway, let me reiterate: bz has at least the start of an email reply
facility, and making that work if it doesn't already should not be
beyond us.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew Dunstan <andrew@dunslane.net> writes:
> Anyway, let me reiterate: bz has at least the start of an email reply
> facility, and making that work if it doesn't already should not be
> beyond us.

I agree that starting from scratch seems like a good way to waste a
lot of time. I don't have a preference for BZ over debbugs or the
others that have been mentioned, but I'd suggest starting with something
that exists and trying to adapt it. If you end up throwing it away and
starting over, well, you'll have spent a lot less time on the trial
version than if you insist on coding from scratch.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
>
> AFAICS the bottom line here is that we need some intelligent filtering.
> In the short run I doubt that we can have that except through human
> gruntwork to filter the mail traffic and update a tracker database.
> Maybe after we see such a system in operation for awhile, we can start
> to automate some obvious bits. But if we start with the assumption that
> it's going to be mostly automated on day zero, I predict a resounding
> failure.
>
>
>

+1

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Oh, so the bug is tracked by being part of the email reply list. That
> > is a good idea. Now, how does that get assigned for non-bugs, like
> > patches? Does any email sent to the lists that doesn't already have a
> > bug number get one? That might be really valuable.
>
> *Any* email? I hope not ... otherwise it's hard to see what you've got
> that you don't get with a full-text search on a mailing list archive.

Yes, I was thinking any email. +50% of features/bugs/patches don't come
in via the bug form. If we don't capture everything, will it be useful?

> AFAICS the bottom line here is that we need some intelligent filtering.
> In the short run I doubt that we can have that except through human
> gruntwork to filter the mail traffic and update a tracker database.
> Maybe after we see such a system in operation for awhile, we can start
> to automate some obvious bits. But if we start with the assumption that
> it's going to be mostly automated on day zero, I predict a resounding
> failure.
>
> It strikes me that the CERT CVE database might be a useful analogy.
> AFAIK there is little or no automated entry into that database ---
> every change has a human reviewer in front. Of course, they have some
> darn good security reasons for wanting strong filters in front of their
> database, but still it's a case worth thinking about. They have the
> same problem of pulling status information from a lot of not-very-
> well-standardized input sources.

Oh, lots of grunt work. I can see that working, but at a high cost.

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

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Bruce Momjian wrote:
>
> Oh, lots of grunt work. I can see that working, but at a high cost.
>
>

I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we would not be including HEAD, but
only stable branches. With HEAD the volume would be quite a bit higher,
but not impossibly so.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>>
>> Oh, lots of grunt work. I can see that working, but at a high cost.
>>
>>
>
> I doubt it. Let's just start with bugs, since that's the easy case
> anyway. Our real volume is pretty low, so the cost of maintaining it
> should not be high. I am assuming we would not be including HEAD, but
> only stable branches. With HEAD the volume would be quite a bit higher,
> but not impossibly so.

The email interface to bugzilla has potential. I *think* with a nominal
amount of work, we should be able to modify it, so that a person could
reply to the bug and it would correct associate as a bug.

Joshua D. Drake


>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew Dunstan <andrew@dunslane.net> writes:
> Bruce Momjian wrote:
>> Oh, lots of grunt work. I can see that working, but at a high cost.

> I doubt it. Let's just start with bugs, since that's the easy case
> anyway. Our real volume is pretty low, so the cost of maintaining it
> should not be high. I am assuming we would not be including HEAD, but
> only stable branches. With HEAD the volume would be quite a bit higher,
> but not impossibly so.

Maybe we're working from different assumptions, but I thought the entire
basis for this discussion is that the project has grown to the point
where we have more resources than we used to --- and in particular,
we can find people who don't feel able to fix deep backend bugs, but are
ready and willing to track bug details and status with a goodly amount
of cluefulness. If that resource doesn't actually exist, then I fear
this whole discussion will come to naught. If it does exist, we should
call upon it.

This is not that far different from the premise upon which you built
the buildfarm: that there were people out there able to provide machine
resources and a certain amount of admin time. The resources this
project requires are not those exactly, but why shouldn't we expect
that some people will answer the call?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

> This is not that far different from the premise upon which you built
> the buildfarm: that there were people out there able to provide machine
> resources and a certain amount of admin time. The resources this
> project requires are not those exactly, but why shouldn't we expect
> that some people will answer the call?

I concur, more then one person has complained on this thread and others
about wanting these tools. It is time that those people step up.

Sincerely,

Joshua D. Drake


>
> regards, tom lane
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend