Re: [HACKERS] Collaboration Tool Proposal
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 Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
Tom Lane said: Josh Berkus [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
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 [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businesses fax 651-9224 and non-profit organizations. San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Collaboration Tool Proposal
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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
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
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
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 ---(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
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Collaboration Tool Proposal -- Summary to date
Josh Berkus [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Collaboration Tool Proposal
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Collaboration Tool Proposal
Janos, So far, all of the solutions that are being seriously considered seem to be free, open-source software. I can't find any indication on your site that this is software the PostgreSQL community can hack to bits as needed over the years. Even if it's free now, there's the possibility that it will later turn out to be a free straitjacket. Regards, Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, February 27, 2004 1:19 PM To: [EMAIL PROTECTED] Subject: Re: [HACKERS] Collaboration Tool Proposal 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Collaboration Tool Proposal
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 Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Collaboration Tool Proposal
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 ---(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
Re: [HACKERS] Collaboration Tool Proposal
Josh Berkus wrote: Folks, Discuss: Has anyone talked to the people at collabnet (http://www.collab.net)? I wonder if they'd be willing to put something together for the PostgreSQL team? They run the tigris.org site, which is one of the nicest OSS collaboration sites I've worked with. GForge is nice, but seems more kludgey than Tigris. What does the Apache project run? Another option is something like Drupal (http://www.drupal.org). Drupal is a CMS system with tons of plugins. I'm not sure that it could handle a project as large as PostgreSQL, but Drupal's own development work is self hosted. It may merit some investigation. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Collaboration Tool Proposal
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
