Re: [HACKERS] Collaboration Tool Proposal

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-www(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Collaboration Tool Proposal
Date: 2004-02-27 14:29:24
Message-ID: 403F5444.9080305@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-hackers-win32 pgsql-www

Josh Berkus wrote:

>Tom,
>
>
>
>>Possibly workable, but what's your definition of "registered user"?
>>
>>
>
>Signing up via a webform, getting an e-mailed password back, logging in.
>
>
>
>>I'd hope that anyone subscribed to any of the mailing lists would be
>>considered registered, for instance. Not sure if we can do that with
>>either BZ or GForge; anyone know?
>>
>>
>
>Usually it works the other way around; people can't subscribe until they've
>registered via web.
>
>

I believe it should not be hard to do a one-time bulk registration of
everyone on the lists, if that was desired.

Stepping back a bit and gathering a few threads.

BZ versions etc. There is finally some movement in the mainline BZ code
to get DB independence into it - and the first DB to benefit will be
Postgres. Dave Lawrence at RedHat appears to be working again on
landing this (after a long hiatus). See
http://bugzilla.mozilla.org/show_bug.cgi?id=98304 and
http://bugzilla.mozilla.org/show_bug.cgi?id=146679 . The reason I would
prefer to go with mainline BZ (assuming we go with BZ at all) is that my
past experience of upgrading BZ has not been pleasant, and I am sure it
would be even harder doing it from a fork like the RedHat one.

Signal to Noise. It's not at all clear to me why a bug tracking system
should have a worse signal to noise ratio than a mailing list with
similar access rules, especially since we also provide the facility to
log bugs through a web form directly off the postgresql.org home page.
But even if it does, that can be managed by good triage. That should
improve the ratio for all but those doing the triage. Personally, I'd be
surprised if it took one knowledgable person more than 30 minutes a day
to weed out the garbage (sorry for the mixed metaphor), and if the load
was spread across several people it would be just a few minutes a day
for any one of them, at a significant saving to everyone else.

Email interface: it should not be beyond the wit of man to provide some
level of email interface to any reasonable bug tracking system. Whether
or not it is worth doing depends on the demand. Two obvious places for
it would be 1) to allow initial logging of a bug via email, and 2)
periodically run query 'foo' and email me the results. Getting a once a
day digest of new bug reports might be quite nice in fact.

One size fits all: I understood that this discussion arose in the
context of a suggestion to migrate GBorg to a GForge base (a proposal I
generally support). What is right for the core project might well not be
right for GBorg projects. Perhaps a conservative approach might be to
try things out on GBorg/GForge and see how things go, without touching
how the core operates for now.

cheers

andrew

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Shridhar Daithankar 2004-02-27 14:51:27 Re: [pgsql-www] Collaboration Tool Proposal
Previous Message Dan Langille 2004-02-27 12:35:16 Re: features required for SQL 92 conformance

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Gamache 2004-02-27 14:38:51 Re: Any Gentoo users interested in a slotted PostgreSQL
Previous Message Bruno Wolff III 2004-02-27 14:29:17 Re: bgwriter never dies

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Shridhar Daithankar 2004-02-27 14:51:27 Re: [pgsql-www] Collaboration Tool Proposal
Previous Message Josh Berkus 2004-02-27 07:11:14 Re: [HACKERS] Collaboration Tool Proposal

Browse pgsql-www by date

  From Date Subject
Next Message Shridhar Daithankar 2004-02-27 14:51:27 Re: [pgsql-www] Collaboration Tool Proposal
Previous Message Chris Ryan 2004-02-27 13:31:30 Re: Feeds Integration