public inbox for [email protected]
help / color / mirror / Atom feedFrom: Andrew Dunstan <[email protected]>
To: [email protected]
To: [email protected]
Subject: Re: [HACKERS] Collaboration Tool Proposal
Date: Fri, 27 Feb 2004 09:29:24 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
view thread (62+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: [HACKERS] Collaboration Tool Proposal
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox