Thread: pgFoundry Download URLs
Howdy, I recently noticed that Devrim added pgTAP to his RPMs: https://projects.commandprompt.com/public/pgcore/changeset/1021 I'm pleased about this, of course, but I couldn't help noticing that the URL he's forced to use is rather…unfortunate. https://projects.commandprompt.com/public/pgcore/browser/rpm/redhat/8.4/pgtap/F-11/pgtap.spec?rev=1021 See the "2316" in the URL? This is the URL that pgFoundry creates for downloads. Every single download on the site has uniqueID like this. This makes it possible for a project to predict URLs in advance of a release. This is not good. What would be required to make that go away? IOW, I'm asking, how can we have URLs like this: http://pgfoundry.org/frs/download.php/pgtap-0.23.tar.gz Instead of this? http://pgfoundry.org/frs/download.php/2512/pgtap-0.23.tar.gz If there is a better list for this inquiry, please do let me know. Thanks, David
On Sat, Dec 26, 2009 at 5:43 PM, David E. Wheeler <david@justatheory.com> wrote: > https://projects.commandprompt.com/public/pgcore/browser/rpm/redhat/8.4/pgtap/F-11/pgtap.spec?rev=1021 > > See the "2316" in the URL? No. :-) ...Robert
On Dec 26, 2009, at 4:42 PM, Robert Haas wrote: >> https://projects.commandprompt.com/public/pgcore/browser/rpm/redhat/8.4/pgtap/F-11/pgtap.spec?rev=1021 >> >> See the "2316" in the URL? > > No. :-) Click the URL to see the pgtap.spec file, which has the download URL in it. D
On Sat, Dec 26, 2009 at 7:44 PM, David E. Wheeler <david@justatheory.com> wrote: > On Dec 26, 2009, at 4:42 PM, Robert Haas wrote: > >>> https://projects.commandprompt.com/public/pgcore/browser/rpm/redhat/8.4/pgtap/F-11/pgtap.spec?rev=1021 >>> >>> See the "2316" in the URL? >> >> No. :-) > > Click the URL to see the pgtap.spec file, which has the download URL in it. Oh. I see now. Heh... ...Robert
2009/12/27 Robert Haas <robertmhaas@gmail.com>: > On Sat, Dec 26, 2009 at 7:44 PM, David E. Wheeler <david@justatheory.com> wrote: >> On Dec 26, 2009, at 4:42 PM, Robert Haas wrote: >> >>>> https://projects.commandprompt.com/public/pgcore/browser/rpm/redhat/8.4/pgtap/F-11/pgtap.spec?rev=1021 >>>> >>>> See the "2316" in the URL? >>> >>> No. :-) >> >> Click the URL to see the pgtap.spec file, which has the download URL in it. > > Oh. I see now. Heh... And the answer is unfortunately, no, there is no way around that unless you want to start hacking the gforge code. And if you want to do that, you can start by upgrading it :-p -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
2009/12/27 Dave Page <dpage@pgadmin.org>: > 2009/12/27 Robert Haas <robertmhaas@gmail.com>: >> On Sat, Dec 26, 2009 at 7:44 PM, David E. Wheeler <david@justatheory.com> wrote: >>> On Dec 26, 2009, at 4:42 PM, Robert Haas wrote: >>> >>>>> https://projects.commandprompt.com/public/pgcore/browser/rpm/redhat/8.4/pgtap/F-11/pgtap.spec?rev=1021 >>>>> >>>>> See the "2316" in the URL? >>>> >>>> No. :-) >>> >>> Click the URL to see the pgtap.spec file, which has the download URL in it. >> >> Oh. I see now. Heh... > > And the answer is unfortunately, no, there is no way around that > unless you want to start hacking the gforge code. And if you want to > do that, you can start by upgrading it :-p You can always use the mirror network to download the file, instead of going to the pgfoundry site itself, no? See: http://www.postgresql.org/ftp/projects/pgFoundry/pgtap/ Which will give you download URLs. You can also point directly to a mirror either through the redirection service (http://wwwmaster.postgresql.org/redir/155/h/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz for example, where 155 is the mirror id of one of the swedish mirrors), or directly at a single mirror. If it would help we can easily add a mirror redirector specifically for automatic downloads that will just throw you to a random mirror. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sun, Dec 27, 2009 at 10:14 AM, Magnus Hagander <magnus@hagander.net> wrote: > You can always use the mirror network to download the file, instead of > going to the pgfoundry site itself, no? See: > http://www.postgresql.org/ftp/projects/pgFoundry/pgtap/ That's not going to work in a spec file. > Which will give you download URLs. You can also point directly to a > mirror either through the redirection service > (http://wwwmaster.postgresql.org/redir/155/h/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > for example, where 155 is the mirror id of one of the swedish > mirrors), or directly at a single mirror. If it would help we can > easily add a mirror redirector specifically for automatic downloads > that will just throw you to a random mirror. That would, if you're satisfied that the mirror you choose is reliable and doesn't get removed from the network when you aren't looking. Probably the best bet would be ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Sun, 2009-12-27 at 09:12 +0000, Dave Page wrote: > And the answer is unfortunately, no, there is no way around that > unless you want to start hacking the gforge code. And if you want to > do that, you can start by upgrading it :-p Probably adding a feature like RAC to PostgreSQL is easier than upgrading GForge. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
David E. Wheeler wrote: > See the "2316" in the URL? This is the URL that pgFoundry creates for downloads. Every single download on the site hasunique ID like this. This makes it possible for a project to predict URLs in advance of a release. This is not good. > Why is that not good? If you want a unique namespace for each file set published by every project, you have to tag them with a unique prefix, and a numeric one is as good as any. In any case, given that you can bundle the .tar.gz source file with the source RPM, linking directly to the source there is an optional shortcut anyway. You'd need to have a pretty serious objection to justify changing something here, and I'm not even sure what you don't like. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Dec 27, 2009, at 2:50 AM, Dave Page wrote: > That would, if you're satisfied that the mirror you choose is reliable > and doesn't get removed from the network when you aren't looking. > > Probably the best bet would be > ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz That's fine with me. There isn't an http link, is there? Devrim, would it make sense to update pgtap.spec to point to that URL? Best, David
On Dec 27, 2009, at 4:30 AM, Devrim GÜNDÜZ wrote: >> And the answer is unfortunately, no, there is no way around that >> unless you want to start hacking the gforge code. And if you want to >> do that, you can start by upgrading it :-p > > Probably adding a feature like RAC to PostgreSQL is easier than > upgrading GForge. Oracle Real Application Clusters? David
2009/12/27 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Sun, 2009-12-27 at 09:12 +0000, Dave Page wrote: >> And the answer is unfortunately, no, there is no way around that >> unless you want to start hacking the gforge code. And if you want to >> do that, you can start by upgrading it :-p > > Probably adding a feature like RAC to PostgreSQL is easier than > upgrading GForge. Are you offering? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Dec 27, 2009, at 2:14 AM, Magnus Hagander wrote: > Which will give you download URLs. You can also point directly to a > mirror either through the redirection service > (http://wwwmaster.postgresql.org/redir/155/h/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > for example, where 155 is the mirror id of one of the swedish > mirrors), or directly at a single mirror. If it would help we can > easily add a mirror redirector specifically for automatic downloads > that will just throw you to a random mirror. Might be a good idea. I assume that would work for all pgFoundry projects? Best, David
On Dec 27, 2009, at 5:51 AM, Greg Smith wrote: > Why is that not good? If you want a unique namespace for each file set published by every project, you have to tag themwith a unique prefix, and a numeric one is as good as any. I don't want a unique namespace. The file name includes the version number and therefore is unique enough. > In any case, given that you can bundle the .tar.gz source file with the source RPM, linking directly to the source thereis an optional shortcut anyway. You'd need to have a pretty serious objection to justify changing something here, andI'm not even sure what you don't like. That's something for Devrim to consider. But for the pgtap.spec that's included in pgTAP itself, I need to have a stable,predictable URL to use. Best, David
2009/12/27 David E. Wheeler <david@justatheory.com>: > On Dec 27, 2009, at 2:14 AM, Magnus Hagander wrote: > >> Which will give you download URLs. You can also point directly to a >> mirror either through the redirection service >> (http://wwwmaster.postgresql.org/redir/155/h/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz >> for example, where 155 is the mirror id of one of the swedish >> mirrors), or directly at a single mirror. If it would help we can >> easily add a mirror redirector specifically for automatic downloads >> that will just throw you to a random mirror. > > Might be a good idea. I assume that would work for all pgFoundry projects? Yeha, they're all mirrored to the ftp network. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sun, 2009-12-27 at 10:50 +0000, Dave Page wrote: > Probably the best bet would be > ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > This will save some time while updating my specs... Nice. BTW, is it possible to grant HTTP access to FTP repository? Regards, -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Sun, 2009-12-27 at 08:22 -0800, David E. Wheeler wrote: > > > ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > > That's fine with me. There isn't an http link, is there? > > Devrim, would it make sense to update pgtap.spec to point to that URL? Yeah, I will do it in next set of updates. Thanks, -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Sun, 2009-12-27 at 08:22 -0800, David E. Wheeler wrote: > > Probably adding a feature like RAC to PostgreSQL is easier than > > upgrading GForge. > > Oracle Real Application Clusters? Yeah:) -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Sun, 2009-12-27 at 17:38 +0000, Dave Page wrote: > > Probably adding a feature like RAC to PostgreSQL is easier than > > upgrading GForge. > > Are you offering? Working on RAC? No :P. Upgrading GForge? Probably not. I know how many people tried it before. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Dec 27, 2009, at 1:12 AM, Dave Page wrote: > And the answer is unfortunately, no, there is no way around that > unless you want to start hacking the gforge code. And if you want to > do that, you can start by upgrading it :-p Since that doesn't seem to be likely to happen anytime soon, and indeed there are folks who want to kill pgFoundry, I'm consideringmoving my project elsewhere. The only hesitation I have is that then pgTAP will not be visible on any PostgreSQL-orientedcommunity site. I know that when I release a Perl module to CPAN that it will be visible to lots of people in the Perl community, and automaticallysearchable via search.cpan.org and other tools. A CPAN release is a release to the Perl community. There is nothing like this for PostgreSQL. pgFoundry is the closest thing, and, frankly, nowhere near as good (pgFoundry'ssearch rankings have always stunk). So if I were to remove my projects from pgFoundry, how could I make themvisible to the community? Is there any other central repository of or searchable list of third-party PostgreSQL offerings? Thanks, David
2009/12/27 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Sun, 2009-12-27 at 17:38 +0000, Dave Page wrote: >> > Probably adding a feature like RAC to PostgreSQL is easier than >> > upgrading GForge. >> >> Are you offering? > > Working on RAC? No :P. > > Upgrading GForge? Probably not. I know how many people tried it before. Not that I'm necessarily volunteering to do anything whatsoever, but would someone be willing to point me in the direction of, and/or give me access to, whatever I would need to understand the scope of this apparently intractable problem? ...Robert
On Mon, Dec 28, 2009 at 1:14 AM, David E. Wheeler <david@justatheory.com> wrote: > Is there any other central repository of or searchable list of third-party PostgreSQL offerings? http://www.postgresql.org/download/product-categories -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
2009/12/28 Robert Haas <robertmhaas@gmail.com>: > 2009/12/27 Devrim GÜNDÜZ <devrim@gunduz.org>: >> On Sun, 2009-12-27 at 17:38 +0000, Dave Page wrote: >>> > Probably adding a feature like RAC to PostgreSQL is easier than >>> > upgrading GForge. >>> >>> Are you offering? >> >> Working on RAC? No :P. >> >> Upgrading GForge? Probably not. I know how many people tried it before. > > Not that I'm necessarily volunteering to do anything whatsoever, but > would someone be willing to point me in the direction of, and/or give > me access to, whatever I would need to understand the scope of this > apparently intractable problem? Not sure what I'd point you too. A large part of the problem is that the original installation of GForge was hacked about to a) run on FreeBSD and b) add some features/bells 'n' whistles, but whoever did it, didn't document it. A) is not really an issue - we can move to Linux, but we will need a proper migration plan for the user accounts of course. B) is potentially more of an issue. Guillaume Smet did perform an initial migration (http://takara.postgresql.org/) on FreeBSD, which has stalled, largely due to lack of spare time I think. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page wrote: > 2009/12/28 Robert Haas <robertmhaas@gmail.com>: >> 2009/12/27 Devrim GÜNDÜZ <devrim@gunduz.org>: >>> On Sun, 2009-12-27 at 17:38 +0000, Dave Page wrote: >>>>> Probably adding a feature like RAC to PostgreSQL is easier than >>>>> upgrading GForge. >>>> Are you offering? >>> Working on RAC? No :P. >>> >>> Upgrading GForge? Probably not. I know how many people tried it before. >> Not that I'm necessarily volunteering to do anything whatsoever, but >> would someone be willing to point me in the direction of, and/or give >> me access to, whatever I would need to understand the scope of this >> apparently intractable problem? > > Not sure what I'd point you too. A large part of the problem is that > the original installation of GForge was hacked about to a) run on > FreeBSD and b) add some features/bells 'n' whistles, but whoever did > it, didn't document it. > > A) is not really an issue - we can move to Linux, but we will need a > proper migration plan for the user accounts of course. yeah > > B) is potentially more of an issue. > > Guillaume Smet did perform an initial migration > (http://takara.postgresql.org/) on FreeBSD, which has stalled, largely > due to lack of spare time I think. note that despite what people claim usually our pgfoundry code is only marginally modified ( two or three things to make it work better on freebsd and some manual backports for security issues). The main issue is just that upgrading is simply a large amount of work that needs a concerted effort from a few of us. Stefan
2009/12/28 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: > Dave Page wrote: >> Guillaume Smet did perform an initial migration >> (http://takara.postgresql.org/) on FreeBSD, which has stalled, largely >> due to lack of spare time I think. Yes. I apologize for that. I'm stuck on a large project for 7 months now and I don't have any free cycle. AFAICS, the project is likely to end in one month or so. It's my top priority task as soon as I get some spare cycles back. > note that despite what people claim usually our pgfoundry code is only > marginally modified ( two or three things to make it work better on freebsd > and some manual backports for security issues). I confirm. The version on takara has all the specific patches backported and it's really minor (mostly system related and I'm going to document them). > The main issue is just that upgrading is simply a large amount of work that > needs a concerted effort from a few of us. Yup. I could have managed all the migration myself in a RH environment but I'm not FreeBSD fluent and I don't have any time to invest in a system environment I'm not familiar with. The current status is that most of the software stuff is done. But we need to work on the system part and on the migration path. -- Guillaume
On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage@pgadmin.org> wrote: > Probably the best bet would be > ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz Unfortunately, it's not. All these paths are going to change during the migration as files aren't organized in the same way in newer versions of GForge/FusionForge (newer as in more recent than january 2005)... I concur that it's a pain for RPM packaging (especially when your spec file is inside your tarball). -- Guillaume
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Probably the best bet would be >> ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > Unfortunately, it's not. > All these paths are going to change during the migration as files > aren't organized in the same way in newer versions of > GForge/FusionForge (newer as in more recent than january 2005)... Wow, strike another blow against gforge, eh? Still, isn't this easily solved by an Apache redirect rule? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 200912280652 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAks4nB4ACgkQvJuQZxSWSsgJswCfSOakoiXAC9x407T0i2dkJX6o qNYAoJ20MxtkdDzpkfp5KMnseS9ubqmv =JJzX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Robert Hass wrote: > Not that I'm necessarily volunteering to do anything whatsoever, but > would someone be willing to point me in the direction of, and/or give > me access to, whatever I would need to understand the scope of this > apparently intractable problem? Not intractable so much as a very high ratio of amount of work to tangible results. To put another way, almost everyone has more important things to work on. Frankly, that would include you as well. As you are a new committer, I'd hate to see you spend time on the pgf mess. :) - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 200912280655 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAks4nPcACgkQvJuQZxSWSsiaEwCdHEVlBMpVL8UHddemLHIBr6t3 UKsAnRoaGLA4LdB/iGDlh1mcycFEiuKA =7a9d -----END PGP SIGNATURE-----
On Mon, Dec 28, 2009 at 12:53 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: > Wow, strike another blow against gforge, eh? The current URIs published on GForge/FusionForge are stable. It's just the internal filesystem organization which changes in 2005 so it's not a GForge/FusionForge problem by itself. > Still, isn't this > easily solved by an Apache redirect rule? No. The old filesystem organization is: $projectname/$filename The new one is: $projectname/$package/$release/$filename IIRC, the reason of this change is that a few people wanted to be able to publish a file with the same name in different packages/releases. NB: the problem is only if you want to use the filesystem organization as an URI. It's not recommended. -- Guillaume
On Mon, Dec 28, 2009 at 12:56 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: > Not intractable so much as a very high ratio of amount of work to > tangible results. To put another way, almost everyone has more > important things to work on. Frankly, that would include you as well. > As you are a new committer, I'd hate to see you spend time on the > pgf mess. :) As already mentioned by Stefan, it's far from being a mess. And what's currently needed is some spare time from me and from one person of the sysadmin team to work on the migration path and migrate the service. I wasn't able to dedicate time to PostgreSQL stuff for a long time now (I only made a brief exception for pgday.eu). It's going to change very soon. -- Guillaume
On Dec 28, 2009, at 1:05 AM, Dave Page wrote: >> Is there any other central repository of or searchable list of third-party PostgreSQL offerings? > > http://www.postgresql.org/download/product-categories Wow. Not very useful. Hard to read, you need to know what category of thing you're looking for, and no search. :-( David
On Dec 28, 2009, at 2:52 AM, Guillaume Smet wrote: > On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage@pgadmin.org> wrote: >> Probably the best bet would be >> ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > > Unfortunately, it's not. > > All these paths are going to change during the migration as files > aren't organized in the same way in newer versions of > GForge/FusionForge (newer as in more recent than january 2005)... And that will affect mirroring URLs? Will the old URLs stop working? > I concur that it's a pain for RPM packaging (especially when your spec > file is inside your tarball). Yes. Best, David
On Mon, Dec 28, 2009 at 10:52 AM, Guillaume Smet <guillaume.smet@gmail.com> wrote: > On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage@pgadmin.org> wrote: >> Probably the best bet would be >> ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > > Unfortunately, it's not. > > All these paths are going to change during the migration as files > aren't organized in the same way in newer versions of > GForge/FusionForge (newer as in more recent than january 2005)... That's really not a option. Wholesale reorganisation of the FTP will cause a world of pain for people with scripts such as Devrim's. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Dec 28, 2009 at 6:42 PM, David E. Wheeler <david@justatheory.com> wrote: > On Dec 28, 2009, at 1:05 AM, Dave Page wrote: > >>> Is there any other central repository of or searchable list of third-party PostgreSQL offerings? >> >> http://www.postgresql.org/download/product-categories > > Wow. Not very useful. Hard to read, you need to know what category of thing you're looking for, and no search. :-( Well it's a shedload better than what we did have. Feel free to propose and implement improvements. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, 2009-12-28 at 19:13 +0000, Dave Page wrote: > On Mon, Dec 28, 2009 at 10:52 AM, Guillaume Smet > <guillaume.smet@gmail.com> wrote: > > On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage@pgadmin.org> wrote: > >> Probably the best bet would be > >> ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > > > > Unfortunately, it's not. > > > > All these paths are going to change during the migration as files > > aren't organized in the same way in newer versions of > > GForge/FusionForge (newer as in more recent than january 2005)... > > That's really not a option. Wholesale reorganisation of the FTP will > cause a world of pain for people with scripts such as Devrim's. The user experience is quite a bit more important than people with scripts such as Devrim's. If we are going to offer the service we should do so in a manner that is useful and productive to the consumers of that service. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Mon, 2009-12-28 at 19:15 +0000, Dave Page wrote: > On Mon, Dec 28, 2009 at 6:42 PM, David E. Wheeler <david@justatheory.com> wrote: > > On Dec 28, 2009, at 1:05 AM, Dave Page wrote: > > > >>> Is there any other central repository of or searchable list of third-party PostgreSQL offerings? > >> > >> http://www.postgresql.org/download/product-categories > > > > Wow. Not very useful. Hard to read, you need to know what category of thing you're looking for, and no search. :-( > > Well it's a shedload better than what we did have. Feel free to > propose and implement improvements. That is true. Unfortunately we are back to the "need a cpan/pypy" for PostgreSQL. Sigh. Joshua D. Drake > > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: > The user experience is quite a bit more important than people with > scripts such as Devrim's. If we are going to offer the service we should > do so in a manner that is useful and productive to the consumers of that > service. That includes scriptability, so that third parties can build services on top of it. Best, David
On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: > On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: > > > The user experience is quite a bit more important than people with > > scripts such as Devrim's. If we are going to offer the service we should > > do so in a manner that is useful and productive to the consumers of that > > service. > > That includes scriptability, so that third parties can build services on top of it. Certainly. I am just saying that if we have 20 people it will negatively impact and 20,000 it will positively impact.. the 20 people need to suck it up. JD > > Best, > > David -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Mon, Dec 28, 2009 at 7:24 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On Mon, 2009-12-28 at 19:15 +0000, Dave Page wrote: >> On Mon, Dec 28, 2009 at 6:42 PM, David E. Wheeler <david@justatheory.com> wrote: >> > On Dec 28, 2009, at 1:05 AM, Dave Page wrote: >> > >> >>> Is there any other central repository of or searchable list of third-party PostgreSQL offerings? >> >> >> >> http://www.postgresql.org/download/product-categories >> > >> > Wow. Not very useful. Hard to read, you need to know what category of thing you're looking for, and no search. :-( >> >> Well it's a shedload better than what we did have. Feel free to >> propose and implement improvements. > > That is true. Unfortunately we are back to the "need a cpan/pypy" for > PostgreSQL. That really doesn't help, as the software catalog contains everything from drivers, to native applications, web apps, commercial stuff and more. It's far from limited to 'code modules' that could be managed with a cpan-type system. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Dec 28, 2009 at 8:13 PM, Dave Page <dpage@pgadmin.org> wrote: > That's really not a option. Wholesale reorganisation of the FTP will > cause a world of pain for people with scripts such as Devrim's. Could you elaborate on these scripts? What do they do and what are they used for? IIRC, Devrim doesn't use the mirror URI for his pgFoundry RPM packages. The mirror exposes the internal structure of the file repository of GForge. It's really a matter of interface in the OO programming way. This method is private and they decided to change the implementation a long time ago, the public method to access the files haven't changed and is stable. If we really want it, we can decide to keep the old structure but we may have problems from time to time if people want to upload a file with the same name in another release/package (and it's one more patch). -- Guillaume
On Dec 28, 2009, at 11:44 AM, Joshua D. Drake wrote: >> That includes scriptability, so that third parties can build services on top of it. > > Certainly. I am just saying that if we have 20 people it will negatively > impact and 20,000 it will positively impact.. the 20 people need to suck > it up. You're getting ahead of yourself. I agree with you in principal, but no one has said we face that kind of question just yet.I mean, work is not being done at this time. Best, David
On Mon, Dec 28, 2009 at 7:52 PM, Guillaume Smet <guillaume.smet@gmail.com> wrote: > On Mon, Dec 28, 2009 at 8:13 PM, Dave Page <dpage@pgadmin.org> wrote: >> That's really not a option. Wholesale reorganisation of the FTP will >> cause a world of pain for people with scripts such as Devrim's. > > Could you elaborate on these scripts? What do they do and what are > they used for? IIRC, Devrim doesn't use the mirror URI for his > pgFoundry RPM packages. Well, anyone with build scripts that access stuff on the pgfoundry directory hierarchy. We simply don't know how many people it might affect, any more than some changes we might make in the server where we go out of our way to maintain compatibility. > The mirror exposes the internal structure of the file repository of > GForge. It's really a matter of interface in the OO programming way. > This method is private and they decided to change the implementation a > long time ago, the public method to access the files haven't changed > and is stable. > > If we really want it, we can decide to keep the old structure but we > may have problems from time to time if people want to upload a file > with the same name in another release/package (and it's one more > patch). We mirrored the internal structure (and then moved a bunch of downloads so they didn't point to pgfoundry) because gforge was a bottleneck for things like installers which can clock up tens of thousands of downloads per week. I don't recall anyone ever complaining that they couldn't have multiple files with the same name on pgFoundry (frankly, it sounds like a recipe for disaster), but I can envisage the structure change causing pain for people. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Mon, Dec 28, 2009 at 9:04 PM, Dave Page <dpage@pgadmin.org> wrote: > We mirrored the internal structure (and then moved a bunch of > downloads so they didn't point to pgfoundry) because gforge was a > bottleneck for things like installers which can clock up tens of > thousands of downloads per week. > > I don't recall anyone ever complaining that they couldn't have > multiple files with the same name on pgFoundry (frankly, it sounds > like a recipe for disaster), but I can envisage the structure change > causing pain for people. We can keep the old behaviour if people accept the limitation and agree that we should patch FusionForge for it. And if we do so, we can also change the public URI to be static (and keep the old ones in parallel, of course). -- Guillaume
On Dec 28, 2009, at 1:02 PM, Guillaume Smet wrote: > We can keep the old behaviour if people accept the limitation and > agree that we should patch FusionForge for it. > > And if we do so, we can also change the public URI to be static (and > keep the old ones in parallel, of course). +1 David
On Mon, 2009-12-28 at 19:13 +0000, Dave Page wrote: > On Mon, Dec 28, 2009 at 10:52 AM, Guillaume Smet > <guillaume.smet@gmail.com> wrote: > > On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage@pgadmin.org> wrote: > >> Probably the best bet would be > >> ftp://ftp.postgresql.org/pub/projects/pgFoundry/pgtap/pgtap-0.23.tar.gz > > > > Unfortunately, it's not. > > > > All these paths are going to change during the migration as files > > aren't organized in the same way in newer versions of > > GForge/FusionForge (newer as in more recent than january 2005)... > > That's really not a option. Wholesale reorganisation of the FTP will > cause a world of pain for people with scripts such as Devrim's. The user experience is quite a bit more important than people with scripts such as Devrim's. If we are going to offer the service we should do so in a manner that is useful and productive to the consumers of that service. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Mon, 2009-12-28 at 19:15 +0000, Dave Page wrote: > On Mon, Dec 28, 2009 at 6:42 PM, David E. Wheeler <david@justatheory.com> wrote: > > On Dec 28, 2009, at 1:05 AM, Dave Page wrote: > > > >>> Is there any other central repository of or searchable list of third-party PostgreSQL offerings? > >> > >> http://www.postgresql.org/download/product-categories > > > > Wow. Not very useful. Hard to read, you need to know what category of thing you're looking for, and no search. :-( > > Well it's a shedload better than what we did have. Feel free to > propose and implement improvements. That is true. Unfortunately we are back to the "need a cpan/pypy" for PostgreSQL. Sigh. Joshua D. Drake > > -- > Dave Page > EnterpriseDB UK: http://www.enterprisedb.com > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: > On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: > > > The user experience is quite a bit more important than people with > > scripts such as Devrim's. If we are going to offer the service we should > > do so in a manner that is useful and productive to the consumers of that > > service. > > That includes scriptability, so that third parties can build services on top of it. Certainly. I am just saying that if we have 20 people it will negatively impact and 20,000 it will positively impact.. the 20 people need to suck it up. JD > > Best, > > David -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: >> On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: >> >> > The user experience is quite a bit more important than people with >> > scripts such as Devrim's. If we are going to offer the service we should >> > do so in a manner that is useful and productive to the consumers of that >> > service. >> >> That includes scriptability, so that third parties can build services on top of it. > > Certainly. I am just saying that if we have 20 people it will negatively > impact and 20,000 it will positively impact.. the 20 people need to suck > it up. Presumably the packages that rely on the existing URLs are actually being used by large numbers of end-users, who will all be sad if they break. ...Robert
Robert Haas wrote: > On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: >>> On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: >>> >>>> The user experience is quite a bit more important than people with >>>> scripts such as Devrim's. If we are going to offer the service we should >>>> do so in a manner that is useful and productive to the consumers of that >>>> service. >>> That includes scriptability, so that third parties can build services on top of it. >> Certainly. I am just saying that if we have 20 people it will negatively >> impact and 20,000 it will positively impact.. the 20 people need to suck >> it up. > > Presumably the packages that rely on the existing URLs are actually > being used by large numbers of end-users, who will all be sad if they > break. I might be wrong but I don't think we have that many users that are regulary rebuilding rpms from source with the original tar.gz being on pgfoundry... Stefan
2009/12/29 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: > Robert Haas wrote: >> >> On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >>> >>> On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: >>>> >>>> On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: >>>> >>>>> The user experience is quite a bit more important than people with >>>>> scripts such as Devrim's. If we are going to offer the service we should >>>>> do so in a manner that is useful and productive to the consumers of that >>>>> service. >>>> >>>> That includes scriptability, so that third parties can build services on top of it. >>> >>> Certainly. I am just saying that if we have 20 people it will negatively >>> impact and 20,000 it will positively impact.. the 20 people need to suck >>> it up. >> >> Presumably the packages that rely on the existing URLs are actually >> being used by large numbers of end-users, who will all be sad if they >> break. > > I might be wrong but I don't think we have that many users that are regulary rebuilding rpms from source with the originaltar.gz being on pgfoundry... Well, the big users would be Devrim (RPMs) and I guess whomever does debian packages of the things. But there are quite a number of companies that build their own RPMs, either completely on their own or off slightly modified specs. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > 2009/12/29 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: >> Robert Haas wrote: >>> On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >>>> On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: >>>>> On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: >>>>> >>>>>> The user experience is quite a bit more important than people with >>>>>> scripts such as Devrim's. If we are going to offer the service we should >>>>>> do so in a manner that is useful and productive to the consumers of that >>>>>> service. >>>>> That includes scriptability, so that third parties can build services on top of it. >>>> Certainly. I am just saying that if we have 20 people it will negatively >>>> impact and 20,000 it will positively impact.. the 20 people need to suck >>>> it up. >>> Presumably the packages that rely on the existing URLs are actually >>> being used by large numbers of end-users, who will all be sad if they >>> break. >> I might be wrong but I don't think we have that many users that are regulary rebuilding rpms from source with the originaltar.gz being on pgfoundry... > > Well, the big users would be Devrim (RPMs) and I guess whomever does > debian packages of the things. > > But there are quite a number of companies that build their own RPMs, > either completely on their own or off slightly modified specs. well yeah but that might sum up to a dozends of people that will have to wit for an updated spec file vs. we having to hack up fusionforge code and have it maintained over years... Stefan
On Tue, Dec 29, 2009 at 12:05 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > well yeah but that might sum up to a dozends of people that will have to wit > for an updated spec file vs. we having to hack up fusionforge code and have > it maintained over years... IIRC, Devrim uses the public URIs in his spec files (e.g. the download.php/id/file URI). The real problem is the mirrors and whoever uses the URIs provided by the mirrors (see a previous email of Dave about this). -- Guillaume
On Tue, 2009-12-29 at 11:59 +0100, Magnus Hagander wrote: > > I might be wrong but I don't think we have that many users that are > regulary rebuilding rpms from source with the original tar.gz being on > pgfoundry... > > Well, the big users would be Devrim (RPMs) and I guess whomever does > debian packages of the things. Right. Because of the nature of build system, my build scripts download up to 50 copies of each tarball :) -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Devrim GÜNDÜZ escribió: > On Tue, 2009-12-29 at 11:59 +0100, Magnus Hagander wrote: > > > > I might be wrong but I don't think we have that many users that are > > regulary rebuilding rpms from source with the original tar.gz being on > > pgfoundry... > > > > Well, the big users would be Devrim (RPMs) and I guess whomever does > > debian packages of the things. > > Right. Because of the nature of build system, my build scripts download > up to 50 copies of each tarball :) I don't understand how this is a problem. For each new release Devrim needs to update the URL in the SPEC file anyway, due to the way the URLs are namespaced with the silly numeric ID, no? Which is exactly what David is complaining about. How would this be different? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Devrim GÜNDÜZ escribió: >> On Tue, 2009-12-29 at 11:59 +0100, Magnus Hagander wrote: >> >>>> I might be wrong but I don't think we have that many users that are >>> regulary rebuilding rpms from source with the original tar.gz being on >>> pgfoundry... >>> >>> Well, the big users would be Devrim (RPMs) and I guess whomever does >>> debian packages of the things. >> Right. Because of the nature of build system, my build scripts download >> up to 50 copies of each tarball :) > > I don't understand how this is a problem. For each new release Devrim > needs to update the URL in the SPEC file anyway, due to the way the URLs > are namespaced with the silly numeric ID, no? Which is exactly what > David is complaining about. How would this be different? it's not only what some here call the "silly numeric id" - if there is a new release you will have to adjust to the new filename as well so I really don't see the problem here. Stefan
On Dec 29, 2009, at 6:39 AM, Stefan Kaltenbrunner wrote: > it's not only what some here call the "silly numeric id" - if there is a new release you will have to adjust to the newfilename as well so I really don't see the problem here. In general, the only thing you need to update is the version number. For example, I have this script for installing pgtop: #!/bin/bash export VERSION=3.6.2 . `dirname $0`/functions.sh setup /usr/local/bin/pg_top download http://pgfoundry.org/frs/download.php/1770/pg_top-$VERSION.tar.bz2 build pg_top-$VERSION Whenever I seen an announcement for a new version of pg_top, I can just update the version number in this script and runit to get the new one. Except I can't. Because it has that fucking ID in it. So instead I have to go to the download page for pg_top (if I can findit), then find the URL for the new version, find the ID in that URL, then update my script. *Then* I can run it again. This, my friends, sucks. It sucks hard. The ID serves no valid purpose aside from allowing one to upload two files with thesame file name. And who really cares about that anyway? Don't these people use file systems? Crimony. Even worse is projects like pgTAP include a .spec file in the distribution. But I can't have an accurate URL in the .specfile until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it againwith the proper URL, but then it'd have *another* fucking ID. I can't win. So having an alternate URL, such as the ftp URL that Dave mentioned a few days ago, is a fine workaround for this issue.With that, pgFoundry can have any URL it wants for its downloads, and I won't care because I won't use them. But if the mirrored FTP URLs are unreliable or subject to change with a new version of pgFoundry/KForge/whatever, then manyexisting applications will likely be screwed. Best, David
On Tue, Dec 29, 2009 at 6:05 AM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > Magnus Hagander wrote: >> >> 2009/12/29 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: >>> >>> Robert Haas wrote: >>>> >>>> On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd@commandprompt.com> >>>> wrote: >>>>> >>>>> On Mon, 2009-12-28 at 11:42 -0800, David E. Wheeler wrote: >>>>>> >>>>>> On Dec 28, 2009, at 11:23 AM, Joshua D. Drake wrote: >>>>>> >>>>>>> The user experience is quite a bit more important than people with >>>>>>> scripts such as Devrim's. If we are going to offer the service we >>>>>>> should >>>>>>> do so in a manner that is useful and productive to the consumers of >>>>>>> that >>>>>>> service. >>>>>> >>>>>> That includes scriptability, so that third parties can build services >>>>>> on top of it. >>>>> >>>>> Certainly. I am just saying that if we have 20 people it will >>>>> negatively >>>>> impact and 20,000 it will positively impact.. the 20 people need to >>>>> suck >>>>> it up. >>>> >>>> Presumably the packages that rely on the existing URLs are actually >>>> being used by large numbers of end-users, who will all be sad if they >>>> break. >>> >>> I might be wrong but I don't think we have that many users that are >>> regulary rebuilding rpms from source with the original tar.gz being on >>> pgfoundry... >> >> Well, the big users would be Devrim (RPMs) and I guess whomever does >> debian packages of the things. >> >> But there are quite a number of companies that build their own RPMs, >> either completely on their own or off slightly modified specs. > > well yeah but that might sum up to a dozends of people that will have to wit > for an updated spec file vs. we having to hack up fusionforge code and have > it maintained over years... I can't speak to the maintenance effort but I wouldn't dismiss the problem too lightly. I rebuild RPMs from source not infrequently - it is often the case that the source RPM is a great deal more portable than the binary RPM. ...Robert
On Tue, Dec 29, 2009 at 3:17 PM, David E. Wheeler <david@justatheory.com> wrote: > Even worse is projects like pgTAP include a .spec file in the distribution. But I can't have an accurate URL in the .specfile until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it againwith the proper URL, but then it'd have *another* fucking ID. I can't win. I realize this isn't funny at all, but I'm LMAO reading it... what a pain in the tail. ...Robert
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Dec 29, 2009 at 3:17 PM, David E. Wheeler <david@justatheory.com> wrote:
>> Even worse is projects like pgTAP include a .spec file in the distribution. But I can't have an accurate URL in the
.specfile until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it
againwith the proper URL, but then it'd have *another* fucking ID. I can't win.
> I realize this isn't funny at all, but I'm LMAO reading it... what a
> pain in the tail.
The notion that spec files can be expected to have an exact URL for a
source file is one of the sillier flights of fancy that I've had to deal
with in my time packaging stuff for Red Hat/Fedora. There are way too
many sites with way too many creative notions about making you click
here or redirecting your click to some mirror-of-the-moment. What would
be a sane design is to have a URL for a page where a human could be
expected to look to find the file to be downloaded. I'd say less than
half of my RH packages actually have wget-able URLs in the Source:
lines. The rest require a certain amount of interpretation.
Which is not to say that it wouldn't be nice if pgfoundry were
better-than-average on this point. But it's not worse than average;
it's right in line with the generally abysmal state of persistent URIs.
regards, tom lane
2009/12/29 Tom Lane <tgl@sss.pgh.pa.us>: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Dec 29, 2009 at 3:17 PM, David E. Wheeler <david@justatheory.com> wrote: >>> Even worse is projects like pgTAP include a .spec file in the distribution. But I can't have an accurate URL in the .specfile until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it againwith the proper URL, but then it'd have *another* fucking ID. I can't win. > >> I realize this isn't funny at all, but I'm LMAO reading it... what a >> pain in the tail. > > The notion that spec files can be expected to have an exact URL for a > source file is one of the sillier flights of fancy that I've had to deal > with in my time packaging stuff for Red Hat/Fedora. There are way too > many sites with way too many creative notions about making you click > here or redirecting your click to some mirror-of-the-moment. What would > be a sane design is to have a URL for a page where a human could be > expected to look to find the file to be downloaded. I'd say less than > half of my RH packages actually have wget-able URLs in the Source: > lines. The rest require a certain amount of interpretation. > > Which is not to say that it wouldn't be nice if pgfoundry were > better-than-average on this point. But it's not worse than average; > it's right in line with the generally abysmal state of persistent URIs. Awesome. :-( ...Robert
On Dec 29, 2009, at 8:51 PM, Tom Lane wrote: > Which is not to say that it wouldn't be nice if pgfoundry were > better-than-average on this point. But it's not worse than average; > it's right in line with the generally abysmal state of persistent URIs. What an endorsement. Please, can it at least suck less? Best, David
On Tue, Dec 29, 2009 at 11:05 AM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > well yeah but that might sum up to a dozends of people that will have to wit > for an updated spec file vs. we having to hack up fusionforge code and have > it maintained over years... The major issue with hacking up gforge in the past was that noone bothered to document what was changed, not that it was hacked in the first place. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page wrote: > On Tue, Dec 29, 2009 at 11:05 AM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: >> well yeah but that might sum up to a dozends of people that will have to wit >> for an updated spec file vs. we having to hack up fusionforge code and have >> it maintained over years... > > The major issue with hacking up gforge in the past was that noone > bothered to document what was changed, not that it was hacked in the > first place. while I agree that this should have been done in a dedicated repo/branch in an SCM at least the changes done in the last few years (a handful of security fixes) have been at least discussed on the gforge-admins list. And as I said before our changes have been minor so that is not really our issue. Stefan
On Wed, Dec 30, 2009 at 12:50 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > Dave Page wrote: >> >> On Tue, Dec 29, 2009 at 11:05 AM, Stefan Kaltenbrunner >> <stefan@kaltenbrunner.cc> wrote: >>> >>> well yeah but that might sum up to a dozends of people that will have to >>> wit >>> for an updated spec file vs. we having to hack up fusionforge code and >>> have >>> it maintained over years... >> >> The major issue with hacking up gforge in the past was that noone >> bothered to document what was changed, not that it was hacked in the >> first place. > > while I agree that this should have been done in a dedicated repo/branch in > an SCM at least the changes done in the last few years (a handful of > security fixes) have been at least discussed on the gforge-admins list. > And as I said before our changes have been minor so that is not really our > issue. As far as I've seen, they've been the main holdup in upgrading gforge, as noone willing the work on the upgrade had any idea what the changes were. If it weren't for that, we probably could have just installed an new version and upgraded as other gforge users do. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page wrote: > On Wed, Dec 30, 2009 at 12:50 PM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> wrote: >> Dave Page wrote: >>> On Tue, Dec 29, 2009 at 11:05 AM, Stefan Kaltenbrunner >>> <stefan@kaltenbrunner.cc> wrote: >>>> well yeah but that might sum up to a dozends of people that will have to >>>> wit >>>> for an updated spec file vs. we having to hack up fusionforge code and >>>> have >>>> it maintained over years... >>> The major issue with hacking up gforge in the past was that noone >>> bothered to document what was changed, not that it was hacked in the >>> first place. >> while I agree that this should have been done in a dedicated repo/branch in >> an SCM at least the changes done in the last few years (a handful of >> security fixes) have been at least discussed on the gforge-admins list. >> And as I said before our changes have been minor so that is not really our >> issue. > > As far as I've seen, they've been the main holdup in upgrading gforge, > as noone willing the work on the upgrade had any idea what the changes > were. If it weren't for that, we probably could have just installed an > new version and upgraded as other gforge users do. well simply diffing the original source with ours would have answered that quickly :) Also until guillaume started working on this the upgrade scripts in fusionforge didn't actually work due to the fact that our version was soo outdated. I Think the main and only issue is that we never had a concerted effort between somebody who knows gforge/fusionforge and the sysadmin team (or the gforge team for that matter). I think due to the huge number of "external" users pgf is by far the most complex to upgrade system we have and simply nobody has stepped up to waste days/weeks/months worth of time yet (well I spend a lot of time on various migration attempts in the past which all died due to various reasons so I'm a bit biased). Stefan
On Wed, Dec 30, 2009 at 2:02 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > well simply diffing the original source with ours would have answered that > quickly :) > Also until guillaume started working on this the upgrade scripts in > fusionforge didn't actually work due to the fact that our version was soo > outdated. > I Think the main and only issue is that we never had a concerted effort > between somebody who knows gforge/fusionforge and the sysadmin team (or the > gforge team for that matter). I think due to the huge number of "external" > users pgf is by far the most complex to upgrade system we have and simply > nobody has stepped up to waste days/weeks/months worth of time yet (well I > spend a lot of time on various migration attempts in the past which all died > due to various reasons so I'm a bit biased). I totally agree with the analysis of Stefan. Apart from the delay caused by external reasons, I'm still commited to do the ground work on the GForge/FusionForge part. -- Guillaume
On Dec 30, 2009, at 6:07 AM, Guillaume Smet wrote: > I totally agree with the analysis of Stefan. > > Apart from the delay caused by external reasons, I'm still commited to > do the ground work on the GForge/FusionForge part. I think that settles it, then. Guillaume, did you say you could perhaps get to this in February? Thanks, David
You realise the upgrade won't do anything to resolve your original gripe right? On 12/30/09, David E. Wheeler <david@justatheory.com> wrote: > On Dec 30, 2009, at 6:07 AM, Guillaume Smet wrote: > >> I totally agree with the analysis of Stefan. >> >> Apart from the delay caused by external reasons, I'm still commited to >> do the ground work on the GForge/FusionForge part. > > I think that settles it, then. Guillaume, did you say you could perhaps get > to this in February? > > Thanks, > > David -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Dec 30, 2009, at 11:16 AM, Dave Page wrote: > You realise the upgrade won't do anything to resolve your original gripe right? Yes, although Guillaume seemed to indicate that he'd make sure that the mirror URLs still work without the stupid ID. AmI wrong, Guillaume? Thanks, David
On Wednesday 30 December 2009 02:17:06 David E. Wheeler wrote: > On Dec 29, 2009, at 8:51 PM, Tom Lane wrote: > > Which is not to say that it wouldn't be nice if pgfoundry were > > better-than-average on this point. But it's not worse than average; > > it's right in line with the generally abysmal state of persistent URIs. > > What an endorsement. > > Please, can it at least suck less? > I think my favorite part of this is the sourceforge, which was the predecessor to the gforge fork, seems to have solved this problem. Here is the download url for phppgadmin: http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-4.2.2.tar.bz2?download Side note, +1 for killing pgf , if we're taking votes ;-) -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
On Wed, Dec 30, 2009 at 7:53 PM, Robert Treat <xzilla@users.sourceforge.net> wrote: > I think my favorite part of this is the sourceforge, which was the predecessor > to the gforge fork, seems to have solved this problem. Here is the download > url for phppgadmin: > http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-4.2.2.tar.bz2?download > > Side note, +1 for killing pgf , if we're taking votes ;-) We're not. Unless you have a simple migration path to a good alternative (which, imnsho, sourceforge is most certainly not). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Wed, 30 Dec 2009 20:17:03 +0000, Dave Page <dpage@pgadmin.org> wrote: > On Wed, Dec 30, 2009 at 7:53 PM, Robert Treat > <xzilla@users.sourceforge.net> wrote: >> I think my favorite part of this is the sourceforge, which was the >> predecessor >> to the gforge fork, seems to have solved this problem. Here is the >> download >> url for phppgadmin: >> http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-4.2.2.tar.bz2?download >> >> Side note, +1 for killing pgf , if we're taking votes ;-) > > We're not. Unless you have a simple migration path to a good > alternative (which, imnsho, sourceforge is most certainly not). Launchpad. Joshua D. Drake -- PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
2009/12/30 Joshua D. Drake <jd@commandprompt.com>: > On Wed, 30 Dec 2009 20:17:03 +0000, Dave Page <dpage@pgadmin.org> wrote: >> On Wed, Dec 30, 2009 at 7:53 PM, Robert Treat >> <xzilla@users.sourceforge.net> wrote: >>> I think my favorite part of this is the sourceforge, which was the >>> predecessor >>> to the gforge fork, seems to have solved this problem. Here is the >>> download >>> url for phppgadmin: >>> > http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-4.2.2.tar.bz2?download >>> >>> Side note, +1 for killing pgf , if we're taking votes ;-) >> >> We're not. Unless you have a simple migration path to a good >> alternative (which, imnsho, sourceforge is most certainly not). > > Launchpad. Want to start a launchpad vs github flamewar? FWIW, both are AFAIK missing the "simple migration path" that Dave was asking for. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Wed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <magnus@hagander.net> wrote: >> http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-4.2.2.tar.bz2?download >>>> >>>> Side note, +1 for killing pgf , if we're taking votes ;-) >>> >>> We're not. Unless you have a simple migration path to a good >>> alternative (which, imnsho, sourceforge is most certainly not). >> >> Launchpad. > > Want to start a launchpad vs github flamewar? No. I actually don't care which you use. I just don't think .Org will ever be able to productively host this infrastructure, ever. We haven't been able to do it right since 2001, why would we suddenly start now? And no offense to anyone who has tried. I am not suggesting we haven't just that our priorities are not nor will they ever be, pgFoundry or some successor. > > FWIW, both are AFAIK missing the "simple migration path" that Dave was > asking for. Not really... let the developers move it themselves. Joshua D. Drake -- PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
On Wednesday 30 December 2009 16:11:36 Joshua D. Drake wrote: > On Wed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <magnus@hagander.net> > wrote: > > > http://downloads.sourceforge.net/phppgadmin/phpPgAdmin-4.2.2.tar.bz2?downlo >ad > > >>>> Side note, +1 for killing pgf , if we're taking votes ;-) > >>> > >>> We're not. Unless you have a simple migration path to a good > >>> alternative (which, imnsho, sourceforge is most certainly not). > >> > >> Launchpad. > > > > Want to start a launchpad vs github flamewar? > > No. I actually don't care which you use. And in fact, why be so limiting, there are *dozens* of alternatives: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities > I just don't think .Org will > ever be able to productively host this infrastructure, ever. We haven't > been able to do it right since 2001, why would we suddenly start now? > +1 > And no offense to anyone who has tried. I am not suggesting we haven't > just that our priorities are not nor will they ever be, pgFoundry or some > successor. > +1 > > FWIW, both are AFAIK missing the "simple migration path" that Dave was > > asking for. > > Not really... let the developers move it themselves. > +1. One thing I learned doing the gborg migration/shutdown was that everyone uses the existing infrastructure differently, and the relative importance of any of it seems to fluctuate on how much work they will have to do to keep something. So my migration plan *is* simple, it's "NMFP". (Except of course for those projects of my own which are on pgfoundry, which would be MFP, but I'm willing to move them) -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
Joshua D. Drake wrote: <blockquote cite="mid:0fdce962980773863e3b25e6150a5ffe@commandprompt.com" type="cite"><pre wrap="">OnWed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <a class="moz-txt-link-rfc2396E" href="mailto:magnus@hagander.net"><magnus@hagander.net></a> wrote: </pre><blockquote type="cite"><pre wrap="">FWIW, both are AFAIK missing the "simple migration path" that Dave was asking for. </pre></blockquote><pre wrap=""> Not really... let the developers move it themselves. </pre></blockquote><br /> I don't have a large data set, just a coupleof dozen people I've talked to about this. Based on some wild-ass extrapolation from those conversations, I wouldventure that if one took a survey of every active pgfoundry maintainer, and told them "we're migrating to a better andeasier to support system, but you'll lose all your active projects and you'll have to move them yourself to the new hostmanually", votes would still be at least 10:1 in favor of that over the status quo. I'd expect that if you provisionedan officially sanctioned replacement candidate, the most popular projects would migrate to it in a minute giventhe opportunity. The idea that anyone is going to put more time into trying to maintain it boggles my mind.<br /><br/> The real key as I see it is to never again choose from among anything but the most popular of such systems <br />available. Pick one of the widely deployed solutions here, don't customize *anything*, keep up with updates to it, andlet a larger slice of the rest of the world solve this problem. Seriously--the most important criteria here is maximizingthe odds that somebody else with a much larger use base is going to maintain and extend the underlying code ofwhatever solution is used so this project doesn't have to. A quick glance at the page Robert suggested:<br /><br /><aclass="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities">http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities</a><br /><br/> And sorting by real or estimated Alexa rank as a popularity estimate, where lower is more popular:<br /><br /> Sourceforge198<br /> Google Code 1000 (estimated, but unsuitable anyway so who cares)<br /> GitHub 2342<br /> CodePlex 3334<br/> Tigris.org 10896<br /> Launchpad 12268<br /><br /> Obviously these are not all suitable just based on basic features,but I would argue that nothing else but the ones on this list are worth doing any work with.<br /><br /><pre class="moz-signature"cols="72">-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a> </pre>
2009/12/30 Robert Treat <xzilla@users.sourceforge.net>: > On Wednesday 30 December 2009 16:11:36 Joshua D. Drake wrote: >> > Want to start a launchpad vs github flamewar? >> >> No. I actually don't care which you use. > > And in fact, why be so limiting, there are *dozens* of alternatives: > http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities Of course. >> > FWIW, both are AFAIK missing the "simple migration path" that Dave was >> > asking for. >> >> Not really... let the developers move it themselves. >> > > +1. > > One thing I learned doing the gborg migration/shutdown was that everyone uses > the existing infrastructure differently, and the relative importance of any of > it seems to fluctuate on how much work they will have to do to keep something. > So my migration plan *is* simple, it's "NMFP". (Except of course for those > projects of my own which are on pgfoundry, which would be MFP, but I'm willing > to move them) If we actually want to go down that path, we need to figure out what we need to do to fill the needs that pgfoundry supposedly does today, that other solutions *don't*. A first one would be an aggregated newsfeed from projects somewhere - and this is probably different from planet, in that it's a different kind of posts. It's not hard to do technically, but it needs to be done. There may well be others. Also, we'd still have to maintain pgfoundry for quite a while. I guess we could eventually retire some services into readonly mode, but a phase-out would be just like gforge. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
2009/12/31 Greg Smith <greg@2ndquadrant.com>: > Joshua D. Drake wrote: > > On Wed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <magnus@hagander.net> > wrote: > > > FWIW, both are AFAIK missing the "simple migration path" that Dave was > asking for. > > > Not really... let the developers move it themselves. > > > I don't have a large data set, just a couple of dozen people I've talked to about this. Based on some wild-ass extrapolationfrom those conversations, I would venture that if one took a survey of every active pgfoundry maintainer, andtold them "we're migrating to a better and easier to support system, but you'll lose all your active projects and you'llhave to move them yourself to the new host manually", votes would still be at least 10:1 in favor of that over thestatus quo. I'd expect that if you provisioned an officially sanctioned replacement candidate, the most popular projectswould migrate to it in a minute given the opportunity. The idea that anyone is going to put more time into tryingto maintain it boggles my mind. > > The real key as I see it is to never again choose from among anything but the most popular of such systems > available. Pick one of the widely deployed solutions here, don't customize *anything*, keep up with updates to it, andlet a larger slice of the rest of the world solve this problem. Seriously--the most important criteria here is maximizingthe odds that somebody else with a much larger use base is going to maintain and extend the underlying code ofwhatever solution is used so this project doesn't have to. A quick glance at the page Robert suggested: I can't see us picking a different system and run it ourselves. If we're going to run it ourselves, it'll be FusionForge (as I understand it that's the name of gforge now). The other option is to let somebody else run it for us, and just provide "some glue" if necessary. Which is becoming increasinly attractive... > http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities This is all options where somebody else runs them, right? -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Wed, Dec 30, 2009 at 10:12 PM, Robert Treat <xzilla@users.sourceforge.net> wrote: > One thing I learned doing the gborg migration/shutdown was that everyone uses > the existing infrastructure differently, and the relative importance of any of > it seems to fluctuate on how much work they will have to do to keep something. One thing I learned form the gborg migration was that we should never have done it in the first place. GBorg worked well, and was well maintained by it's original author. Why on earth we had to move to gforge is still beyond me. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
2009/12/31 Dave Page <dpage@pgadmin.org>: > On Wed, Dec 30, 2009 at 10:12 PM, Robert Treat > <xzilla@users.sourceforge.net> wrote: >> One thing I learned doing the gborg migration/shutdown was that everyone uses >> the existing infrastructure differently, and the relative importance of any of >> it seems to fluctuate on how much work they will have to do to keep something. > > One thing I learned form the gborg migration was that we should never > have done it in the first place. GBorg worked well, and was well > maintained by it's original author. Why on earth we had to move to > gforge is still beyond me. I assume it was the usual "if we run an off-the-shelf product, it will be much less work". That we all know well both from community and professional experience usually isn't true once you move past the sales pitch :-) I definitely agree. Which is why I say that if we're moving off gforge, we're moving to Somebody Elses Problem, not to another platform maintained by *us*. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Thu, 31 Dec 2009 13:15:42 +0100, Magnus Hagander <magnus@hagander.net> wrote: +1 on directing people to Launchpad and/or Github and creating an index page that can point to those projects. Joshua D. Drake -- PostgreSQL - XMPP: jdrake(at)jabber(dot)postgresql(dot)org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
On Thu, Dec 31, 2009 at 1:15 PM, Magnus Hagander <magnus@hagander.net> wrote: > I definitely agree. Which is why I say that if we're moving off > gforge, we're moving to Somebody Elses Problem, not to another > platform maintained by *us*. "Somebody Elses Problem" is going to be ours if we consider the whole community and not only the sysadmins/web teams. PostgreSQL is defined by/appreciated for its whole ecosystem, not only the core code. As a community member I think it's a great thing to have a code repository that we manage as a community: - when we approve a project, we sometimes discuss the license with the project creator; - we also sometimes decide to give a dead project to another community member; - we are sure the code repository won't go to trash because managed by some random company having problems or making the wrong decision for us; - it's a good opportunity to have a lot of PostgreSQL projects gathered in one place. As a developer having a project on pgFoundry, I don't really like the idea of moving elsewhere: - I'm going to lose my trackers/forums history; - I'll have to chose another place with CVS/Subversion repositories (I don't really want to use bazaar or git) and hope it won't be closed in the next few years. I'm pretty sure I'm not the only one in this case and I'm also pretty sure there's a lot of projects that won't be moved and will be lost (either immediately or after a few years). I don't really see pgFoundry maintenance as something requiring a lot of time. Am I wrong? -- Guillaume
On Dec 31, 2009, at 9:06 AM, Guillaume Smet wrote: > "Somebody Elses Problem" is going to be ours if we consider the whole > community and not only the sysadmins/web teams. PostgreSQL is defined > by/appreciated for its whole ecosystem, not only the core code. > > As a community member I think it's a great thing to have a code > repository that we manage as a community: > - when we approve a project, we sometimes discuss the license with the > project creator; > - we also sometimes decide to give a dead project to another community member; > - we are sure the code repository won't go to trash because managed by > some random company having problems or making the wrong decision for > us; > - it's a good opportunity to have a lot of PostgreSQL projects > gathered in one place. None of this requires Web sites, email lists, bug tracking, or VCS. Just a central repository of releases. Think PAUSE/CPAN. > As a developer having a project on pgFoundry, I don't really like the > idea of moving elsewhere: > - I'm going to lose my trackers/forums history; There are ways to migrate that content, depending on how hard one wants to work at it. > - I'll have to chose another place with CVS/Subversion repositories (I > don't really want to use bazaar or git) and hope it won't be closed in > the next few years. This will *always* be the case, and applies no less to pgFoundry itself. Even if you host your own Subversion install itcould go away. (At least with Git you always have a complete copy of the repository in your clones, so can easily moveelsewhere if the need arises.) > I'm pretty sure I'm not the only one in this case and I'm also pretty > sure there's a lot of projects that won't be moved and will be lost > (either immediately or after a few years). Only if the site is shut down. > I don't really see pgFoundry maintenance as something requiring a lot > of time. Am I wrong? From the sound of things, quite a bit of time has been invested with not much result. Not saying you won't get results, justthat discussion has given the appearance of large time investments. Best, David
David, On Thu, Dec 31, 2009 at 6:11 PM, David E. Wheeler <david@justatheory.com> wrote: > On Dec 31, 2009, at 9:06 AM, Guillaume Smet wrote: >> "Somebody Elses Problem" is going to be ours if we consider the whole >> community and not only the sysadmins/web teams. PostgreSQL is defined >> by/appreciated for its whole ecosystem, not only the core code. >> >> As a community member I think it's a great thing to have a code >> repository that we manage as a community: >> - when we approve a project, we sometimes discuss the license with the >> project creator; >> - we also sometimes decide to give a dead project to another community member; >> - we are sure the code repository won't go to trash because managed by >> some random company having problems or making the wrong decision for >> us; >> - it's a good opportunity to have a lot of PostgreSQL projects >> gathered in one place. > > None of this requires Web sites, email lists, bug tracking, or VCS. Just a central repository of releases. Think PAUSE/CPAN. The first 3 items do require it. >> As a developer having a project on pgFoundry, I don't really like the >> idea of moving elsewhere: >> - I'm going to lose my trackers/forums history; > > There are ways to migrate that content, depending on how hard one wants to work at it. See the GBorg migration disaster. And we did have the control of each end of the migration path... >> - I'll have to chose another place with CVS/Subversion repositories (I >> don't really want to use bazaar or git) and hope it won't be closed in >> the next few years. > > This will *always* be the case, and applies no less to pgFoundry itself. Even if you host your own Subversion install itcould go away. (At least with Git you always have a complete copy of the repository in your clones, so can easily moveelsewhere if the need arises.) I disagree with that. The community controls pgFoundry. I find it much more future-proof than any other services (at least with the current sysadmin team we have). >> I'm pretty sure I'm not the only one in this case and I'm also pretty >> sure there's a lot of projects that won't be moved and will be lost >> (either immediately or after a few years). > > Only if the site is shut down. If we don't shut it down, we'll have to maintain it (at least for security fixes) so I don't see the point of doing so. >> I don't really see pgFoundry maintenance as something requiring a lot >> of time. Am I wrong? > > From the sound of things, quite a bit of time has been invested with not much result. Not saying you won't get results,just that discussion has given the appearance of large time investments. We need to move it anyway, even if we only keep it readonly. We don't force anyone to use pgFoundry AFAIK. People could use github, sf.net, launchpad... but they still use pgFoundry, even if it's old and only proposes CVS. Perhaps there is a good reason to it? I'm pretty sure we're not all masochist. Note that if people want to stop the pgFoundry service, it's some time I would be able to invest elsewhere. But I really have the impression we want to stop it for bad reasons and without considering the service it offers to the community as a whole. -- Guillaume
On Thu, 2009-12-31 at 18:37 +0100, Guillaume Smet wrote: <major snip> I believe people are looking at this the wrong way. Migration is such a trivial issue in comparison to the larger problem it isn't even funny. .Org has NEVER made Gborg or PgFoundry a priority. Migration to FusionForge will not change that because Migration is the easiest of the problems to solve. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Dec 31, 2009, at 9:37 AM, Guillaume Smet wrote: >>> - when we approve a project, we sometimes discuss the license with the >>> project creator; >>> - we also sometimes decide to give a dead project to another community member; >>> - we are sure the code repository won't go to trash because managed by >>> some random company having problems or making the wrong decision for >>> us; >>> - it's a good opportunity to have a lot of PostgreSQL projects >>> gathered in one place. >> >> None of this requires Web sites, email lists, bug tracking, or VCS. Just a central repository of releases. Think PAUSE/CPAN. > > The first 3 items do require it. They require a site for managing it, but in what sense do they require a VCS, mail list, project site, or bug tracking? >> There are ways to migrate that content, depending on how hard one wants to work at it. > > See the GBorg migration disaster. And we did have the control of each > end of the migration path... Yeah, I mean for individual developers. I've moved systems many times, frankly, and it's a PITA, but do-able. > I disagree with that. The community controls pgFoundry. I find it much > more future-proof than any other services (at least with the current > sysadmin team we have). Then why is there so much discussion of killing it? It's not as future-proof as one might hope. > If we don't shut it down, we'll have to maintain it (at least for > security fixes) so I don't see the point of doing so. Make it READ-only. >> From the sound of things, quite a bit of time has been invested with not much result. Not saying you won't get results,just that discussion has given the appearance of large time investments. > > We need to move it anyway, even if we only keep it readonly. Sure. > We don't force anyone to use pgFoundry AFAIK. People could use github, > sf.net, launchpad... but they still use pgFoundry, even if it's old > and only proposes CVS. Perhaps there is a good reason to it? I'm > pretty sure we're not all masochist. Yeah. Nothing else is a perfect fit, alas. pgFoundry itself isn't a perfect fit, hence all the bitching. :-) > Note that if people want to stop the pgFoundry service, it's some time > I would be able to invest elsewhere. But I really have the impression > we want to stop it for bad reasons and without considering the service > it offers to the community as a whole. I'm ambivalent, personally. I'd like something better, but don't yet have anything better unless I build it myself. Best, David
On Wednesday 30 December 2009 18:54:57 Magnus Hagander wrote: > 2009/12/30 Robert Treat <xzilla@users.sourceforge.net>: > > On Wednesday 30 December 2009 16:11:36 Joshua D. Drake wrote: > >> > Want to start a launchpad vs github flamewar? > >> > >> No. I actually don't care which you use. > > > > And in fact, why be so limiting, there are *dozens* of alternatives: > > http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_f > >acilities > > Of course. > > >> > FWIW, both are AFAIK missing the "simple migration path" that Dave was > >> > asking for. > >> > >> Not really... let the developers move it themselves. > > > > +1. > > > > One thing I learned doing the gborg migration/shutdown was that everyone > > uses the existing infrastructure differently, and the relative importance > > of any of it seems to fluctuate on how much work they will have to do to > > keep something. So my migration plan *is* simple, it's "NMFP". (Except > > of course for those projects of my own which are on pgfoundry, which > > would be MFP, but I'm willing to move them) > > If we actually want to go down that path, we need to figure out what > we need to do to fill the needs that pgfoundry supposedly does today, > that other solutions *don't*. A first one would be an aggregated > newsfeed from projects somewhere - and this is probably different from > planet, in that it's a different kind of posts. It's not hard to do > technically, but it needs to be done. > Yeah, I have been thinking about that. It seems we need more of a freshmeat than a sourceforge. I think the existing software catalog could be used for just that purpose, with a specific rss feed for news people want to post there about thier projects (or just changes within the catalog). > There may well be others. > The other thing that I have seen is having an easy place for packagers to get thier downloads. As someone who maintins a package outside of the pgf infrastructure that is packaged on multiple distributions, I'm not overly worried about this. It will be a bit of work for packagers initially, but long term it is no more work. Also it might be possible to have the software catalog contain links to latest downloads that could be mirrored, though I'm not sure how desirable that really would be. > Also, we'd still have to maintain pgfoundry for quite a while. I guess > we could eventually retire some services into readonly mode, but a > phase-out would be just like gforge. > Sure, but I think that would be better than the state we are in now. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
On Thu, Dec 31, 2009 at 5:48 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On Thu, 2009-12-31 at 18:37 +0100, Guillaume Smet wrote: > > <major snip> > > I believe people are looking at this the wrong way. Migration is such a > trivial issue in comparison to the larger problem it isn't even funny. > > .Org has NEVER made Gborg or PgFoundry a priority. Migration to > FusionForge will not change that because Migration is the easiest of the > problems to solve. At the risk of pissing off some people, .org did put effort into maintaining GBorg - it worked very well and was supported by it's original author and others who chipped in from time to time as needed. It did not put effort into maintaining pgFoundry, largely because it was setup outside of the normal .org processes and infrastructure management (consider for example, the fact that it's pgfoundry.org, and not part of postgresql.org like all the other services we maintain). I'll also note that it's extremely easy to say that migration isn't an issue when you host most/all of your projects elsewhere, and won't be migrating anyone else's projects. As I believe the only person that actually did migrate active projects from GBorg to pgFoundry, I can say with complete confidence that it is not trivial in the slightest, and that it will be much easier to upgrade and maintain a new, properly documented VM within the normal management processes than go through the pain of migrating just a handful of projects. The issue, is simply one of time, and going forward, ensuring the the site is properly maintained by people willing to put in the effort, rather than leave it to fester. In the hands of the infrastructure team, much of the problem vanishes as it becomes 'just another VM' to manage. In any case, pgFoundry isn't going anywhere. If people don't want to use it, that's fine, but there are many people that do actively use it and don't have the time, energy or desire to try to migrate elsewhere, myself included. Oh, and to end on a positive note - Happy New Year folks :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Thu, 2009-12-31 at 18:43 +0000, Dave Page wrote: > > .Org has NEVER made Gborg or PgFoundry a priority. Migration to > > FusionForge will not change that because Migration is the easiest of the > > problems to solve. > > At the risk of pissing off some people, .org did put effort into > maintaining GBorg - it worked very well and was supported by it's > original author and others who chipped in from time to time as needed. > It did not put effort into maintaining pgFoundry, largely because it > was setup outside of the normal .org processes and infrastructure > management (consider for example, the fact that it's pgfoundry.org, > and not part of postgresql.org like all the other services we > maintain). To be fair to all involved, my recollection is going to be during the time when both were in service (which was a couple of years) and then the subsequent migration and after effects. > > I'll also note that it's extremely easy to say that migration isn't an > issue when you host most/all of your projects elsewhere, and won't be > migrating anyone else's projects. My point is not that migration is easy, it is that it is the smallest part of the problem. > Oh, and to end on a positive note - Happy New Year folks :-) > And to you! Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Thursday 31 December 2009 12:06:10 Guillaume Smet wrote: > it's a good opportunity to have a lot of PostgreSQL projects > gathered in one place. > I think there are two sides to this. One is that there is actually a danger of concentrating a lot of our projects in one place. It makes the community more insular, and also creates a perception in other development communties (sourceforge/launchpad/github/etc...) that there is less postgresql related activity going on than what is really the case. However in general I agree that the postgresql project should try to promote postgresql related software, however I don't think we need project hosting to do it, and in fact I think that is the wrong way to do it. The software catalog is a much better system for that, since it allows inclusion of any/all projects and requires less operational overhead. > I'm pretty sure I'm not the only one in this case and I'm also pretty > sure there's a lot of projects that won't be moved and will be lost > (either immediately or after a few years). > Ah the delicious irony of life. Trust me there was no bigger advocate of this position than me when we were shutting down gborg. I pestered people so much on this idea, I think I even got Josh to move some dead projects to pgfoundry before it was all over with. In time I have come around to the idea (which everyone else held at the time) that if the code is valuable enough to keep, someone will move it. > I don't really see pgFoundry maintenance as something requiring a lot > of time. Am I wrong? I don't know how much time it requires, but I do know it's more time than we have been able to come up with. For years. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
Guillaume Smet wrote: > - we are sure the code repository won't go to trash because managed by > some random company having problems or making the wrong decision for > us... > - I'll have to chose another place with CVS/Subversion repositories (I > don't really want to use bazaar or git) and hope it won't be closed in > the next few years. > That first issue here is a self-inflicted problem solved by reconsidering the second one. The whole idea of having one master version control repository where you'll be in trouble if you lose access to it is obsolete. If you switch to a distributed version control system where every copy of the repo is a sibling containing the full repository, this entire issue goes away. Any copy of the repo can turn into a new seed if something happens to where you've got another copy hosted at. This is actually the main thing that got me to finally adopt git: I can never again get stuck where a loss of the master repo causes me any problem whatsoever. The copy on my desktop, my laptops, and on github are all the same, and as long as there's one left standing after a disaster everything is fine. I've had quite enough of rsync'ing cvs repos and svnadmin hotcopy. > I'm pretty sure I'm not the only one in this case and I'm also pretty > sure there's a lot of projects that won't be moved and will be lost > (either immediately or after a few years). > The flip side to this is that the many obsolete projects on there that waste people's time when they dowload them and discover they don't work anymore will finally go away. Just in the top 10 most downloaded projects, about 1/3 of them haven't been updated in years and are basically dead already. I would roughly guess that there's from 50-100 projects like yours that really need to be migrated somewhere if pgFoundry is deprecated. I feel the community would be better off if most of the rest disappeared, just to cut down on newbie confusion. Having hundreds of half-baked projects in there isn't helping anyone. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Thu, 2009-12-31 at 18:37 +0100, Guillaume Smet wrote: <major snip> I believe people are looking at this the wrong way. Migration is such a trivial issue in comparison to the larger problem it isn't even funny. .Org has NEVER made Gborg or PgFoundry a priority. Migration to FusionForge will not change that because Migration is the easiest of the problems to solve. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Thu, 2009-12-31 at 18:43 +0000, Dave Page wrote: > > .Org has NEVER made Gborg or PgFoundry a priority. Migration to > > FusionForge will not change that because Migration is the easiest of the > > problems to solve. > > At the risk of pissing off some people, .org did put effort into > maintaining GBorg - it worked very well and was supported by it's > original author and others who chipped in from time to time as needed. > It did not put effort into maintaining pgFoundry, largely because it > was setup outside of the normal .org processes and infrastructure > management (consider for example, the fact that it's pgfoundry.org, > and not part of postgresql.org like all the other services we > maintain). To be fair to all involved, my recollection is going to be during the time when both were in service (which was a couple of years) and then the subsequent migration and after effects. > > I'll also note that it's extremely easy to say that migration isn't an > issue when you host most/all of your projects elsewhere, and won't be > migrating anyone else's projects. My point is not that migration is easy, it is that it is the smallest part of the problem. > Oh, and to end on a positive note - Happy New Year folks :-) > And to you! Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
Greg Smith wrote: > Guillaume Smet wrote: [...] >> I'm pretty sure I'm not the only one in this case and I'm also pretty >> sure there's a lot of projects that won't be moved and will be lost >> (either immediately or after a few years). >> > > The flip side to this is that the many obsolete projects on there that > waste people's time when they dowload them and discover they don't work > anymore will finally go away. Just in the top 10 most downloaded > projects, about 1/3 of them haven't been updated in years and are > basically dead already. I would roughly guess that there's from 50-100 > projects like yours that really need to be migrated somewhere if > pgFoundry is deprecated. I feel the community would be better off if > most of the rest disappeared, just to cut down on newbie confusion. > Having hundreds of half-baked projects in there isn't helping anyone. depends - even a half baked project can be of use to somebody who is interested in using it as a base for a similiar project (or even taking it over). I don't think that code that has not been updated in ages is actually "useless" - sure itmight not work on a more recent version of PostgreSQL or such but it is still something that might be of use. What actually might be more helpful is categorizing the projects in a more straight forward way(as in combine download stats and activity for a start) to give the what you call a "newbie" a better idea of what project is in what state. There is a way to do that easily withing gforge but maybe just improving the visibility of that would help with that(like the OLEdb project). On the other hand we got more than 50 project applications this year(not all of the accepted) so there seems to be a need and an interest from the community for a postgresql centric project hosting infrastructure. Stefan
On Jan 1, 2010, at 7:01 AM, Stefan Kaltenbrunner wrote: > On the other hand we got more than 50 project applications this year(not all of the accepted) so there seems to be a needand an interest from the community for a postgresql centric project hosting infrastructure. Yes, but are those people applying to pgFoundry to take advantage of the tools, or to have a presence in the community? I'llbet that the latter is usually the more important reason, since there are better tools elsewhere. Best, David
On Thu, Dec 31, 2009 at 18:06, Guillaume Smet <guillaume.smet@gmail.com> wrote: > On Thu, Dec 31, 2009 at 1:15 PM, Magnus Hagander <magnus@hagander.net> wrote: >> I definitely agree. Which is why I say that if we're moving off >> gforge, we're moving to Somebody Elses Problem, not to another >> platform maintained by *us*. > > "Somebody Elses Problem" is going to be ours if we consider the whole > community and not only the sysadmins/web teams. PostgreSQL is defined > by/appreciated for its whole ecosystem, not only the core code. True. Though it would definitely be good to have some sort of "project directory" somewhere, with good aggregation functionality, *regardless*. Because today, if you want a reasonably modern version control system, or a reasonably working tracker system, or things like that, you *have* to go elsewhere. Which is why many have *already* gone elsewhere. We, as the project, need to care about those who don't want pgfoundry as well - regardless of if we continue the service or not. > I don't really see pgFoundry maintenance as something requiring a lot > of time. Am I wrong? Given that people say it's only time that has kept us from upgrading it to a non-ancient version, and that we have been talking about said upgrade for many years now, yes, I think you are wrong. It may not require a lot of time, but it requires significantly more time than anybody is willing to invest. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sat, Jan 2, 2010 at 00:43, David E. Wheeler <david@justatheory.com> wrote: > On Jan 1, 2010, at 7:01 AM, Stefan Kaltenbrunner wrote: > >> On the other hand we got more than 50 project applications this year(not all of the accepted) so there seems to be a needand an interest from the community for a postgresql centric project hosting infrastructure. > > Yes, but are those people applying to pgFoundry to take advantage of the tools, or to have a presence in the community?I'll bet that the latter is usually the more important reason, since there are better tools elsewhere. It's certainly not to take advantage of the tools, unless they have been living under a rock for the past 5 years when the rest of the world of project-hosting overtook pgfoundry rapidly :) That said, a lot of the projects on pgfoundry don't *need* anything more advanced than what it provides. And given that restriction, it's "good enough", and the "community visibility" (which IMHO pgfoundry actually doesn't give you, but that's a different thing - people think it does and that's what matters) adds value, and it's "the default place to go". -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sat, Jan 2, 2010 at 12:07 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Dec 31, 2009 at 18:06, Guillaume Smet <guillaume.smet@gmail.com> wrote: >> I don't really see pgFoundry maintenance as something requiring a lot >> of time. Am I wrong? > > Given that people say it's only time that has kept us from upgrading > it to a non-ancient version, and that we have been talking about said > upgrade for many years now, yes, I think you are wrong. It may not > require a lot of time, but it requires significantly more time than > anybody is willing to invest. I still think the major part of the problem is that pgFoundry was implemented outside the web/sysadmin teams, and had exactly zero documentation, yet when something goes wrong, it's one of us that ends up trying to resolve the problems with little clue about how it all works. With Guillaume re-building the entire VM from the ground up, fully involving the sysadmin team and doing so within our management processes, I for one will feel far more confident about managing it as 'just another VM'. Which reminds, me - I need to do a bunch of VM upgrades... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Thursday 31 December 2009 13:43:43 Dave Page wrote: > On Thu, Dec 31, 2009 at 5:48 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > On Thu, 2009-12-31 at 18:37 +0100, Guillaume Smet wrote: > > > > <major snip> > > > > I believe people are looking at this the wrong way. Migration is such a > > trivial issue in comparison to the larger problem it isn't even funny. > > > > .Org has NEVER made Gborg or PgFoundry a priority. Migration to > > FusionForge will not change that because Migration is the easiest of the > > problems to solve. > > At the risk of pissing off some people, .org did put effort into > maintaining GBorg - it worked very well and was supported by it's > original author and others who chipped in from time to time as needed. It did run well, but you are glossing over some history here. A lot of people wanted to see new features added and/or improved with that code base (svn support was a big one), and there were issues with both code access and extensibility of that codebase that it was decided we would not overcome. That was one of the big sells with pgfoundry; new feature development would be the work of someone else, and we could just manage the software. Of course things didn't turn out that way, for a host of reasons sure, but clearly moving to the new system was not a success (where is my svn support?) based on the original intentions. > It did not put effort into maintaining pgFoundry, largely because it > was setup outside of the normal .org processes and infrastructure > management (consider for example, the fact that it's pgfoundry.org, > and not part of postgresql.org like all the other services we > maintain). > > I'll also note that it's extremely easy to say that migration isn't an > issue when you host most/all of your projects elsewhere, and won't be > migrating anyone else's projects. As I believe the only person that > actually did migrate active projects from GBorg to pgFoundry, I can > say with complete confidence that it is not trivial in the slightest, You can believe that, but it simply isn't true. I helped migrate several projects between the two sites, some my own but many I had no involvment in. I know Marc and Devrim both helped out during that process. I agree it isn't trivial, but it is a process that can be distributed amongst those who are most directly the stakeholders (ie. the projects themselves) > and that it will be much easier to upgrade and maintain a new, > properly documented VM within the normal management processes than go > through the pain of migrating just a handful of projects. >> The issue, > is simply one of time, and going forward, ensuring the the site is > properly maintained by people willing to put in the effort, rather > than leave it to fester. In the hands of the infrastructure team, much > of the problem vanishes as it becomes 'just another VM' to manage. > > In any case, pgFoundry isn't going anywhere. If people don't want to > use it, that's fine, but there are many people that do actively use it > and don't have the time, energy or desire to try to migrate elsewhere, > myself included. > > Oh, and to end on a positive note - Happy New Year folks :-) So far so good :) -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
On tis, 2009-12-29 at 11:59 +0100, Magnus Hagander wrote: > >> Presumably the packages that rely on the existing URLs are actually > >> being used by large numbers of end-users, who will all be sad if they > >> break. > > > > I might be wrong but I don't think we have that many users that are regulary rebuilding rpms from source with the originaltar.gz being on pgfoundry... > > Well, the big users would be Devrim (RPMs) and I guess whomever does > debian packages of the things. Actually, most if not all of the (official) Debian packages built for PgFoundry stuff use the pgfoundry.org URLs like http://pgfoundry.org/frs/?group_id=1000258 /frs/download.php/[0-9]+/pgbouncer-([0-9.]+).tgz that were the original complaint in this thread. If *that* breaks, about five people including me will be briefly unhappy, but it's not the end of the world.
David E. Wheeler wrote: > On Jan 1, 2010, at 7:01 AM, Stefan Kaltenbrunner wrote: > >> On the other hand we got more than 50 project applications this year(not all of the accepted) so there seems to be a needand an interest from the community for a postgresql centric project hosting infrastructure. > > Yes, but are those people applying to pgFoundry to take advantage of the tools, or to have a presence in the community?I'll bet that the latter is usually the more important reason, since there are better tools elsewhere. I cannot really answer that question but I guess it is a bit of both. As in for most of the simple projects the tools are still "good enough" and you get the community presence on top of that. Stefan
On Sun, Jan 3, 2010 at 1:29 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > Actually, most if not all of the (official) Debian packages built for > PgFoundry stuff use the pgfoundry.org URLs like > > http://pgfoundry.org/frs/?group_id=1000258 /frs/download.php/[0-9]+/pgbouncer-([0-9.]+).tgz > > that were the original complaint in this thread. If *that* breaks, > about five people including me will be briefly unhappy, but it's not the > end of the world. If I understand you correctly, we not only have to keep the current urls working (which was obviously planned) but also that they need to be the urls on the /frs/page as the debian packages are scanning the page looking for this pattern? -- Guillaume
On sön, 2010-01-03 at 15:17 +0100, Guillaume Smet wrote: > On Sun, Jan 3, 2010 at 1:29 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > > Actually, most if not all of the (official) Debian packages built for > > PgFoundry stuff use the pgfoundry.org URLs like > > > > http://pgfoundry.org/frs/?group_id=1000258 /frs/download.php/[0-9]+/pgbouncer-([0-9.]+).tgz > > > > that were the original complaint in this thread. If *that* breaks, > > about five people including me will be briefly unhappy, but it's not the > > end of the world. > > If I understand you correctly, we not only have to keep the current > urls working (which was obviously planned) but also that they need to > be the urls on the /frs/page as the debian packages are scanning the > page looking for this pattern? Personally, I think you don't have to keep that part working, but anyway that's what's currently in use.
On Jan 3, 2010, at 6:06 AM, Stefan Kaltenbrunner wrote: >> Yes, but are those people applying to pgFoundry to take advantage of the tools, or to have a presence in the community?I'll bet that the latter is usually the more important reason, since there are better tools elsewhere. > > I cannot really answer that question but I guess it is a bit of both. As in for most of the simple projects the tools arestill "good enough" and you get the community presence on top of that. Except that: a. There are better tools available that provide higher visibility in general; and b. The community presenceacquired as a result of being on pgFoundry is, as Magnus parentheticaly indicated and I agree, negligible. Best, David
All, My $0.02: With the presensce today of Launchpad, Codehaus, SourceForge, Tigris, Java.net, CPAN, GEM, Developerworks, Github, Code.Google.com, and others, it seems silly for our project to be putting our scarce admin resources into maintaining/improving an outdated collab site. Let others do the work. There's also a 2nd advantage to having the PG accessory project mostly hosted elsewhere: it makes us more visible to outside communities. What we need out of pgfoundry is five things, none of which require a full collab framework, and some of which are really unrelated to the others: 1) a place for less offical mailing lists (e.g. non-permanent non-@postgresql.org mailing lists) which can be created without the whole process required for a new "official" list. Note that many of these lists are not related to any code development project. 2) a place for web pages/documentation for some projects (which could be a wiki, or something else) 3) a search and download service for postgresql accessories (something pgfoundry currently does a poor job of) 4) a news feed for postgresql accessories (something pgfoundry currently does a bad job of) 5) A place to store files for download for internal project use which is easier to manage than mediawiki's "images", and includes the ability to restrict files to a specific access list. Like (1), these files are largely not related to specific development projects. It seems to me that *all* of the above could be better done than how pgfoundry does it, and done in a simpler and more maintainable way. --Josh Berkus
On Mon, 2010-01-04 at 11:31 -0800, Josh Berkus wrote: > All, > > My $0.02: > > With the presensce today of Launchpad, Codehaus, SourceForge, Tigris, > Java.net, CPAN, GEM, Developerworks, Github, Code.Google.com, and > others, it seems silly for our project to be putting our scarce admin > resources into maintaining/improving an outdated collab site. Let > others do the work. > +1 > There's also a 2nd advantage to having the PG accessory project mostly > hosted elsewhere: it makes us more visible to outside communities. > +1 > What we need out of pgfoundry is five things, none of which require a > full collab framework, and some of which are really unrelated to the others: > > 1) a place for less offical mailing lists (e.g. non-permanent > non-@postgresql.org mailing lists) which can be created without the > whole process required for a new "official" list. Note that many of > these lists are not related to any code development project. Not sure why this is needed, everyone of the sites listed above provides mailing list capability. > > 2) a place for web pages/documentation for some projects (which could be > a wiki, or something else) > Again, not sure why this is needed, all the sites above provide this. > 3) a search and download service for postgresql accessories (something > pgfoundry currently does a poor job of) > See Robert's remarks ala Freshmeat > 4) a news feed for postgresql accessories (something pgfoundry currently > does a bad job of) Freshmeat style. > > 5) A place to store files for download for internal project use which is > easier to manage than mediawiki's "images", and includes the ability to > restrict files to a specific access list. Like (1), these files are > largely not related to specific development projects. This seems to be a request for something that doesn't really have anything to do with the topic. You want a file manager? Set up SVN/GIT or something. In all, this coincides with what I and several others have also brought up. We need to get out of this game. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
Josh Berkus wrote: > All, > > My $0.02: > > With the presensce today of Launchpad, Codehaus, SourceForge, Tigris, > Java.net, CPAN, GEM, Developerworks, Github, Code.Google.com, and > others, it seems silly for our project to be putting our scarce admin > resources into maintaining/improving an outdated collab site. Let > others do the work. > > There's also a 2nd advantage to having the PG accessory project mostly > hosted elsewhere: it makes us more visible to outside communities. and makes it harder to aggregate them back into a canonical search/aggregator which is what some people want... > > What we need out of pgfoundry is five things, none of which require a > full collab framework, and some of which are really unrelated to the others: > > 1) a place for less offical mailing lists (e.g. non-permanent > non-@postgresql.org mailing lists) which can be created without the > whole process required for a new "official" list. Note that many of > these lists are not related to any code development project. I hope you are not advocating we should put those lists on @postgresql.org again which is almost the opposite of what you proposed with "hosting stuff elsewhere. Also a fair number of the above mentioned resources don't actually provide mailinglists. > > 2) a place for web pages/documentation for some projects (which could be > a wiki, or something else) hmm? again this sounds like a central wiki (which we have) or are you asking for every project running their own wiki? > > 3) a search and download service for postgresql accessories (something > pgfoundry currently does a poor job of) > > 4) a news feed for postgresql accessories (something pgfoundry currently > does a bad job of) again the news feed stuff is mostly a tool issue (newer fusionforge versions do actually have way better RSS feed capabilities). However what we probably want is a thin aggregation layer on top of those (maybe a version of planet.postgresql.org on steriods with aggregates the various feeds and adds search on top). > > 5) A place to store files for download for internal project use which is > easier to manage than mediawiki's "images", and includes the ability to > restrict files to a specific access list. Like (1), these files are > largely not related to specific development projects. imho that one is not at all related to pgfoundry or the problem at hand. > > It seems to me that *all* of the above could be better done than how > pgfoundry does it, and done in a simpler and more maintainable way. so what place would you redirect people too if they ask for a listing of stuff related to postgresql? and no I don't think a manually maintained "software catalogue" like we have on the website is any/much better. What we need is aggregation of information and it is kind of hard to see how we would get that out of any of the existing collab sites (except maybe freshmeat but even that would not work too well). For stuff on pgf we essentially get most of the important information for "free" as part of people running their projects. Just because we failed to utilize that information so far does not mean that the whole concept is flawed. Stefan
On Jan 4, 2010, at 12:06 PM, Stefan Kaltenbrunner wrote: > and makes it harder to aggregate them back into a canonical search/aggregator which is what some people want... How so? It's not hard to aggregate stuff, and we're not doing it *at all* right now. > I hope you are not advocating we should put those lists on @postgresql.org again which is almost the opposite of what youproposed with "hosting stuff elsewhere. Also a fair number of the above mentioned resources don't actually provide mailinglists. Any subdomain would do. >> 2) a place for web pages/documentation for some projects (which could be >> a wiki, or something else) > > hmm? again this sounds like a central wiki (which we have) or are you asking for every project running their own wiki? The latter. Which most other project hosting sites already offer. > again the news feed stuff is mostly a tool issue (newer fusionforge versions do actually have way better RSS feed capabilities).However what we probably want is a thin aggregation layer on top of those (maybe a version of planet.postgresql.orgon steriods with aggregates the various feeds and adds search on top). Yes. > imho that one is not at all related to pgfoundry or the problem at hand. Well, it's certainly related to download URLs. But it's not at all what pgFoundry does, I agree. > so what place would you redirect people too if they ask for a listing of stuff related to postgresql? and no I don't thinka manually maintained "software catalogue" like we have on the website is any/much better. Agreed. Best, David
David E. Wheeler wrote: > On Jan 4, 2010, at 12:06 PM, Stefan Kaltenbrunner wrote: > >> and makes it harder to aggregate them back into a canonical search/aggregator which is what some people want... > > How so? It's not hard to aggregate stuff, and we're not doing it *at all* right now. well exactly my point - that is what I think we really need and basing it upon a service we directly control is certainly easier than doing (useful) aggregation of only external services. That said we probably need both :) > >> I hope you are not advocating we should put those lists on @postgresql.org again which is almost the opposite of whatyou proposed with "hosting stuff elsewhere. Also a fair number of the above mentioned resources don't actually providemailinglists. > > Any subdomain would do. why centralize again? if we are advocating external resources why would we bother with maintaining an even more complex mailinglist setup? > >>> 2) a place for web pages/documentation for some projects (which could be >>> a wiki, or something else) >> hmm? again this sounds like a central wiki (which we have) or are you asking for every project running their own wiki? > > The latter. Which most other project hosting sites already offer. ok but still you would have to aggregate all the stuff on those wikis back into the (hypothetical) aggregation/umbrella service ;) Stefan
On Jan 4, 2010, at 12:30 PM, Stefan Kaltenbrunner wrote: > well exactly my point - that is what I think we really need and basing it upon a service we directly control is certainlyeasier than doing (useful) aggregation of only external services. That said we probably need both :) Yes, because whether or not pgFoundry sticks around, lots of folks will use other stuff. > why centralize again? if we are advocating external resources why would we bother with maintaining an even more complexmailinglist setup? It's already centralized on pgFoundry. What's the difference? >> The latter. Which most other project hosting sites already offer. > > ok but still you would have to aggregate all the stuff on those wikis back into the (hypothetical) aggregation/umbrellaservice ;) No, you don't need an aggregation of Web sites. Just stuff like news or releases. Best, David
David E. Wheeler wrote: > On Jan 4, 2010, at 12:30 PM, Stefan Kaltenbrunner wrote: > >> well exactly my point - that is what I think we really need and basing it upon a service we directly control is certainlyeasier than doing (useful) aggregation of only external services. That said we probably need both :) > > Yes, because whether or not pgFoundry sticks around, lots of folks will use other stuff. yep > >> why centralize again? if we are advocating external resources why would we bother with maintaining an even more complexmailinglist setup? > > It's already centralized on pgFoundry. What's the difference? I kinda think given the different usecases of the core lists and external ones as well as the huge setup differences (mj2 vs mailman for example) it would make more sense to let those go as well because migration will be at least as complex as guiding people to other services. > >>> The latter. Which most other project hosting sites already offer. >> ok but still you would have to aggregate all the stuff on those wikis back into the (hypothetical) aggregation/umbrellaservice ;) > > No, you don't need an aggregation of Web sites. Just stuff like news or releases. well I can easily imagine that putting a (hopefully powerful) search on top of that aggregator and being able to search data we already have (in the wiki database or pgf itself) seems logical. Stefan
On Jan 4, 2010, at 12:41 PM, Stefan Kaltenbrunner wrote: >> It's already centralized on pgFoundry. What's the difference? > > I kinda think given the different usecases of the core lists and external ones as well as the huge setup differences (mj2vs mailman for example) it would make more sense to let those go as well because migration will be at least as complexas guiding people to other services. I don't mean use the core mailman. I mean have a separate projects mailman, which is exactly what pgf does. Hell, one couldkeep using the exact domains and lists now with no significant downtime, even if pgf went away. > well I can easily imagine that putting a (hopefully powerful) search on top of that aggregator and being able to searchdata we already have (in the wiki database or pgf itself) seems logical. That would be reason to have a central system for release distribution and documentation management. I've got some ideasabout that I'll post later, under a different subject. Best, David
Josh, Stefan, >> 1) a place for less offical mailing lists (e.g. non-permanent >> non-@postgresql.org mailing lists) which can be created without the >> whole process required for a new "official" list. Note that many of >> these lists are not related to any code development project. > > Not sure why this is needed, everyone of the sites listed above provides > mailing list capability. You didn't read the whole thing: "Note that many of these lists are not related to any code development project." For example: funds-group eu-conference press-regional etc. > I hope you are not advocating we should put those lists on > @postgresql.org again which is almost the opposite of what you proposed > with "hosting stuff elsewhere. Nope, I wasn't. I was thinking of just a pglists.org mailman list server for non-essential lists, in the same way we currently use the one on pgfoundry. It would be understood that lists on this server are not included in archives.postgresql.org or the other infrastructure. > Also a fair number of the above mentioned > resources don't actually provide mailinglists. Exactly. >> 2) a place for web pages/documentation for some projects (which could be >> a wiki, or something else) >> > Again, not sure why this is needed, all the sites above provide this. Actually, several don't, or I wouldn't have mentioned it. Launchpad and Code.google.com both do not, at least. > hmm? again this sounds like a central wiki (which we have) or are you > asking for every project running their own wiki? wiki.postgresql.org would be adequate if we could somehow have real URLs for the project home pages, and if it were googlebot compatible. >> 3) a search and download service for postgresql accessories (something >> pgfoundry currently does a poor job of) >> > See Robert's remarks ala Freshmeat Freshmeat is just a listing service. I'd like something a little bit more robust, more like CPAN or GEM. >> 5) A place to store files for download for internal project use which is >> easier to manage than mediawiki's "images", and includes the ability to >> restrict files to a specific access list. Like (1), these files are >> largely not related to specific development projects. > > imho that one is not at all related to pgfoundry or the problem at hand. Yes, it is, because it is one thing pgfoundry is currently being used for and which would be missed if pgfoundry were shut down. --Josh Berkus
On Mon, 2010-01-04 at 11:31 -0800, Josh Berkus wrote: > All, > > My $0.02: > > With the presensce today of Launchpad, Codehaus, SourceForge, Tigris, > Java.net, CPAN, GEM, Developerworks, Github, Code.Google.com, and > others, it seems silly for our project to be putting our scarce admin > resources into maintaining/improving an outdated collab site. Let > others do the work. > +1 > There's also a 2nd advantage to having the PG accessory project mostly > hosted elsewhere: it makes us more visible to outside communities. > +1 > What we need out of pgfoundry is five things, none of which require a > full collab framework, and some of which are really unrelated to the others: > > 1) a place for less offical mailing lists (e.g. non-permanent > non-@postgresql.org mailing lists) which can be created without the > whole process required for a new "official" list. Note that many of > these lists are not related to any code development project. Not sure why this is needed, everyone of the sites listed above provides mailing list capability. > > 2) a place for web pages/documentation for some projects (which could be > a wiki, or something else) > Again, not sure why this is needed, all the sites above provide this. > 3) a search and download service for postgresql accessories (something > pgfoundry currently does a poor job of) > See Robert's remarks ala Freshmeat > 4) a news feed for postgresql accessories (something pgfoundry currently > does a bad job of) Freshmeat style. > > 5) A place to store files for download for internal project use which is > easier to manage than mediawiki's "images", and includes the ability to > restrict files to a specific access list. Like (1), these files are > largely not related to specific development projects. This seems to be a request for something that doesn't really have anything to do with the topic. You want a file manager? Set up SVN/GIT or something. In all, this coincides with what I and several others have also brought up. We need to get out of this game. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> There's also a 2nd advantage to having the PG accessory project mostly >> hosted elsewhere: it makes us more visible to outside communities. > > and makes it harder to aggregate them back into a canonical > search/aggregator which is what some people want... We're never going to have that. See below. ... > so what place would you redirect people too if they ask for a listing of > stuff related to postgresql? and no I don't think a manually maintained > "software catalogue" like we have on the website is any/much better. There is no single *place* we can redirect people to, nor will there ever be moving forward. It's way too late for that. Look at the number of Postgres related projects that are *not* on pgf, and ask yourself if they will ever migrate back to pgf or its successor (hint: no). > What we need is aggregation of information and it is kind of hard to see > how we would get that out of any of the existing collab sites (except > maybe freshmeat but even that would not work too well). For stuff on pgf > we essentially get most of the important information for "free" as part > of people running their projects. Just because we failed to utilize that > information so far does not mean that the whole concept is flawed. I think it does indicate just that. How many years has gborg and now pgfoundry limped along? I agree that we can do better with a central listing. Rather than the hard to navigate and hard to find software catalogoue (or however Dave spells it :), let's create a page on the wiki that lists all interesting and active Postgres related projects. Not a category, not a set of pages, a single page. There are probably at most 50 such projects. The inclusion rule would be simple: someone who cares enough about a particular project can get a wiki account and add it in themselves. Name, link, short description, done. In case I'm not clear, I'm also +1 for shutting down pgf at some point. It's a big jumbled mess of unloved and unfinished projects right now, with a tiny handful of truly active and useful projects. Cut them all free, and the survivors will find other homes (e.g. github). I know that's harsh, but it's 2010 and pgf is still embarassingly bad after all these years. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201001051330 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktDhb8ACgkQvJuQZxSWSsgDcgCbBlXAv8g9DiQPkqf124pbcZyW N/8AoIdLOkFN7es5Kis1niqoYIC7qAD+ =i0dZ -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: > let's create a page on the > wiki that lists all interesting and active Postgres related projects. > Not a category, not a set of pages, a single page. There are probably > at most 50 such projects. The inclusion rule would be simple: someone > who cares enough about a particular project can get a wiki account > and add it in themselves. Name, link, short description, done. +1 if there's also a column or two that states what version(s?) of postgres it works with. Should help find abandoned projects if it doesn't get updated for a few releases; and should help users avoid (or find) pre-production projects if the column says it only works with cvs head.
Greg Sabino Mullane wrote: > Rather than the hard to navigate and hard to find software > catalogoue (or however Dave spells it :), let's create a page on the > wiki that lists all interesting and active Postgres related projects. > Not a category, not a set of pages, a single page. There are probably at most 50 such projects Here's a stub page for discussion: http://wiki.postgresql.org/wiki/Add-Ons_and_Tools Upthread I estimated the number of projects as being between 50 and 100, so your take on the scope is similar to mine. The hard part here will be accurately determining the version compatibility situation of each project. This is IMHO one of the most important things the community needs to be better about labeling anyway. I see Ron already chimed in with a similar sentiment. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Tue, Jan 5, 2010 at 11:32 PM, Greg Smith <greg@2ndquadrant.com> wrote: > Greg Sabino Mullane wrote: >> >> Rather than the hard to navigate and hard to find software >> catalogoue (or however Dave spells it :), let's create a page on the >> wiki that lists all interesting and active Postgres related projects. >> Not a category, not a set of pages, a single page. There are probably at >> most 50 such projects > > Here's a stub page for discussion: > http://wiki.postgresql.org/wiki/Add-Ons_and_Tools > > Upthread I estimated the number of projects as being between 50 and 100, so > your take on the scope is similar to mine. The hard part here will be > accurately determining the version compatibility situation of each project. > This is IMHO one of the most important things the community needs to be > better about labeling anyway. I see Ron already chimed in with a similar > sentiment. The catalogue was written after a great deal of discussion precisely because we were fed up with having multiple pages in different places listing all the addons etc, and causing much confusion for users and a maintenance headache for us. Kindly don't revert us to that state by creating yet another page following a couple of emails on an otherwise unrelated thread. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Josh Berkus a écrit : > Josh, Stefan, > >>> 1) a place for less offical mailing lists (e.g. non-permanent >>> non-@postgresql.org mailing lists) which can be created without the >>> whole process required for a new "official" list. Note that many of >>> these lists are not related to any code development project. >> Not sure why this is needed, everyone of the sites listed above provides >> mailing list capability. > > You didn't read the whole thing: "Note that many of these lists are not > related to any code development project." > > For example: > funds-group > eu-conference > press-regional > etc. > hi guys, While i don't have a strong opinion on this whole thread, i really think that local tools ( mailing-lists, websites ) should be handled by local communities. For example, the .fr platform already offers mailing-lists since 2006 and so far we have 9 active lists. PG Europe also has its own ressources. From my perspective, i don't see the need of another centralized mailing-list system on .org Even if the project is small and people don't want to manage a mailing-list software themself, there are free mailing-lists services out there ( yahoogroups and google groups are obvious ,but there are alternatives too )
Damien, > While i don't have a strong opinion on this whole thread, i really think > that local tools ( mailing-lists, websites ) should be handled by local > communities. > > For example, the .fr platform already offers mailing-lists since 2006 > and so far we have 9 active lists. PG Europe also has its own ressources. > > From my perspective, i don't see the need of another centralized > mailing-list system on .org None of the mailing lists we're talking about *are* "local". press-regional is international, funds-group is as well, etc. I think spinning up (or merely keeping) one mailman instance on postgresql.org resources for non-critical and/or private lists isn't much of a resource drain. Esp. if that mail server isn't tied to pgFoundry, so that we can (for example) delete lists which are inactive. --Josh Berkus
Josh Berkus a écrit : > Damien, > >> While i don't have a strong opinion on this whole thread, i really think >> that local tools ( mailing-lists, websites ) should be handled by local >> communities. >> >> For example, the .fr platform already offers mailing-lists since 2006 >> and so far we have 9 active lists. PG Europe also has its own ressources. >> >> From my perspective, i don't see the need of another centralized >> mailing-list system on .org > > None of the mailing lists we're talking about *are* "local". > press-regional is international, funds-group is as well, etc. > ok i probably misunderstood what you meant by "funds-group" and "eu-conference". Anyway To me, fund raising is a very "local" activity because each country/culture has its own ways to deal with it. But that's way out of topic. Sorry for the noise.
> ok i probably misunderstood what you meant by "funds-group" and > "eu-conference". Anyway To me, fund raising is a very "local" activity > because each country/culture has its own ways to deal with it. But > that's way out of topic. funds-group is attached to SPI, so it's the one "international" fundraising group we have. I'm not sure if we have "local" lists on pgfoundry now; probably. However, we're bound to have some local groups who don't have internet infrastructure of their own, no? --Josh Berkus
Dave Page wrote: > The catalogue was written after a great deal of discussion precisely > because we were fed up with having multiple pages in different places > listing all the addons etc, and causing much confusion for users and a > maintenance headache for us. > The concept I thought was interesting and wanted to explore for a minute was what a single page listing all the still active free add-on components in the briefest way possible would look like, as a potential replacement for the "place to find add-ons" component of pgFoundry. Maybe that page could be produced as a view out of the software catalogue, but it's missing two of the three critical pieces of data: the version compatibility info and a *short* description. You'd also have to add a lot more projects. If you're proposing that the catalogue is capable of serving the role of replacing the project location aspect of pgFoundry, that's a reasonable position. But I feel that would take some improvements to the catalogue to do it, which would bring us right back to prototyping what they might look like. Whenever I send someone to either the catalogue or pgFoundry suggesting it's filled with the useful pieces they expect bundled with the database, ones that are available but just distributed separately in PostgreSQL, they return either overwhelmed or having tried something out only to discover it was obsolete. I don't think you see this problem as often because you're often distributing a larger package that includes compatible versions of many of those components, but that's not right for everyone. > Kindly don't revert us to that state by creating yet another page > following a couple of emails on an otherwise unrelated thread. > If you look you'll see that page is referenced exactly nowhere except on this list; I didn't even link to it on any other wiki pages. I thought it was easier to spend 10 minutes producing a visual prototype than to just talk about what the page might look like instead. If this discussion dies down and it doesn't go anywhere useful, I'll wipe it out. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
Josh Berkus wrote: > > > ok i probably misunderstood what you meant by "funds-group" and > > "eu-conference". Anyway To me, fund raising is a very "local" activity > > because each country/culture has its own ways to deal with it. But > > that's way out of topic. > > funds-group is attached to SPI, so it's the one "international" > fundraising group we have. FWIW it's not all that international anyway, because it's subject to US embargoes and other funny stuff. Which makes me wonder what's the usefulness of it at all, seeing how PostgreSQL-US is already raising funds for the US community. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Wed, 2010-01-06 at 17:14 -0300, Alvaro Herrera wrote: > Josh Berkus wrote: > > > > > ok i probably misunderstood what you meant by "funds-group" and > > > "eu-conference". Anyway To me, fund raising is a very "local" activity > > > because each country/culture has its own ways to deal with it. But > > > that's way out of topic. > > > > funds-group is attached to SPI, so it's the one "international" > > fundraising group we have. > > FWIW it's not all that international anyway, because it's subject to US > embargoes and other funny stuff. Every country has their own rules and regulations that have to be followed. SPI is as International as it is going to get. > Which makes me wonder what's the > usefulness of it at all, seeing how PostgreSQL-US is already raising > funds for the US community. The majority of money SPI spent in the last year had nothing to do with the United States. There is some, but most went to things like sponsoring PgCon.BR and PgCon.JP. It has also sponsored PgDay.EU (not this past one but the one before.) Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> funds-group is attached to SPI, so it's the one "international" >> fundraising group we have. > FWIW it's not all that international anyway, because it's subject to US > embargoes and other funny stuff. Which makes me wonder what's the > usefulness of it at all, seeing how PostgreSQL-US is already raising > funds for the US community. Well, that's a bit of a stretch to say it's not international. Like any other organization, it has to be based *somewhere*, and any place will have its little quirks and problems. In this case, the United States has a stupid anti-Cuba fixation. But Debian (and to a lesser extent Postgres) has been using SPI 'internationally' just fine for years. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201001061523 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktE8YsACgkQvJuQZxSWSsivUACg9hBEPTRuYUK1JM6Rpj0K2iCs MhIAoMN2R+eRd8fw8JYL5e2JH3VPzyfp =6oBY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Dave wrote: >> Here's a stub page for discussion: >> http://wiki.postgresql.org/wiki/Add-Ons_and_Tools > > The catalogue was written after a great deal of discussion precisely > because we were fed up with having multiple pages in different places > listing all the addons etc, and causing much confusion for users and a > maintenance headache for us. > > Kindly don't revert us to that state by creating yet another page > following a couple of emails on an otherwise unrelated thread. The other Greg's just made a quick prototype. I was all for the catalog when we created it, as it was (and still is) better than what we had before. But there is no shame in admitting later on that it is not working out, and could be improved upon. It's certainly much better than pgfoundry's listings, which as other have pointed out, does more harm than good. In that respect, I'd like us to be a little *less* like CPAN. Using CPAN is great if you already know what you want, but there is no way to sort the good from the bad, or know which of 10 similar projects to choose. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201001061527 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAktE8sMACgkQvJuQZxSWSsjUxgCgpVAhz9fgxICkyeEukE2xyHqz 7MoAn0gBvgiJE+7ER8cXLTkAKUTNDKOw =JdDo -----END PGP SIGNATURE-----
On Jan 6, 2010, at 12:30 PM, Greg Sabino Mullane wrote: > In that respect, I'd like us to be a little *less* like CPAN. Using CPAN > is great if you already know what you want, but there is no way to sort > the good from the bad, or know which of 10 similar projects to choose. That's the kind of problem to have! Davdi
On Wed, Jan 6, 2010 at 4:48 PM, David E. Wheeler <david@kineticode.com> wrote: > On Jan 6, 2010, at 12:30 PM, Greg Sabino Mullane wrote: > >> In that respect, I'd like us to be a little *less* like CPAN. Using CPAN >> is great if you already know what you want, but there is no way to sort >> the good from the bad, or know which of 10 similar projects to choose. > > That's the kind of problem to have! Not really. The saving grace wrt/CPAN is that for some reason nearly all Perl modules have documentation, it's all in the same format, and CPAN lets you browse it on the web. That's often enough to distinguish the good stuff from the crap. IMHO, if it weren't for that, it would be worthless. ...Robert
On Wed, 2010-01-06 at 17:14 -0300, Alvaro Herrera wrote: > Josh Berkus wrote: > > > > > ok i probably misunderstood what you meant by "funds-group" and > > > "eu-conference". Anyway To me, fund raising is a very "local" activity > > > because each country/culture has its own ways to deal with it. But > > > that's way out of topic. > > > > funds-group is attached to SPI, so it's the one "international" > > fundraising group we have. > > FWIW it's not all that international anyway, because it's subject to US > embargoes and other funny stuff. Every country has their own rules and regulations that have to be followed. SPI is as International as it is going to get. > Which makes me wonder what's the > usefulness of it at all, seeing how PostgreSQL-US is already raising > funds for the US community. The majority of money SPI spent in the last year had nothing to do with the United States. There is some, but most went to things like sponsoring PgCon.BR and PgCon.JP. It has also sponsored PgDay.EU (not this past one but the one before.) Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir.
On Jan 6, 2010, at 5:18 PM, Robert Haas wrote: > Not really. The saving grace wrt/CPAN is that for some reason nearly > all Perl modules have documentation, it's all in the same format, and > CPAN lets you browse it on the web. That's often enough to > distinguish the good stuff from the crap. IMHO, if it weren't for > that, it would be worthless. search.cpan.org has been fantastic for the success of CPAN, but CPAN was pretty successful before that site came along. Best, David
On Wed, Jan 6, 2010 at 8:02 PM, Greg Smith <greg@2ndquadrant.com> wrote: > The concept I thought was interesting and wanted to explore for a minute was > what a single page listing all the still active free add-on components in > the briefest way possible would look like, as a potential replacement for > the "place to find add-ons" component of pgFoundry. 'add-ons' is far too short sighted (much like the seemingly endless mentions of CPAN). There are far more things than just add-ons to deal with, and most of them could never be installed/managed with anything like CPAN. Consider just Windows for a minute - we have database add-ons (think contrib modules), applications such as pgAdmin, .NET applications which may need certain versions of the .NET runtimes, IIS applications, PHP apps that need a suitable Apache/PHP build, JBOSS apps...... All those things are things we want to tell users about, to show off the rich range of 'stuff' you can get to work with PostgreSQL. Most don't even remotely fit into the add-ons class though. > Maybe that page could > be produced as a view out of the software catalogue, but it's missing two of > the three critical pieces of data: the version compatibility info and a > *short* description. You'd also have to add a lot more projects. The short description could be added if people felt it was required. It wasn't something that was wanted when we specced out the original project. The version compatibility info was one of the things we intentionally left off. Why? Because after a we added a project/product to any of the old pages that had anything like that kind of info, the data invariably became out of date within a few months, and we simply didn't (and still do not) have the manpower to keep those sort of ever-changing details up to date. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Thu, Jan 7, 2010 at 11:00 AM, Dave Page <dpage@pgadmin.org> wrote: > 'add-ons' is far too short sighted (much like the seemingly endless > mentions of CPAN). There are far more things than just add-ons to deal > with, and most of them could never be installed/managed with anything > like CPAN. I claim there's nothing useful we can do with those things anyways. The reason CPAN is a success is because it tackles a single problem which is susceptible to a technical solution and makes people's lives easier. > Consider just Windows for a minute - we have database > add-ons (think contrib modules), applications such as pgAdmin, .NET > applications which may need certain versions of the .NET runtimes, IIS > applications, PHP apps that need a suitable Apache/PHP build, JBOSS > apps...... > > All those things are things we want to tell users about, to show off > the rich range of 'stuff' you can get to work with PostgreSQL. Most > don't even remotely fit into the add-ons class though. Well we want the whole world of data driven software to use Postgres don't we? Trying to market software based on what databases it interoperates with and organize the world into web sites with one for each database layer seems backwards. It makes more sense to organize and market software based on the user visible functionality and just assume they all support postgres. -- greg
On Jan 7, 2010, at 11:34 AM, Greg Stark wrote: > I claim there's nothing useful we can do with those things anyways. > The reason CPAN is a success is because it tackles a single problem > which is susceptible to a technical solution and makes people's lives > easier. Well put! Best, David
Dave Page wrote: > The version compatibility info was one of the things we intentionally > left off. Why? Because after a we added a project/product to any of > the old pages that had anything like that kind of info, the data > invariably became out of date within a few months, and we simply > didn't (and still do not) have the manpower to keep those sort of > ever-changing details up to date. > You might have noted that part of the suggestion I was acting on here included making the project maintainers responsible (and able) to keep that info up to date. At no point can it ever be the WWW team's responsibility to do that sort of thing--everybody knows that won't scale. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Thu, Jan 7, 2010 at 10:45 PM, Greg Smith <greg@2ndquadrant.com> wrote: > You might have noted that part of the suggestion I was acting on here > included making the project maintainers responsible (and able) to keep that > info up to date. At no point can it ever be the WWW team's responsibility > to do that sort of thing--everybody knows that won't scale. The problem is, they rarely do keep them up to date. We get the occasional email requesting changes, but most people aren't checking these things regularly enough to keep them up to date. I'd also note, that the addition of an 'edit' option to the existing pages would seem sensible, as opposed to the 'throw the bath out with the water' approach of just moving it all to the wiki, where marketing teams will have a field day making their products stand out. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave, > I'd also note, that the addition of an 'edit' option to the existing > pages would seem sensible, as opposed to the 'throw the bath out with > the water' approach of just moving it all to the wiki, where marketing > teams will have a field day making their products stand out. Unfortunately, I'd say that trying to improve the GForge code would take more effort than coding a new application ourselves. And, btw, Wheeler's PGAN proposal (on hackers) obviously does not address drivers, applications, developer tools, etc. But I'd say that for those, an expansion of the existing application listing service we have makes more sense than preserving pgFoundry as an extremely inefficient directory. --Josh Berkus
On Fri, Jan 8, 2010 at 6:57 PM, Josh Berkus <josh@agliodbs.com> wrote: > Dave, > >> I'd also note, that the addition of an 'edit' option to the existing >> pages would seem sensible, as opposed to the 'throw the bath out with >> the water' approach of just moving it all to the wiki, where marketing >> teams will have a field day making their products stand out. > > Unfortunately, I'd say that trying to improve the GForge code would take > more effort than coding a new application ourselves. We're talking about the Software Catalogue on the website, not GForge. > And, btw, Wheeler's PGAN proposal (on hackers) obviously does not > address drivers, applications, developer tools, etc. But I'd say that > for those, an expansion of the existing application listing service we > have makes more sense than preserving pgFoundry as an extremely > inefficient directory. Err, yes. That sounds like a good idea :-p -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
>> And, btw, Wheeler's PGAN proposal (on hackers) obviously does not >> address drivers, applications, developer tools, etc. But I'd say that >> for those, an expansion of the existing application listing service we >> have makes more sense than preserving pgFoundry as an extremely >> inefficient directory. > > Err, yes. That sounds like a good idea :-p Ok, I misunderstood you. Then we're in accord. My basic thinking is that rather than trying to fix pgFoundry or replace it with some single piece of software which addresses the 7 things people use pgfoundry for, we should instead look at those 7 services as *separate* web services for postgresql.org, and address them with separate, *simple* pieces of software. Therefore: Source Code management:git.postgresql.orgLaunchpad, code.google.com, SF.net, etc. Listing and Searching of PG-related Software:Software Catalogsearch.pgan.org (for extensions) Distribution and Installation of PG-related Software:StackBuilderpgan.org (for extensions) News Feed:projects-planet.postgresql.org, or similar Web Pages:expansion of Software Catalog, or a wiki Unsupported Mailing Listsmailman server File Sharing, with permissions:some other tool, or SocialText account. As you can see, none of the above requires us to operate a collab environment. In fact, given our experience, I'm wondering if the whole concept of a collab environment is flawed. --Josh Berkus
On Fri, Jan 8, 2010 at 8:24 PM, Josh Berkus <josh@agliodbs.com> wrote: > > My basic thinking is that rather than trying to fix pgFoundry or replace > it with some single piece of software which addresses the 7 things > people use pgfoundry for, we should instead look at those 7 services as > *separate* web services for postgresql.org, and address them with > separate, *simple* pieces of software. Therefore: Well, I'm for improving the catalogue to provide what people want from it, but I'm certainly not going to support web pages, mailing lists, file sharing or the one your forgot, bug tracking as well as pgFoundry. Given past experience of migration, I can only believe that the least painful, and most likely to happen option is an upgrade of pgFoundry on a new, documented VM that the sysadmin team can manage properly. Trying to get rid of pgFoundry will lead to years of faffing about while we try to migrate people - if we even can migrate them anywhere without losing mailing list/tracker history etc. I don't have any great desire to move my own projects (though I won't hold up a migration if that's what we choose), but frankly I just don't see anyone knuckling down and doing it. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Fri, Jan 8, 2010 at 21:24, Josh Berkus <josh@agliodbs.com> wrote: > > My basic thinking is that rather than trying to fix pgFoundry or replace > it with some single piece of software which addresses the 7 things > people use pgfoundry for, we should instead look at those 7 services as > *separate* web services for postgresql.org, and address them with > separate, *simple* pieces of software. Therefore: > > Source Code management: > git.postgresql.org I actually think we should deprecate the use of git.postgresql.org for anything other than postgresql repositories for people working on patches and official community repos (like website code etc). We do a much worse service than say github for general projects. As long as we can solve the visibility part (and frankly, if you think pgfoundry does a bad job at that, the git server doesn't even try) > Listing and Searching of PG-related Software: > Software Catalog > search.pgan.org (for extensions) So we're not making it a community project? ;) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
> Well, I'm for improving the catalogue to provide what people want from > it, but I'm certainly not going to support web pages, mailing lists, > file sharing or the one your forgot, bug tracking as well as > pgFoundry. AFAIK, nobody is using the bug tracking since it appears to be pretty much broken. > Given past experience of migration, I can only believe that the least > painful, and most likely to happen option is an upgrade of pgFoundry > on a new, documented VM that the sysadmin team can manage properly. > Trying to get rid of pgFoundry will lead to years of faffing about > while we try to migrate people - if we even can migrate them anywhere > without losing mailing list/tracker history etc. Well, we can simply keep it on life support while we encourage people to use other services. Then, like GBorg, we can kill it because nothing on it is maintained anymore. --Josh Berkus
On Fri, Jan 8, 2010 at 9:00 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> Well, I'm for improving the catalogue to provide what people want from >> it, but I'm certainly not going to support web pages, mailing lists, >> file sharing or the one your forgot, bug tracking as well as >> pgFoundry. > > AFAIK, nobody is using the bug tracking since it appears to be pretty > much broken. Works fine on the projects I've used it on. What's up with it? >> Given past experience of migration, I can only believe that the least >> painful, and most likely to happen option is an upgrade of pgFoundry >> on a new, documented VM that the sysadmin team can manage properly. >> Trying to get rid of pgFoundry will lead to years of faffing about >> while we try to migrate people - if we even can migrate them anywhere >> without losing mailing list/tracker history etc. > > Well, we can simply keep it on life support while we encourage people to > use other services. Then, like GBorg, we can kill it because nothing on > it is maintained anymore. It's been on life support for years. I honestly believe it'll be less effort to rebuild it, and then take it off life support as a properly managed service, than go through the pain and embarrassment of having it rot for years whilst noone does anything about migrations for users. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Josh Berkus wrote: > Dave, > >> I'd also note, that the addition of an 'edit' option to the existing >> pages would seem sensible, as opposed to the 'throw the bath out with >> the water' approach of just moving it all to the wiki, where marketing >> teams will have a field day making their products stand out. > > Unfortunately, I'd say that trying to improve the GForge code would take > more effort than coding a new application ourselves. well gforge/fusionforge is actually improving - the fault is actually with not taking advantage of those improvements. > > And, btw, Wheeler's PGAN proposal (on hackers) obviously does not > address drivers, applications, developer tools, etc. But I'd say that > for those, an expansion of the existing application listing service we > have makes more sense than preserving pgFoundry as an extremely > inefficient directory. again even if pgan succeeds (which is still a theoretical thing) calling pgf an extremely inefficient directory is probably not really fair, If we failed to utilize pgf as a single resource who says that we will succeed in utilizing a mix of random external resources as well as some unestablished custom developed solutions? Stefan
Dave Page wrote: <blockquote cite="mid:937d27e11001080057t1309b9fcod75fa78bf26ddf2f@mail.gmail.com" type="cite"><pre wrap="">OnThu, Jan 7, 2010 at 10:45 PM, Greg Smith <a class="moz-txt-link-rfc2396E" href="mailto:greg@2ndquadrant.com"><greg@2ndquadrant.com></a>wrote: </pre><blockquote type="cite"><pre wrap="">You might have noted that part of the suggestion I was acting on here included making the project maintainers responsible (and able) to keep that info up to date. At no point can it ever be the WWW team's responsibility to do that sort of thing--everybody knows that won't scale. </pre></blockquote><pre wrap=""> The problem is, they rarely do keep them up to date. We get the occasional email requesting changes, but most people aren't checking these things regularly enough to keep them up to date. </pre></blockquote><br /> There's a chicken/egg problem here: thecatalogue isn't very useful to a lot of people due to its UI issues. Because of that, people don't really use the catalog. As such, there's very little motivation to keep it current anyway.<br /><br /> As for concerns about project datagetting stale, the whole point of talking about the compatible version is that projects are out of date already, butthere's no way to know that. If there were a version tag on there, and it mentioned an ancient version because the maintainerdoesn't care, that's a valuable data point for someone browsing the catalogue, right? If the catalog gets to whereit's useful to more people, the projects that have good community support will mention they work with the latest versionsas they come out and get updated there, and the abandoned projects won't, and from some perspectives that could beconsidered a good thing because it makes it easier to figure out which are the serious projects.<br /><br /><blockquotecite="mid:937d27e11001080057t1309b9fcod75fa78bf26ddf2f@mail.gmail.com" type="cite"><pre wrap="">I'd also note,that the addition of an 'edit' option to the existing pages would seem sensible, as opposed to the 'throw the bath out with the water' approach of just moving it all to the wiki, where marketing teams will have a field day making their products stand out. </pre></blockquote> One reason the format on that prototypepage was so constrained was to keep that from being possible without said edit sticking out. If all the other entriesare short, somebody who tries to make their product stand out by bucking the standard format is going to look prettysilly. But the larger point that encouraging edit wars on a resources mainly aimed at community support is taken anyway. <br /><br /> Let me see if I can wrap up this part...as for a wishlist for what the catalogue would need to do inorder to work better as a community project locator, I think those are:<br /><br /> -Make it easy for people to edit theircatalogue entries.<br /> -Add a short description field, limited to around 60 characters. Can initially populate thisby taking the first 57 characters of the existing description and adding in "..." if it's longer than that.<br /> -Adda new "Compatible database versions" field. Make these all empty initially. Seeing who fills them in will be an interestingbit of data about which projects are paying attention.<br /> -Create a couple of simplified views of the data:<br/> --Single page list of all entries in the catalog, with entires that fit in a moderately wide line: product, shortdescription, version info, license<br /> --Same thing but only the open-source projects listed<br /><br /> I know I'drather see work on those things instead of trying to salvage pgFoundry as a catalog, which as the other Greg pointed outis an effort whose opportunity has already passed.<br /><br /> P.S. "Add-Ons and Tools" page is now removed from the wiki,its usefulness as a prototype seems to have passed.<br /><br /><pre class="moz-signature" cols="72">-- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> <a class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a> </pre>
On Wednesday 06 January 2010 14:47:28 Josh Berkus wrote: > > ok i probably misunderstood what you meant by "funds-group" and > > "eu-conference". Anyway To me, fund raising is a very "local" activity > > because each country/culture has its own ways to deal with it. But > > that's way out of topic. > > funds-group is attached to SPI, so it's the one "international" > fundraising group we have. > > I'm not sure if we have "local" lists on pgfoundry now; probably. > However, we're bound to have some local groups who don't have internet > infrastructure of their own, no? > I count 9 services who offer mailing lists for open source projects on http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities, and that doesn't contain things like yahoo/google groups and other strictly mailing list options. Is there some reason you don't think those would work? -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
On Friday 08 January 2010 16:04:27 Dave Page wrote: > On Fri, Jan 8, 2010 at 9:00 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> Well, I'm for improving the catalogue to provide what people want from > >> it, but I'm certainly not going to support web pages, mailing lists, > >> file sharing or the one your forgot, bug tracking as well as > >> pgFoundry. > > > > AFAIK, nobody is using the bug tracking since it appears to be pretty > > much broken. > > Works fine on the projects I've used it on. What's up with it? > > >> Given past experience of migration, I can only believe that the least > >> painful, and most likely to happen option is an upgrade of pgFoundry > >> on a new, documented VM that the sysadmin team can manage properly. > >> Trying to get rid of pgFoundry will lead to years of faffing about > >> while we try to migrate people - if we even can migrate them anywhere > >> without losing mailing list/tracker history etc. > > > > Well, we can simply keep it on life support while we encourage people to > > use other services. Then, like GBorg, we can kill it because nothing on > > it is maintained anymore. > > It's been on life support for years. I honestly believe it'll be less > effort to rebuild it, and then take it off life support as a properly > managed service, than go through the pain and embarrassment of having > it rot for years whilst noone does anything about migrations for > users. > It's already painful/embarrassing in it's current shape, so a little more of that really shouldn't be our primary concern. But you're right, let's not pretend that we're really going to migrate people when we wont, just send out an email now saying that as of Jan 1, 2011, we will be shutting the site down, and that we encourage all users to move thier projects elsewhere before then. No waiting, no dragging on; set a deadline, follow through, end of story. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
On Sun, Jan 10, 2010 at 5:01 AM, Robert Treat <xzilla@users.sourceforge.net> wrote: > On Wednesday 06 January 2010 14:47:28 Josh Berkus wrote: >> > ok i probably misunderstood what you meant by "funds-group" and >> > "eu-conference". Anyway To me, fund raising is a very "local" activity >> > because each country/culture has its own ways to deal with it. But >> > that's way out of topic. >> >> funds-group is attached to SPI, so it's the one "international" >> fundraising group we have. >> >> I'm not sure if we have "local" lists on pgfoundry now; probably. >> However, we're bound to have some local groups who don't have internet >> infrastructure of their own, no? >> > > I count 9 services who offer mailing lists for open source projects on > http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities, > and that doesn't contain things like yahoo/google groups and other strictly > mailing list options. Is there some reason you don't think those would work? How many of those offer any kind of import/export facilities so you can migrate to/from them? And for the record, I remain strongly opposed to shutting down pgFoundry anyway. I have no desire to entrust any of my projects to third parties over with whom I have no come-back if they lose any of may data, and I still have no desire to go through the pain of moving my projects elsewhere and most likely losing a tone of history. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com