Re: Learning curves and such (was Re: pgFoundry)

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > Beyond "the core developers want to stick to email", I think there is a
> > good reason that we should stick primarily to email for project
> > management: Bugzilla and similar systems are "point to point", whereas a
> > mailing list is multicast[1].
>
> That seems to me to be a great summary of the issue. I've been dealing
> with Bugzilla for a few years now in my employment with Red Hat, and
> I think the bottom line for that kind of system is that it's designed
> to limit the visibility of issues, rather than expose them.
>
> Now that is just exactly what you want for a corporate-sized bug
> tracking system --- at Red Hat, I do not want to hear about bugs in the
> kernel, or X, or a thousand other components that I have no expertise in
> --- but I cannot see that restricting the flow of information is what we
> need for Postgres.
>
> 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.

Good point, and I think the big criticism of our current system is that
it is hard for someone to come in and see only a limited view of our
issues. For example, if you only want to see ecpg issues, we don't make
it very easy. This is the same issue Joshua Drake was mentioning, that
there is no easy way to point someone at bug number XXX and assume they
will have a full summary of the issue.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073