Re: [HACKERS] pgfoundry references in docs
On Wed, Jul 4, 2012 at 4:21 PM, David E. Wheeler da...@justatheory.com wrote: On Jul 4, 2012, at 9:15 AM, Magnus Hagander wrote: Not really. We have nowhere else to recommend, since we don't run a replacement for it. And we really don't want to get involved in listing all the different third party sites out there. (For example, we had a reference to sourceforge.net in the same paragraph. And while that was certainly state of the art when the docs were written, I don't think anybody sane would recommend that today. The reality keeps changing on those things, so it really doesn't belong in the docs). We could put a set of links on the wiki if we want something more live. Ah, then perhaps a link to such a wiki page would suffice. I think that would be a good compromise. That can really be said for all of Appendix H in that case... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On Tue, Jul 3, 2012 at 10:32 PM, Dave Page dp...@pgadmin.org wrote: On Tuesday, July 3, 2012, Peter Geoghegan wrote: On 3 July 2012 20:20, Magnus Hagander mag...@hagander.net wrote: The second one removes the reference to pgfoundry completely. As a step in the deprecation. I'd prefer to apply the second one, but will settle for the first one if people object ;) I'd also prefer if you applied the second one. +1 Since all those who commented preferred that option, I've applied that patch. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On Tue, Jul 3, 2012 at 10:01 PM, David E. Wheeler da...@justatheory.com wrote: On Jul 3, 2012, at 9:20 PM, Magnus Hagander wrote: The smaller one, pgfoundry_1.diff, removes the suggestion to apply for new projects on pgfoundry. The reason for this being that pgfoundry doesn't *accept* new projects anymore. Should you not perhaps recommend that they go somewhere else? Not really. We have nowhere else to recommend, since we don't run a replacement for it. And we really don't want to get involved in listing all the different third party sites out there. (For example, we had a reference to sourceforge.net in the same paragraph. And while that was certainly state of the art when the docs were written, I don't think anybody sane would recommend that today. The reality keeps changing on those things, so it really doesn't belong in the docs). We could put a set of links on the wiki if we want something more live. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
Magnus Hagander wrote: Attached are two patches, one of which I'd like to apply. Open for discussion on which one. The smaller one, pgfoundry_1.diff, removes the suggestion to apply for new projects on pgfoundry. The reason for this being that pgfoundry doesn't *accept* new projects anymore. The second one removes the reference to pgfoundry completely. As a step in the deprecation. I'd prefer to apply the second one, but will settle for the first one if people object ;) Well, I don't object to the documentation change, but I have a problem with the fact. Are there any other places that could be recommended for hosting my pgFoundry projects? If yes, that should be mentioned in the documentation. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On Wed, Jul 4, 2012 at 9:18 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote: Magnus Hagander wrote: Attached are two patches, one of which I'd like to apply. Open for discussion on which one. The smaller one, pgfoundry_1.diff, removes the suggestion to apply for new projects on pgfoundry. The reason for this being that pgfoundry doesn't *accept* new projects anymore. The second one removes the reference to pgfoundry completely. As a step in the deprecation. I'd prefer to apply the second one, but will settle for the first one if people object ;) Well, I don't object to the documentation change, but I have a problem with the fact. Are there any other places that could be recommended for hosting my pgFoundry projects? If yes, that should be mentioned in the documentation. Exiting pgfoundry projects are perfectly safe for now - but *new* projects are not accepted. There is a project underway (for a *long* time - it keeps getting stalled) working on migration paths. Until such paths are available and documented, existing projects will still be safe on pgfoundry. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On Jul 4, 2012, at 9:15 AM, Magnus Hagander wrote: Not really. We have nowhere else to recommend, since we don't run a replacement for it. And we really don't want to get involved in listing all the different third party sites out there. (For example, we had a reference to sourceforge.net in the same paragraph. And while that was certainly state of the art when the docs were written, I don't think anybody sane would recommend that today. The reality keeps changing on those things, so it really doesn't belong in the docs). We could put a set of links on the wiki if we want something more live. Ah, then perhaps a link to such a wiki page would suffice. I think that would be a good compromise. David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pgfoundry references in docs
Attached are two patches, one of which I'd like to apply. Open for discussion on which one. The smaller one, pgfoundry_1.diff, removes the suggestion to apply for new projects on pgfoundry. The reason for this being that pgfoundry doesn't *accept* new projects anymore. The second one removes the reference to pgfoundry completely. As a step in the deprecation. I'd prefer to apply the second one, but will settle for the first one if people object ;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ pgfoundry_1.diff Description: Binary data pgfoundry_2.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On Jul 3, 2012, at 9:20 PM, Magnus Hagander wrote: The smaller one, pgfoundry_1.diff, removes the suggestion to apply for new projects on pgfoundry. The reason for this being that pgfoundry doesn't *accept* new projects anymore. Should you not perhaps recommend that they go somewhere else? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On 3 July 2012 20:20, Magnus Hagander mag...@hagander.net wrote: The second one removes the reference to pgfoundry completely. As a step in the deprecation. I'd prefer to apply the second one, but will settle for the first one if people object ;) I'd also prefer if you applied the second one. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry references in docs
On Tuesday, July 3, 2012, Peter Geoghegan wrote: On 3 July 2012 20:20, Magnus Hagander mag...@hagander.net javascript:; wrote: The second one removes the reference to pgfoundry completely. As a step in the deprecation. I'd prefer to apply the second one, but will settle for the first one if people object ;) I'd also prefer if you applied the second one. +1 -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
[HACKERS] pgfoundry down?
Does anybody know what's going on? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgfoundry down?
Apologies ... everything should be back up and running now ... On Mon, 11 Apr 2011, Tatsuo Ishii wrote: Does anybody know what's going on? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers Marc G. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PgFoundry] Unsigned Data Types
On Sat, Aug 16, 2008 at 10:53 AM, Decibel! [EMAIL PROTECTED] wrote: On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote: Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. Is the intention for the types to go into pg_catalog? It'd be nice if you could specify what schema they should be installed in. An uninstall would also be good. The pg_catalog made since to me at first (especially for my application), but on reflection I believe you are right. I will remove the references to the pg_catalog schema and allow the user to add the unsigned data type to any schema. Good catch on the uninstall script. I should have written this as well. I will post an update to the wiki later tonight. Thanks for doing this, I've wished we had uint types in the past, and I'm sure I will again in the future! I am glad it is useful. I needed it for my current project, and I was hoping others could use it as well. Thanks, - Ryan
Re: [HACKERS] [PgFoundry] Unsigned Data Types
I can say that we have had several times to use bigint instead because of the lack of uint type in postgres. On Sun, Aug 17, 2008 at 9:03 PM, Ryan Bradetich [EMAIL PROTECTED]wrote: On Sat, Aug 16, 2008 at 10:53 AM, Decibel! [EMAIL PROTECTED] wrote: On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote: Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. Is the intention for the types to go into pg_catalog? It'd be nice if you could specify what schema they should be installed in. An uninstall would also be good. The pg_catalog made since to me at first (especially for my application), but on reflection I believe you are right. I will remove the references to the pg_catalog schema and allow the user to add the unsigned data type to any schema. Good catch on the uninstall script. I should have written this as well. I will post an update to the wiki later tonight. Thanks for doing this, I've wished we had uint types in the past, and I'm sure I will again in the future! I am glad it is useful. I needed it for my current project, and I was hoping others could use it as well. Thanks, - Ryan
Re: [HACKERS] [PgFoundry] Unsigned Data Types
On Aug 15, 2008, at 1:00 AM, Ryan Bradetich wrote: Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. Is the intention for the types to go into pg_catalog? It'd be nice if you could specify what schema they should be installed in. An uninstall would also be good. Thanks for doing this, I've wished we had uint types in the past, and I'm sure I will again in the future! -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
[HACKERS] [PgFoundry] Unsigned Data Types
Hello all, Here is the first pass at the unsigned data type I have been working on. I am planning on adding these to the September 2008 commitfest wiki page. The unsigned data type is not targeted for core, but for the uint PgFoundry project. The uint.c.gz file is the main source file for the uint1, uint2, and uint4 data types. The uing.sql.gz file contains the SQL statements to add the unsigned data type to the database. The pg_atoui.c.gz file is based off the function in the PostgreSQL source code but works for unsigned data types instead of signed data types. The Makefile is used to build the unsigned data type shared library on Linux. The tests.tar.gz is my unit test suit that I worked on to make sure the unsigned integer types worked as expected. The tests cover cases like: * table creation with the unsigned integer types. * comparision operations. * INSERT statements (binary and text forms). * COPY statements (binary and text forms). * unique btree index support. In addition to correctness issues, I would also appreciate feedback on best practices and portability concerns. For example: I doubt my Makefiles are very portable. What is the proper solution to handle this? pgxs? Thanks, - Ryan uint.c.gz Description: GNU Zip compressed data uint.sql.gz Description: GNU Zip compressed data pg_atoui.c.gz Description: GNU Zip compressed data Makefile Description: Binary data tests.tar.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PGFoundry down?
PGFoundry is responding with: PgFoundry Could Not Connect to Database: -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pgfoundry - news - is working?
Hello yesterday I did one news notice on my orafunc page. But it isn't on main page yet. Why? Can someboody explain mechanism of publishing messages on pgfoundry? Regards Pavel Stehule _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Mon, Feb 20, 2006 at 02:49:30PM +0700, Jeroen T. Vermeulen wrote: On Mon, February 20, 2006 11:00, Marc G. Fournier wrote: Speaking for libpqxx, my only concern with that is the mailing list. Would those have to move to different addresses--or conversely, would a forced migration make it much easier to move *all* GBorg mailing lists to pgFoundry and maintain their old addresses? All addresses would have to be changed to the pgfoundry.org one ... Ouch! Moving my project off GBorg wasn't so hard, but forcing all mailing list subscribers to move to a different address does hurt. If the same goes for many other projects on there, wouldn't it be possible to move all mail handling for gborg.postgresql.org over to pgFoundry at once, but preserve the domain name and list names? It may help people make the jump if mailing list migration could be decoupled from the other changes. Actually, it should be entirely possible to setup forwarding for projects as they migrate, one-by-one. AFAIK mailman will handle something like [EMAIL PROTECTED] being forwarded to [EMAIL PROTECTED] -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Wed, 22 Feb 2006, Jim C. Nasby wrote: On Mon, Feb 20, 2006 at 02:49:30PM +0700, Jeroen T. Vermeulen wrote: On Mon, February 20, 2006 11:00, Marc G. Fournier wrote: Speaking for libpqxx, my only concern with that is the mailing list. Would those have to move to different addresses--or conversely, would a forced migration make it much easier to move *all* GBorg mailing lists to pgFoundry and maintain their old addresses? All addresses would have to be changed to the pgfoundry.org one ... Ouch! Moving my project off GBorg wasn't so hard, but forcing all mailing list subscribers to move to a different address does hurt. If the same goes for many other projects on there, wouldn't it be possible to move all mail handling for gborg.postgresql.org over to pgFoundry at once, but preserve the domain name and list names? It may help people make the jump if mailing list migration could be decoupled from the other changes. Actually, it should be entirely possible to setup forwarding for projects as they migrate, one-by-one. AFAIK mailman will handle something like [EMAIL PROTECTED] being forwarded to [EMAIL PROTECTED] Woo hoo ... a mailman expert ... let us know how it is done so that we can do it :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Wed, Feb 22, 2006 at 01:11:46PM -0400, Marc G. Fournier wrote: Actually, it should be entirely possible to setup forwarding for projects as they migrate, one-by-one. AFAIK mailman will handle something like [EMAIL PROTECTED] being forwarded to [EMAIL PROTECTED] Woo hoo ... a mailman expert ... let us know how it is done so that we can do it :) To test this, I created [EMAIL PROTECTED] http://lists.decibel.org/mailman/listinfo/test In postfix, I setup the following in main.cf: virtual_alias_maps = hash:/usr/local/etc/postfix/virtuals/virtual, regexp:/usr/local/etc/postfix/virtuals-regex/decibel.org, where virtuals-regex/decibel.org contains: # commands /^(test)-(post|admin|bounces|confirm|join|leave|owner|request|subscribe|unsubscribe)@nasby.net$/ mailman-$2+$1 # lists (command -post) /^(test)@nasby.net$/ mailman-post+$1 (yeah, I flubbed the file name... oh well...) I can now post, subscribe, or issue any commands by sending email to [EMAIL PROTECTED] or [EMAIL PROTECTED] Feel free to subscribe and test for yourself. While this forwarding implimentation is obviously postfix-specific, the point is that as long as the email eventually makes it to the proper list addresses, that's all that mailman cares about. So, is there a formal project setup anywhere for the migration? ISTM that it would be best to create a project on either gborg or pgfoundry with the intention that it produce a set of code/scripts/procedures that allow for migrating projects from gborg to pgfoundry, since obviously moving lists over is a minor portion of the effort. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Wed, 22 Feb 2006, Jim C. Nasby wrote: So, is there a formal project setup anywhere for the migration? ISTM that it would be best to create a project on either gborg or pgfoundry with the intention that it produce a set of code/scripts/procedures that allow for migrating projects from gborg to pgfoundry, since obviously moving lists over is a minor portion of the effort. Actually, we've even got a prelim script setup for moving teh database that I have to spend some time testing, after which we can start moving ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Wed, Feb 22, 2006 at 04:26:27PM -0400, Marc G. Fournier wrote: On Wed, 22 Feb 2006, Jim C. Nasby wrote: So, is there a formal project setup anywhere for the migration? ISTM that it would be best to create a project on either gborg or pgfoundry with the intention that it produce a set of code/scripts/procedures that allow for migrating projects from gborg to pgfoundry, since obviously moving lists over is a minor portion of the effort. Actually, we've even got a prelim script setup for moving teh database that I have to spend some time testing, after which we can start moving ... Well, there's more than that. You'd need to move the actual mailman list (though afaik that shouldn't be very hard; one issue is that you'd want to shut mailman and probably the MTA down while a list is being moved). What about files? Is there anything else? I suggest setting up a project on pgfoundry and putting scripts there, especially since some of this stuff can be figured out without access to the actual environments (ie: a script to transfer a mailman list). I know we've got a test copy of pgfoundry setup; do we have a test copy of gborg somewhere as well? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
-Original Message- From: [EMAIL PROTECTED] on behalf of Joshua D. Drake Sent: Sun 2/19/2006 12:35 AM To: Bruce Momjian Cc: Christopher Browne; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Pgfoundry and gborg: shut one down This is not get everything everyone wants before shutting down a site time. We should move to one site, and if the new site is not to someone's liking, there is always sourceforge and other hosting sites. I do agree with Bruce here but... we need to make sure that we give everyone their data. If Gborg does CVS like Gforge we may have a problem in that there is only one cvs repository. Moving CVS is not a problem - each project has their own repo on both systems. The problem is moving all the database stuff such as the bug trackers and todo lists, for which I'm told there are no working scripts. The other one that caused me great pain when I moved psqlODBC over was the GBorg genpages. I ended up manually pulling the code out of them and into plain HTML files as there is no equivalent area on pgFoundry. FWIW, in both the moves I have done (psqlODBC and Npgsql), only the CVS was actually moved. Regards, Dave ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Pgfoundry and gborg: shut one down
Dave Page wrote: Moving CVS is not a problem - each project has their own repo on both systems. The problem is moving all the database stuff such as the bug trackers and todo lists, for which I'm told there are no working scripts. The other one that caused me great pain when I moved psqlODBC over was the GBorg genpages. I ended up manually pulling the code out of them and into plain HTML files as there is no equivalent area on pgFoundry. FWIW, in both the moves I have done (psqlODBC and Npgsql), only the CVS was actually moved. Perhaps that's the general solution. Forget about the database, genpages etc. and ask respective project administrators to move them manually? The two really important things are the CVS and the mailing-list. On my part, It'd be sufficient if those two where moved. My html content stems from my CVS and I plan to restructure it a bit anyway. My bug-tracking can be moved manually if need be. I too would be happy if I could somehow migrate to SVN but that can be done later. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pgfoundry and gborg: shut one down
FYI - as a positive enhancement, Greenplum donated a beefy server to host pgFoundry. - Luke On 2/18/06 10:34 AM, Tom Lane [EMAIL PROTECTED] wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Sun, February 19, 2006 05:10, Bruce Momjian wrote: I don't care what direction we go, just kill one. Speaking for libpqxx, my only concern with that is the mailing list. Would those have to move to different addresses--or conversely, would a forced migration make it much easier to move *all* GBorg mailing lists to pgFoundry and maintain their old addresses? Jeroen ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Mon, 20 Feb 2006, Jeroen T. Vermeulen wrote: On Sun, February 19, 2006 05:10, Bruce Momjian wrote: I don't care what direction we go, just kill one. Speaking for libpqxx, my only concern with that is the mailing list. Would those have to move to different addresses--or conversely, would a forced migration make it much easier to move *all* GBorg mailing lists to pgFoundry and maintain their old addresses? All addresses would have to be changed to the pgfoundry.org one ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Mon, February 20, 2006 11:00, Marc G. Fournier wrote: Speaking for libpqxx, my only concern with that is the mailing list. Would those have to move to different addresses--or conversely, would a forced migration make it much easier to move *all* GBorg mailing lists to pgFoundry and maintain their old addresses? All addresses would have to be changed to the pgfoundry.org one ... Ouch! Moving my project off GBorg wasn't so hard, but forcing all mailing list subscribers to move to a different address does hurt. If the same goes for many other projects on there, wouldn't it be possible to move all mail handling for gborg.postgresql.org over to pgFoundry at once, but preserve the domain name and list names? It may help people make the jump if mailing list migration could be decoupled from the other changes. Jeroen ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Pgfoundry and gborg: shut one down
Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. Just before shutting it off, we should dump the existing project information to an FTP directory so it can be reclaimed as needed. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Pgfoundry and gborg: shut one down
Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. Just before shutting it off, we should dump the existing project information to an FTP directory so it can be reclaimed as needed. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, claiming that the CVS repository and the mailing list are what really matters. I'd be fairly upset if gborg was shut down without that happening. FTP archive or not. Kind Regards, Thomas Hallgren ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Pgfoundry and gborg: shut one down
Thomas Hallgren [EMAIL PROTECTED] writes: Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Sat, Feb 18, 2006 at 09:31:18AM -0500, Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. Well, first you need to mark one as deprecated. Looking at both sites I don't see anything indicating that either is to be preferred. You can still sign up to both of them. How is one to know a migration is expected? Secondly, say I have a project to migrate, what next? Googling for gborg migration doesn't bring up anything useful. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] Pgfoundry and gborg: shut one down
Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. Well that is not exactly true. We have been encouraging gborg projects to move for at least a year. What we haven't done is provided an easy means to do so. But frankly after seeing, working on and with pgFoundry I don't think pushing them there is a good choice either. Documentation is very sparse, bugs are rampant and I don't want to even consider the possible security issues involved with it. That being said, as an inclusive solution there really isn't anything else out there :( Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Pgfoundry and gborg: shut one down
Joshua D. Drake wrote: Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. Well that is not exactly true. We have been encouraging gborg projects to move for at least a year. What we haven't done is provided an easy means to do so. But frankly after seeing, working on and with pgFoundry I don't think pushing them there is a good choice either. Documentation is very sparse, bugs are rampant and I don't want to even consider the possible security issues involved with it. That being said, as an inclusive solution there really isn't anything else out there :( I think that's overstating it a bit (even though I know you held back ;-) ). We have stomped on most of the significant bugs that have arisen from our implementation, and gotten some fixes from upstream too. We do have a couple of GForge devs who help us out. We have in fact been pretty careful about security issues. Frankly, what we need is someone with enough dedicated time and drive to push the migration through. Ideally that would be someone who could work fulltime for the several weeks I suspect a complete migration would take. Unfortunately, I don't know of such a resource. If we could get to be running pgFoundry on the latest GForge, with PHP/CGI enabled project web pages, a database per project available, SVN as well as CVS, and a known stable mailman release we'd be in excellent shape. I'd rather move forwards than back. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. If we don't push folks, nothing will happen, which is what has happened for years now. Let's set a date and tell people to move, or else. Keeping our stuff split like this is not helping us. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pgfoundry and gborg: shut one down
Andrew Dunstan wrote: If we could get to be running pgFoundry on the latest GForge, with PHP/CGI enabled project web pages, a database per project available, SVN as well as CVS, and a known stable mailman release we'd be in excellent shape. I'd rather move forwards than back. I don't care what direction we go, just kill one. We are at the dancing bear stage with this thing, like we were with the web site redesign: [ old posting ] We have been talking about a new web page layout for years at this point. I almost don't care if they just put a dancing bear up on the web site. Let's do something! What's wrong with the existing one? Have you designed the dancing bear you'd like us to put up in place of what we have now? Looking around now. Perhaps a dancing elephant. WARNING: This will make you ill: http://janetskiles.com/ART/greeting/greet-ani/dancing-elephant.jpg That URL is priceless, and perhaps instead of shutting down the old server, we should just put this up on there to shame people into moving. Anyway, it is time to do something, and doing anything is starting to look good. I think I even have some stuff on gborg and would move it if there was a push to do that, so I know from experience that a deadline is what it is going to take. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
A long time ago, in a galaxy far, far away, pgman@candle.pha.pa.us (Bruce Momjian) wrote: Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. If we don't push folks, nothing will happen, which is what has happened for years now. Let's set a date and tell people to move, or else. Keeping our stuff split like this is not helping us. Be sure there's a carrot as well as the stick... pgFoundry does generally look more featureful, which is a good thing. A choice of CVS and SVN would be a bigger carrot... -- output = reverse(moc.liamg @ enworbbc) http://linuxdatabases.info/info/internet.html We English-speaking peoples should keep hold of the essential fact about foreign languages: They exist to make us laugh. -- John Derbyshire ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Andrew Dunstan)
would write:
If we could get to be running pgFoundry on the latest GForge, with
PHP/CGI enabled project web pages, a database per project available,
SVN as well as CVS, and a known stable mailman release we'd be in
excellent shape.
Slony-I would move there fairly quickly upon availability of SVN; a
lot of our folks would be pretty keen on storing things in SVN.
*That* is about the only thing holding off migration for at least one
project...
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/slony.html
...In my phone conversation with Microsoft's lawyer I copped to the
fact that just maybe his client might see me as having been in the
past just a bit critical of their products and business
practices. This was too bad, he said with a sigh, because they were
having a very hard time finding a reporter who both knew the industry
well enough to be called an expert and who hadn't written a negative
article about Microsoft. -- Robert X. Cringely
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
Christopher Browne wrote: Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Andrew Dunstan) would write: If we could get to be running pgFoundry on the latest GForge, with PHP/CGI enabled project web pages, a database per project available, SVN as well as CVS, and a known stable mailman release we'd be in excellent shape. Slony-I would move there fairly quickly upon availability of SVN; a lot of our folks would be pretty keen on storing things in SVN. *That* is about the only thing holding off migration for at least one project... SVN is actually on pgFoundry and Apache is ready to allow webdav connections. What doesn't work is the integration with pgFoundry/Gforge. Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
Christopher Browne wrote: Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Andrew Dunstan) would write: If we could get to be running pgFoundry on the latest GForge, with PHP/CGI enabled project web pages, a database per project available, SVN as well as CVS, and a known stable mailman release we'd be in excellent shape. Slony-I would move there fairly quickly upon availability of SVN; a lot of our folks would be pretty keen on storing things in SVN. *That* is about the only thing holding off migration for at least one project... This is not get everything everyone wants before shutting down a site time. We should move to one site, and if the new site is not to someone's liking, there is always sourceforge and other hosting sites. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
This is not get everything everyone wants before shutting down a site time. We should move to one site, and if the new site is not to someone's liking, there is always sourceforge and other hosting sites. I do agree with Bruce here but... we need to make sure that we give everyone their data. If Gborg does CVS like Gforge we may have a problem in that there is only one cvs repository. Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pgfoundry and gborg: shut one down
Bruce Momjian wrote: Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, Indeed, we haven't made any particular effort to encourage gborg projects to move. I think it's a bit premature to hold a gun to their heads. If we don't push folks, nothing will happen, which is what has happened for years now. Let's set a date and tell people to move, or else. Keeping our stuff split like this is not helping us. Slowly disabling things is also an option to encourage people to move, while not ending up with a huge number of projects trying to move in the same week. Disabling the ability to create new accounts and projects will tell both existing and new people that this is not the place to be going forward. If you need a new developer or project, you need to put in the effort to move your project. Disabling the ability to upload files will make people create a project on PgFoundry when they make a new releases, putting more pressure on to move across. Even with the above two items changed, it would soon encourage people to move, or at least create a project on PgFoundry and move there file releases there. CVS and mailing lists will need to be moved by admins, but that process doesn't need to be done in a single day. It creates more operational overhead for each project in the short term, but that will continue to push them to migrate. Who are the people who can help move projects across and how can they be contacted? Maybe posting some news items on gborg about it would encourage people. Having the people who can help available to assist people to move will mean that more projects are likely too. I agree dates need to be made, not necessarily about the total shutdown, but feature removal dates will mean people are much more likely to want to move. Regards Russell Smith ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Sat, 18 Feb 2006, Christopher Browne wrote: Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Andrew Dunstan) would write: If we could get to be running pgFoundry on the latest GForge, with PHP/CGI enabled project web pages, a database per project available, SVN as well as CVS, and a known stable mailman release we'd be in excellent shape. Slony-I would move there fairly quickly upon availability of SVN; a lot of our folks would be pretty keen on storing things in SVN. *That* is about the only thing holding off migration for at least one project... SVN is installed on the pgFoundry server, but I think getting pgFoundry to use it got stalled somewhere along the way ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
Slony-I would move there fairly quickly upon availability of SVN; a lot of our folks would be pretty keen on storing things in SVN. *That* is about the only thing holding off migration for at least one project... SVN is installed on the pgFoundry server, but I think getting pgFoundry to use it got stalled somewhere along the way ... Yes.. I called no joy after finding a complete lack of documentation on integrating it. See the archives :) Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Sat, 18 Feb 2006, Joshua D. Drake wrote: Slony-I would move there fairly quickly upon availability of SVN; a lot of our folks would be pretty keen on storing things in SVN. *That* is about the only thing holding off migration for at least one project... SVN is installed on the pgFoundry server, but I think getting pgFoundry to use it got stalled somewhere along the way ... Yes.. I called no joy after finding a complete lack of documentation on integrating it. See the archives :) Ya, I know ... just wasn't pointing any fingers :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Sat, 18 Feb 2006, Thomas Hallgren wrote: Bruce Momjian wrote: Having run had both pgfoundary and gborg for several years, I think we have to conclude that any clean migration is never going to happen, so let's just pick a server and announce date, and shut one of them off. Just before shutting it off, we should dump the existing project information to an FTP directory so it can be reclaimed as needed. I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, claiming that the CVS repository and the mailing list are what really matters. I'd be fairly upset if gborg was shut down without that happening. FTP archive or not. gBorg won't be just shut down until its ready to happen, don't worry about that ... I've sent you a private email about migration, and will follow up with you as soon as I've been able to look into the database migration aspect ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Pgfoundry and gborg: shut one down
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Joshua D. Drake) transmitted: Slony-I would move there fairly quickly upon availability of SVN; a lot of our folks would be pretty keen on storing things in SVN. *That* is about the only thing holding off migration for at least one project... SVN is installed on the pgFoundry server, but I think getting pgFoundry to use it got stalled somewhere along the way ... Yes.. I called no joy after finding a complete lack of documentation on integrating it. See the archives :) Ah, fair enough. It probably makes sense to start arguing again about what to do about pgFoundry on the Slony-I list... I have some time again to get on with some Slony-I work after things had gotten a bit nuts in other areas, between a new TLD grabbing all my time, and then the personal matter of my father undergoing (happily successful) cancer surgery. I think I had a client connect to the IRC channel for about a week and a bit of not being around to watch it :-(. Anyway, it probably makes some sense to move Slony-I over some time soon. -- select 'cbbrowne' || '@' || 'acm.org'; http://linuxdatabases.info/info/lisp.html Implying that youcan build systems without rigourous interface specification is always a powerful selling technique to the clueless. -- Paul Campbell, seen in comp.object.corba ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pgfoundry and gborg: shut one down
Marc G. Fournier wrote: I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, claiming that the CVS repository and the mailing list are what really matters. I'd be fairly upset if gborg was shut down without that happening. FTP archive or not. gBorg won't be just shut down until its ready to happen, don't worry about that ... I've sent you a private email about migration, and will follow up with you as soon as I've been able to look into the database migration aspect ... I'm happy with that, as long as everyone understands that: - Migrating my CVS and mailing-lists is not something I can do by myself - My project is alive and would take a serious hit if the upload functionality was disabled - Being ridiculed by displaying dancing elephants on GBorg wouldn't exactly be honoring my efforts I could move everything all by myself I would have done so a long time ago. Extra 'motivation' is not necessary. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Pgfoundry and gborg: shut one down
On Sun, 19 Feb 2006, Thomas Hallgren wrote: Marc G. Fournier wrote: I've repeatedly asked for help moving my PL/Java stuff over to pgfoundry and offered my help in the process, claiming that the CVS repository and the mailing list are what really matters. I'd be fairly upset if gborg was shut down without that happening. FTP archive or not. gBorg won't be just shut down until its ready to happen, don't worry about that ... I've sent you a private email about migration, and will follow up with you as soon as I've been able to look into the database migration aspect ... I'm happy with that, as long as everyone understands that: - Migrating my CVS and mailing-lists is not something I can do by myself - My project is alive and would take a serious hit if the upload functionality was disabled - Being ridiculed by displaying dancing elephants on GBorg wouldn't exactly be honoring my efforts None of the above will happen, I can assure you ... or, at least, the second two ... the first one we'll work on ... I'm just looking into some things right now ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Tom Lane ([EMAIL PROTECTED]) wrote: It's essential IMHO that we provide pg_shadow and pg_group as reasonably backward-compatible views on the new pg_roles catalog. It's not at all negotiable that CREATE USER and CREATE GROUP have to still work in a sane fashion --- to say otherwise is to say that we aren't going to load pg_dumpall scripts from older PG versions, and that is a Non Starter. Right, makes sense, I had just busted them while getting the initial code written. I've now gone back and cleaned up the main parser quite a bit with regard to create/alter/drop/etc user/role. My latest work is available here: http://kenobi.snowman.net/~sfrost/pg_role/latest-role_20050609.1.patch.gz Also the .h files in the same directory (pg_auth_members.h, pg_authid.h) which need to be put into src/include/catalog/. It patches and compiles cleanly against latest CVS (at least, latest as of a few hours ago). I've also updated and flushed out a bit the set of milestones/todo items. My latest version of that can be found here: http://kenobi.snowman.net/~sfrost/pg_role/role_milestones * Means completed in the patch, ? means I'm not sure if it's something that should be done or not. No marker means it needs to be done and hasn't been yet. In general I feel it's starting to get close to meeting all the expectations that I had for it. The more critical things, imv, are the ACL changes for multi-level role resolution (for owners and others) and the per-backend role-member cacheing and fixing the other parsers (ecpg, etc, shouldn't be too hard now that I've got it figured out for the main parser, or at least think I do). Unfortunately, it's starting to get close to July 1st and my availablity is rather sporadic in terms of when I can spend time on this. I'd certainly be willing to work with others (I'm generally pretty responsive to email) to get this finished off and polished up. I do hope to spend some more time on it over the next two weeks and may be able to finish it by July 1st myself but I can't really be 100% sure on that. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Andrew Dunstan wrote: Tom Lane said: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On May 20, 2005, at 11:43 PM, Bruce Momjian wrote: Andrew Dunstan wrote: Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. This may be a bit off-the-wall, but I recall Joel Spolsky recently writing about using Bayesian filtering to classify mail into groups other than spam/ham. I wonder if there's any use for something like that in this case. http://www.joelonsoftware.com/articles/FogBugzII.html Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Fri, May 20, 2005 at 11:59:00PM +0900, Michael Glaesemann wrote: Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. This may be a bit off-the-wall, but I recall Joel Spolsky recently writing about using Bayesian filtering to classify mail into groups other than spam/ham. I wonder if there's any use for something like that in this case. http://www.joelonsoftware.com/articles/FogBugzII.html No, definitely not. Pseudo-bayesian classification as used by the more optimistic spam-filtering folks is pretty crappy at the best of times, and it's really unusuable for more than 3-4 categories. There are natural language analysis techniques that'll do this sort of thing, but they're in the realms of research projects, not canned tools. Cheers, Steve ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. However RT isn't really targeted at bug tracking specifically. It's more of a trouble ticket system. Targeted largely to things like NOCs or incident response ticketing systems. It's much more flexible than pure bug tracking systems like bugzilla and might be able to adapt to a more open email based working model better. But by the same token it would take more attention to set it up and adapt it to bug tracking. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Joshua, does RT has full support of PostgreSQL ? Oleg On Tue, 17 May 2005, Joshua D. Drake wrote: discuss it, and contribute to resolving it. More often than not, a web-based interface like Bugzilla leads to a single bug master, who does most of this work by themselves. Besides the fact we don't have such a person, it would also mean that knowledge of bugs/patches and the discussion about resolving issues is distributed among a smaller pool of people. I can only speak for RT but with RT you can easily avoid this. For example you can set it up so that anything that would go to [EMAIL PROTECTED] would automatically create a ticket an alert all people within the patches group. Multiple people can be assigned to a ticket as a maintainer or just a watcher. You can even respond to specific messages within the thread instead of just a top down (one email after the other). There is definitely room for improvement; submitted patches do occasionally fall through the cracks, for example. I would personally be interested in a bug-tracking system that is closer to a shared email archive. That would be another nice part of RT. RT automatically deals with attachments and although I wouldn't use it for this you could even use it as a semi patch repository until the patch is actually approved for submission. issues, searching through issues, etc. But the point is that the current system works well; Well does it though? I am not saying it is bad, well yes I am ;). There is no central place for me to point one of my developers and say -- Hey, look at this patch... weren't we working on something like this? Let's help them out. I have to have the dig through the mail archives which is fairly counter productive. It would be much better to be able to say, hey... look at patch #42345. What do you think? I'm not sure which existing systems fit this model (suggestions are welcome) -- email needs to be the primary interface, not an afterthought (as is often the case). Perhaps RT would work, I'm not sure. RT supports complete email integration. Most of the interaction I do with it is actually through email not through the web interface. It also has the ability to have a knowledge base dropped right on top of it. Sincerely, Joshua D. Drake -Neil [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point effectively. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane wrote: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. What we do now is not to require the reporter or the developers to classify the email traffic, and the burden is on the people looking for specific information to find it. I am not suggesting we change that, but this the trade-off we have made. The only classification we do is the TODO list and the release notes --- everything else is email searches. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On K, 2005-05-18 at 02:23 -0400, Bruce Momjian wrote: What we do now is not to require the reporter or the developers to classify the email traffic, and the burden is on the people looking for specific information to find it. I am not suggesting we change that, but this the trade-off we have made. The only classification we do is the TODO list and the release notes --- everything else is email searches. Maybe we should look for some mail-archive software which allows adding such tagging after the mail is stored in the list, so that once someone has found the information he was looking for, he could check some checkboxes or make some selections to make finding the info easier the next time. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane said: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Apart from the question of who gets notifications, tracking systems provide some structure and manageability to the data. I find it mildly ironic to see database people eschew the methods of organisation which their own product could help to provide. But all this discussion seems to me pointless anyway - I don't see anybody with enough experience and respect being able to devote enough time to keep a tracking system healthy and useful. And without that we might as well just sit tight. Meanwhile, how about the earlier suggestions related to improving the TODO list a bit (e.g. a beginner's list)? cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane [EMAIL PROTECTED] writes: [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. Right, what I'm saying is that in RT it's more flexible; you can set it up to send mail for the things *you* think people should know about. Also, BZ and most bug tracking systems make it hard to keep email as the communication mechanism of choice. Most of them (like BZ) just send you email with URLs to click to go to the web. There's also the Debian bug tracking system. It also works well with a mailing list set to be the maintainer. Then everyone on the mailing list gets every update on any bug. And you can update or close bugs by just sending email. Several of the larger Debian packages use this model including the X packages. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Tom Lane ([EMAIL PROTECTED]) wrote: I think most of the real advantages of bug trackers that have been mentioned in this thread have to do with history and searchability. We have the raw info for that, in the pgsql-bugs and pgsql-commmitters mail archives, and so it seems to me that this reduces to the perennial gripe that we don't have good enough search tools for the archives. This also means, to some extent anyway, that someone who wants to show off the latest-greatest bug tracking system that will satisfy all our needs could 'seed' the system with at least some of the history that's available currently through the mailing list archives. If they (or the part of the community interested in it, whatever) then work to keep it up to date and show that it's a better system in whatever way, that'd go a great deal farther towards acceptance. Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
People: I think maybe we're putting on the frosting without the cake here. The primary purpose of bug trackers is to help get bugs fixed. Over the last couple of days, we've had a lot of comments from major bug-fixers that a BT isn't *needed* to get bugs fixed. Let's look at tools which address what we actually *do* need, rather than what we don't. Here's where I see a lack: 1) The TODO list is a bit impenetrable for new hackers wanting to get started with PostgreSQL tasks. 2) Users could use a place to look up their current bug and find out what version it was/will be fixed in. 3) Users could use a place to look up known issues/misunderstandings and find education and workarounds. None of those tasks necessarily requires a bug tracker. In fact, I'd advocate a project task list for (1) (which we conveninetly have in pgFoundry) and a knowledge base for (2) and (3). The issue in all cases is upkeep. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wednesday 18 May 2005 04:54, Andrew Dunstan wrote:
Meanwhile, how about the earlier suggestions related to improving the TODO
list a bit (e.g. a beginner's list)?
I think it would be simple enough to tag certain items on the list as low
hanging fruit that there is no reason not to do it.
On a side note, I think that also moving a few items in to a urgent section
like we had for 8.0 would be a really good idea for the start of each
development cycle. Tom mentioned that an item being included on the TODO list
doesn't mean all of core has bought in to it, so let's see a few items that
all of core has bought in to and agrees we might be close to. (Hierarchical
queries and updateable views, both of which are items with outstanding
patches/work and general core approval, come to mind.)
While we can't garauntee these things will be included in any release, a
section of 4-5 items that core/hackers agreed that should be in the next
release would probably help steer people to tackling those problems.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(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: Learning curves and such (was Re: [HACKERS] pgFoundry)
Oleg Bartunov wrote: Joshua, does RT has full support of PostgreSQL ? It support's Postgres, but it uses a dynamic query builder that is pretty brain dead. It only implements features that are cross DB compatible. It comes up with some pretty ugly queries. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tuesday 17 May 2005 01:41, Josh Berkus wrote: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince Yes, I have. Yes, it's steeper. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Lamar Owen ([EMAIL PROTECTED]) wrote: On Tuesday 17 May 2005 01:41, Josh Berkus wrote: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince Yes, I have. Yes, it's steeper. That seems rather odd to me. I havn't really looked at the OpenOffice.org code very much but generally I've found the PostgreSQL code to be pretty well commented and generally well thought-out. I've also found the acceptance, understanding and hand-holding of the PostgreSQL developers to be *better* than I've found in other communities (such as the Linux kernel...) that I've developed and have had code included in. I havn't actually gotten anything real into PostgreSQL *yet*, but I've been spending a fair bit of time on implementing support for SQL Roles and have had alot of help developing the approach for best implementing it (thanks Tom!) and help with stupid questions (what's a tuple?) from a couple developers on IRC (thanks Neil! thanks Andrew!). So, no, I don't think the barrier to entry is all that steep, and it's certainly not *too* steep by any means. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, May 18, 2005 at 05:19:55PM -0400, Stephen Frost wrote: * Lamar Owen ([EMAIL PROTECTED]) wrote: On Tuesday 17 May 2005 01:41, Josh Berkus wrote: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince Yes, I have. Yes, it's steeper. That seems rather odd to me. I havn't really looked at the OpenOffice.org code very much but generally I've found the PostgreSQL code to be pretty well commented and generally well thought-out. I've also found the acceptance, understanding and hand-holding of the PostgreSQL developers to be *better* than I've found in other communities (such as the Linux kernel...) that I've developed and have had code included in. Certainly the code is exceptionally beautiful. Anyone who has seen both Postgres' and MySQL sources can confirm that I think. Now *that* is an unreadable mess :-( I havn't actually gotten anything real into PostgreSQL *yet*, but I've been spending a fair bit of time on implementing support for SQL Roles and have had alot of help developing the approach for best implementing it (thanks Tom!) and help with stupid questions (what's a tuple?) from a couple developers on IRC (thanks Neil! thanks Andrew!). Say, how are you doing on that front? -- Alvaro Herrera (alvherre[a]surnet.cl) No es bueno caminar con un hombre muerto ---(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: Learning curves and such (was Re: [HACKERS] pgFoundry)
Josh Berkus wrote: 1) The TODO list is a bit impenetrable for new hackers wanting to get started with PostgreSQL tasks. [snip] In fact, I'd advocate a project task list for (1) (which we conveninetly have in pgFoundry) It belongs as part of the TODO list, I believe, or keeping it in sync will bedevil it. Just mark possible beginner tasks with something, like *, # or whatever. Or else maybe give them their own section. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: I havn't actually gotten anything real into PostgreSQL *yet*, but I've been spending a fair bit of time on implementing support for SQL Roles and have had alot of help developing the approach for best implementing it (thanks Tom!) and help with stupid questions (what's a tuple?) from a couple developers on IRC (thanks Neil! thanks Andrew!). Say, how are you doing on that front? Current status is- it now compiles with a few pieces still missing: Better parser/backend setup needs to be done. I've hacked 'create role' into place where 'create group' was, but really I need to sit down and think about the *correct* statements, looking at the standard, etc, and write those and the associated back-end parts (most of the back-end parts are already done I think). Once those are done and implemented I'll see about backwards compatibility to the create user/create group parts. pg_group and associated views (information_schema, etc). We don't currently have an aggregate-into-array function that I saw so either we'll need to write one or we'll have to fake the information in pg_group (as, say, just the first group you're in, or something). This is only for backwards-compatibility to things which used pg_group so I'm not sure how important it is for it to be fully functional. I *think* I updated all the information_schema views to not use pg_group but to use the new system tables and that they're implemented correctly. I'm trying to think but there might be another view that was involved in this but I'm not sure. Write the base-case (no cache available) 'in_role' lookup code. I expect this code will also be used during role assignment to verify there are no loops. 'in_role' currently works for the one-level case, but doesn't handle the multi-level case. Shouldn't be too hard to do. Per-connection cacheing code for 'in_role' information. Discussed this with Tom, basically it'll be similar to the search_path cacheing code which is in namespace.c where the cache is marked out of date and regenerated whenever there's a change to the pg_auth_members table. Don't expect this to be very difficult. Once this is done the 'in_role' code in the ACL system will need to be updated for it. flat-file startup updating. This is what I'm currently working on. The difficulty is that I want the flat-files to have only names but the role/member information is in terms of Oids which need to be looked up to role names. Since this is during startup code now the syscache isn't available. What I'm doing is building a copy of the tables in memory (since they should be reasonably small), qsorting them and using bsearch for the lookups. Since they're in memory already and the write-new-role-information situation is much less common than startup I think I'm also going to qsort based on role name and define the format of the pg_auth table to be already-sorted so that the startup code doesn't need to sort it. Once I get all of the startup code working and can actually *connect* to the database I'll be doing a great deal more testing, bug fixing, and implementing the remaining items and testing them. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Stephen Frost [EMAIL PROTECTED] writes: Say, how are you doing on that front? Current status is- it now compiles with a few pieces still missing: [snip] It's essential IMHO that we provide pg_shadow and pg_group as reasonably backward-compatible views on the new pg_roles catalog. It's not at all negotiable that CREATE USER and CREATE GROUP have to still work in a sane fashion --- to say otherwise is to say that we aren't going to load pg_dumpall scripts from older PG versions, and that is a Non Starter. (Not too many releases ago, we couldn't even say that: once upon a time pg_dumpall tried to emit COPY TO pg_shadow commands :-(. But I hope that it's no longer necessary to handle that ...) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgFoundry
Tom Lane wrote: We did do that (not very rigorously) during the 7.4 release cycle. I'm not sure why we fell out of the habit again for 8.0. It seems like a reasonable idea to me. In the past I have suggested incrementally maintaining release.sgml (or some plaintext version of it), rather than having Bruce generate the release notes from a single sweep through the CVS logs prior to a release. The current process can easily lose information: Bruce needs to make a snap decision about which changes are relevant, and it's not always easy to make that decision correctly. It also means the person who implemented a feature (and therefore knows the problem well) is not writing the release notes for it. And it means the release notes are always at least a little bit behind the times. IIRC, the previous discussion petered out when Bruce said he prefers the current process. -Neil ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On T, 2005-05-17 at 01:32 -0400, Tom Lane wrote: As against that I notice some new arrivals proposing to add deductive reasoning to Postgres: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php or implement SQL99 hierarchical queries: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I guess you have missed most of the latest discussion around hierarchical queries ;) From what I understand, what is proposed is a code beautification project, (although likely not minor :) , because the pathes have been around (and allegedly in production use) for a few years already, originally supporting Oracle-style HQs and then, for about a year also subset of SQL99 (it misses SEARCH and CYCLE clauses, see the railroad diagram at http://gppl.moonbone.ru/with_clause.gif ) The patch is available at http://gppl.moonbone.ru/index.shtml I might be wrong, but I'll bet lunch that neither of those projects will come to anything. You can't run before you learn to crawl. Maybe you could take a look at the existing patch and comment what are the points that are most wrong with it. The last one was for 8.0.1. I'm sure someone more at home with pg internals would get the patch to acceptable level faster, but my feeling is that somehow these patches have been just not interesting to core developers. Maybe what we need is some documentation about how to get started as a Postgres hacker --- what to read, what sort of things to tackle for your first hack, etc. I think the people who have been successful around here are the ones who have managed to figure out the syllabus by themselves ... but surely we could try to teach those who come after. A code documentation or beautification project is usually a good way to get newcomers up to speed. And though the getting the the HQ patch into acceptable shape is probably quite big work, just starting with understanding and documenting what it does now and getting further help from pgsql-hackers on what it should do may be something that is possible without existing thorough understanding. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
I think it might also be valuable to have a list of things that are good 'starter projects'. Maybe some indication of TODO items that are simpler. Possibly a list of bugs, too. As someone who has looked at hacking the pg code, I agree it is difficult to know what to look at to get started. I love fixing bugs, but I'm used to the bug tracker type situation and being able to find something that looks relatively easy. That is how I've started on a number of other projects. With no formal bug tracker, I'm not sure what bugs I could look at. I have talked to some people on IRC about tackling the infinite date issue, but was warned off that, as the date/time code is a scary place. Then I looked into the possibility of working on the autovacuum stuff, and again got myself in a little too deep. Not low enough fruit for me. The curve to get the meaning of some things is sometimes hard PG_TRY and things like that just need reading code lots. Not meaning to attack Tom, but for new people proposing new patches he can seem intimidating. I have been around for a little while now and am adjusting to the reality. Maybe people shouldn't be hacking the code before being here a year. It would probably also be useful to point out ways people can help that don't involve hacking C code (or at least not much). Things like docs, the website, advocacy, performance testing, etc. It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). But at the same time, how do I not get into something that is being duplicated by somebody else? I'm just trying to give a bit of a perspective on the way I see things as some who has been around pg for about 12 months and attempted to hack the code a couple of times. Regards Russell Smith ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, May 17, 2005 at 09:23:42PM +1000, Russell Smith wrote: I think it might also be valuable to have a list of things that are good 'starter projects'. Maybe some indication of TODO items that are simpler. Possibly a list of bugs, too. As someone who has looked at hacking the pg code, I agree it is difficult to know what to look at to get started. I love fixing bugs, but I'm used to the bug tracker type situation and being able to find something that looks relatively easy. That is how I've started on a number of other projects. With no formal bug tracker, I'm not sure what bugs I could look at. I have talked to some people on IRC about tackling the infinite date issue, but was warned off that, as the date/time code is a scary place. I'd say the datetime code is a good place to start, the most important characteristic being that it's self contained. It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). Yes, performance testing may also show some implementation bugs that are important to find too. Stress-testing is important too. Or find corner cases, push implementation limits, etc. Or, find some area that people mentions as needing testing, the current example being SIGTERM handling in busy backends. But at the same time, how do I not get into something that is being duplicated by somebody else? Tell -hackers. But if you are going to do testing, it doesn't matter there is multiple people doing it. -- Alvaro Herrera (alvherre[a]surnet.cl) The first of April is the day we remember what we are the other 364 days of the year (Mark Twain) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). But at the same time, how do I not get into something that is being duplicated by somebody else? I reckon a good newbie task at the moment would be to add ALTER object SET SCHEMA blah; on all objects... Chris ---(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: Learning curves and such (was Re: [HACKERS] pgFoundry)
Russell Smith wrote: Maybe people shouldn't be hacking the code before being here a year. If you want to code, jump in. It is a practical craft that you only learn by doing. You might learn something of the people but you'll probably learn precious little of the code by just watching. But don't jump in at the deep end - massive reorganisation of the planner should not be your first project ;-). Ask lots of questions. Tell people what you're doing. I like the idea of a relatively simple low hanging fruit list that we could point newcomers at. Here are some nominations: . add some more tests for the PLs now we have a standard testing framework. . clean up and document some of the contrib modules so they can go into the core (e.g. pgcrypto, dbsize, cube, seg) . rewrite contrib/reindexdb in C so it can be used on Windows . this TODO item: Remove Money type, add money formatting for decimal type I'm sure other people will have additions to such a list. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane [EMAIL PROTECTED] Date: Tue, 17 May 2005 01:32:03 -0400 As against that I notice some new arrivals proposing to add deductive reasoning to Postgres: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php or implement SQL99 hierarchical queries: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I might be wrong, but I'll bet lunch that neither of those projects will come to anything. You can't run before you learn to crawl. The main advantage of deductive reasoning implementation I propose is in fundamental extension of database query language, I don't propose to extent SQL with some cumbersome constructions, for example, like WITH to express recursive queries (inefficiency of such constructions can be easily seen if you try to express a bit more complex recursive query then finding ancestors, e.g. query which finds minimal paths). Also it should be mentioned that original query language (SQL) de facto remains without great changes, the logic program which defines predicates (intensional relations) is located in the system table (there can be put the name and both the text and inner code of logic program). When we want to get intensional relation we simply write in SQL query the name of the logic program (deductive database) and the name of the predicate with the list of arguments. This syntax is identical to the syntax of table function calling with the schema name. Regards, Dmitriy ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Russell, What should be performance tested (I assume new code, like the bitmap scan). I've been meaning to put a task list for performance testing up on the TestPerf project. Yet another personal TODO ... -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
As someone who's been lurking on the postgres lists for quite some time, and submitted one (minor) patch, I think the notion of an entry-level task list for we beginners is fantastic. And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? BJ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, 18 May 2005, Brendan Jurd wrote: As someone who's been lurking on the postgres lists for quite some time, and submitted one (minor) patch, I think the notion of an entry-level task list for we beginners is fantastic. And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? Because none of the core developers will use it, so bugs would be added, but never removed ... Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? We have a long list of 'TODO' items, but could anyone generate a list of known bugs? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Marc G. Fournier wrote: And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? Because none of the core developers will use it, so bugs would be added, but never removed ... Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? We have a long list of 'TODO' items, but could anyone generate a list of known bugs? Bug tracking systems are used to track more than just bugs ... they are often used to track enhancements, support requests, and other tasks. GForge (and hence pgfoundry) provides each project by default with several trackers, one for each of these classes. But then, as a pgfoundry admin you know that, right? :-) cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, 17 May 2005, Andrew Dunstan wrote: Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. The key requirement that has always come up is that the core developers wouldn't use anything web based, so the tracker would have to somehow tie into the mailing lists themselves ... Bug tracking systems are used to track more than just bugs ... they are often used to track enhancements, support requests, and other tasks. GForge (and hence pgfoundry) provides each project by default with several trackers, one for each of these classes. But then, as a pgfoundry admin you know that, right? :-) Again, it comes down to who will maintain it? I believe that Bruce has already stated that he hasn't got the time/desire to do much more then his current TODO lists, Tom has stated a lack of desire to use a web-based tracking tool ... so we'd need to find someone with the time to act as intermediary to update things accordingly ... ... and I think *that* is probably one of hte major show stoppers ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Andrew, Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. Or whether to use one.Roughly 1/3 bugzilla, 1/3 something else, and 1/3 don't want a bugtracker. And, among the people who didn't want bugzilla, some were vehemently opposed to it. Bugtrackers discussed included GForge, bugzilla, RT, Roundup, Jura (they offered a free license) and a few I don't remember. Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. Request Tracker (RT) can do that. We use it for all of our support ticket stuff. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Marc G. Fournier [EMAIL PROTECTED] wrote: The key requirement that has always come up is that the core developers wouldn't use anything web based, so the tracker would have to somehow tie into the mailing lists themselves ... What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. I can't speak for the people who don't like web based but my guess is that the web is not their primary medium of communication. Email is. It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. This is true or at least, this is my experience but you are not going to convince many people of that. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I agree. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Joshua D. Drake [EMAIL PROTECTED] writes: It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. This is true or at least, this is my experience but you are not going to convince many people of that. The Postgres project has been exceedingly successful while using email lists as the primary means of communication/organization. I for one am disinclined to tinker with such a fundamental aspect of the way that the community operates. If we try to substitute a bug tracker for the mailing lists, I think we'll be making a very basic change in the community's communication structure, and not one for the better. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I agree. Since the development community is neither centralised nor organized, why would you expect such a repository to have anything to do with what actually happens? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Brendan Jurd wrote: What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. Brendan, please review the past versions of this thread. For example, see here: http://groups-beta.google.com/group/comp.databases.postgresql.hackers/browse_thread/thread/1cca714cc34865a5/f802a2a78c94faa3?q=bugzillarnum=1hl=en#f802a2a78c94faa3 cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pgFoundry
On Mon, 16 May 2005 20:54:15 -0400 (EDT), Bruce Momjian pgman@candle.pha.pa.us wrote: I have modifed the TODO HTML so the completed items are in italics. Isn't it a bit misleading to have those items on the TODO list at all? Shouldn't there be a separate list: DONE for the next release? Servus Manfred ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Tom Lane [EMAIL PROTECTED] wrote: The Postgres project has been exceedingly successful while using email lists as the primary means of communication/organization. I for one am disinclined to tinker with such a fundamental aspect of the way that the community operates. If we try to substitute a bug tracker for the mailing lists, I think we'll be making a very basic change in the community's communication structure, and not one for the better. I agree that it's a major change, and the significance of changing the communication structure should not be underestimated. But a) I believe it would be a change for the better, and b) BZ uses a very flexible and verbose email notification system, so the departure from the existing email list structure would not be so drastic. I read through the discussion link that Andrew provided (thanks Andrew), and during that discussion you appeared to be in favour of bugzilla, for the same sorts of reasons I am promoting it now. What changed? Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I agree. Since the development community is neither centralised nor organized, why would you expect such a repository to have anything to do with what actually happens? I think the decentralised nature of the community is one of the things that is responsible for this steep learning curve, and could stand to be improved. And deploying a more centralised system for development management would be a crucial first step in said improvement. In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. ---(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: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, 17 May 2005 14:45:00 -0300 (ADT), Marc G. Fournier [EMAIL PROTECTED] wrote: Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? Just imagine our marketing crew being able to say: According to our great bug tracking system NN serious bugs have been reported last year, 98% of which have been fixed within three days. Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Manfred, Just imagine our marketing crew being able to say: According to our great bug tracking system NN serious bugs have been reported last year, 98% of which have been fixed within three days. grin You're not going to win over many people on *this* list with marketing arguments. -- --Josh 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])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Brendan Jurd wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. It's a nice offer, but honestly, my experience in the commercial world as well as in FOSS tells me that a bug tracking system would need loving care from somebody with years of experience in the postgres development community. When I was managing this stuff in a commercial setting it took a large part of my day - I had a 30 to 60 minute meeting every morning and spent a further similar period updating, assigning, etc. The people who could do it are just too damned busy. Given the amount that Tom gets done now I'm amazed that he finds time to eat drink and sleep. The things I tried to suggest earlier in this thread would be much less burdensome. As for central management ... the phrase herding cats springs to mind. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. Request Tracker (RT) can do that. We use it for all of our support ticket stuff. debbugs can do it too, though I don't know of anyone who's actually got it working outside of the Debian stuff. :) Personally, I like Debian's bug tracking system, but I suppose that's just me... I believe OTRS can do it too. Havn't played with the email interface of it really though. Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Stephen Frost [EMAIL PROTECTED] wrote: * Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. I'm detecting sarcasm here, but just in case you're being serious ... For such a tool to serve its intended purpose, the postgres community needs to be, to a certain extent, agreed on and aware of its use as the primary dev management system. There's no point creating, hosting, updating and maintaining anything if the community isn't using it. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, May 18, 2005 at 08:04:51AM +1000, Brendan Jurd wrote: On 5/18/05, Stephen Frost [EMAIL PROTECTED] wrote: * Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. I'm detecting sarcasm here, but just in case you're being serious ... I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) -- Alvaro Herrera (alvherre[a]surnet.cl) Oh, oh, las chicas galacianas, lo harán por las perlas, ¡Y las de Arrakis por el agua! Pero si buscas damas Que se consuman como llamas, ¡Prueba una hija de Caladan! (Gurney Halleck) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) Well sorry but that is ridiculous. Either the community (or more specifically core) chooses to use it upfront or not. I think it is a complete waste of time and energy to expect someone to put in all that effort just to have the community give them the finger. This isn't something that is going to serve the person who loose all the sleep to configure and maintain it. It is something that is going to help the PostgreSQL community has a whole, to grow in a reasonably organized and hopefully less painful way. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Brendan Jurd ([EMAIL PROTECTED]) wrote: I'm detecting sarcasm here, but just in case you're being serious ... Yeah, for the most part I *was* being quite serious. For such a tool to serve its intended purpose, the postgres community needs to be, to a certain extent, agreed on and aware of its use as the primary dev management system. There's no point creating, hosting, updating and maintaining anything if the community isn't using it. Nope, that's not the way the world works. If you build it, they will come. You'll want to make the *community* aware of it, sure, but that's just to encourage people to use it. You don't need anything to be agreed upon, either people will use it, or they won't. If enough people use it that it becomes apparent that it's clearly better *then* you'll likely get a more buy-in and acceptance from developers. Until the developers are on-board you'll need to act as an intermediary (unless you can automate it) between the people using your system and the developers. That's more of your time, but if you're willing to spend it on this to prove it's a better way to work, then go for it. You're never going to get everyone to whole-sale jump over to a new system. It's just not going to happen. You need to build the basics and then get people to start using it. Eventually if it manages to get to a critical mass of some sort you'll get enough people using it that some of them may be willing to help maintain it- perhaps not even developers but other people who are willing to help with the interaction with the developers. You could always start by just doing the 'todo' list that Bruce has and maintaining it as a set of 'enhancements' in the system you build. That shouldn't even be very hard to keep up to date w/ Bruce's todo list provided you watch for his commits to it on the CVS mailing list. Then, if people decide to use your system to open up new enhancement requests you can forward them on to the appropriate list/people and if it makes it onto Bruce's 'todo' list then some how mark it as 'approved' or something to distinguish it from stuff that's been suggested/asked for that *doesn't* make it on the list (and thus is unlikely to be done or worked on). Having the list of stuff that didn't make it would actually be useful and is something Bruce's list misses and thus would be a valuable addition (imv) you would be providing. Now, generally the way this kind of stuff works is that someone gets bitten by a bug and just decides this would be useful and just *does* it w/o asking permission or getting approval from anyone. When people just ask permission or nebulously volunteer their time towards it, generally it *doesn't* happen. Just my 2c. Stephen signature.asc Description: Digital signature
