From: | Chris Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Learning curves and such |
Date: | 2005-05-18 20:47:36 |
Message-ID: | 60acmsqn13.fsf@dba2.int.libertyrms.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
sfrost(at)snowman(dot)net (Stephen Frost) writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> I think most of the real advantages of bug trackers that have been
>> mentioned in this thread have to do with history and searchability.
>> We have the raw info for that, in the pgsql-bugs and
>> pgsql-commmitters mail archives, and so it seems to me that this
>> reduces to the perennial gripe that we don't have good enough
>> search tools for the archives.
>
> This also means, to some extent anyway, that someone who wants to
> show off the latest-greatest bug tracking system that will satisfy
> all our needs could 'seed' the system with at least some of the
> history that's available currently through the mailing list
> archives. If they (or the part of the community interested in it,
> whatever) then work to keep it up to date and show that it's a
> better system in whatever way, that'd go a great deal farther
> towards acceptance.
There's a good point.
If you can take something like RT and "seed" it with a sufficiently
sizable set of reasonably deeply interlinked data, such that it could
be useful for some "use cases," that could represent a useful
experiment.
I have some small understanding of what's good and bad about RT;
there's certainly some merit to it from several perspectives:
1. It adds a way to support uploaded 'objects.'
2. It adds a way to link together related discussions for posterity.
3. It allows associating various extended attributes with
tickets. Commonly, that is used for associating them with
customers or business partners. It would be obvious for
PostgreSQL to have software components as associations.
It certainly does offer the ability for interested folk to see
a "multicasted" presentation of discussion.
The "deeper" the initial seeding, the better, of course.
--
(format nil "~S(at)~S" "cbbrowne" "acm.org")
http://www.ntlug.org/~cbbrowne/sap.html
Rules of the Evil Overlord #78. "I will not tell my Legions of Terror
"And he must be taken alive!" The command will be: ``And try to take
him alive if it is reasonably practical.''"
<http://www.eviloverlord.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Ed L. | 2005-05-18 20:49:40 | Re: Image storage questions |
Previous Message | Sergey Ten | 2005-05-18 20:42:57 | Re: patches for items from TODO list |