Collaboration Tool Proposal

Josh Berkus wrote:

Folks,

Discuss:

Has anyone talked to the people at collabnet (http://www.collab.net)? I
wonder if they'd be willing to put something together for the PostgreSQL
team? They run the tigris.org site, which is one of the nicest OSS
collaboration sites I've worked with. GForge is nice, but seems more
kludgey than Tigris.

What does the Apache project run?

Another option is something like Drupal (http://www.drupal.org). Drupal
is a CMS system with tons of plugins. I'm not sure that it could handle
a project as large as PostgreSQL, but Drupal's own development work is
self hosted. It may merit some investigation.

Joseph,

Thanks for feedback.

Has anyone talked to the people at collabnet (http://www.collab.net)? I
wonder if they'd be willing to put something together for the PostgreSQL
team? They run the tigris.org site, which is one of the nicest OSS
collaboration sites I've worked with. GForge is nice, but seems more
kludgey than Tigris.

Collabnet is not OSS. We would be dependant on their charity (and
profitablity) to host us, which has not been The PostgreSQL Way (tm) to
date. Also, as a former OpenOffice.org Project lead, Collabnet is not very
responsive to user feature requests unless they are backed by $$$$. It's
the way proprietary software works. Last time I was involved (late 2002),
all web management on CN was done via CVS, which meant that everything,
including news items, needed to be coded in raw HTML. Not the direction we
want to go in.

Believe me, I considered CN, because it *is* an excellent code management
tool. But it's not OSS and the community management support isn't there.

What does the Apache project run?

Not sure. Anyone?

Another option is something like Drupal (http://www.drupal.org). Drupal
is a CMS system with tons of plugins. I'm not sure that it could handle
a project as large as PostgreSQL, but Drupal's own development work is
self hosted. It may merit some investigation.

Nope. Drupal is stricty community; it doesn't do project/code management.
Also it doesn't scale (and isn't intended to).

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, 2004-02-26 at 13:19, Josh Berkus wrote:

What does the Apache project run?

Not sure. Anyone?

Apache uses a home-brew collection of OSS tools. I think they have the
advantage of a larger community of web developers to help out than we
have ;-)

Josh, are you still in favor of this move if the larger community does
not want to move the main project to a gforge based system? or vice
versa?

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert,

Josh, are you still in favor of this move if the larger community does
not want to move the main project to a gforge based system? or vice
versa?

Not sure. Depends on what the leads of the associated projects think.
Obviously, if everyone's dead set against it, we won't do it.

However, keep in mind that this is a proposal to *try* migrating to GForge.
We can reverse the process if we decide it's not worth it. That's why I'd
like to start with a few projects at a time.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, Feb 26, 2004 at 10:49:46AM -0800, Josh Berkus wrote:

Not sure. Depends on what the leads of the associated projects think.
Obviously, if everyone's dead set against it, we won't do it.

I for one am willing to try this in the near term. I've got an external
domain (pqxx.tk) pointing to the libpqxx page on GBorg, and moving it over
to a new URL is child's play. My main worry is transition management:

- How will mailing list subscribers be affected?
- How will CVS users be affected?
- Can the mailing list archives be moved over?
- Where will my old bug reports and corresponding discussions go?
- Can FAQ entries be copied over automatically?
- Is there a way of migrating these services one by one?

If it takes some scripting and/or programming to do some of this, I'm
willing to help insofar as I have time.

Jeroen

Jeroen,

I for one am willing to try this in the near term.

Great!

I've got an external
domain (pqxx.tk) pointing to the libpqxx page on GBorg, and moving it over
to a new URL is child's play. My main worry is transition management:

- How will mailing list subscribers be affected?
- How will CVS users be affected?
- Can the mailing list archives be moved over?
- Where will my old bug reports and corresponding discussions go?
- Can FAQ entries be copied over automatically?
- Is there a way of migrating these services one by one?

Either Tim, Chris, or both will help with this. If we can't migrate
everything by script, we'll have to give up on the idea. Some projects, like
JDBC, have huge mailing list archives.

I think you would want to do the migration "all at once", though. Putting up
a page explaining that the CVS is on GForge but the mailing lists are non
GBorg for a week would confuse the heck out of people, I think.

Since both systems are based on postgresql databases, migration should be the
simple expedient of writing the right Perl/PHP+SQL script.

If it takes some scripting and/or programming to do some of this, I'm
willing to help insofar as I have time.

Terrific!

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Feb 26, 2004, at 6:53 PM, Joseph Tate wrote:

Josh Berkus wrote:

Folks,
Discuss:

Has anyone talked to the people at collabnet (http://www.collab.net)?
I wonder if they'd be willing to put something together for the
PostgreSQL team? They run the tigris.org site, which is one of the
nicest OSS collaboration sites I've worked with. GForge is nice, but
seems more kludgey than Tigris.

What does the Apache project run?

Another option is something like Drupal (http://www.drupal.org).
Drupal is a CMS system with tons of plugins. I'm not sure that it
could handle a project as large as PostgreSQL, but Drupal's own
development work is self hosted. It may merit some investigation.

Drupal? I would not recommend it. WIth every plug and play CMS you get
what you pay for aka when you need to change something, you are in
trouble and you end up searching their classes and grasp to understand
they way they code in php.

Is this as an alternative to gborg or the current website ? As far as I
know drupal has nothing like bug tracking etc. for sure GForge (to me )
is way better then drupal :D

Thanks
David Costa

Josh Berkus wrote:

PROPOSAL: GBorg --> GForge Migration

Why do we want a full-service collaboration tool?

In terms of improving the hosting infrastructure, this would surely be a
step forward, but the problem with "collaboration" is not that the
tools are missing, it's that people are unwilling to use any tools for
issue tracking, etc. This is in fact a near-universal problem. If you
look at sourceforge, very few projects actually use any of the
"collaboration" tools. If you want to get the project to do something,
you still have to use email and CVS. And with those projects (not
necessarily on sourceforge) that have a sophisticated bug tracking
structure, the sheer number of filed bugs is so large and irregular in
quality that the bugs are in fact meaningless. (Oddly enough, the
projects I have in mind here do *not* use a full-service collaboration
tool, just a bug tracker. Make of that what you will.) So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.

On Thu, Feb 26, 2004 at 09:16:38PM +0100, Peter Eisentraut wrote:

In terms of improving the hosting infrastructure, this would surely be a
step forward, but the problem with "collaboration" is not that the
tools are missing, it's that people are unwilling to use any tools for
issue tracking, etc. This is in fact a near-universal problem. If you
look at sourceforge, very few projects actually use any of the
"collaboration" tools. If you want to get the project to do something,
you still have to use email and CVS. And with those projects (not
necessarily on sourceforge) that have a sophisticated bug tracking
structure, the sheer number of filed bugs is so large and irregular in
quality that the bugs are in fact meaningless. (Oddly enough, the
projects I have in mind here do *not* use a full-service collaboration
tool, just a bug tracker. Make of that what you will.) So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.

One thing that helps a lot in my experience is the ability to manage bug
reports. On gborg, for instance, I'm stuck with several dozen duplicates
from a time there were technical problems with the site; lots of "semantic
garbage" in the form of people making silly assumptions, not reading
earlier bug reports, or asking generic C++ questions; requests for features
that are already there; support requests and other irrelevant issues; and
multiple reports covering the same underlying problem.

If I could merge, delete, categorize & group these requests the list would
be a lot easier to manage.

Jeroen

Peter,

So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.

Yeah. As my grandfather used to say, "You can lead a horse to water, but you
can't make him shrink." (granddad is under care, now).

Everyone: Further data: if we prefer BugZilla to GForge's lighter-weight bug
tracking, it turns out that there is a BZ plug-in for GForge.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

Peter,

So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.

Yeah. As my grandfather used to say, "You can lead a horse to water, but you
can't make him shrink." (granddad is under care, now).

Everyone: Further data: if we prefer BugZilla to GForge's lighter-weight bug
tracking, it turns out that there is a BZ plug-in for GForge.

Perhaps when BZ supports PG - some progress is being made on that front,
but it's not a done deal yet.

cheers

andrew

On Feb 26, 2004, at 6:12 PM, Josh Berkus wrote:

Why do we want to replace GBorg?

GBorg was pretty good collab tool technology for 2000.
Heck, it's still not a bad tool. Unfortunately, since the
demise of Great Bridge, it's had only one maintainer (for
whose efforts we are very grateful), meaning
that little or no progressive development has taken place.
For example, GBorg still lacks both project and bug search
features, and based on our community is unlikely to develop
these things.

+1 for me. I think the bug tracking is a must. I have some experience
with bugs on php.net
(http://bugs.php.net/) and the excellent platform makes the volunteers
work much easier.

Why GForge?

GForge runs on PostgreSQL and their team are enthusiastic PG
users. Most other collab tools run on other databases and would

Again +1, they run PostgreSQL their project is made for postgresql (and
this is rare in the PHP world) it makes sense to me.

But I don't want to migrate my project!

See above. You'd have at least a year to procrastinate about it,
and may be able to get someone else to do most of the
migration work for you.

I would be glad to help, gforge is a PHP based project so I could try
something out. I don't think that
we (or better said gborg developers) should be scared about the move.
It is always a pain to migrate but, if it is worth the effort (and in
this case
we could all benefit from a more structured system) we have to do it.

The suggestion is to move slowly, so, worth a shoot.

Cheers
David Costa

On Thu, 2004-02-26 at 15:41, Andrew Dunstan wrote:

Josh Berkus wrote:

Peter,

So yes, I
think this is a reasonable plan, just don't expect "collaboration" to
suddenly appear out of nowhere.

Yeah. As my grandfather used to say, "You can lead a horse to water, but you
can't make him shrink." (granddad is under care, now).

Everyone: Further data: if we prefer BugZilla to GForge's lighter-weight bug
tracking, it turns out that there is a BZ plug-in for GForge.

Perhaps when BZ supports PG - some progress is being made on that front,
but it's not a done deal yet.

I can't imagine the BZ plugin for Gforge would require you to use a
second database system would it? Besides which we can always use red
hats bugzilla port if need be. I know people have a lot of issues with
it, but if it works for a project of red hats size, i think it would
work for us...

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

In terms of improving the hosting infrastructure, this would surely be a
step forward, but the problem with "collaboration" is not that the
tools are missing, it's that people are unwilling to use any tools for
issue tracking, etc.  

I quite agree with Peter. Most sub-projects have one or two lead developers,
who organize themselves. In the case of PostgreSQL, the problem is not
developer intelligence, PostgreSQL project already host the best brains.

On a different level:

I feel that new-comers to PostgreSQL have a hard time finding the right tools,
installing and starting PostgreSQL, connecting locally, etc...

We probably never hear from these users, as they never reach the first
connection. In a way, PostgreSQL is targetted at an "elite of hackers".

At pgAdmin, I started a (very) experimental project of mass-download:
http://www.pgadmin.org/pgadmin3/advocacy.php#list

There are no precise statistics, we do not know yet the impact of releasing
pgAdmin III on so many sites. And PostgreSQL Win32 port is not there.

In a few weeks ... with the arrival of PostgreSQL win32 version,
there could be a rush to PostgreSQL, like never before.

A bundle including PHP, PostgreSQL, PhpPgAdmin and pgAdmin III
could reach (at least) 100.000 download every month on:

- PostgreSQL mirrors,
- PHP mirrors,
- Shareware and freeware sites,
- Community sites.

A real flow of people... How are we going to receive them?

My preffered answer would be to use the same techniques that proved to be
successful. No need to find complicated solutions:

PHP.NET web site proved successful,
let us fork PHP.NET web site

But, do we really want to become the Apache of the database world?
(don't flame me if you think I am becoming mad... I don't think I am.)

If you would like to answer, maybe try posting to
pgsql-advocacy@postgresql.org (no cross-posts).

Otherwise, let us sleep well and make dreams of a better world.

Cheers,
Jean-Michel Pouré

Robert Treat <xzilla@users.sourceforge.net> writes:

On Thu, 2004-02-26 at 15:41, Andrew Dunstan wrote:

Perhaps when BZ supports PG - some progress is being made on that front,
but it's not a done deal yet.

I can't imagine the BZ plugin for Gforge would require you to use a
second database system would it? Besides which we can always use red
hats bugzilla port if need be.

Yeah, I looked into that when core started discussing this whole thing
awhile back. The Red Hat port of BZ to Postgres is perfectly usable.
Dave Lawrence (maintainer of said port) told me he hopes to see those
changes folded back upstream in another major release or so, at which
point RH will stop needing to maintain a fork. But in the meantime
we can use their version. It'd sure beat using You Know Who to keep
track of our own bugs ;-)

I would favor using Bugzilla over anything else just because I'm used
to it (have to use it internally at Red Hat anyway).

regards, tom lane

Tom Lane wrote:

Yeah, I looked into that when core started discussing this whole
thing awhile back. The Red Hat port of BZ to Postgres is perfectly
usable.

Is it available anywhere?

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane wrote:

Yeah, I looked into that when core started discussing this whole
thing awhile back. The Red Hat port of BZ to Postgres is perfectly
usable.

Is it available anywhere?

Sure, download it off their front bugzilla page:

http://bugzilla.redhat.com/bugzilla/

The link is presently about two paras down in the "News" section.

regards, tom lane

People,

The question is, do we need BZ right off or should we try GForge's lightweight
tool first? Personally I find that BZ is a little intimidating to new
users, particularly for searching on issues; as a result it tends to lead to
a lot of duplicate filings.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Feb 26, 2004, at 11:11 PM, Jean-Michel POURE wrote:

I feel that new-comers to PostgreSQL have a hard time finding the
right tools,
installing and starting PostgreSQL, connecting locally, etc...

We probably never hear from these users, as they never reach the first
connection. In a way, PostgreSQL is targetted at an "elite of hackers".

Hello,
It could be true. Perhaps a beginner's guide will do the trick.

A bundle including PHP, PostgreSQL, PhpPgAdmin and pgAdmin III
could reach (at least) 100.000 download every month on:

- PostgreSQL mirrors,
- PHP mirrors,
- Shareware and freeware sites,
- Community sites.

A real flow of people... How are we going to receive them?

Not sure if that would really gain consensus. Many PostgreSQL users are
not into PHP.
I am a volunteer at PHP.net and as far as I see they do not offer a
bundle.

Then you might get perl users complaining for example. Of course I see
that other companies
are already offering such a bundle, NuSphere does
http://www.nusphere.com/products/index.htm

My preffered answer would be to use the same techniques that proved to
be
successful. No need to find complicated solutions:

PHP.NET web site proved successful,
let us fork PHP.NET web site

Umh, the php.net code is available on each page via the "source" link.
That said I am not sure that a clone/fork will be a good start.
We can make the site better with other components without having to
fork anything IMHO

But, do we really want to become the Apache of the database world?
(don't flame me if you think I am becoming mad... I don't think I am.)

Not sure but my personal aim is to make the php community aware of the
fact that PostgreSQL is way better then MySQL and other solutions out
there.

If you would like to answer, maybe try posting to
pgsql-advocacy@postgresql.org (no cross-posts).

Regards,
David Costa, PostgreSQL Advocate http://dotgeek.org
david at postgresql ddoot org gurugeek att php dot net
$dsn = 'pgsql://world:most_advanced@localhost/open_source_database';

Josh Berkus wrote:

The question is, do we need BZ right off or should we try GForge's
lightweight tool first? Personally I find that BZ is a little
intimidating to new users, particularly for searching on issues; as a
result it tends to lead to a lot of duplicate filings.

I think we had previously decided that we will not allow a random user
off the street to file bug reports into whatever system we end up
using. I see it primarily as a bug *tracking* system, not a bug
*reporting* system.

Peter Eisentraut wrote:

Josh Berkus wrote:

The question is, do we need BZ right off or should we try GForge's
lightweight tool first? Personally I find that BZ is a little
intimidating to new users, particularly for searching on issues; as a
result it tends to lead to a lot of duplicate filings.

I think we had previously decided that we will not allow a random user
off the street to file bug reports into whatever system we end up
using. I see it primarily as a bug *tracking* system, not a bug
*reporting* system.

I don't recall that there was a consensus about that. The difference
between BZ's "unconfirmed" and "new" states is that the latter means it
has been triaged. See http://bugzilla.mozilla.org/bug_status.html .

I certainly don't think we should impose such a restrictive rule on
every project that we might host on a GForge installation.

cheers

andrew

Peter Eisentraut <peter_e@gmx.net> writes:

I think we had previously decided that we will not allow a random user
off the street to file bug reports into whatever system we end up
using.

Uh, why not? (And more to the point, why raise the barrier to entry on
reporting bugs?)

Individuals can already post to pgsql-bugs "off the street", and it is
not much of a problem. Invalid bug reports can easily be marked as
such.

-Neil

On Thu, 2004-02-26 at 13:41, Andrew Dunstan wrote:

Perhaps when BZ supports PG - some progress is being made on that front,
but it's not a done deal yet.

Redhat puts out a PG version of Bugzilla. It works pretty well.

However, we just dropped it in favor of Jira.

Jira is a lot friendlier for the less technically adept, and IIRC, it's
free for open source projects. It's not enough to have something that
can track bugs; you have to have something that people are willing to
use. :)

On Thu, 2004-02-26 at 15:45, Peter Eisentraut wrote:

Tom Lane wrote:

Yeah, I looked into that when core started discussing this whole
thing awhile back. The Red Hat port of BZ to Postgres is perfectly
usable.

Is it available anywhere?

http://bugzilla.redhat.com/download/bugzilla-redhat-20031120.tar.gz

Tom Lane <tgl@sss.pgh.pa.us> writes:

I would favor using Bugzilla over anything else just because I'm used
to it (have to use it internally at Red Hat anyway).

I might suggest again RT. It's open source and has serious commercial
traction. The postgres port needs a lot of work for it to really catch up to
the original MySQL implementation so most of the users are using it with
MySQL.

But it works ok under postgres and having more postgres-familiar eyes looking
at it would help polish both its postgres port and fix the problems it exposes
in the postgres optimizer.

It's more of a generic ticketing system than a single-purpose bug tracking
system though. I'm not sure how smoothly it would be usable for bug-tracking
an open source project like postgres.

--
greg

Neil Conway <neilc@samurai.com> writes:

Peter Eisentraut <peter_e@gmx.net> writes:

I think we had previously decided that we will not allow a random user
off the street to file bug reports into whatever system we end up
using.

Uh, why not? (And more to the point, why raise the barrier to entry on
reporting bugs?)

Our first try at a bug tracking system, several years ago, was open to
anybody to create entries, and we found that the signal-to-noise ratio
went to zero in no time. Too many not-a-bugs, too many support
requests, too few actual bugs. We went back to using the pgsql-bugs
mailing list.

It could be that in the intervening time, people have gotten used to bug
trackers because of their availability on other projects. If so, we
might find a better grade of reports coming in. I'm not very optimistic
about that though.

As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform. Most of the bug trackers I'm
aware of are webform-only. I don't consider that a step forward,
especially since a webform isn't very conducive to making good reports
(it's hard to attach test cases, for instance).

regards, tom lane

Tom,

Our first try at a bug tracking system, several years ago, was open to
anybody to create entries, and we found that the signal-to-noise ratio
went to zero in no time. Too many not-a-bugs, too many support
requests, too few actual bugs. We went back to using the pgsql-bugs
mailing list.

I actually sort of agree with Tom, although I don't want to raise the barrier
too high. I'd suggest allowing all registered users to submit bugs.
Needing to go through registration should severely reduce the "noise", even
if we give no restriction on who can register.

I field the Advocacy webform right now, and only get about 10 e-mails a day,
even though some of those are really support requests better handled by the
mailing lists. I think we could handle 5 bad bug reports a day.

As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform. Most of the bug trackers I'm
aware of are webform-only. I don't consider that a step forward,
especially since a webform isn't very conducive to making good reports
(it's hard to attach test cases, for instance).

Both the BZ and GForge webforms allow uploading files. And I'd far rather
have a single copy of a test case on our web site than a couple dozen being
e-mailed out.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh@agliodbs.com> writes:

I actually sort of agree with Tom, although I don't want to raise the barrier
too high. I'd suggest allowing all registered users to submit bugs.

Possibly workable, but what's your definition of "registered user"?

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?

regards, tom lane

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.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Folks,

Tim Perdue sent me this.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

-----Original Message-----
From: Greg Stark [mailto:gsstark@mit.edu]
Sent: Friday, February 27, 2004 12:17 AM
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [pgsql-www] Collaboration Tool Proposal

[...snip...]

I might suggest again RT. It's open source and has serious commercial
traction. The postgres port needs a lot of work for it to
really catch up to
the original MySQL implementation so most of the users are
using it with
MySQL.

A second for considering RT. I've been using RT 3.0.6 for about five months
now for our internal support and (closed-source) bug tracking, and can
report that it works very smoothly with PostgreSQL. I had more problems with
getting all the Perl dependencies lined up than anything else, but that was
mostly my ignorance regarding big Perl apps and Apache.

It also can accept tickets via web or e-mail, so using it would not require
reducing the available methods for submitting bugs.

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

On Friday 27 February 2004 19:59, Andrew Dunstan wrote:

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

I agree. If possible we could also run postgresql registration system where we
can track general usage of postgresql on various fronts, for the information
people are willing to put their name on. It could be a massive advocacy
ammo..

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.

Look at KDE bugzilla. They first make you search and then file the bug. I have
seen duplicates dropping from several thousands to few hundreds. Simple but
effective step. For sure postgresql will hardly receive that kind of bug
flurry.

They put a direct report a bug in KDE2.0. Click on a menu item and it send a
bug report. As a result they had massive duplicates. Now the menu item give
you a URL to click on, then you go and search etc. Very nice system.

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.

Logging bugs via email is a bad idea because you can not enforce the fields.
Would you like somebody filing a bug via mail and leaving postgresql version
out?

Let people use webforms. It is nice enough IMHO..

Shridhar

On Fri, 27 Feb 2004 09:17:13 -0500
"Bort, Paul" <pbort@tmwsystems.com> wrote:

-----Original Message-----
From: Greg Stark [mailto:gsstark@mit.edu]

[...snip...]

I might suggest again RT. It's open source and has serious
commercial traction. The postgres port needs a lot of work for it to

really catch up to
the original MySQL implementation so most of the users are
using it with
MySQL.

A second for considering RT. I've been using RT 3.0.6 for about five
months now for our internal support and (closed-source) bug tracking,
and can report that it works very smoothly with PostgreSQL. I had more
problems with getting all the Perl dependencies lined up than anything
else, but that was mostly my ignorance regarding big Perl apps and
Apache.

That perl dependency issue is not such a small one, IMHO. We've used RT
in the past, but ditched it because without installing a compiler on the
exposed server, we spent far too much time trying to keep all those
modules up-to-date. If you run an mod_perl web server anyway, maybe it's
not such a big deal. But if you do not, I'm not sure RT is good enough
to justify the extra work.

That said, if the perl module depencies are not a big deal for you, the
UI is nice. Just IMHO not nice enugh to justify the extra work when
there are so many other options to choose from.

(FWIW, I would love to see more effort in keeping bugzilla's current
versions up-to-date wrt to postgresql, and I note that full postgresql
compatibility is part of the next major release [2.18]. But my hopes are
probably not worth the bits required to transmit them)

--
Karl DeBisschop (kdebisschop@alert.infoplease.com)
Pearson Education/Infoplease (http://www.infoplease.com)

Tom Lane <tgl@sss.pgh.pa.us> writes:

As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform. Most of the bug trackers I'm
aware of are webform-only. I don't consider that a step forward,
especially since a webform isn't very conducive to making good reports
(it's hard to attach test cases, for instance).

There are plenty of bug tracking systems that use email extensively. In fact I
think the traditional approach was to be entirely email based. GNATS, the
venerable candidate in this field for example, is entirely email based. But
GNATS kind of sucks.

The Debian system is entirely email controllable, including command messages
to close, reassign, etc. bugs. It depends on people following instructions and
following up to the numeric address it sends you.

RT behaves like a ticketing system where it assigns you a ticket number on the
initial email and then tracks subsequent emails by the subject and other
headers.

I dislike BZ for the way it *forces* you to use the web interface. I prefer
email based systems for the simple reason that I already have a perfectly good
tool for composing text and reading conversations. It alerts me when I get
messages, sorts the messages into folders etc. The last thing I want to do is
have to remember 20 different web sites to check to see if there's any news.
And the last thing I want to do when I have a long detailed explanation of a
problem is try typing into some little bitty box in a web browser with the
pitiful editing features they have.

I also dislike BZ for aesthetic reasons. If one person is editing a ticket
while another person updates the same ticket, it refuses your edits and you
have to start all over. I think all the updates are stored in one big field.

--
greg

Hi,

please look at CodeBeamer (www.intland.com) it has all featured you
described and for selected open source projects is free now.
It is a web based collaborative software development platform with
-project tracking (dashboard)
-tracker
-document manager (sharing + versioning)
-forum
-cvs, Subversion and other SCM integration, GUI
-code browsing, xref for C/C++ and Java
-automated build

Thanks,
Janos

Folks:

ALTERNATIVE BUG TRACKERS:

Jira: Core did look at and consider (and debate) Jira. Atlassian are
enthusiastic PostgreSQL supporters and offered to host Jira for us.
However, Jira is not OSS and for various reasons it would be difficult to
host a Jira installation at Hub.org. We're very reluctant to endorse any
non-OSS, externally hosted solution becuase of the distinct possibility that
the company will have a change of management and drop us. There is also a
significant political issue; by adopting a non-OSS piece of infrastructure,
we are effectively saying that OSS software isn't good enough, in the eyes of
many members of the public.

RT: I've been using RT for OSCON, and am not wowed by it. Of course, I
can say the same of BZ and GForge-Tracker. From my perspective, it's
neither better nor worse than the other solutions, although the interaction
with e-mail is nice.
More importantly, *we* would have to do the port to PostgreSQL. This is
pretty much prohibitive; how long have we been working on an update to the
main site, Techdocs, and/or Advocacy? If we pick a solution which is not
ready *right now* I fear that we will still be having this discussion in late
2005. I also don't see any good reason, politically, to adopt a tool by a
community who are not at all enthusiastic about Postgres -- when there a
those available that are.

Both of the above alternatives have 2 major issues:
1) They are each bug trackers and bug trackers only. They do not deal with
community or code management at all. I would tend to prefer an integrated
solution where one is available.

2) For whatever reason, most of our volunteer web crew seem to be PHP
developers. We haven't attracted many Perl or Java programmers to helping
with the site. This may be a chicken-and-egg thing, but unless there are
several untapped Perl Hackers/Java programmers waiting to jump in and do
integration work for RT, Jira, or whatever, any non-PHP solution
automatically carries a detraction.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Paul,

Your main concern about RT isn't true, at least here at my office. I
installed RT, with no prior experience with any OSS tracker, back in
October, and it worked on PostgreSQL the first time. (PostgreSQL support was
one of the main reasons I chose it to track issues on my
PostgreSQL/Perl-based webapp.) I made this point in an earlier post in this
thread. There is no conversion effort needed with RT 3.0.6, it just works on
PostgreSQL.

My apologies, then! I was operating off of the statements of others, and the
fact that the only RT impelementations I've used were running on MySQL. So,
questions:

1) can you compare/contrast RT vs. BZ vs. Simplified bug-tracking, like
GForge?

2) What help, if any, would we be able to get in supporting RT from the RT
community?

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Greg Stark wrote:

I also dislike BZ for aesthetic reasons. If one person is editing a ticket
while another person updates the same ticket, it refuses your edits and you
have to start all over. I think all the updates are stored in one big field.

AFAICS it's one row per comment, at least in the 2.17 code base. BZ does
have horrible locking issues - they are being dealt with as part of the
bugs I referred to elsewhere.

cheers

andrew

My apologies, then! I was operating off of the statements
of others, and the
fact that the only RT impelementations I've used were running
on MySQL. So,
questions:

1) can you compare/contrast RT vs. BZ vs. Simplified
bug-tracking, like
GForge?

I've used Bugzilla for searching for FOP issues, and a couple other places,
and I find the RT search much more obvious. I can get what I want out of
Bugzilla, but usually by creating a really broad search and sifting entries
one at a time for likely candidates. The fact that an RT search is iterative
is much more obvious, because the bottom of the search page lists all of the
current criteria, and the box for adding new ones. Add or remove, and re-run
the search. I like the trick that it does with mutually exclusive
conditions: It assumes an 'or' between them. (eg, all tickets that are in
state 'open' or 'closed'.)

OTOH, Bugzilla tracks a whole pile more fields by default. I've taken to
putting version numbers in the ticket subject in RT because for the small
project here, it's easier than learning how to add a version field. (I
haven't tried adding my own fields.)

Both handle attachments and comments sanely. I don't know if BZ has an
e-mail interface, but the one in RT has filled the basic needs here. (We
haven't pushed the limits of the e-mail part.)

I have never tried to install BZ. RT's install (RedHat 8.0, PostgreSQL 7.2.4
from RPMs) was straightforward once all the Perl modules were up to date.
(All of the needed modules were available from CPAN.)

I don't recall using any simplified bug tracking on-line, except maybe at
ImageMagick.com, which seems to be more a forum or mailing list search, with
no real tracking fields.

2) What help, if any, would we be able to get in supporting
RT from the RT
community?

