Re: Managing the community information stream - Mailing list pgsql-hackers

Dave Page wrote:
> Bruce Momjian wrote:
>> The idea of the patch number in the subject line works with that
>> streaming model because it merely marks streams so they can be grouped.
>> The defining event that marks the stream is a post to the patches list.
>> We already number posts to the bugs list, so in a way we could improve
>> tracking there and somehow link it to TODO items and patch submissions,
>> but because many TODO items are not the result of bug reports but come
>> out of general discussions, I am not sure tracking would work as well
>> there.  And what about features?  Do you start assigning numbers there,
>> and what is your trigger event?  In my opinion, as you start trying to
>> place more structure on the stream, the stream itself starts to degrade
>> in its dynamism and ease of use.  To me, that is the fundamental issue,
>> and risk.
>
> Bruce,
>
> I cannot really add to that except to say that you neatly summarized 
> what I've completely failed to in my last few emails to Andrew. I 
> agree completely.
>
>

Frankly, this strikes me as painting lipstick on a pig.

Try searching the mailing list archives to find information. It's hard. 
It sucks badly. So often you have to post a query on a mailing list, 
which you have to join unless you want your query to sit in limbo for 
days. If you think this is treating users nicely then you have a 
different idea from me of what that means. Yes, what I'm proposing means 
work, and no it can't be fully automated. That doesn't mean it's not 
worth doing.

Case 1 (bug): Recently I had a problem with Gaim/Pidgin on my fc6 boxes. 
I went to the bug site, clicked a few buttons and found that our own 
Devrim Gunduz had reported the problem. Later, when I found out some 
more information, I went back and added it to the bug. When the 
RedHat/Fedora guys get around to fixing it they will know what the 
problem is and what the solution is. They will have all the info 
gathered in one spot.

Case 2 (feature): Several years ago I wanted to find out what had 
happened about BZ support for Postgres. It was in their roadmap doc, so 
I went and looked at the tracking item. Nothing seemed to be happening, 
so I asked. Then I reviewed the patches (plural, note - another reason 
why tracking patches rather than action items is not necessarily good) 
that related to the item. I didn't like the direction they were going so 
I did some work and proposed an alternative. That got picked up by Ed 
Sobol and Max Kanat-Alexander (iirc) and the result is that today there 
is full support for Postgres in BZ mainline. If someone wants to review 
the history it is all there, with patches and comments all gathered neatly.

Oh, the answer to Bruce's question about when to create a feature item? 
You could well do it at the time when today you create a TODO item. 
However, we might even do better. For example, we might well add feature 
requests that are denied. That would help people to see if something has 
been proposed before.

I could go on but I'm actually trying to get some code written today :-)

cheers

andrew