public inbox for [email protected]
help / color / mirror / Atom feedCollaboration Tool Proposal
47+ messages / 21 participants
[nested] [flat]
* Collaboration Tool Proposal
@ 2004-02-26 17:12 Josh Berkus <[email protected]>
0 siblings, 4 replies; 47+ messages in thread
From: Josh Berkus @ 2004-02-26 17:12 UTC (permalink / raw)
To: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 17:53 Joseph Tate <[email protected]>
parent: Josh Berkus <[email protected]>
3 siblings, 3 replies; 47+ messages in thread
From: Joseph Tate @ 2004-02-26 17:53 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-www; [email protected]
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.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 18:19 Josh Berkus <[email protected]>
parent: Joseph Tate <[email protected]>
2 siblings, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-26 18:19 UTC (permalink / raw)
To: Joseph Tate <[email protected]>; +Cc: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 18:45 Robert Treat <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Robert Treat @ 2004-02-26 18:45 UTC (permalink / raw)
To: Josh Berkus <[email protected]>; +Cc: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 18:49 Josh Berkus <[email protected]>
parent: Robert Treat <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-26 18:49 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 19:00 Jeroen T. Vermeulen <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Jeroen T. Vermeulen @ 2004-02-26 19:00 UTC (permalink / raw)
To: Josh Berkus <[email protected]>; +Cc: Robert Treat <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 19:07 Josh Berkus <[email protected]>
parent: Jeroen T. Vermeulen <[email protected]>
0 siblings, 0 replies; 47+ messages in thread
From: Josh Berkus @ 2004-02-26 19:07 UTC (permalink / raw)
To: Jeroen T. Vermeulen <[email protected]>; +Cc: Robert Treat <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 20:05 David Costa <[email protected]>
parent: Joseph Tate <[email protected]>
2 siblings, 0 replies; 47+ messages in thread
From: David Costa @ 2004-02-26 20:05 UTC (permalink / raw)
To: Joseph Tate <[email protected]>; +Cc: [email protected]; [email protected]; pgsql-www
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-02-26 20:16 Peter Eisentraut <[email protected]>
parent: Josh Berkus <[email protected]>
3 siblings, 2 replies; 47+ messages in thread
From: Peter Eisentraut @ 2004-02-26 20:16 UTC (permalink / raw)
To: [email protected]; pgsql-www; [email protected]
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.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 20:28 Jeroen T. Vermeulen <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Jeroen T. Vermeulen @ 2004-02-26 20:28 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-02-26 20:28 Josh Berkus <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-26 20:28 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 20:41 Andrew Dunstan <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 2 replies; 47+ messages in thread
From: Andrew Dunstan @ 2004-02-26 20:41 UTC (permalink / raw)
To: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-02-26 21:03 David Costa <[email protected]>
parent: Josh Berkus <[email protected]>
3 siblings, 0 replies; 47+ messages in thread
From: David Costa @ 2004-02-26 21:03 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-www
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 21:04 Robert Treat <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 1 reply; 47+ messages in thread
From: Robert Treat @ 2004-02-26 21:04 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; Josh Berkus <[email protected]>; +Cc: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 22:29 Tom Lane <[email protected]>
parent: Robert Treat <[email protected]>
0 siblings, 2 replies; 47+ messages in thread
From: Tom Lane @ 2004-02-26 22:29 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Josh Berkus <[email protected]>; pgsql-www; [email protected]
Robert Treat <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 22:45 Peter Eisentraut <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 2 replies; 47+ messages in thread
From: Peter Eisentraut @ 2004-02-26 22:45 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Robert Treat <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; Josh Berkus <[email protected]>; pgsql-www; [email protected]
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?
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 22:47 Tom Lane <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 47+ messages in thread
From: Tom Lane @ 2004-02-26 22:47 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; Josh Berkus <[email protected]>; pgsql-www; [email protected]
Peter Eisentraut <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 22:52 Josh Berkus <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-26 22:52 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; +Cc: Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 23:20 Peter Eisentraut <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 2 replies; 47+ messages in thread
From: Peter Eisentraut @ 2004-02-26 23:20 UTC (permalink / raw)
To: [email protected]; Tom Lane <[email protected]>; +Cc: Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
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.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-26 23:57 Andrew Dunstan <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Andrew Dunstan @ 2004-02-26 23:57 UTC (permalink / raw)
To: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 02:08 Neil Conway <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 1 reply; 47+ messages in thread
From: Neil Conway @ 2004-02-27 02:08 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]; Tom Lane <[email protected]>; Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
Peter Eisentraut <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 03:57 Cott Lang <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Cott Lang @ 2004-02-27 03:57 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-www
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. :)
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 04:01 Cott Lang <[email protected]>
parent: Peter Eisentraut <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Cott Lang @ 2004-02-27 04:01 UTC (permalink / raw)
To: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-27 05:17 Greg Stark <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Greg Stark @ 2004-02-27 05:17 UTC (permalink / raw)
To: [email protected]
Tom Lane <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 05:25 Tom Lane <[email protected]>
parent: Neil Conway <[email protected]>
0 siblings, 2 replies; 47+ messages in thread
From: Tom Lane @ 2004-02-27 05:25 UTC (permalink / raw)
To: Neil Conway <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; [email protected]; Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
Neil Conway <[email protected]> writes:
> Peter Eisentraut <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 06:10 Josh Berkus <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-27 06:10 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Neil Conway <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 06:19 Tom Lane <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Tom Lane @ 2004-02-27 06:19 UTC (permalink / raw)
To: [email protected]; +Cc: Neil Conway <[email protected]>; Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
Josh Berkus <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 07:11 Josh Berkus <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 2 replies; 47+ messages in thread
From: Josh Berkus @ 2004-02-27 07:11 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Neil Conway <[email protected]>; Peter Eisentraut <[email protected]>; Robert Treat <[email protected]>; Andrew Dunstan <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 14:29 Andrew Dunstan <[email protected]>
parent: Josh Berkus <[email protected]>
1 sibling, 2 replies; 47+ messages in thread
From: Andrew Dunstan @ 2004-02-27 14:29 UTC (permalink / raw)
To: pgsql-www; [email protected]
Josh Berkus wrote:
>Tom,
>
>
>
>>Possibly workable, but what's your definition of "registered user"?
>>
>>
>
>Signing up via a webform, getting an e-mailed password back, logging in.
>
>
>
>>I'd hope that anyone subscribed to any of the mailing lists would be
>>considered registered, for instance. Not sure if we can do that with
>>either BZ or GForge; anyone know?
>>
>>
>
>Usually it works the other way around; people can't subscribe until they've
>registered via web.
>
>
I believe it should not be hard to do a one-time bulk registration of
everyone on the lists, if that was desired.
Stepping back a bit and gathering a few threads.
BZ versions etc. There is finally some movement in the mainline BZ code
to get DB independence into it - and the first DB to benefit will be
Postgres. Dave Lawrence at RedHat appears to be working again on
landing this (after a long hiatus). See
http://bugzilla.mozilla.org/show_bug.cgi?id=98304 and
http://bugzilla.mozilla.org/show_bug.cgi?id=146679 . The reason I would
prefer to go with mainline BZ (assuming we go with BZ at all) is that my
past experience of upgrading BZ has not been pleasant, and I am sure it
would be even harder doing it from a fork like the RedHat one.
Signal to Noise. It's not at all clear to me why a bug tracking system
should have a worse signal to noise ratio than a mailing list with
similar access rules, especially since we also provide the facility to
log bugs through a web form directly off the postgresql.org home page.
But even if it does, that can be managed by good triage. That should
improve the ratio for all but those doing the triage. Personally, I'd be
surprised if it took one knowledgable person more than 30 minutes a day
to weed out the garbage (sorry for the mixed metaphor), and if the load
was spread across several people it would be just a few minutes a day
for any one of them, at a significant saving to everyone else.
Email interface: it should not be beyond the wit of man to provide some
level of email interface to any reasonable bug tracking system. Whether
or not it is worth doing depends on the demand. Two obvious places for
it would be 1) to allow initial logging of a bug via email, and 2)
periodically run query 'foo' and email me the results. Getting a once a
day digest of new bug reports might be quite nice in fact.
One size fits all: I understood that this discussion arose in the
context of a suggestion to migrate GBorg to a GForge base (a proposal I
generally support). What is right for the core project might well not be
right for GBorg projects. Perhaps a conservative approach might be to
try things out on GBorg/GForge and see how things go, without touching
how the core operates for now.
cheers
andrew
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-27 14:51 Shridhar Daithankar <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Shridhar Daithankar @ 2004-02-27 14:51 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-27 14:57 Greg Stark <[email protected]>
parent: Tom Lane <[email protected]>
1 sibling, 1 reply; 47+ messages in thread
From: Greg Stark @ 2004-02-27 14:57 UTC (permalink / raw)
To: [email protected]
Tom Lane <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-02-27 18:19 [email protected]
parent: Joseph Tate <[email protected]>
2 siblings, 0 replies; 47+ messages in thread
From: [email protected] @ 2004-02-27 18:19 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 18:48 Josh Berkus <[email protected]>
parent: Josh Berkus <[email protected]>
1 sibling, 3 replies; 47+ messages in thread
From: Josh Berkus @ 2004-02-27 18:48 UTC (permalink / raw)
To: pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 19:05 Josh Berkus <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-27 19:05 UTC (permalink / raw)
To: Bort, Paul <[email protected]>; pgsql-www; [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-27 19:12 Andrew Dunstan <[email protected]>
parent: Greg Stark <[email protected]>
0 siblings, 0 replies; 47+ messages in thread
From: Andrew Dunstan @ 2004-02-27 19:12 UTC (permalink / raw)
To: PostgreSQL-development <[email protected]>
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-27 19:49 Bort, Paul <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Bort, Paul @ 2004-02-27 19:49 UTC (permalink / raw)
To: pgsql-www; [email protected]
>
> 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.
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-27 23:31 Josh Berkus <[email protected]>
parent: Josh Berkus <[email protected]>
2 siblings, 1 reply; 47+ messages in thread
From: Josh Berkus @ 2004-02-27 23:31 UTC (permalink / raw)
To: Mikhail Terekhov <[email protected]>; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-28 00:47 Andrew Dunstan <[email protected]>
parent: Bort, Paul <[email protected]>
0 siblings, 0 replies; 47+ messages in thread
From: Andrew Dunstan @ 2004-02-28 00:47 UTC (permalink / raw)
To: pgsql-www; PostgreSQL-development <[email protected]>
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-28 04:04 Greg Stark <[email protected]>
parent: Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 47+ messages in thread
From: Greg Stark @ 2004-02-28 04:04 UTC (permalink / raw)
To: [email protected]
Andrew Dunstan <[email protected]> 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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [pgsql-www] Collaboration Tool Proposal
@ 2004-02-28 04:14 elein <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 0 replies; 47+ messages in thread
From: elein @ 2004-02-28 04:14 UTC (permalink / raw)
To: Josh Berkus <[email protected]>; +Cc: Mikhail Terekhov <[email protected]>; [email protected]
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
[email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-02-28 17:05 Greg Sabino Mullane <[email protected]>
parent: Josh Berkus <[email protected]>
2 siblings, 0 replies; 47+ messages in thread
From: Greg Sabino Mullane @ 2004-02-28 17:05 UTC (permalink / raw)
To: pgsql-www
-----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 [email protected]
PGP Key: 0x14964AC8 200402280736
-----BEGIN PGP SIGNATURE-----
iD8DBQFAQIuHvJuQZxSWSsgRAnHqAKDIHNlaRZhjxnkJlHGeWVm3Fn6R/wCgmgo5
MA2Qz6ChHdbKuBvESWKoNv8=
=KAO/
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-02-29 01:35 Kaare Rasmussen <[email protected]>
parent: Josh Berkus <[email protected]>
3 siblings, 1 reply; 47+ messages in thread
From: Kaare Rasmussen @ 2004-02-29 01:35 UTC (permalink / raw)
To: [email protected]
> 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: [email protected]
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-02-29 03:03 Tim Larson <[email protected]>
parent: Kaare Rasmussen <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Tim Larson @ 2004-02-29 03:03 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-03-01 08:24 Kaare Rasmussen <[email protected]>
parent: Tim Larson <[email protected]>
0 siblings, 1 reply; 47+ messages in thread
From: Kaare Rasmussen @ 2004-03-01 08:24 UTC (permalink / raw)
To: [email protected]
> 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: [email protected]
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-03-01 15:09 Andrew Sullivan <[email protected]>
parent: Josh Berkus <[email protected]>
2 siblings, 0 replies; 47+ messages in thread
From: Andrew Sullivan @ 2004-03-01 15:09 UTC (permalink / raw)
To: pgsql-www; [email protected]
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 | [email protected]
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: Collaboration Tool Proposal
@ 2004-03-01 19:12 Oliver Elphick <[email protected]>
parent: Kaare Rasmussen <[email protected]>
0 siblings, 0 replies; 47+ messages in thread
From: Oliver Elphick @ 2004-03-01 19:12 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
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
^ permalink raw reply [nested|flat] 47+ messages in thread
* Re: [HACKERS] Collaboration Tool Proposal
@ 2004-06-09 00:27 Larry Rosenman <[email protected]>
parent: Josh Berkus <[email protected]>
0 siblings, 0 replies; 47+ messages in thread
From: Larry Rosenman @ 2004-06-09 00:27 UTC (permalink / raw)
To: Josh Berkus <[email protected]>; +Cc: Bort, Paul <[email protected]>; pgsql-www; [email protected]
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: [email protected]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
^ permalink raw reply [nested|flat] 47+ messages in thread
end of thread, other threads:[~2004-06-09 00:27 UTC | newest]
Thread overview: 47+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-02-26 17:12 Collaboration Tool Proposal Josh Berkus <[email protected]>
2004-02-26 17:53 ` Joseph Tate <[email protected]>
2004-02-26 18:19 ` Josh Berkus <[email protected]>
2004-02-26 18:45 ` Robert Treat <[email protected]>
2004-02-26 18:49 ` Josh Berkus <[email protected]>
2004-02-26 19:00 ` Jeroen T. Vermeulen <[email protected]>
2004-02-26 19:07 ` Josh Berkus <[email protected]>
2004-02-26 20:05 ` David Costa <[email protected]>
2004-02-27 18:19 ` [email protected]
2004-02-26 20:16 ` Peter Eisentraut <[email protected]>
2004-02-26 20:28 ` Jeroen T. Vermeulen <[email protected]>
2004-02-26 20:28 ` Josh Berkus <[email protected]>
2004-02-26 20:41 ` Andrew Dunstan <[email protected]>
2004-02-26 21:04 ` Robert Treat <[email protected]>
2004-02-26 22:29 ` Tom Lane <[email protected]>
2004-02-26 22:45 ` Peter Eisentraut <[email protected]>
2004-02-26 22:47 ` Tom Lane <[email protected]>
2004-02-26 22:52 ` Josh Berkus <[email protected]>
2004-02-26 23:20 ` Peter Eisentraut <[email protected]>
2004-02-26 23:57 ` Andrew Dunstan <[email protected]>
2004-02-27 02:08 ` Neil Conway <[email protected]>
2004-02-27 05:25 ` Tom Lane <[email protected]>
2004-02-27 06:10 ` Josh Berkus <[email protected]>
2004-02-27 06:19 ` Tom Lane <[email protected]>
2004-02-27 07:11 ` Josh Berkus <[email protected]>
2004-02-27 14:29 ` Andrew Dunstan <[email protected]>
2004-02-27 14:51 ` Shridhar Daithankar <[email protected]>
2004-02-28 04:04 ` Greg Stark <[email protected]>
2004-02-27 18:48 ` Josh Berkus <[email protected]>
2004-02-27 23:31 ` Josh Berkus <[email protected]>
2004-02-28 04:14 ` elein <[email protected]>
2004-02-28 17:05 ` Greg Sabino Mullane <[email protected]>
2004-03-01 15:09 ` Andrew Sullivan <[email protected]>
2004-02-27 14:57 ` Greg Stark <[email protected]>
2004-02-27 19:12 ` Andrew Dunstan <[email protected]>
2004-02-27 04:01 ` Cott Lang <[email protected]>
2004-02-27 05:17 ` Greg Stark <[email protected]>
2004-02-27 03:57 ` Cott Lang <[email protected]>
2004-02-26 21:03 ` David Costa <[email protected]>
2004-02-29 01:35 ` Kaare Rasmussen <[email protected]>
2004-02-29 03:03 ` Tim Larson <[email protected]>
2004-03-01 08:24 ` Kaare Rasmussen <[email protected]>
2004-03-01 19:12 ` Oliver Elphick <[email protected]>
2004-02-27 19:05 Re: [HACKERS] Collaboration Tool Proposal Josh Berkus <[email protected]>
2004-06-09 00:27 ` Larry Rosenman <[email protected]>
2004-02-27 19:49 Re: [HACKERS] Collaboration Tool Proposal Bort, Paul <[email protected]>
2004-02-28 00:47 ` Andrew Dunstan <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox