Thread: Collaboration Tool Proposal
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
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
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
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.
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
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.
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
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
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
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
> In terms of improving the hosting infrastructure, this would surely be a > step forward, but the problem with "collaboration" is not that the > tools are missing, it's that people are unwilling to use any tools for > issue tracking, etc. I quite agree with Peter. Most sub-projects have one or two lead developers, who organize themselves. In the case of PostgreSQL, the problem is not developer intelligence, PostgreSQL project already host the best brains. On a different level: I feel that new-comers to PostgreSQL have a hard time finding the right tools, installing and starting PostgreSQL, connecting locally, etc... We probably never hear from these users, as they never reach the first connection. In a way, PostgreSQL is targetted at an "elite of hackers". At pgAdmin, I started a (very) experimental project of mass-download: http://www.pgadmin.org/pgadmin3/advocacy.php#list There are no precise statistics, we do not know yet the impact of releasing pgAdmin III on so many sites. And PostgreSQL Win32 port is not there. In a few weeks ... with the arrival of PostgreSQL win32 version, there could be a rush to PostgreSQL, like never before. A bundle including PHP, PostgreSQL, PhpPgAdmin and pgAdmin III could reach (at least) 100.000 download every month on: - PostgreSQL mirrors, - PHP mirrors, - Shareware and freeware sites, - Community sites. A real flow of people... How are we going to receive them? My preffered answer would be to use the same techniques that proved to be successful. No need to find complicated solutions: PHP.NET web site proved successful, let us fork PHP.NET web site But, do we really want to become the Apache of the database world? (don't flame me if you think I am becoming mad... I don't think I am.) If you would like to answer, maybe try posting to pgsql-advocacy@postgresql.org (no cross-posts). Otherwise, let us sleep well and make dreams of a better world. Cheers, Jean-Michel Pouré
Robert Treat <xzilla@users.sourceforge.net> writes:
> On Thu, 2004-02-26 at 15:41, Andrew Dunstan wrote:
>> Perhaps when BZ supports PG - some progress is being made on that front,
>> but it's not a done deal yet.
> I can't imagine the BZ plugin for Gforge would require you to use a
> second database system would it? Besides which we can always use red
> hats bugzilla port if need be.
Yeah, I looked into that when core started discussing this whole thing
awhile back. The Red Hat port of BZ to Postgres is perfectly usable.
Dave Lawrence (maintainer of said port) told me he hopes to see those
changes folded back upstream in another major release or so, at which
point RH will stop needing to maintain a fork. But in the meantime
we can use their version. It'd sure beat using You Know Who to keep
track of our own bugs ;-)
I would favor using Bugzilla over anything else just because I'm used
to it (have to use it internally at Red Hat anyway).
regards, tom lane
Tom Lane wrote: > Yeah, I looked into that when core started discussing this whole > thing awhile back. The Red Hat port of BZ to Postgres is perfectly > usable. Is it available anywhere?
Peter Eisentraut <peter_e@gmx.net> writes: > Tom Lane wrote: >> Yeah, I looked into that when core started discussing this whole >> thing awhile back. The Red Hat port of BZ to Postgres is perfectly >> usable. > Is it available anywhere? Sure, download it off their front bugzilla page: http://bugzilla.redhat.com/bugzilla/ The link is presently about two paras down in the "News" section. regards, tom lane
People, The question is, do we need BZ right off or should we try GForge's lightweight tool first? Personally I find that BZ is a little intimidating to new users, particularly for searching on issues; as a result it tends to lead to a lot of duplicate filings. -- -Josh Berkus Aglio Database Solutions San Francisco
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.
Neil Conway <neilc@samurai.com> writes:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> I think we had previously decided that we will not allow a random user
>> off the street to file bug reports into whatever system we end up
>> using.
> Uh, why not? (And more to the point, why raise the barrier to entry on
> reporting bugs?)
Our first try at a bug tracking system, several years ago, was open to
anybody to create entries, and we found that the signal-to-noise ratio
went to zero in no time. Too many not-a-bugs, too many support
requests, too few actual bugs. We went back to using the pgsql-bugs
mailing list.
It could be that in the intervening time, people have gotten used to bug
trackers because of their availability on other projects. If so, we
might find a better grade of reports coming in. I'm not very optimistic
about that though.
As for raising the barrier, you can presently submit bug reports to
pgsql-bugs by either mail or webform. Most of the bug trackers I'm
aware of are webform-only. I don't consider that a step forward,
especially since a webform isn't very conducive to making good reports
(it's hard to attach test cases, for instance).
regards, tom lane
Tom, > Our first try at a bug tracking system, several years ago, was open to > anybody to create entries, and we found that the signal-to-noise ratio > went to zero in no time. Too many not-a-bugs, too many support > requests, too few actual bugs. We went back to using the pgsql-bugs > mailing list. I actually sort of agree with Tom, although I don't want to raise the barrier too high. I'd suggest allowing all registered users to submit bugs. Needing to go through registration should severely reduce the "noise", even if we give no restriction on who can register. I field the Advocacy webform right now, and only get about 10 e-mails a day, even though some of those are really support requests better handled by the mailing lists. I think we could handle 5 bad bug reports a day. > As for raising the barrier, you can presently submit bug reports to > pgsql-bugs by either mail or webform. Most of the bug trackers I'm > aware of are webform-only. I don't consider that a step forward, > especially since a webform isn't very conducive to making good reports > (it's hard to attach test cases, for instance). Both the BZ and GForge webforms allow uploading files. And I'd far rather have a single copy of a test case on our web site than a couple dozen being e-mailed out. -- -Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> I actually sort of agree with Tom, although I don't want to raise the barrier
> too high. I'd suggest allowing all registered users to submit bugs.
Possibly workable, but what's your definition of "registered user"?
I'd hope that anyone subscribed to any of the mailing lists would be
considered registered, for instance. Not sure if we can do that with
either BZ or GForge; anyone know?
regards, tom lane
Tom, > Possibly workable, but what's your definition of "registered user"? Signing up via a webform, getting an e-mailed password back, logging in. > I'd hope that anyone subscribed to any of the mailing lists would be > considered registered, for instance. Not sure if we can do that with > either BZ or GForge; anyone know? Usually it works the other way around; people can't subscribe until they've registered via web. -- -Josh Berkus Aglio Database Solutions San Francisco
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
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. :)
Peter Eisentraut <peter_e@gmx.net> writes: > I think we had previously decided that we will not allow a random user > off the street to file bug reports into whatever system we end up > using. Uh, why not? (And more to the point, why raise the barrier to entry on reporting bugs?) Individuals can already post to pgsql-bugs "off the street", and it is not much of a problem. Invalid bug reports can easily be marked as such. -Neil
On Thu, 2004-02-26 at 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
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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 2) For whatever reason, most of our volunteer web crew seem > to be PHP developers. We haven't attracted many Perl or Java > programmers to helping with the site. This may be a chicken-and-egg > thing, but unless there are several untapped Perl Hackers/Java > programmers waiting to jump in and do integration work for RT, > Jira, or whatever, any non-PHP solution automatically carries > a detraction. Definitely a chicken-and-egg thing. I am a Perl person, otherwise I would have done more than I have on the site. I cannot speak for Java, but I don't think Perl would be a problem, as I can think of a few people besides myself with Perl skills who would be willing to help out. FWIW, I think bugzilla is our best option - it's open source, mature, and familiar to a lot of people. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200402280736 -----BEGIN PGP SIGNATURE----- iD8DBQFAQIuHvJuQZxSWSsgRAnHqAKDIHNlaRZhjxnkJlHGeWVm3Fn6R/wCgmgo5 MA2Qz6ChHdbKuBvESWKoNv8= =KAO/ -----END PGP SIGNATURE-----
Folks,
I thought that I would give everyone a summary of the current discussion of
collaboration tools and bug-trackers for our project as I read them. I
think that we are quite close to a consensus. Please comment if I've missed
something.
GBorg-->GForge migration: so far, nobody has objected to this idea, except
for justifiable caution about the resources required. If the conversion
can be accomplished relatively seamlessly, and/or through outside help, I
don't think we have any reason NOT to proceed with a *gradual* migration.
BugTrackers: here, opinion is more divided. Many people seem to feel that
they would like bug trackers more sophisticated than those offered by the
built-in GForge tool. The criteria that seem to have general consensus
are:
A. The bug tracker should have some kind of e-mail interface which allows
responding to bugs a well as tracking them, so that people who don't like web
interfaces don't need to use them.
B. The bug tracker must be OSS; proprietary software is too risky when there
are alternatives.
C. The bug tracker must use PostgreSQL, and it would be preferable if
PostgreSQL support was available in the default branch of the project.
And I will add one that I see as unavoidable, even though it's been sort of
glossed over in the discussions:
D. The bug tracker should not require extensive customization or other work by
our team, becuase we simply don't have the people.
Based on this, I will evaluate the various bug trackers which have been
mentioned to date:
GForge's Tracker: This choice has the tremendous benefit of already being
built-in to GForge and thus integrated with the rest of the project
infrastructure. On the rest of the criteria:
A. GF-Tr does not support e-mail interaction at all.
B. pass
C. pass
D. pass
Otherwise, GF-Tr's other detraction is that it is relatively unsophisticated,
not supporting, for example, tying bugs to version numbers. This simplicity
can also be an asset as far as start-up time is concerned, though, but there
exists the danger that newbies would use the tracker while developers
continute to use e-mail. making the system ineffective.
BugZilla: This has been a popular suggestion because lots of people are
familiar with it. However, BZ fails our criteria on three counts:
A. BZ does not support issue alterations by e-mail; in fact, you can't even
log in by e-mail link.
B. Pass
C. BZ does not have any PG support in its default branch, and the RH port is
currently unmaintained. While a member of the BZ team is attempting to
complete a port, there is no expected completion date.
D. Given C., we could reasonably expect that using BZ would require
significant support from the PG community in order to maintain a PG port.
Given that one of the goals of the migration is to *reduce* the resources
required by our community to maintain our infrastructure, this seems unwise.
There is also the factor that several people on this list hate BZ's
interface with a passion not expressed for other possible tools. I am one of
them, I'm afraid, and since I am the primary volunteer for admining the
system, I think my opinion carries some weight. I find the BZ interface
baffling, cumbersome, inefficient, and difficult to learn.
Jira: While I have not actually tested it, this is known as a very
sophisticated, professional enterprise-grade bug tracker. The commercial
developers are PostgreSQL supporters and have offered us this option as their
support for our project, for which we are greatful.
A. Pass
B. Jira is unfortunately not OSS, meaning that we would be 100% dependant on
the management policy of Alessian corp. for our use of it. I am not
comfortable with this idea, nor is Core, nor several other people.
C. Pass
D. Pass
There is the further issue that based on technical requirements Jira might
have to the eternally hosted to postgresql.org, making it difficult to
integrate it into the rest of our operations.
Request Tracker: perl.org's issue tracker has grown quite sophisticated and
added PostgreSQL support.
A. Pass -- RT supports commenting on, and modifying, bugs by e-mail, as well
as running e-mail "scripts" on creation or alteration of bugs.
B. Pass
C. Pass -- PostgreSQL and MySQL are fully supported in version 3.
D. One possible reservation may be integrating RT with GForge. Andrew D. and
some of the GForge people will be checking on how troublesome this will be,
and whether or not this might become a standard GForge option in the future.
Overall, I personally am liking the new RT and seeing it as our best
option for a bug-tracker which would genuinely improve the operations of our
community. One thing I'm really attracted to is the ability to create
"personal list" so that I can put my personal core-member todo list online.
Roundup: This was suggested by a couple of people, including Elein who is
quite fond of it. Per my perusing, however, there are several issues:
A. Pass: roundup allows full interaction by e-mail.
B. Pass
C. Roundup was designed not to rely on a relational database. See: http://
roundup.sourceforge.net/doc-0.6/overview.html#roundup-s-hyperdatabase
Like a lot of Zope tools, Roundup uses python objects for storage of data
except between sessions. Further, where Roundup does suggest databases for
scalability, their recommendations do not include PostgreSQL. While this is
a perfectly valid design methodology according to certain criteria, I think
that the PostgreSQL project would be very much sending the wrong message to
use an effectively non-Postgres tool.
D. If there is a version of Roundup which supports PostgreSQL, it is not the
default branch ... once again putting us in the same situation we would be in
with BZ or are in with GBorg.
Other Tools: The other bug tracking tools, OSS and otherwise, do not seem to
be anywhere near as mature as the above options, making them not an
enhancement to current issue processing.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
On Sun, 29 Feb 2004, Josh Berkus wrote:
> A. GF-Tr does not support e-mail interaction at all.
Just curious, but:
1. how much work would be involved in adding that?
2. would the gforge developers be willing to integrate it in?
The reason I ask is that we have several PHP developers around, some of
which might be willing to work on integrating such into the bug tracker
... ?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
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
On Sun, 29 Feb 2004, Neil Conway wrote: > Josh Berkus wrote: > > D. One possible reservation may be integrating RT with GForge. > > I'm confused. Are we considering moving core backend development over > to GForge as well, or just GBorg? (Personally the former doesn't > strike me as a good idea, at least initially.) There are no plans, at this time, to move the core development stuff from its current "format" ... this is all for gborg hosted projects at this time ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Folks, Re: moving the main project to GForge/whatever: we're not considering that at this time. The way the discussion got entangled is that a few people mentioned wanting a better bug tracker than then one offered with GForge, and that we are considering using a Bug Tracker for the main project. If we do want an upgraded BT for the main project, it would make sense to use the same BT for GForge/GBorg projects. -- -Josh Berkus Aglio Database Solutions San Francisco
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > BugTrackers: here, opinion is more divided. Many people seem to feel that > they would like bug trackers more sophisticated than those offered by the > built-in GForge tool. Another option, of course, is to try an enhance the current GForge tool. Seems if we are willing to expend the effort to install, configure, and (not to be overlooked) migrating something *from* GForge, one of our options should be to direct that energy to enhancing what we already have. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200402292041 -----BEGIN PGP SIGNATURE----- iD8DBQFAQpT5vJuQZxSWSsgRAiUbAJwMq84yfBEfRBZVnv2LwOKlshrZXQCgpVvN lODj99J9XNjl4vh3PeulZIc= =MDVY -----END PGP SIGNATURE-----
Josh Berkus <josh@agliodbs.com> writes:
> C. BZ does not have any PG support in its default branch, and the RH port is
> currently unmaintained.
I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ
maintainer) would be too. As would be the thousands of people who
regularly use bugzilla.redhat.com.
If you want to reject BZ because you don't like it, fine, but please
don't allege that it's unmaintained or that we'd have to put our own
resources into maintaining it. There *will* be BZ-on-PG running at Red
Hat for the foreseeable future. Obviously Dave would like to get the
port folded back upstream, and it looks like that will happen
eventually, but we need not fear being alone in running BZ-on-PG
meanwhile.
regards, tom lane
Josh Berkus wrote: > 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 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
Josh Berkus wrote: >Request Tracker: perl.org's issue tracker has grown quite sophisticated and >added PostgreSQL support. > > ... >D. One possible reservation may be integrating RT with GForge. Andrew D. and >some of the GForge people will be checking on how troublesome this will be, >and whether or not this might become a standard GForge option in the future. > > I have a lot of experience with configuring and customising RT and would be willing to help with this. As a long time lurker on pgsql-hackers I vote for this option because it's something I can actually help with... :-) -- Kris Shannon <kris@sisgroup.com.au>
Tom Lane said: > Josh Berkus <josh@agliodbs.com> writes: >> C. BZ does not have any PG support in its default branch, and the RH >> port is currently unmaintained. > > I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ > maintainer) would be too. As would be the thousands of people who > regularly use bugzilla.redhat.com. > > If you want to reject BZ because you don't like it, fine, but please > don't allege that it's unmaintained or that we'd have to put our own > resources into maintaining it. There *will* be BZ-on-PG running at Red > Hat for the foreseeable future. Obviously Dave would like to get the > port folded back upstream, and it looks like that will happen > eventually, but we need not fear being alone in running BZ-on-PG > meanwhile. > *nod* The RH port is a few minor versions behind the mainline BZ project. I suspect that reasonable Pg support is not too far away in the mainline code. Dave Lawrence is in fact working actively on that, as I saw from a flurry of email just the other day. There seems to me to be sufficient resistance to BZ on other grounds to make the matter moot. Personally, I have long learned to live with its quirkiness and the klunky interface, and I don't find the lack of an email interface an issue, but it is clear that others have much graver objections on these and other grounds. cheers andrew
On Fri, Feb 27, 2004 at 10:48:57AM -0800, Josh Berkus wrote:
>
> RT: I've been using RT for OSCON, and am not wowed by it. Of course, I
> can say the same of BZ and GForge-Tracker. From my perspective, it's
> neither better nor worse than the other solutions, although the interaction
> with e-mail is nice.
> More importantly, *we* would have to do the port to PostgreSQL. This is
That's not true. RT 3.2 supports PostgreSQL out of the box, and at
least one of Best Practical's customers (Afilias) requires that MySQL
not be the platform (because I'm just too worried about the current
license). That isn't to say it's the only choice, but it does indeed
support Postgres. Jesse Vincent has told me, also, that PostgreSQL
support is important to him.
RT is pretty flexible for managing issues, bugs, problems, &c. I'm
not real sure it's right for this job, but it might be. CPAN appears
to use it, for instance.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland
Tom,
> I was quite surprised to read this, and I'm sure Dave Lawrence (RH's BZ
> maintainer) would be too. As would be the thousands of people who
> regularly use bugzilla.redhat.com.
My sincerest apologies to you and Dave Lawrence. I misunderstood what I was
being told on this list.
A revised summary will be fortcoming tommorrow.
--
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh@agliodbs.com
and data management solutions (415) 565-7293
for law firms, small businesses fax 651-9224
and non-profit organizations. San Francisco