I'm afraid I have no idea what or where the larger RT community is. I know
there's commercial support available from the author (whom I have no contact
with), and I found the answers to my (self-created) problems during setup
using Google. I found RT because of a (don't ban me, please ;-) discussion
on SlashDot. (http://slashdot.org/article.pl?sid=03/10/06/1854211) There
were a large number of proponents of RT there; their posts claimed years of
use at many sites.

I would be happy to lend my meager talents to setting it up for a trial, if
that's where the group decides to go.

But Josh made a good point off-list: are we trying to solve the problem of
ticket/bug tracking, or community/collaboration in general?

My $0.02: CVS handles the code, mailing lists handle the dialog, and a
ticket/bug tracker keeps people from losing things. About all that leaves
for the web site to do is advocate PostgreSQL (which I think it does nicely)
and related projects, and provide some glue (like how to find the name of
the other lists or projects to see what they're doing.) New tools or old,
every day with PostgreSQL is a good day.

Mikhail,

For a standalone bug/issue tracking tool take a look on
http://roundup.sourceforge.net

I don't see PostgreSQL support listed -- just SQLite and MySQL.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Bort, Paul wrote:

My apologies, then! I was operating off of the statements
of others, and the
fact that the only RT impelementations I've used were running
on MySQL. So,
questions:

1) can you compare/contrast RT vs. BZ vs. Simplified
bug-tracking, like
GForge?

I've used Bugzilla for searching for FOP issues, and a couple other places,
and I find the RT search much more obvious. I can get what I want out of
Bugzilla, but usually by creating a really broad search and sifting entries
one at a time for likely candidates. The fact that an RT search is iterative
is much more obvious, because the bottom of the search page lists all of the
current criteria, and the box for adding new ones. Add or remove, and re-run
the search. I like the trick that it does with mutually exclusive
conditions: It assumes an 'or' between them. (eg, all tickets that are in
state 'open' or 'closed'.)

OTOH, Bugzilla tracks a whole pile more fields by default. I've taken to
putting version numbers in the ticket subject in RT because for the small
project here, it's easier than learning how to add a version field. (I
haven't tried adding my own fields.)

Both handle attachments and comments sanely. I don't know if BZ has an
e-mail interface, but the one in RT has filled the basic needs here. (We
haven't pushed the limits of the e-mail part.)

I have never tried to install BZ. RT's install (RedHat 8.0, PostgreSQL 7.2.4
from RPMs) was straightforward once all the Perl modules were up to date.
(All of the needed modules were available from CPAN.)

I don't recall using any simplified bug tracking on-line, except maybe at
ImageMagick.com, which seems to be more a forum or mailing list search, with
no real tracking fields.

2) What help, if any, would we be able to get in supporting
RT from the RT
community?

I'm afraid I have no idea what or where the larger RT community is. I know
there's commercial support available from the author (whom I have no contact
with), and I found the answers to my (self-created) problems during setup
using Google. I found RT because of a (don't ban me, please ;-) discussion
on SlashDot. (http://slashdot.org/article.pl?sid=03/10/06/1854211) There
were a large number of proponents of RT there; their posts claimed years of
use at many sites.

[some stuff about RT]

FWIW there's a good directory of bug tracking systems on google:
http://directory.google.com/Top/Computers/Software/Configuration_Management/Bug_Tracking/Free/

I have looked at RT briefly today, and its technology appears to be
sound. (Just the fact that it will run under both mod_perl and FastCGI
means that a lot of common insanity is missing - these environments are
very good at blowing up with badly written software. They are also far
more scalable than standard CGI web environments, so we would be less
likely to have performance issues.)

I would be happy to lend my meager talents to setting it up for a trial, if
that's where the group decides to go.

ditto

But Josh made a good point off-list: are we trying to solve the problem of
ticket/bug tracking, or community/collaboration in general?

The discussion arose in the context of an alternative to the rather
simple bug tracking system that comes with GForge. The biggest issue
with any replacement would be to plug it in successfully. If too much
glue is needed, we haven't really made an advance on the current GBorg
code base.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

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.

Actually none of these are quite the most important. I think the most
important aspect of the email interface is being able to submit additional
information on a bug.

I find it frustrating to receive an email saying "user foo said foo" and not
be able to hit reply to send a response. Instead I have to start a browser,
click a link in the email, log in with a username and password, ...

If something sends me an email it should expect me to respond in the same
medium.

--
greg

There is a roundup version for postgresql. I have not tried it.
For python people, this is the ultimate solution. It is
customizable to death. I have the mailing list archives for
the last couple of months.

I like round up and use it. It has a great email interface
and a "nosy" list feature which enables people to track
the status of their issues.

But as it is now, a resident python person would be extremely
helpful to wrap up any customization (yes we'll want customization).

--elein
elein@varlena.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

2) For whatever reason, most of our volunteer web crew seem
to be PHP developers. We haven't attracted many Perl or Java
programmers to helping with the site. This may be a chicken-and-egg
thing, but unless there are several untapped Perl Hackers/Java
programmers waiting to jump in and do integration work for RT,
Jira, or whatever, any non-PHP solution automatically carries
a detraction.

Definitely a chicken-and-egg thing. I am a Perl person, otherwise
I would have done more than I have on the site. I cannot speak
for Java, but I don't think Perl would be a problem, as I can think
of a few people besides myself with Perl skills who would be
willing to help out.

FWIW, I think bugzilla is our best option - it's open source,
mature, and familiar to a lot of people.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200402280736

-----BEGIN PGP SIGNATURE-----

iD8DBQFAQIuHvJuQZxSWSsgRAnHqAKDIHNlaRZhjxnkJlHGeWVm3Fn6R/wCgmgo5
MA2Qz6ChHdbKuBvESWKoNv8=
=KAO/
-----END PGP SIGNATURE-----

Janos,

So far, all of the solutions that are being seriously considered seem to be
free, open-source software. I can't find any indication on your site that
this is software the PostgreSQL community can hack to bits as needed over
the years. Even if it's free now, there's the possibility that it will later
turn out to be a free straitjacket.

Regards,
Paul

Why GForge?

GForge seems to be technically OK. But what about the future outlook. The home
page lists 5 projects, whereof the 4 are tests. Are you sure they will not
fold in a month or two, will they be reliable, responsive and real nice (the
three r's) ?

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 �ben 12.00-18.00 Email: kar@kakidata.dk
2000 Frederiksberg L�rdag 12.00-16.00 Web: www.suse.dk

On Sun, Feb 29, 2004 at 02:35:59AM +0100, Kaare Rasmussen wrote:

Why GForge?

GForge seems to be technically OK. But what about the future outlook. The home
page lists 5 projects, whereof the 4 are tests. Are you sure they will not
fold in a month or two, will they be reliable, responsive and real nice (the
three r's) ?

http://gforge.org/ is not a hosting site, that is why you only found 4
test projects and the GForge project itself hosted on the site. The idea
is that you download the software and host it on your own hardware.

--Tim Larson

Dear all ,

I dont know to what state this discussion has reached but
have a thought for

http://www.otrs.org

It has Postgresql Support and uses Perl

--
Best Regards,
Vishal Kashyap
Director / Lead Developer,
Sai Hertz And Control Systems Pvt Ltd,
http://saihertz.rediffblogs.com
Jabber IM: vishalkashyap@jabber.org
ICQ : 264360076
Yahoo IM: mailforvishal@yahoo.com
-----------------------------------------------
You yourself, as much as anybody in the entire
universe, deserve your love and affection.
- Buddha
---------------
pgsql=# select marital_status from vishals_life;

marital_status
------------------
Single not looking

1 Row(s) affected

___
//\\\
( 0_0 )
----------------o0o-----o0o---------------------

Folks,

I thought that I would give everyone a summary of the current discussion of
collaboration tools and bug-trackers for our project as I read them. I
think that we are quite close to a consensus. Please comment if I've missed
something.

GBorg-->GForge migration: so far, nobody has objected to this idea, except
for justifiable caution about the resources required. If the conversion
can be accomplished relatively seamlessly, and/or through outside help, I
don't think we have any reason NOT to proceed with a *gradual* migration.

BugTrackers: here, opinion is more divided. Many people seem to feel that
they would like bug trackers more sophisticated than those offered by the
built-in GForge tool. The criteria that seem to have general consensus
are:
A. The bug tracker should have some kind of e-mail interface which allows
responding to bugs a well as tracking them, so that people who don't like web
interfaces don't need to use them.
B. The bug tracker must be OSS; proprietary software is too risky when there
are alternatives.
C. The bug tracker must use PostgreSQL, and it would be preferable if
PostgreSQL support was available in the default branch of the project.

And I will add one that I see as unavoidable, even though it's been sort of
glossed over in the discussions:
D. The bug tracker should not require extensive customization or other work by
our team, becuase we simply don't have the people.

Based on this, I will evaluate the various bug trackers which have been
mentioned to date:

GForge's Tracker: This choice has the tremendous benefit of already being
built-in to GForge and thus integrated with the rest of the project
infrastructure. On the rest of the criteria:
A. GF-Tr does not support e-mail interaction at all.
B. pass
C. pass
D. pass
Otherwise, GF-Tr's other detraction is that it is relatively unsophisticated,
not supporting, for example, tying bugs to version numbers. This simplicity
can also be an asset as far as start-up time is concerned, though, but there
exists the danger that newbies would use the tracker while developers
continute to use e-mail. making the system ineffective.

BugZilla: This has been a popular suggestion because lots of people are
familiar with it. However, BZ fails our criteria on three counts:
A. BZ does not support issue alterations by e-mail; in fact, you can't even
log in by e-mail link.
B. Pass
C. BZ does not have any PG support in its default branch, and the RH port is
currently unmaintained. While a member of the BZ team is attempting to
complete a port, there is no expected completion date.
D. Given C., we could reasonably expect that using BZ would require
significant support from the PG community in order to maintain a PG port.
Given that one of the goals of the migration is to *reduce* the resources
required by our community to maintain our infrastructure, this seems unwise.
There is also the factor that several people on this list hate BZ's
interface with a passion not expressed for other possible tools. I am one of
them, I'm afraid, and since I am the primary volunteer for admining the
system, I think my opinion carries some weight. I find the BZ interface
baffling, cumbersome, inefficient, and difficult to learn.

Jira: While I have not actually tested it, this is known as a very
sophisticated, professional enterprise-grade bug tracker. The commercial
developers are PostgreSQL supporters and have offered us this option as their
support for our project, for which we are greatful.
A. Pass
B. Jira is unfortunately not OSS, meaning that we would be 100% dependant on
the management policy of Alessian corp. for our use of it. I am not
comfortable with this idea, nor is Core, nor several other people.
C. Pass
D. Pass
There is the further issue that based on technical requirements Jira might
have to the eternally hosted to postgresql.org, making it difficult to
integrate it into the rest of our operations.

Request Tracker: perl.org's issue tracker has grown quite sophisticated and
added PostgreSQL support.
A. Pass -- RT supports commenting on, and modifying, bugs by e-mail, as well
as running e-mail "scripts" on creation or alteration of bugs.
B. Pass
C. Pass -- PostgreSQL and MySQL are fully supported in version 3.
D. One possible reservation may be integrating RT with GForge. Andrew D. and
some of the GForge people will be checking on how troublesome this will be,
and whether or not this might become a standard GForge option in the future.
Overall, I personally am liking the new RT and seeing it as our best
option for a bug-tracker which would genuinely improve the operations of our
community. One thing I'm really attracted to is the ability to create
"personal list" so that I can put my personal core-member todo list online.

Roundup: This was suggested by a couple of people, including Elein who is
quite fond of it. Per my perusing, however, there are several issues:
A. Pass: roundup allows full interaction by e-mail.
B. Pass
C. Roundup was designed not to rely on a relational database. See: http://
roundup.sourceforge.net/doc-0.6/overview.html#roundup-s-hyperdatabase
Like a lot of Zope tools, Roundup uses python objects for storage of data
except between sessions. Further, where Roundup does suggest databases for
scalability, their recommendations do not include PostgreSQL. While this is
a perfectly valid design methodology according to certain criteria, I think
that the PostgreSQL project would be very much sending the wrong message to
use an effectively non-Postgres tool.
D. If there is a version of Roundup which supports PostgreSQL, it is not the
default branch ... once again putting us in the same situation we would be in
with BZ or are in with GBorg.

Other Tools: The other bug tracking tools, OSS and otherwise, do not seem to
be anywhere near as mature as the above options, making them not an
enhancement to current issue processing.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

On Sun, 29 Feb 2004, Josh Berkus wrote:

A. GF-Tr does not support e-mail interaction at all.

Just curious, but:

1. how much work would be involved in adding that?
2. would the gforge developers be willing to integrate it in?

The reason I ask is that we have several PHP developers around, some of
which might be willing to work on integrating such into the bug tracker
... ?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Josh Berkus wrote:

D. One possible reservation may be integrating RT with GForge.

I'm confused. Are we considering moving core backend development over
to GForge as well, or just GBorg? (Personally the former doesn't
strike me as a good idea, at least initially.)

I think that the PostgreSQL project would be very much sending the
wrong message to use an effectively non-Postgres tool.

Frankly, I think the PostgreSQL project would be sending "the wrong
message" if we chose our tools on any basis other than functionality.
We ought to use what works, whether it supports PG or not. Whether the
bug tracker tool uses PostgreSQL, flat files or MS Access to store
data is entirely secondary to whether it serves the needs of the
development group.

-Neil

Neil,

Frankly, I think the PostgreSQL project would be sending "the wrong
message" if we chose our tools on any basis other than functionality.
We ought to use what works, whether it supports PG or not. Whether the
bug tracker tool uses PostgreSQL, flat files or MS Access to store
data is entirely secondary to whether it serves the needs of the
development group.

OK, then, more substantial: I personally lack confidence in any tool that
uses an in-memory object database to store persistent data. I also feel
pessimistic about our ability to extend and integrate a tool which uses
radically different storage mechanism than the other tools we're using.
Finally, for any of these things I forsee asking the communites involved with
those projects for help, and it seems foolish to beg for help (as would
probably be required of a project that does nor support PG) when there are
people offering to help us.

THIS JUST IN: as if we didn't have enough options, Talli of the OpenACS
community has offered their help with using OpenACS modules for any of the
web tasks we've discussed. More later.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

Neil Conway wrote:

Josh Berkus wrote:

D. One possible reservation may be integrating RT with GForge.

I'm confused. Are we considering moving core backend development over
to GForge as well, or just GBorg? (Personally the former doesn't
strike me as a good idea, at least initially.)

You are correct that this has (quite annoyingly) been overlooked in much
of the discussion. Indeed, the needs of a GBorg project might well
differ both from the core project and from other GBorg projects. ISTM
the sensible thing right now would be to work on migrating GBorg and
leave the core project exactly as it is. OTOH, there was considerable
discussion a few months ago about bug tracking for the core project, and
we have unfortunately largely repeated that discussion with similar
results (for cheese in my_favourite_bugtrackers print "I like
$cheese\n"; ). I think that a careful choice made for GBorg might allow
us to progress the matter for the core project at a later stage, and the
choice should be made with that possible suitability in mind.

I think that the PostgreSQL project would be very much sending the
wrong message to use an effectively non-Postgres tool.

Frankly, I think the PostgreSQL project would be sending "the wrong
message" if we chose our tools on any basis other than functionality.
We ought to use what works, whether it supports PG or not. Whether the
bug tracker tool uses PostgreSQL, flat files or MS Access to store
data is entirely secondary to whether it serves the needs of the
development group.

The big issue is not going to be the bug tracker iteself, but how easy
it is to glue it to GForge (and if it requires too much customised glue
we really won't be making an advance at all). On those grounds alone a
FOSS bug tracker surely is preferable, regardless of political
considerations. Apart from the fact that its DB Schema lacks all
referential integrity constraints - a legacy of its origin in
you-know-what - RT doesn't look half bad.

If we wanted to step outside the FOSS world, I don't think bug tracking
would be the area where there might be most need, but maybe that's just
me ;-)

cheers

andrew

On Sun, 29 Feb 2004, Neil Conway wrote:

Josh Berkus wrote:

D. One possible reservation may be integrating RT with GForge.

I'm confused. Are we considering moving core backend development over
to GForge as well, or just GBorg? (Personally the former doesn't
strike me as a good idea, at least initially.)

There are no plans, at this time, to move the core development stuff from
its current "format" ... this is all for gborg hosted projects at this
time ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Folks,

Re: moving the main project to GForge/whatever: we're not considering that at
this time.

The way the discussion got entangled is that a few people mentioned wanting a
better bug tracker than then one offered with GForge, and that we are
considering using a Bug Tracker for the main project.

If we do want an upgraded BT for the main project, it would make sense to use
the same BT for GForge/GBorg projects.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BugTrackers: here, opinion is more divided. Many people seem to feel that
they would like bug trackers more sophisticated than those offered by the
built-in GForge tool.

Another option, of course, is to try an enhance the current GForge tool.
Seems if we are willing to expend the effort to install, configure,
and (not to be overlooked) migrating something *from* GForge, one of
our options should be to direct that energy to enhancing what we already
have.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200402292041

-----BEGIN PGP SIGNATURE-----

iD8DBQFAQpT5vJuQZxSWSsgRAiUbAJwMq84yfBEfRBZVnv2LwOKlshrZXQCgpVvN
lODj99J9XNjl4vh3PeulZIc=
=MDVY
-----END PGP SIGNATURE-----

Josh Berkus <josh@agliodbs.com> writes:

C. BZ does not have any PG support in its default branch, and the RH port is
currently unmaintained.

I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ
maintainer) would be too. As would be the thousands of people who
regularly use bugzilla.redhat.com.

If you want to reject BZ because you don't like it, fine, but please
don't allege that it's unmaintained or that we'd have to put our own
resources into maintaining it. There *will* be BZ-on-PG running at Red
Hat for the foreseeable future. Obviously Dave would like to get the
port folded back upstream, and it looks like that will happen
eventually, but we need not fear being alone in running BZ-on-PG
meanwhile.

regards, tom lane

Josh Berkus wrote:

Request Tracker: perl.org's issue tracker has grown quite sophisticated and
added PostgreSQL support.

...

D. One possible reservation may be integrating RT with GForge. Andrew D. and
some of the GForge people will be checking on how troublesome this will be,
and whether or not this might become a standard GForge option in the future.

I have a lot of experience with configuring and customising RT and would
be willing to help with this.
As a long time lurker on pgsql-hackers I vote for this option because
it's something I can
actually help with... :-)

--
Kris Shannon <kris@sisgroup.com.au>

http://gforge.org/ is not a hosting site, that is why you only found 4

Well that's what you get when you write messages at 2:30 AM. Should know
better.

But on this topic, does a site based on GForge similar to Sourceforge exist ?

--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 �ben 12.00-18.00 Email: kar@kakidata.dk
2000 Frederiksberg L�rdag 12.00-16.00 Web: www.suse.dk

Tom Lane said:

Josh Berkus <josh@agliodbs.com> writes:

C. BZ does not have any PG support in its default branch, and the RH
port is currently unmaintained.

I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ
maintainer) would be too. As would be the thousands of people who
regularly use bugzilla.redhat.com.

If you want to reject BZ because you don't like it, fine, but please
don't allege that it's unmaintained or that we'd have to put our own
resources into maintaining it. There *will* be BZ-on-PG running at Red
Hat for the foreseeable future. Obviously Dave would like to get the
port folded back upstream, and it looks like that will happen
eventually, but we need not fear being alone in running BZ-on-PG
meanwhile.

*nod*

The RH port is a few minor versions behind the mainline BZ project. I
suspect that reasonable Pg support is not too far away in the mainline
code. Dave Lawrence is in fact working actively on that, as I saw from a
flurry of email just the other day.

There seems to me to be sufficient resistance to BZ on other grounds to
make the matter moot. Personally, I have long learned to live with its
quirkiness and the klunky interface, and I don't find the lack of an email
interface an issue, but it is clear that others have much graver
objections on these and other grounds.

cheers

andrew

On Fri, Feb 27, 2004 at 10:48:57AM -0800, Josh Berkus wrote:

RT: I've been using RT for OSCON, and am not wowed by it. Of course, I
can say the same of BZ and GForge-Tracker. From my perspective, it's
neither better nor worse than the other solutions, although the interaction
with e-mail is nice.
More importantly, *we* would have to do the port to PostgreSQL. This is

That's not true. RT 3.2 supports PostgreSQL out of the box, and at
least one of Best Practical's customers (Afilias) requires that MySQL
not be the platform (because I'm just too worried about the current
license). That isn't to say it's the only choice, but it does indeed
support Postgres. Jesse Vincent has told me, also, that PostgreSQL
support is important to him.

RT is pretty flexible for managing issues, bugs, problems, &c. I'm
not real sure it's right for this job, but it might be. CPAN appears
to use it, for instance.

A
--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

Tom,

I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ
maintainer) would be too. As would be the thousands of people who
regularly use bugzilla.redhat.com.

My sincerest apologies to you and Dave Lawrence. I misunderstood what I was
being told on this list.

A revised summary will be fortcoming tommorrow.

--
-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh@agliodbs.com
and data management solutions (415) 565-7293
for law firms, small businesses fax 651-9224
and non-profit organizations. San Francisco

On Mon, 2004-03-01 at 08:24, Kaare Rasmussen wrote:

http://gforge.org/ is not a hosting site, that is why you only found

4

Well that's what you get when you write messages at 2:30 AM. Should
know
better.

But on this topic, does a site based on GForge similar to Sourceforge
exist ?

http://alioth.debian.org

(It is due to be taken down for a few hours this week while it is moved
to a new machine.)

Oliver Elphick

On Fri, 27 Feb 2004, Josh Berkus wrote:

Paul,

Your main concern about RT isn't true, at least here at my office. I
installed RT, with no prior experience with any OSS tracker, back in
October, and it worked on PostgreSQL the first time. (PostgreSQL support was
one of the main reasons I chose it to track issues on my
PostgreSQL/Perl-based webapp.) I made this point in an earlier post in this
thread. There is no conversion effort needed with RT 3.0.6, it just works on
PostgreSQL.

My apologies, then! I was operating off of the statements of others, and the
fact that the only RT impelementations I've used were running on MySQL. So,
questions:

1) can you compare/contrast RT vs. BZ vs. Simplified bug-tracking, like
GForge?

I can't help here, but...

2) What help, if any, would we be able to get in supporting RT from the RT
community?

RT community is VERY good, the rt-users list is REAL good, and Jesse
Vincent (the primary author) is VERY good about keeping PG support
up to date, and making the improvements necessary.

I run a RT on PG here as well.

LER

--
-Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749