Thread: Proposal to shutdown pgFoundry
As most of you will know, the pgFoundry system is in dire need of a huge amount of work. It's running an extremely old version of GForge, which has been hacked about to run on FreeBSD and is almost certainly full of potential security issues. In order to bring the system up to date we would need to do at least the following: - Figure out what functionality changes our version has over the latest release. - Install the latest version of GForge on our new hosting platform. - Re-implement the code changes, if still required. - Figure out how to migrate all the user accounts and related data from FreeBSD to Debian. - Figure out how to migrate all the data from the old system to the new. We've had numerous attempts in the past to do this *before* we had the new hosting platform, all of which failed miserably, due to the lack of people with the time and interest in doing the work. Following some discussions last night at PGCon, I'd therefore like to propose that we deprecate and eventually shutdown the PGFoundry service. This would involve: - Emailing all users with the details of the shutdown timetable. - Suggest users migrate to GitHub or Sourceforge, depending on their needs. - Migrate "core" projects (such as psqlODBC and the press/advocacy project) to mailing lists in postgresql.org (if required) and to git.postgresql.org. - Offer other users tarballs of their CVS repos, mail archives and downloads. - After 6 months, shut down the system and permanently archive it. Comments? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
> - Offer other users tarballs of their CVS repos, mail archives and downloads. > > - After 6 months, shut down the system and permanently archive it. > > Comments? > It's about time? +1 from me. There are much better, free services out there. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
On 05/20/2011 10:15 AM, Dave Page wrote: > As most of you will know, the pgFoundry system is in dire need of a > huge amount of work. It's running an extremely old version of GForge, > which has been hacked about to run on FreeBSD and is almost certainly > full of potential security issues. In order to bring the system up to > date we would need to do at least the following: > > - Figure out what functionality changes our version has over the latest release. afaik there are no features in our version that are not in later versions (or the successor to gforge - that is fusionforge) > > - Install the latest version of GForge on our new hosting platform. fusionforge is packaged > > - Re-implement the code changes, if still required. most of our code changes in the past have been backports of upstream fixes and security updates > > - Figure out how to migrate all the user accounts and related data > from FreeBSD to Debian. that's likely quite hard :/ > > - Figure out how to migrate all the data from the old system to the new. iirc one of the attempts to migrate resulted in quite a few changes to fusionforge to fix the upgrade path but it will still be a huge task. > > We've had numerous attempts in the past to do this *before* we had the > new hosting platform, all of which failed miserably, due to the lack > of people with the time and interest in doing the work. > > Following some discussions last night at PGCon, I'd therefore like to > propose that we deprecate and eventually shutdown the PGFoundry > service. This would involve: > > - Emailing all users with the details of the shutdown timetable. > > - Suggest users migrate to GitHub or Sourceforge, depending on their needs. > > - Migrate "core" projects (such as psqlODBC and the press/advocacy > project) to mailing lists in postgresql.org (if required) and to > git.postgresql.org. > > - Offer other users tarballs of their CVS repos, mail archives and downloads. > > - After 6 months, shut down the system and permanently archive it. sounds like the most sensible way forward until somebody can come up with a very convincing argument on why we should stay in the general hosting business. Stefan
On Fri, May 20, 2011 at 7:15 AM, Dave Page <dpage@pgadmin.org> wrote: > Following some discussions last night at PGCon, I'd therefore like to > propose that we deprecate and eventually shutdown the PGFoundry > service. This would involve: > > - Emailing all users with the details of the shutdown timetable. > > - Suggest users migrate to GitHub or Sourceforge, depending on their needs. > > - Migrate "core" projects (such as psqlODBC and the press/advocacy > project) to mailing lists in postgresql.org (if required) and to > git.postgresql.org. > > - Offer other users tarballs of their CVS repos, mail archives and downloads. > > - After 6 months, shut down the system and permanently archive it. > > Comments? +1 A couple more things: * Enter projects on pgfoundry into the Software Catalogue, and add search functionality to the catalogue. * Collect contact information for the developers of existing and retiring projects. I think it would be very helpful to save people's information, even if we don't have a public resource list. Also, I'd like it in chartreuse. -selena -- http://chesnok.com
Hi, On Fri, 2011-05-20 at 14:15 +0000, Dave Page wrote: <snip heavily> > Comments? I won't object in general (since I'm not maintaining pgfoundry ;) ), but the only positive thing about PGFoundry from my perspective (as a user and packager) is that it is a "PostgreSQL community hosted website", where people can find some 3rd party software, like pgpool, skytools, and other stuff. It is no different than hosting yum repo and pgxn in the community infrastructure, which is fine. When we shut it down, all projects will all go somewhere else, and that somewhere else might sound reliable to the people outside the community. That is the only concern of me. Getting rid of CVS is fine, and they can move their projects to git.postgresql.org, which would be excellent. Still, is there a simple way that PostgreSQL infrastructure team can provide hosting are for tarballs for ex-pgfoundry projects? (I'm sure Tatsuo will be unhappy with shutting pgfoundry, so you might want to talk to him today about this ;) ) (/me will also need to figure out where the projects will go, and update all related spec files, and that is another story) Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
Le 05/20/2011 04:15 PM, Dave Page a écrit : > As most of you will know, the pgFoundry system is in dire need of a > huge amount of work. It's running an extremely old version of GForge, > which has been hacked about to run on FreeBSD and is almost certainly > full of potential security issues. In order to bring the system up to > date we would need to do at least the following: > > - Figure out what functionality changes our version has over the latest release. > > - Install the latest version of GForge on our new hosting platform. > > - Re-implement the code changes, if still required. > > - Figure out how to migrate all the user accounts and related data > from FreeBSD to Debian. > > - Figure out how to migrate all the data from the old system to the new. > > We've had numerous attempts in the past to do this *before* we had the > new hosting platform, all of which failed miserably, due to the lack > of people with the time and interest in doing the work. > > Following some discussions last night at PGCon, I'd therefore like to > propose that we deprecate and eventually shutdown the PGFoundry > service. This would involve: > > - Emailing all users with the details of the shutdown timetable. > > - Suggest users migrate to GitHub or Sourceforge, depending on their needs. > > - Migrate "core" projects (such as psqlODBC and the press/advocacy > project) to mailing lists in postgresql.org (if required) and to > git.postgresql.org. > > - Offer other users tarballs of their CVS repos, mail archives and downloads. > > - After 6 months, shut down the system and permanently archive it. > > Comments? > Seems a really good idea. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
2011/5/20 Devrim GÜNDÜZ <devrim@gunduz.org>: > Hi, > > On Fri, 2011-05-20 at 14:15 +0000, Dave Page wrote: > > <snip heavily> >> Comments? > > I won't object in general (since I'm not maintaining pgfoundry ;) ), but > the only positive thing about PGFoundry from my perspective (as a user > and packager) is that it is a "PostgreSQL community hosted website", > where people can find some 3rd party software, like pgpool, skytools, > and other stuff. It is no different than hosting yum repo and pgxn in > the community infrastructure, which is fine. We can make better use of the software catalog on the main website for this purpose. > When we shut it down, all projects will all go somewhere else, and that > somewhere else might sound reliable to the people outside the community. > That is the only concern of me. Getting rid of CVS is fine, and they can > move their projects to git.postgresql.org, which would be excellent. > Still, is there a simple way that PostgreSQL infrastructure team can > provide hosting are for tarballs for ex-pgfoundry projects? I think we'd want to try to avoid doing that as it would require policing to ensure inappropriate content wasn't uploaded. That is less of an issue now, as the requirements to upload a package to pgFoundry are high enough that people aren't really bothering to use it for inappropriate purposes. That may not be the case if we introduce a simple way to add files to the mirror network. Plus, people can always use SourceForge for distribution. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave Page <dpage@pgadmin.org> writes:
> 2011/5/20 Devrim G�ND�Z <devrim@gunduz.org>:
>> When we shut it down, all projects will all go somewhere else, and that
>> somewhere else might sound reliable to the people outside the community.
>> That is the only concern of me. Getting rid of CVS is fine, and they can
>> move their projects to git.postgresql.org, which would be excellent.
>> Still, is there a simple way that PostgreSQL infrastructure team can
>> provide hosting are for tarballs for ex-pgfoundry projects?
> I think we'd want to try to avoid doing that as it would require
> policing to ensure inappropriate content wasn't uploaded.
... yeah, that's a problem.
> Plus, people can always use SourceForge for distribution.
If you drive people to sourceforge for distribution, what value is there
in git.postgresql.org?
I need to figure out what to do with pg_filedump. All I need for it
is an SCM and someplace to put release tarballs. I'd prefer to use
git.postgresql.org, but if there's nowhere for tarballs, that's not
going to work.
regards, tom lane
2011/5/20 Tom Lane <tgl@sss.pgh.pa.us>: > If you drive people to sourceforge for distribution, what value is there > in git.postgresql.org? A number of us in the sysadmin team see git.postgresql.org as a resource for "family" projects that want to use it, like pgadmin, psqlODBC, JDBC, translation team, press etc. For more general project use, and for personal development trees, the feeling is that GitHub or SourceForge are the appropriate places. > I need to figure out what to do with pg_filedump. All I need for it > is an SCM and someplace to put release tarballs. I'd prefer to use > git.postgresql.org, but if there's nowhere for tarballs, that's not > going to work. Hmm, that's a good example. It would certainly qualify to live on git.postgresql.org using the criteria I have in mind, but I can see the tarballs would be an issue. If we do keep git.postgresql.org for trusted projects, then perhaps it wouldn't be such an issue to give certain users from each one access to a server to upload tarballs into the mirror network. I certainly wouldn't want to offer that to every project on pgFoundry though. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Dave Page's message of vie may 20 11:48:58 -0400 2011: > 2011/5/20 Tom Lane <tgl@sss.pgh.pa.us>: > > I need to figure out what to do with pg_filedump. All I need for it > > is an SCM and someplace to put release tarballs. I'd prefer to use > > git.postgresql.org, but if there's nowhere for tarballs, that's not > > going to work. > > Hmm, that's a good example. It would certainly qualify to live on > git.postgresql.org using the criteria I have in mind, but I can see > the tarballs would be an issue. If we do keep git.postgresql.org for > trusted projects, then perhaps it wouldn't be such an issue to give > certain users from each one access to a server to upload tarballs into > the mirror network. So how does pgadmin deal with tarballs and installers etc? Do they have their own server for that? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 05/20/2011 11:43 AM, Tom Lane wrote: > Dave Page <dpage@pgadmin.org> writes: >> 2011/5/20 Devrim GÜNDÜZ <devrim@gunduz.org>: >>> When we shut it down, all projects will all go somewhere else, and that >>> somewhere else might sound reliable to the people outside the community. >>> That is the only concern of me. Getting rid of CVS is fine, and they can >>> move their projects to git.postgresql.org, which would be excellent. >>> Still, is there a simple way that PostgreSQL infrastructure team can >>> provide hosting are for tarballs for ex-pgfoundry projects? > >> I think we'd want to try to avoid doing that as it would require >> policing to ensure inappropriate content wasn't uploaded. > > ... yeah, that's a problem. > >> Plus, people can always use SourceForge for distribution. > > If you drive people to sourceforge for distribution, what value is there > in git.postgresql.org? > > I need to figure out what to do with pg_filedump. All I need for it > is an SCM and someplace to put release tarballs. I'd prefer to use > git.postgresql.org, but if there's nowhere for tarballs, that's not > going to work. hmm tarballs are a really good point, not sure what to do there - provide some some minimal interface to push them to the mirror network or do we need something more fancy? Stefan
2011/5/20 Dave Page <dpage@pgadmin.org>: > 2011/5/20 Tom Lane <tgl@sss.pgh.pa.us>: >> If you drive people to sourceforge for distribution, what value is there >> in git.postgresql.org? > > A number of us in the sysadmin team see git.postgresql.org as a > resource for "family" projects that want to use it, like pgadmin, > psqlODBC, JDBC, translation team, press etc. For more general project > use, and for personal development trees, the feeling is that GitHub or > SourceForge are the appropriate places. Yeah. Note that there is no reason not to have both. We know several projects - e.g. pgadmin - has that. It's trivial to have a project that's hosted on git.postgresql.org to automatically push mirroring to github, and you can then use github download pages for example. (The system is fully automated - if more people want to start using it, I'll include it in the web interface) >> I need to figure out what to do with pg_filedump. All I need for it >> is an SCM and someplace to put release tarballs. I'd prefer to use >> git.postgresql.org, but if there's nowhere for tarballs, that's not >> going to work. > > Hmm, that's a good example. It would certainly qualify to live on > git.postgresql.org using the criteria I have in mind, but I can see > the tarballs would be an issue. If we do keep git.postgresql.org for > trusted projects, then perhaps it wouldn't be such an issue to give > certain users from each one access to a server to upload tarballs into > the mirror network. > > I certainly wouldn't want to offer that to every project on pgFoundry though. No, definitely not. For one thing, the management stuff for git.postgresql.org doesn't scale that way at all. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, 2011-05-20 at 15:48 +0000, Dave Page wrote: > > I need to figure out what to do with pg_filedump. All I need for it > > is an SCM and someplace to put release tarballs. I'd prefer to use > > git.postgresql.org, but if there's nowhere for tarballs, that's not > > going to work. > > Hmm, that's a good example. It would certainly qualify to live on > git.postgresql.org using the criteria I have in mind, but I can see > the tarballs would be an issue. If we do keep git.postgresql.org for > trusted projects, then perhaps it wouldn't be such an issue to give > certain users from each one access to a server to upload tarballs into > the mirror network. > > I certainly wouldn't want to offer that to every project on pgFoundry > though. We already allow *everyone* to distribute their tarballs through our FTP mirror network. -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
On Fri, May 20, 2011 12:20 pm, Stefan Kaltenbrunner wrote: > On 05/20/2011 11:43 AM, Tom Lane wrote: >> Dave Page <dpage@pgadmin.org> writes: >>> 2011/5/20 Devrim GÜNDÜZ <devrim@gunduz.org>: >>>> When we shut it down, all projects will all go somewhere else, and >>>> that >>>> somewhere else might sound reliable to the people outside the >>>> community. >>>> That is the only concern of me. Getting rid of CVS is fine, and they >>>> can >>>> move their projects to git.postgresql.org, which would be excellent. >>>> Still, is there a simple way that PostgreSQL infrastructure team can >>>> provide hosting are for tarballs for ex-pgfoundry projects? >> >>> I think we'd want to try to avoid doing that as it would require >>> policing to ensure inappropriate content wasn't uploaded. >> >> ... yeah, that's a problem. >> >>> Plus, people can always use SourceForge for distribution. >> >> If you drive people to sourceforge for distribution, what value is there >> in git.postgresql.org? >> >> I need to figure out what to do with pg_filedump. All I need for it >> is an SCM and someplace to put release tarballs. I'd prefer to use >> git.postgresql.org, but if there's nowhere for tarballs, that's not >> going to work. > > hmm tarballs are a really good point, not sure what to do there - > provide some some minimal interface to push them to the mirror network > or do we need something more fancy? > > We need something. I need to be able to push buildfarm client tarballs too, so Tom's not the only person who needs this. Even more importantly, the mailings lists on pgfoundry are a critical piece of the buildfarm infrastructure - that's how status notifications get out to people like Tom. We also need lists for commit notifications and members discussion. I don't much like the idea of sending people off to sourceforge. It's a pity GitHub doesn't have some of those extra features. cheers andrew
On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: > I think we'd want to try to avoid doing that as it would require > policing to ensure inappropriate content wasn't uploaded. (I quoted wrong email in my previous reply, sorry) We already allow *everyone* to distribute their tarballs through our FTP mirror network... -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
2011/5/20 Alvaro Herrera <alvherre@commandprompt.com>: > Excerpts from Dave Page's message of vie may 20 11:48:58 -0400 2011: >> 2011/5/20 Tom Lane <tgl@sss.pgh.pa.us>: > >> > I need to figure out what to do with pg_filedump. All I need for it >> > is an SCM and someplace to put release tarballs. I'd prefer to use >> > git.postgresql.org, but if there's nowhere for tarballs, that's not >> > going to work. >> >> Hmm, that's a good example. It would certainly qualify to live on >> git.postgresql.org using the criteria I have in mind, but I can see >> the tarballs would be an issue. If we do keep git.postgresql.org for >> trusted projects, then perhaps it wouldn't be such an issue to give >> certain users from each one access to a server to upload tarballs into >> the mirror network. > > So how does pgadmin deal with tarballs and installers etc? Do they have > their own server for that? Yes. We use git.postgresql.org, and postgresql.org mailing lists. We have our own dev server and webserver, and sync our release packages onto the PostgreSQL FTP mirror from there. psqlODBC does something similar, but does use pgFoundry for CVS and bug tracking. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2011/5/20 Devrim GÜNDÜZ <devrim@gunduz.org>: > On Fri, 2011-05-20 at 15:48 +0000, Dave Page wrote: >> > I need to figure out what to do with pg_filedump. All I need for it >> > is an SCM and someplace to put release tarballs. I'd prefer to use >> > git.postgresql.org, but if there's nowhere for tarballs, that's not >> > going to work. >> >> Hmm, that's a good example. It would certainly qualify to live on >> git.postgresql.org using the criteria I have in mind, but I can see >> the tarballs would be an issue. If we do keep git.postgresql.org for >> trusted projects, then perhaps it wouldn't be such an issue to give >> certain users from each one access to a server to upload tarballs into >> the mirror network. >> >> I certainly wouldn't want to offer that to every project on pgFoundry >> though. > > We already allow *everyone* to distribute their tarballs through our FTP > mirror network. Yes, but that wasn't the point of my comment - more that there's a barrier of entry to pass at present before you can do that, which makes it harder for people to use the distribution facilities inappropriately. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, May 20, 2011 at 5:03 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > On Fri, May 20, 2011 12:20 pm, Stefan Kaltenbrunner wrote: >> On 05/20/2011 11:43 AM, Tom Lane wrote: >>> Dave Page <dpage@pgadmin.org> writes: >>>> 2011/5/20 Devrim GÜNDÜZ <devrim@gunduz.org>: >>>>> When we shut it down, all projects will all go somewhere else, and >>>>> that >>>>> somewhere else might sound reliable to the people outside the >>>>> community. >>>>> That is the only concern of me. Getting rid of CVS is fine, and they >>>>> can >>>>> move their projects to git.postgresql.org, which would be excellent. >>>>> Still, is there a simple way that PostgreSQL infrastructure team can >>>>> provide hosting are for tarballs for ex-pgfoundry projects? >>> >>>> I think we'd want to try to avoid doing that as it would require >>>> policing to ensure inappropriate content wasn't uploaded. >>> >>> ... yeah, that's a problem. >>> >>>> Plus, people can always use SourceForge for distribution. >>> >>> If you drive people to sourceforge for distribution, what value is there >>> in git.postgresql.org? >>> >>> I need to figure out what to do with pg_filedump. All I need for it >>> is an SCM and someplace to put release tarballs. I'd prefer to use >>> git.postgresql.org, but if there's nowhere for tarballs, that's not >>> going to work. >> >> hmm tarballs are a really good point, not sure what to do there - >> provide some some minimal interface to push them to the mirror network >> or do we need something more fancy? >> >> > > We need something. I need to be able to push buildfarm client tarballs > too, so Tom's not the only person who needs this. No, I don't expect he is. Like his work though, in my mind the buildfarm is a "family" project that we could accomodate in other ways. > Even more importantly, the mailings lists on pgfoundry are a critical > piece of the buildfarm infrastructure - that's how status notifications > get out to people like Tom. We also need lists for commit notifications > and members discussion. Any reason we couldn't use the main list server for that? > It's a pity GitHub doesn't have some of those extra features. True. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, May 20, 2011 1:38 pm, Dave Page wrote: >> >> We need something. I need to be able to push buildfarm client tarballs >> too, so Tom's not the only person who needs this. > > No, I don't expect he is. Like his work though, in my mind the > buildfarm is a "family" project that we could accomodate in other > ways. > Sure, I just wanted to make sure this is on the table up front. >> Even more importantly, the mailings lists on pgfoundry are a critical >> piece of the buildfarm infrastructure - that's how status notifications >> get out to people like Tom. We also need lists for commit notifications >> and members discussion. > > Any reason we couldn't use the main list server for that? Would work for me. cheers andrew
2011/5/20 Andrew Dunstan <andrew@dunslane.net>: > On Fri, May 20, 2011 1:38 pm, Dave Page wrote: > >>> >>> We need something. I need to be able to push buildfarm client tarballs >>> too, so Tom's not the only person who needs this. >> >> No, I don't expect he is. Like his work though, in my mind the >> buildfarm is a "family" project that we could accomodate in other >> ways. >> > > Sure, I just wanted to make sure this is on the table up front. The problem here, is how we'd define a "family" project of course. We'd need to keep the numbers low to be manageable. The benefits I imagine would be: - Ability to upload files to the FTP site via ssh. - @postgresql.org mailing lists. - Use of git.postgresql.org for the primary repo. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
> As most of you will know, the pgFoundry system is in dire need of a > huge amount of work. It's running an extremely old version of GForge, > which has been hacked about to run on FreeBSD and is almost certainly > full of potential security issues. In order to bring the system up to > date we would need to do at least the following: > > - Figure out what functionality changes our version has over the latest release. > > - Install the latest version of GForge on our new hosting platform. > > - Re-implement the code changes, if still required. > > - Figure out how to migrate all the user accounts and related data > from FreeBSD to Debian. > > - Figure out how to migrate all the data from the old system to the new. > > We've had numerous attempts in the past to do this *before* we had the > new hosting platform, all of which failed miserably, due to the lack > of people with the time and interest in doing the work. > > Following some discussions last night at PGCon, I'd therefore like to > propose that we deprecate and eventually shutdown the PGFoundry > service. This would involve: > > - Emailing all users with the details of the shutdown timetable. > > - Suggest users migrate to GitHub or Sourceforge, depending on their needs. > > - Migrate "core" projects (such as psqlODBC and the press/advocacy > project) to mailing lists in postgresql.org (if required) and to > git.postgresql.org. > > - Offer other users tarballs of their CVS repos, mail archives and downloads. > > - After 6 months, shut down the system and permanently archive it. > > Comments? One of the hardest part of this for me is, we will lose precious URLs of mailing list archive items. There are bunch of places which refers to the URL. As they are gone, documents/mails refers to them will become more or less meaningless. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
On Fri, May 20, 2011 at 6:04 PM, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: > One of the hardest part of this for me is, we will lose precious URLs > of mailing list archive items. There are bunch of places which refers > to the URL. As they are gone, documents/mails refers to them will > become more or less meaningless. Yeah, that is a pain. I don't know what we can do about that though, unless we maintain the site indefinitely in some form or other - which noone seems willing to do. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, May 20, 2011 at 14:19, Dave Page <dpage@pgadmin.org> wrote: > On Fri, May 20, 2011 at 6:04 PM, Tatsuo Ishii <ishii@sraoss.co.jp> wrote: >> One of the hardest part of this for me is, we will lose precious URLs >> of mailing list archive items. There are bunch of places which refers >> to the URL. As they are gone, documents/mails refers to them will >> become more or less meaningless. > > Yeah, that is a pain. I don't know what we can do about that though, > unless we maintain the site indefinitely in some form or other - which > noone seems willing to do. Well, we could maintain a static copy of the archives in the future - it doesn't really cost any maintenance to do *that*... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Excerpts from Tatsuo Ishii's message of vie may 20 14:04:28 -0400 2011: > One of the hardest part of this for me is, we will lose precious URLs > of mailing list archive items. There are bunch of places which refers > to the URL. As they are gone, documents/mails refers to them will > become more or less meaningless. Would it be an option to keep just the mailing list archives in place, with the same URLs? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 05/20/2011 11:22 AM, Alvaro Herrera wrote: > Excerpts from Tatsuo Ishii's message of vie may 20 14:04:28 -0400 2011: >> One of the hardest part of this for me is, we will lose precious URLs >> of mailing list archive items. There are bunch of places which refers >> to the URL. As they are gone, documents/mails refers to them will >> become more or less meaningless. > > Would it be an option to keep just the mailing list archives in place, > with the same URLs? Yeah that seems reasonable. JD > -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
Le 20/05/2011 16:15, Dave Page a écrit : > > Following some discussions last night at PGCon, I'd therefore like to > propose that we deprecate and eventually shutdown the PGFoundry > service. > Comments? > +1 ...but as a disclaimer i'm not a big user of pgFoundry :) -- damien clochard dalibo.com | dalibo.org
Excerpts from Dave Page's message of vie may 20 13:38:20 -0400 2011: > On Fri, May 20, 2011 at 5:03 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > > Even more importantly, the mailings lists on pgfoundry are a critical > > piece of the buildfarm infrastructure - that's how status notifications > > get out to people like Tom. We also need lists for commit notifications > > and members discussion. > > Any reason we couldn't use the main list server for that? Assuming it's reliable enough ... ;-) How many new lists are we talking about? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On May 20, 2011, at 1:09 PM, Devrim GÜNDÜZ wrote: > On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: > >> I think we'd want to try to avoid doing that as it would require >> policing to ensure inappropriate content wasn't uploaded. > > (I quoted wrong email in my previous reply, sorry) > > We already allow *everyone* to distribute their tarballs through our FTP > mirror network... Why won't we direct them to PGXN? It seems to have a really nice way to store/discover PostgreSQL related projects. -- Alexey Klyukin The PostgreSQL Company - Command Prompt, Inc.
2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: > > On May 20, 2011, at 1:09 PM, Devrim GÜNDÜZ wrote: > >> On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: >> >>> I think we'd want to try to avoid doing that as it would require >>> policing to ensure inappropriate content wasn't uploaded. >> >> (I quoted wrong email in my previous reply, sorry) >> >> We already allow *everyone* to distribute their tarballs through our FTP >> mirror network... > > Why won't we direct them to PGXN? It seems to have a really nice way to store/discover PostgreSQL related projects. That might be appropriate for some packages, but certainly not all. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, May 20, 2011 at 8:11 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Dave Page's message of vie may 20 13:38:20 -0400 2011: >> On Fri, May 20, 2011 at 5:03 PM, Andrew Dunstan <andrew@dunslane.net> wrote: > >> > Even more importantly, the mailings lists on pgfoundry are a critical >> > piece of the buildfarm infrastructure - that's how status notifications >> > get out to people like Tom. We also need lists for commit notifications >> > and members discussion. >> >> Any reason we couldn't use the main list server for that? > > Assuming it's reliable enough ... ;-) > > How many new lists are we talking about? Dunno. We'd have to figure out how we decide which projects to ask, and then ask them. Another option that Stefan just mentioned to me is to have a dedicated mailman instance for these lists, in a different namespace (in fact, it could even be the current instance, migrated to a new box, but without the GForge integration). The downside with that is that it would still need maintenance, and we'll still be looking after two completely separate mailing list and archive systems which seems to be far from ideal. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On May 20, 2011, at 4:18 PM, Dave Page wrote: > 2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: >> >> On May 20, 2011, at 1:09 PM, Devrim GÜNDÜZ wrote: >> >>> On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: >>> >>>> I think we'd want to try to avoid doing that as it would require >>>> policing to ensure inappropriate content wasn't uploaded. >>> >>> (I quoted wrong email in my previous reply, sorry) >>> >>> We already allow *everyone* to distribute their tarballs through our FTP >>> mirror network... >> >> Why won't we direct them to PGXN? It seems to have a really nice way to store/discover PostgreSQL related projects. > > That might be appropriate for some packages, but certainly not all. I'm wondering what are these 'inappropriate' packages. Any examples? -- Alexey Klyukin The PostgreSQL Company - Command Prompt, Inc.
2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: > > On May 20, 2011, at 4:18 PM, Dave Page wrote: > >> 2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: >>> >>> On May 20, 2011, at 1:09 PM, Devrim GÜNDÜZ wrote: >>> >>>> On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: >>>> >>>>> I think we'd want to try to avoid doing that as it would require >>>>> policing to ensure inappropriate content wasn't uploaded. >>>> >>>> (I quoted wrong email in my previous reply, sorry) >>>> >>>> We already allow *everyone* to distribute their tarballs through our FTP >>>> mirror network... >>> >>> Why won't we direct them to PGXN? It seems to have a really nice way to store/discover PostgreSQL related projects. >> >> That might be appropriate for some packages, but certainly not all. > > I'm wondering what are these 'inappropriate' packages. Any examples? The OLEDB driver. pgInstaller. StackBuilder all spring to mind. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2011/5/20 Dave Page <dpage@pgadmin.org>: > 2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: >> >> On May 20, 2011, at 4:18 PM, Dave Page wrote: >> >>> 2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: >>>> >>>> On May 20, 2011, at 1:09 PM, Devrim GÜNDÜZ wrote: >>>> >>>>> On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: >>>>> >>>>>> I think we'd want to try to avoid doing that as it would require >>>>>> policing to ensure inappropriate content wasn't uploaded. >>>>> >>>>> (I quoted wrong email in my previous reply, sorry) >>>>> >>>>> We already allow *everyone* to distribute their tarballs through our FTP >>>>> mirror network... >>>> >>>> Why won't we direct them to PGXN? It seems to have a really nice way to store/discover PostgreSQL related projects. >>> >>> That might be appropriate for some packages, but certainly not all. >> >> I'm wondering what are these 'inappropriate' packages. Any examples? > > The OLEDB driver. pgInstaller. StackBuilder all spring to mind. In fact, if you look at the toplist on the frontpage of the pgfoundry site, I think most of those are not the kind of stuff that belongs on pgxn... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On May 20, 2011, at 4:33 PM, Magnus Hagander wrote: > 2011/5/20 Dave Page <dpage@pgadmin.org>: >> 2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: >>> >>> On May 20, 2011, at 4:18 PM, Dave Page wrote: >>> >>>> 2011/5/20 Alexey Klyukin <alexk@commandprompt.com>: >>>>> >>>>> On May 20, 2011, at 1:09 PM, Devrim GÜNDÜZ wrote: >>>>> >>>>>> On Fri, 2011-05-20 at 15:36 +0000, Dave Page wrote: >>>>>> >>>>>>> I think we'd want to try to avoid doing that as it would require >>>>>>> policing to ensure inappropriate content wasn't uploaded. >>>>>> >>>>>> (I quoted wrong email in my previous reply, sorry) >>>>>> >>>>>> We already allow *everyone* to distribute their tarballs through our FTP >>>>>> mirror network... >>>>> >>>>> Why won't we direct them to PGXN? It seems to have a really nice way to store/discover PostgreSQL related projects. >>>> >>>> That might be appropriate for some packages, but certainly not all. >>> >>> I'm wondering what are these 'inappropriate' packages. Any examples? >> >> The OLEDB driver. pgInstaller. StackBuilder all spring to mind. > > In fact, if you look at the toplist on the frontpage of the pgfoundry > site, I think most of those are not the kind of stuff that belongs on > pgxn... Well, I don't see any reasons blocking you from putting stuff like oledb provider or npgsql into PGXN. It's not just forextensions built via PGXS, but for almost any kind of postgres extensions. The pgInstaller or Stackbuilder are probablynot appropriate for PGXN, but there are not so many postgres installers out there. -- Alexey Klyukin The PostgreSQL Company - Command Prompt, Inc.
Excerpts from Dave Page's message of vie may 20 16:21:05 -0400 2011: > Another option that Stefan just mentioned to me is to have a dedicated > mailman instance for these lists, in a different namespace (in fact, > it could even be the current instance, migrated to a new box, but > without the GForge integration). The downside with that is that it > would still need maintenance, and we'll still be looking after two > completely separate mailing list and archive systems which seems to be > far from ideal. Yeah, I think keeping a single mailing list server is better. I don't think the extra load is going to be all that much anyway -- if we can handle pgsql-hackers and pgsql-general, we shouldn't have much problem adding a couple dozen mostly inactive lists (compared to those). The only interesting bit is going to be the list mgmt interface ... but that's probably OK. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> Yeah, I think keeping a single mailing list server is better. I don't > think the extra load is going to be all that much anyway -- if we can > handle pgsql-hackers and pgsql-general, we shouldn't have much problem > adding a couple dozen mostly inactive lists (compared to those). > > The only interesting bit is going to be the list mgmt interface ... > but that's probably OK. > Well pgfoundry uses mailman....? JD
Dave, As you know, I'm in favor of this in general. Shutting down pgfoundry will be a significant amount of effort though. So, some things: Mailing Lists: I think you're underestimating the number of mailing lists in pgFoundry. I know I use pgFoundry for "disposable" mailinglists for special purposes (Google SOC 2011, for example). While there are plenty of places I can externally hostcode, free mailing list hosting on third parties in general is inadequate for the community purposes I need lists for(yahoo and google groups are problematic for multiple reasons). I really need to have a mailserver which is not consideredcritical by the sysadmin team, and where I can freely create new lists and drop old ones. Links: The pgfoundry page is often the top google link for a lot of projects. If those links stop working a lot of PG-related projectswill effectively vanish from Google. So we're going to need to create redirects for all of the projects.postgresql.orgpages at a minimum to new locations supplied by the project owner. Directory: We're going to need something better than the current software directory app, which is dominated by commercial advertisting. Ideas? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com San Francisco
On 05/21/2011 11:07 AM, Joshua Berkus wrote: > While there are plenty of places I can externally host code, free mailing list hosting on third parties in general isinadequate for the community purposes I need lists for (yahoo and google groups are problematic for multiple reasons). > I'm curious what you feel the problems are with Google Groups in particular; I've had my own issues with Yahoo so agreed that's sketchy. When we went casting around for places to host the repmgr project at, we went through a similar process to what cast adrift pgfoundry ones would be facing here. The following set of resources has worked well for us: Github: code, issue tracker Google Groups: mailing list + archives Release .tar.gz and documentation: Drupal site, hosted on one of our servers The Drupal site is the weakest link in that set, but discussion on this thread has already started hopping on alternatives for that point. I've been happy enough with Google Groups for small mailing lists though. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
Greg, > I'm curious what you feel the problems are with Google Groups in > particular; I've had my own issues with Yahoo so agreed that's sketchy. Inability to manage a closed mailing list, for one thing. That is, any member of the Google group can decide to change the mailing list to "open". Also the fact that *every* member of the group gets the moderation messages, is annoying as all-get out. And several people in our community (Magnus, for example) have reported being completely unable to receive messages from google groups. There are other issues as well; basically Google groups makes Majordomo look user-friendly. I wish it didn't suck so badly, or it would be a nice solution for the non-critical/ephemeral mailing lists task. If someone knows a third-party list manager site which doesn't suck, please speak up. However, as discussed at the pub, I can personally find other solutions such as running my own mailman instance somewhere. Whether that's a better solution for the community, I don't know. Magnus and I should also step through each list individually that I'm talking about; there may be less than I believe which isn't in the categories of "permanent list" or "personal project". -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Mon, May 23, 2011 at 13:44, Josh Berkus <josh@agliodbs.com> wrote: > Greg, > >> I'm curious what you feel the problems are with Google Groups in >> particular; I've had my own issues with Yahoo so agreed that's sketchy. > > Inability to manage a closed mailing list, for one thing. That is, any > member of the Google group can decide to change the mailing list to > "open". Also the fact that *every* member of the group gets the > moderation messages, is annoying as all-get out. And several people in > our community (Magnus, for example) have reported being completely > unable to receive messages from google groups. There are other issues > as well; basically Google groups makes Majordomo look user-friendly. Acutally, just to make it clear, I can receive google groups fine. I can usually not *post* to them, though. (Nor can I unsubscribe once I've subscribed). But not always - it sometimes works. Oh, and another point - there's even less chance of debugging any kind of issue you have with google groups, than anything else we have now. > I wish it didn't suck so badly, or it would be a nice solution for the > non-critical/ephemeral mailing lists task. If someone knows a > third-party list manager site which doesn't suck, please speak up. +1, I could use that in other cases as well. > However, as discussed at the pub, I can personally find other solutions > such as running my own mailman instance somewhere. Whether that's a > better solution for the community, I don't know. Magnus and I should > also step through each list individually that I'm talking about; there > may be less than I believe which isn't in the categories of "permanent > list" or "personal project". Hmm. I said that? I thought that was someone else - but I can +1 that too :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Josh Berkus wrote: > I can personally find other solutions > such as running my own mailman instance somewhere. Whether that's a > better solution for the community, I don't know. I consider this one of the biggest trouble spots to roll your own solution to, in general. It's probably more valuable to consider offering help with than some of the other things the community admins might do. I'm happy to see the PostgreSQL infrastructure dump some of the easily replaced bits of pgFoundry that can be moved, but this one we really could still use the most help with. Coping with the complexity that spammers have forced into mailing list management is a constant infrastructure headache in my own project plans. In particular, there's all this ugly downside you can get into if your mail server IP address ends up on one of the blacklists. Running a mail server, especially one that's got lists on it, is one of those things I avoid whenever possible. Lots of risks and overhead there. Probably why there are so few good services doing it available. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
2011/5/21 Joshua Berkus <josh@agliodbs.com>: > > Mailing Lists: > I think you're underestimating the number of mailing lists in pgFoundry. I know I use pgFoundry for "disposable" mailinglists for special purposes (Google SOC 2011, for example). While there are plenty of places I can externally hostcode, free mailing list hosting on third parties in general is inadequate for the community purposes I need lists for(yahoo and google groups are problematic for multiple reasons). > I really need to have a mailserver which is not considered critical by the sysadmin team, and where I can freely createnew lists and drop old ones. Josh and I discussed this in person. It's still not entirely clear that there is a genuine requirement for this much flexibility, though clearly Josh does need to be able use both public and private mailing lists. I don't see any reason at the moment why those lists couldn't be on the existing list server. > Links: > The pgfoundry page is often the top google link for a lot of projects. If those links stop working a lot of PG-relatedprojects will effectively vanish from Google. So we're going to need to create redirects for all of the projects.postgresql.orgpages at a minimum to new locations supplied by the project owner. Links will be available from the software catalog, which we can redirect to from pgfoundry.org. I don't think we have any responsibility to provide search rankings for projects beyond that. > Directory: > We're going to need something better than the current software directory app, which is dominated by commercial advertisting. Ideas? Option to filter out non-OSS projects? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, May 23, 2011 at 5:44 PM, Josh Berkus <josh@agliodbs.com> wrote: > Greg, > >> I'm curious what you feel the problems are with Google Groups in >> particular; I've had my own issues with Yahoo so agreed that's sketchy. > > Inability to manage a closed mailing list, for one thing. That is, any > member of the Google group can decide to change the mailing list to > "open". Also the fact that *every* member of the group gets the > moderation messages, is annoying as all-get out. Neither of those issues are ones I recognise, despite running 100+ mailing lists on Google Apps at work. Can't speak to the free groups offering, but using the full version of apps for this would only cost $50 pa. Not saying we should though... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave, > Links will be available from the software catalog, which we can > redirect to from pgfoundry.org. I don't think we have any > responsibility to provide search rankings for projects beyond that. We do have a duty not to make people think our accessory projects are dead. If a user follows the top 5 links for, for example, pgpool, and that link is a 404, he's going to assume that the pgpool project is gone. Not that it's moved somewhere else. The alternative to providing forwarding is to keep pgfoundry up for a year after we start telling people to move off of it, but gradually lock out activity on pgfoundry. That way there would be a transition period during which the new locations for projects could climb the search results. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
2011/5/24 Josh Berkus <josh@agliodbs.com>: > Dave, > >> Links will be available from the software catalog, which we can >> redirect to from pgfoundry.org. I don't think we have any >> responsibility to provide search rankings for projects beyond that. > > We do have a duty not to make people think our accessory projects are > dead. If a user follows the top 5 links for, for example, pgpool, and > that link is a 404, he's going to assume that the pgpool project is > gone. Not that it's moved somewhere else. > > The alternative to providing forwarding is to keep pgfoundry up for a > year after we start telling people to move off of it, but gradually lock > out activity on pgfoundry. That way there would be a transition period > during which the new locations for projects could climb the search results. At the end of this period, can we just make pgfoundry generated pages static, for memory and not to break links at all ? > > -- > Josh Berkus > PostgreSQL Experts Inc. > http://pgexperts.com > > -- > Sent via pgsql-www mailing list (pgsql-www@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-www > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On Tue, May 24, 2011 at 6:31 PM, Cédric Villemain <cedric.villemain.debian@gmail.com> wrote: >> The alternative to providing forwarding is to keep pgfoundry up for a >> year after we start telling people to move off of it, but gradually lock >> out activity on pgfoundry. That way there would be a transition period >> during which the new locations for projects could climb the search results. That's why the proposal gave a six month transition time and not something shorter. > At the end of this period, can we just make pgfoundry generated pages > static, for memory and not to break links at all ? That's not a good idea, as a) they won't point to the new projects and b) will become steadily more out of date. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/20/2011 02:04 PM, Tatsuo Ishii wrote: > One of the hardest part of this for me is, we will lose precious URLs > of mailing list archive items. There are bunch of places which refers > to the URL. As they are gone, documents/mails refers to them will > become more or less meaningless. > Would it be possible for people with serious project history in the mailing list archives to rsync their archive directory to somewhere? I just checked archive.org, and it doesn't seem to care about the pgFoundry Pipermail directories either. You'd still have to rewrite the URLs, but at least it would be a simple process. The other strategy idea I was just thinking about is whether it would be possible to build a URL translation table and make each project summary page include it. For example, let's say someone visits http://pgfoundry.org/projects/pgpool/ during the transition period. What if the site read like this for the next 6 months: Pgpool is a connection pooling/replication server for PostgreSQL. * pgFoundry is being closed and is no longer the primarysite for this project. Update all links to use its new location: http://pgpool.projects.postgresql.org/ * Development Status: 5 - Production/Stable I think it's unlikely every project maintainer will update their page with something like this manually. Whereas building a little redirect translation table, then iterating over updates to it until all projects have new URLs listed, seems like it would be straightforward. Of course I say this not knowing how/if GForge can digest such a concept. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
On Mon, 2011-05-23 at 16:12 -0400, Greg Smith wrote: > Josh Berkus wrote: > > I can personally find other solutions > > such as running my own mailman instance somewhere. Whether that's a > > better solution for the community, I don't know. > > I consider this one of the biggest trouble spots to roll your own > solution to, in general. Agreed. Mailing lists are my top concern with shutting down PgFoundry as well. Regards,Jeff Davis
On 05/24/2011 09:08 PM, Dave Page wrote: > That's not a good idea, as a) they won't point to the new projects Uh.. why not? After six months, that should be doable. > and b) will become steadily more out of date. I like out-of-date pages better than unavailable ones. Especially if they clearly state they clearly state that they are unmaintained and point to the new location. Regards Markus Wanner
On Wed, May 25, 2011 at 6:05 AM, Markus Wanner <markus@bluegap.ch> wrote: > On 05/24/2011 09:08 PM, Dave Page wrote: >> That's not a good idea, as a) they won't point to the new projects > > Uh.. why not? After six months, that should be doable. For a start, because GForge doesn't let you put arbitrary links on the project pages, and secondly because even if it did, there would be an extremely high probability that some project authors would forget or not bother to do so. >> and b) will become steadily more out of date. > > I like out-of-date pages better than unavailable ones. Especially if > they clearly state they clearly state that they are unmaintained and > point to the new location. There are hundreds of projects (the majority probably dead) on pgFoundry. *we* simply do not have the resources to ensure they all point to whereever the the projects may move to and ensure all the data on the site is accurate. Besides, leaving the site up there doesn't actually solve the issue that there are probably a ton of security issues in its code, that would likely still be there even if we did disable all logins. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave, On 05/25/2011 10:49 AM, Dave Page wrote: > For a start, because GForge doesn't let you put arbitrary links on the > project pages Hm.. okay, that's unfortunate. Is the customized GForge code that we use available somewhere? > There are hundreds of projects (the majority probably dead) on > pgFoundry. *we* simply do not have the resources to ensure they all > point to whereever the the projects may move to and ensure all the > data on the site is accurate. I didn't mean the to tell the Postgres www team to do that. However, I do think that these projects deserve something better than a 404 after half a year. Keep in mind that project leaders were asked to move from Gborg to pgFoundry just four years ago. > Besides, leaving the site up there doesn't actually solve the issue > that there are probably a ton of security issues in its code, that > would likely still be there even if we did disable all logins. The proposal was to put up a static copy. That hardly has any security issues, I think. Regards Markus Wanner
On Wed, May 25, 2011 at 9:21 AM, Markus Wanner <markus@bluegap.ch> wrote: > Dave, > > On 05/25/2011 10:49 AM, Dave Page wrote: >> For a start, because GForge doesn't let you put arbitrary links on the >> project pages > > Hm.. okay, that's unfortunate. Is the customized GForge code that we > use available somewhere? Not that I know of (aside from the live server of course) >> Besides, leaving the site up there doesn't actually solve the issue >> that there are probably a ton of security issues in its code, that >> would likely still be there even if we did disable all logins. > > The proposal was to put up a static copy. That hardly has any security > issues, I think. Actually generating a static copy may be a non-trivial amount of work though. It's easy enough to spider the site and store it as a static HTML, but we'd also need to ensure we remove any links or forms to non-static features of course. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2011/5/25 Dave Page <dpage@pgadmin.org>: > On Wed, May 25, 2011 at 9:21 AM, Markus Wanner <markus@bluegap.ch> wrote: >> Dave, >> >> On 05/25/2011 10:49 AM, Dave Page wrote: >>> For a start, because GForge doesn't let you put arbitrary links on the >>> project pages >> >> Hm.. okay, that's unfortunate. Is the customized GForge code that we >> use available somewhere? > > Not that I know of (aside from the live server of course) > >>> Besides, leaving the site up there doesn't actually solve the issue >>> that there are probably a ton of security issues in its code, that >>> would likely still be there even if we did disable all logins. >> >> The proposal was to put up a static copy. That hardly has any security >> issues, I think. > > Actually generating a static copy may be a non-trivial amount of work > though. It's easy enough to spider the site and store it as a static > HTML, but we'd also need to ensure we remove any links or forms to > non-static features of course. I believe we don't care :) We can just add a disclaimer at top of each page : "this site is only for archive, do not expect each link to work. Thank you." Those are technical arguments, the point is do we want to trash all of that or not ? I don't want to trash it, even if XX% are dead things with no linkto-url. > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Cédric Villemain <cedric.villemain.debian@gmail.com> writes:
> 2011/5/25 Dave Page <dpage@pgadmin.org>:
>> On Wed, May 25, 2011 at 9:21 AM, Markus Wanner <markus@bluegap.ch> wrote:
>>> The proposal was to put up a static copy. �That hardly has any security
>>> issues, I think.
>> Actually generating a static copy may be a non-trivial amount of work
>> though. It's easy enough to spider the site and store it as a static
>> HTML, but we'd also need to ensure we remove any links or forms to
>> non-static features of course.
> I believe we don't care :)
> We can just add a disclaimer at top of each page : "this site is only
> for archive, do not expect each link to work. Thank you."
Or, just replace the server with something that serves out the same
static page for any pgfoundry URL: "pgfoundry has been retired. Please
see <list of useful resources> to search for the new location of the
project you are looking for."
The main point in my mind is that we'll never get rid of all the
references to pgfoundry. Having those URLs go 404 will not look good
nor be helpful to visitors.
regards, tom lane
On Wed, May 25, 2011 at 10:18, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Cédric Villemain <cedric.villemain.debian@gmail.com> writes: >> 2011/5/25 Dave Page <dpage@pgadmin.org>: >>> On Wed, May 25, 2011 at 9:21 AM, Markus Wanner <markus@bluegap.ch> wrote: >>>> The proposal was to put up a static copy. That hardly has any security >>>> issues, I think. > >>> Actually generating a static copy may be a non-trivial amount of work >>> though. It's easy enough to spider the site and store it as a static >>> HTML, but we'd also need to ensure we remove any links or forms to >>> non-static features of course. > >> I believe we don't care :) >> We can just add a disclaimer at top of each page : "this site is only >> for archive, do not expect each link to work. Thank you." > > Or, just replace the server with something that serves out the same > static page for any pgfoundry URL: "pgfoundry has been retired. Please > see <list of useful resources> to search for the new location of the > project you are looking for." > > The main point in my mind is that we'll never get rid of all the > references to pgfoundry. Having those URLs go 404 will not look good > nor be helpful to visitors. I think the reasonable thing is a combination. For a number of the high-profile, high-traffic projects (like odbc for example), we can specifically put in a forward. Or maybe a project-specific page telling the visitor to update their bookmarks. For the rest, a generic page along the line of what Tom suggests should be enough. Just 404'ing things is mean :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
> That's why the proposal gave a six month transition time and not > something shorter. I don't think six months is enough, unfortunately. Also, I think we need to have a period of time when nobody can log into pgFoundry, but the pages are still up with redirects. As for how the redirects get there: we notify all the project owners now about the requirement. Then we give them several months to change their project pages to indicate the new homes. Overall, doing a migration to FusionForge on Debian is starting to sound like less work ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Excerpts from Josh Berkus's message of mié may 25 16:22:52 -0400 2011: > Overall, doing a migration to FusionForge on Debian is starting to sound > like less work ... Yeah, maybe it is :-P -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, May 25, 2011 at 8:47 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Josh Berkus's message of mié may 25 16:22:52 -0400 2011: > >> Overall, doing a migration to FusionForge on Debian is starting to sound >> like less work ... > > Yeah, maybe it is :-P We'll see. Stefan started to look at it at the airport and looked like he needed a sedative after just a couple of minutes of looking at the existing installation. Thankfully we were in the lounge and the bar was free... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, 2011-05-20 at 14:15 +0000, Dave Page wrote: > - Suggest users migrate to GitHub or Sourceforge, depending on their needs. After a brief look, sourceforge appears to be a good option if you want mailing lists, and sourceforge does support git now. I'll be moving my PERIOD data type extension there. GitHub doesn't offer mailing lists at all. Not all projects need a mailing list, but I've found it to be helpful for the temporal project. Regards,Jeff Davis
On Sun, May 29, 2011 at 19:36, Jeff Davis <pgsql@j-davis.com> wrote: > On Fri, 2011-05-20 at 14:15 +0000, Dave Page wrote: >> - Suggest users migrate to GitHub or Sourceforge, depending on their needs. > > After a brief look, sourceforge appears to be a good option if you want > mailing lists, and sourceforge does support git now. I'll be moving my > PERIOD data type extension there. One big annoyance with the sourceforge lists is, imho, that they put ads in all the mails :( > GitHub doesn't offer mailing lists at all. Not all projects need a > mailing list, but I've found it to be helpful for the temporal project. GitHub beats sourceforge on pretty much everything except for this one thing, imho. But if that's considered critical enough, I agree it's not a good choice. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 05/29/2011 02:00 PM, Magnus Hagander wrote: > On Sun, May 29, 2011 at 19:36, Jeff Davis<pgsql@j-davis.com> wrote: > >> GitHub doesn't offer mailing lists at all. Not all projects need a >> mailing list, but I've found it to be helpful for the temporal project. >> > GitHub beats sourceforge on pretty much everything except for this one > thing, imho. But if that's considered critical enough, I agree it's > not a good choice. > Agreed on all that. I think the decision tree for where to host a projects might look like this: -Are a critical project to the PostgreSQL infrastructure: git.postgresql.org + PostgreSQL hosted mailing list -Don't care about mailing lists or web space: github -Need a basic mailing list, but don't care about integration with the repo: github + Google Groups -Need a mailing list with repo integration: sourceforge To help provide a resource here, I just wrote up a little guide to PostgreSQL related project hosting on the wiki: http://wiki.postgresql.org/wiki/Project_Hosting That includes a little blurb about the uncertainty around PgFoundry. If shutdown plans proceed, that might be worth expanding on with more hosting details, or notes on doing a migration. I started to draw a little chart showing which features are supported on each hosting platform, but suspect that I could probably find such a table elsewhere given a bit more time. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
On Sun, 2011-05-29 at 21:19 -0400, Greg Smith wrote: > Agreed on all that. I think the decision tree for where to host a > projects might look like this: > > -Are a critical project to the PostgreSQL infrastructure: > git.postgresql.org + PostgreSQL hosted mailing list > -Don't care about mailing lists or web space: github > -Need a basic mailing list, but don't care about integration with the > repo: github + Google Groups > -Need a mailing list with repo integration: sourceforge Thank you for the breakdown, it looks like option 3 is for me (at least the "temporal" project, anyway) -- github + google groups. I saw a somewhat strange message on google groups though: "Zipped versions of the pages and files associated with this group will be available for download until August 31, 2011. After this date, this feature and the zip file downloads will be turned off permanently. Download pages| Download Files" Does that mean that you can't export the email out of a group? I suppose it will be available online, and perhaps in local mailboxes, but that seems a little strange (and slightly un-google-like, because usually they offer you some way to export data). Regards,Jeff Davis
On Mon, May 30, 2011 at 03:19, Greg Smith <greg@2ndquadrant.com> wrote: > On 05/29/2011 02:00 PM, Magnus Hagander wrote: >> >> On Sun, May 29, 2011 at 19:36, Jeff Davis<pgsql@j-davis.com> wrote: >> >>> >>> GitHub doesn't offer mailing lists at all. Not all projects need a >>> mailing list, but I've found it to be helpful for the temporal project. >>> >> >> GitHub beats sourceforge on pretty much everything except for this one >> thing, imho. But if that's considered critical enough, I agree it's >> not a good choice. >> > > Agreed on all that. I think the decision tree for where to host a projects > might look like this: > > -Are a critical project to the PostgreSQL infrastructure: > git.postgresql.org + PostgreSQL hosted mailing list > -Don't care about mailing lists or web space: github Um, github gives you web space afaik? I haven't actually used it, so perhaps it's just not good enough and that's why you didn't include it? > -Need a basic mailing list, but don't care about integration with the repo: > github + Google Groups > -Need a mailing list with repo integration: sourceforge > > To help provide a resource here, I just wrote up a little guide to > PostgreSQL related project hosting on the wiki: > http://wiki.postgresql.org/wiki/Project_Hosting > > That includes a little blurb about the uncertainty around PgFoundry. If > shutdown plans proceed, that might be worth expanding on with more hosting > details, or notes on doing a migration. I started to draw a little chart > showing which features are supported on each hosting platform, but suspect > that I could probably find such a table elsewhere given a bit more time. Well, there is always http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities. Which probably has a lot *more* detail than most people care about... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 05/25/2011 05:07 PM, Dave Page wrote: > On Wed, May 25, 2011 at 8:47 PM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: >> Excerpts from Josh Berkus's message of mié may 25 16:22:52 -0400 2011: >> >>> Overall, doing a migration to FusionForge on Debian is starting to sound >>> like less work ... >> >> Yeah, maybe it is :-P > > We'll see. Stefan started to look at it at the airport and looked like > he needed a sedative after just a couple of minutes of looking at the > existing installation. Thankfully we were in the lounge and the bar > was free... > Guys, this is silly. So we migrate to fusion forge.... who is going to maintain that? In 2 years we will be having this same and worse discussion. It will be, we have this half migration to fusion forge but we still have all these projects on pgfoundry and fusion forge is out of date. 6 months for a free service is more than generous. Anybody can set up their own redirect to any page/service the want (we don't have to do that) using either PHP or meta tags. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
All, Where are we with this? We're continuing to get new project submissions on pgfoundry, and I don't know whether to approve them or not. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Tue, May 31, 2011 at 7:06 PM, Josh Berkus <josh@agliodbs.com> wrote: > All, > > Where are we with this? We're continuing to get new project submissions > on pgfoundry, and I don't know whether to approve them or not. Still working on it, however personal issues for one of the team are delaying things. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/31/2011 12:06 PM, Josh Berkus wrote: > All, > > Where are we with this? We're continuing to get new project submissions > on pgfoundry, and I don't know whether to approve them or not. > From the discussion it appears that the shutdown is imminent, we just don't know exactly how we are going to get it done, wouldn't you agree? IMO, we should point all project submissions to SourceForge, Github and Launchpad. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
On Tue, May 31, 2011 at 7:32 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > On 05/31/2011 12:06 PM, Josh Berkus wrote: >> >> All, >> >> Where are we with this? We're continuing to get new project submissions >> on pgfoundry, and I don't know whether to approve them or not. >> > > From the discussion it appears that the shutdown is imminent, we just don't > know exactly how we are going to get it done, wouldn't you agree? Unless you know something I don't, that is not yet the case. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
> - Suggest users migrate to GitHub or Sourceforge, depending on their needs. > > - Migrate "core" projects (such as psqlODBC and the press/advocacy > project) to mailing lists in postgresql.org (if required) and to > git.postgresql.org. Is pgpool counted on the "core" projects? I want to use git.postgresql.org as the main pgpool repository if possible. It seems there are lots of "non core" projects including bucard, pgAdmin, plproxy, skytools, slony and so on, BTW. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
On Wed, Jun 1, 2011 at 4:35 PM, Tatsuo Ishii <ishii@postgresql.org> wrote: >> - Suggest users migrate to GitHub or Sourceforge, depending on their needs. >> >> - Migrate "core" projects (such as psqlODBC and the press/advocacy >> project) to mailing lists in postgresql.org (if required) and to >> git.postgresql.org. > > Is pgpool counted on the "core" projects? I want to use > git.postgresql.org as the main pgpool repository if possible. > > It seems there are lots of "non core" projects including bucard, > pgAdmin, plproxy, skytools, slony and so on, BTW. I think that Dave (or someone else upthread) was using the word "family" earlier, which I think fits a bit better than "core". I consider pgpool family! :) -selena -- http://chesnok.com
On Wed, Jun 1, 2011 at 11:44 PM, Selena Deckelmann <selena@chesnok.com> wrote: > On Wed, Jun 1, 2011 at 4:35 PM, Tatsuo Ishii <ishii@postgresql.org> wrote: >>> - Suggest users migrate to GitHub or Sourceforge, depending on their needs. >>> >>> - Migrate "core" projects (such as psqlODBC and the press/advocacy >>> project) to mailing lists in postgresql.org (if required) and to >>> git.postgresql.org. >> >> Is pgpool counted on the "core" projects? I want to use >> git.postgresql.org as the main pgpool repository if possible. >> >> It seems there are lots of "non core" projects including bucard, >> pgAdmin, plproxy, skytools, slony and so on, BTW. > > I think that Dave (or someone else upthread) was using the word > "family" earlier, which I think fits a bit better than "core". > > I consider pgpool family! :) Yes, me too - but therein lies one of the big problems we'd have to solve; how do we define "family", and what do we do if someone disagrees? I'll just come out with it and state here and now, that as Selena knows, it should be teal. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company