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.

I agree 100%. Lets start off with grunt workers doing their magic in
parallel with whatever systems we currently have. They will one by one
figure out what to automate, what cannot be automated, and maybe provide
value that is promising enough for people to slightly modify their modus
operanti for those aspects that cannot be automated. However there will
probably always be a great deal of grunt work.

Again Email's are great for discussions and I think its great to link up
discussions with a bug or issue tracker id. However Email discussions
also often go in circles, are side tracked by IRC discussions etc. So
its really hard to figure out what decisions have been made if you look
things up later on. So the task of the grunt workers is to make sure
that there is a summary of the relevant information available, even if
all they do is flag the important decision emails.

regards,
Lukas

Andrew Dunstan wrote:

> 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")?

Exactly its a judgement call. The idea would be to try and pick up each
of the proposals in the discussion, summarize them in the issue tracker
or via a link to the wiki. This way people do not argue in circles all
that much (hopefully) and there is something to vote on. More
importantly there is something to point to if the topic ever comes up
again and the previous discussion did not lead to a decision. The
classic "read the archives" is just very suboptimal.

regards,
Lukas

Am Montag, 4. September 2006 04:19 schrieb Bruce Momjian:
> 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?

It's easy: Those who put in the care to capture all that have a better chance
of getting their issue resolved.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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

Tom Lane wrote:
> 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?
>
>
>


I am not saying there is no work involved. In fact, throughout this
thread I have agreed with you that a tracker that is not given regular
maintenance effort is doomed to fail. But I don't think the level of
effort required is undoable, nor that the cost is too high.

Unlike running buildfarm, this is not largely automatable.

Incidentally, the buildfarm has taken far more of my time and energy
than I originally expected. It has probably been worth it - I doubt I
could have delivered anything else as valuable in its place, but in that
sense the cost to me has been quite high. I hope that by spreading the
load a bit maintenance of a tracker will not be as burdensome to anybody.

cheers

andrew

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

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

On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote:
> 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.

In private groups (like companies) that do this well, that sort of
"convenient way" turns out to be someone who is willing to do the
summarisation and post it. Perhaps what is needed is a small group
of people who would like to contribute, who can't contribute code,
but who can spend some time doing summaries, documents, and that sort
of thing? (Yes, I'll put my money where my mouth is.)

A

--
Andrew Sullivan | ajs@crankycanuck.ca
Users never remark, "Wow, this software may be buggy and hard
to use, but at least there is a lot of code underneath."
--Damien Katz

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

http://archives.postgresql.org

Andrew Sullivan wrote:
> On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote:
>
>> 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.
>>
>
> In private groups (like companies) that do this well, that sort of
> "convenient way" turns out to be someone who is willing to do the
> summarisation and post it. Perhaps what is needed is a small group
> of people who would like to contribute, who can't contribute code,
> but who can spend some time doing summaries, documents, and that sort
> of thing? (Yes, I'll put my money where my mouth is.)
>
>


Excellent! You are just the sort of person for this task, I think.

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