Re: [HACKERS] Collaboration Tool Proposal -- Summary to date

Folks,

Discuss/vote/object/scream&shout:

PROPOSAL: GBorg --> GForge Migration

Why do we want a full-service collaboration tool?

PostgreSQL is no longer a monolithic project,
but rather a collection of closely related projects. Some of
these projects are official, some are unofficial, some are
abandoned, some reside in Gborg and some in /contib and the
logic to the separation is not readily apparent.
Some of these "child projects" are substantial, having
several developers and their own communities; others are
maintained by the same core members and major contributors
who do most other things. Worst of all, some key projects,
like phpPgAdmin, are not hosted with us at all, making them
very hard to identify by new users. A high-quality,
full-service community & development tool will help these
"child projects" be more visible and yet more modular and
independant at the same time.

Further, currently bug tracking and TODOs are maintained by
e-mail and Bruce's personal web pages. This is fine for us, but
rather impenetrable to the newcomer or IT support person,
and can dissuade new members from joining our community. Also,
the lack of a more sophisticated issue tracking tool is handicapping
when it comes time to beta-testing releases; at least one bug
made it from beta into 7.4.0 simply because there was no
follow-up on a patch. While an online bugtracker won't replace
having a "beta test master", it will make that person's job
easier.

Finally, most other major OSS projects are using collaboration
tools for their infrastructure, and find them indispensable.
Particularly well-known tools make it easier for new developers
to get acquainted with the project and get started coding faster.
With the incipient possibility of new, corporate-sponsored
contributors to our project, having a ready and easy to understand
structure for them to join is vital. The
structure of tools like SourceForge and Savannah are familiar
to most people in the OSS programming space.

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.

There are several other collab tools created supported by
their own communities, which are being actively maintained
and developed by them -- meaning that we can expect to continue
seeing & receiving new features without having to code them
ourselves. It's what open source is about, hey?

Why GForge?

GForge runs on PostgreSQL and their team are enthusiastic PG
users. Most other collab tools run on other databases and would
have to be ported. Further, the GForge community is excited
about us adopting it and is willing to provide assistance &
advice to us. Both Tim Perdue and Chris DiBona have sought
me out to offer their help with migration & setup.

GForge, being the OSS fork of the now-closed SourceForge,
presents a reasonable familiar interface to people familiar
with OSS projects. However, unlike SF, GForge has continued
to develop and improve.

GForge has a number of additional features that we would find
useful. For example, the "Code Snippets" feature fills in the
desire for a "PL-code CPAN" that we discussed last fall,
replacing Roberto Mello's moribund "PL/pgSQL Library". There
is a "TODO" organizer (Tasks). The is a News feed.
There is even web-forum support in the unlikely event we
want it. The "My Page" feature allows developers to
quick-reference the projects they are working on.

But check it out for yourself: www.gforge.org

What does GForge lack?

Currently, GForge does not have any kind of plug-in for
full project home pages; this would still be ad-hoc.
As well, the integration with CVS is kind of hackish
(PHP wrapper for CVSweb). And the bug tracker, while
more sophisticated than we have currently, does not
measure up to BugZilla or Jira.

There is, in fact, a mailing list feature, it's just
not shown on the test site.

However, with a couple hundred using sites and 2 companies
doing professional GForge support, it seems reasonable
to expect those things to come along soon. And it's
significantly possible that we could encourage new
features by lobbying the GForge community.

What are our alternatives?

It is possible that there is a better tool than GForge
out there somewhere. I just haven't been able to find it.

We could stick with GBorg, and try to make some
incremental improvements to it. We would also want
to then adopt an external bug tracker (Bugzilla, Jira, DCL,
something) for the main project, at least. Personally, I see this option as
one that we will have to pay for a year from now, when we *still* haven't
made the improvements we've talked about.

How can we do the migration?

Sloooooooooowllllly. My thought is that, immediately,
only new projects and people who are enthusiastic about
GForge would migrate. Other projects would migrate at
convenient times for them, and as we can get volunteer help
for the process. I see this migration process taking maybe a
year.

At the same time, we would set up a bug tracker on GForge
for the main project in preparation for 7.5. If this works
well, we could discuss moving other portions of
developer.postgresql.org to GForge. This would give the
main project a degree of transparency it has previously
lacked.

And, of course, we would assess at each step whether or not
the migration was a good idea.

I will volunteer to be the GForge administrator, although I will happily give
someone else that honor if anyone steps forward.

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.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

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

>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

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(at)postgresql(dot)org (no cross-posts).

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

Cheers,
Jean-Michel Pouré

Robert Treat <xzilla(at)users(dot)sourceforge(dot)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(at)gmx(dot)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(at)postgresql(dot)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(at)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(at)gmx(dot)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(at)sss(dot)pgh(dot)pa(dot)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(at)samurai(dot)com> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)agliodbs(dot)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

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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

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

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

Andrew Dunstan <andrew(at)dunslane(dot)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(at)varlena(dot)com

On Fri, Feb 27, 2004 at 03:31:14PM -0800, Josh Berkus wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

-----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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200402280736

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

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

> 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(at)kakidata(dot)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(at)jabber(dot)org
ICQ : 264360076
Yahoo IM: mailforvishal(at)yahoo(dot)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(at)hub(dot)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(at)hub(dot)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(at)turnstep(dot)com
PGP Key: 0x14964AC8 200402292041

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

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

Josh Berkus <josh(at)agliodbs(dot)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(at)sisgroup(dot)com(dot)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(at)kakidata(dot)dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk

Tom Lane said:
> Josh Berkus <josh(at)agliodbs(dot)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(at)crankycanuck(dot)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(at)agliodbs(dot)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