Re: 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 unique ID 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(at)justatheory(dot)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(at)justatheory(dot)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(at)gmail(dot)com>:
> On Sat, Dec 26, 2009 at 7:44 PM, David E. Wheeler <david(at)justatheory(dot)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(at)pgadmin(dot)org>:
> 2009/12/27 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Sat, Dec 26, 2009 at 7:44 PM, David E. Wheeler <david(at)justatheory(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Sun, Dec 27, 2009 at 10:14 AM, Magnus Hagander <magnus(at)hagander(dot)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 has unique 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(at)2ndQuadrant(dot)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(at)gunduz(dot)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 them with 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 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.

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(at)justatheory(dot)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 Hagander
Me: 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 considering moving my project elsewhere. The only hesitation I have is that then pgTAP will not be visible on any PostgreSQL-oriented community 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 automatically searchable 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's search rankings have always stunk). So if I were to remove my projects from pgFoundry, how could I make them visible 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(at)gunduz(dot)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(at)justatheory(dot)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(at)gmail(dot)com>:
> 2009/12/27 Devrim GÜNDÜZ <devrim(at)gunduz(dot)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(at)gmail(dot)com>:
>> 2009/12/27 Devrim GÜNDÜZ <devrim(at)gunduz(dot)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(at)kaltenbrunner(dot)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(at)pgadmin(dot)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(at)turnstep(dot)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(at)turnstep(dot)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(at)turnstep(dot)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(at)turnstep(dot)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(at)pgadmin(dot)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(dot)smet(at)gmail(dot)com> wrote:
> On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage(at)pgadmin(dot)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(at)justatheory(dot)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(dot)smet(at)gmail(dot)com> wrote:
> > On Sun, Dec 27, 2009 at 11:50 AM, Dave Page <dpage(at)pgadmin(dot)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(at)justatheory(dot)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(at)commandprompt(dot)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(at)justatheory(dot)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(at)pgadmin(dot)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(dot)smet(at)gmail(dot)com> wrote:
> On Mon, Dec 28, 2009 at 8:13 PM, Dave Page <dpage(at)pgadmin(dot)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(at)pgadmin(dot)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, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd(at)commandprompt(dot)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(at)commandprompt(dot)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(at)kaltenbrunner(dot)cc>:
> Robert Haas wrote:
>>
>> On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd(at)commandprompt(dot)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.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander wrote:
> 2009/12/29 Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>:
>> Robert Haas wrote:
>>> On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd(at)commandprompt(dot)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...

Stefan

On Tue, Dec 29, 2009 at 12:05 PM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)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 new filename 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 run it 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 find it), 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 the same 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 .spec file until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it again with 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 many existing applications will likely be screwed.

Best,

David

On Tue, Dec 29, 2009 at 6:05 AM, Stefan Kaltenbrunner
<stefan(at)kaltenbrunner(dot)cc> wrote:
> Magnus Hagander wrote:
>>
>> 2009/12/29 Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>:
>>>
>>> Robert Haas wrote:
>>>>
>>>> On Mon, Dec 28, 2009 at 2:44 PM, Joshua D. Drake <jd(at)commandprompt(dot)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(at)justatheory(dot)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 .spec file until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it again with 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(at)gmail(dot)com> writes:
> On Tue, Dec 29, 2009 at 3:17 PM, David E. Wheeler <david(at)justatheory(dot)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 .spec file until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it again with 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(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Dec 29, 2009 at 3:17 PM, David E. Wheeler <david(at)justatheory(dot)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 .spec file until I've uploaded the distribution. I could then update the spec file, create a new tarball and upload it again with 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(at)kaltenbrunner(dot)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(at)kaltenbrunner(dot)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(at)kaltenbrunner(dot)cc> wrote:
> Dave Page wrote:
>>
>> On Tue, Dec 29, 2009 at 11:05 AM, Stefan Kaltenbrunner
>> <stefan(at)kaltenbrunner(dot)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(at)kaltenbrunner(dot)cc> wrote:
>> Dave Page wrote:
>>> On Tue, Dec 29, 2009 at 11:05 AM, Stefan Kaltenbrunner
>>> <stefan(at)kaltenbrunner(dot)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(at)kaltenbrunner(dot)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(at)justatheory(dot)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. Am I 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(at)users(dot)sourceforge(dot)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(at)pgadmin(dot)org> wrote:
> On Wed, Dec 30, 2009 at 7:53 PM, Robert Treat
> <xzilla(at)users(dot)sourceforge(dot)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(at)commandprompt(dot)com>:
> On Wed, 30 Dec 2009 20:17:03 +0000, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> On Wed, Dec 30, 2009 at 7:53 PM, Robert Treat
>> <xzilla(at)users(dot)sourceforge(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Wed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <magnus(at)hagander(dot)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(at)hagander(dot)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:
> On Wed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <magnus(at)hagander(dot)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 extrapolation from those
conversations, I would venture that if one took a survey of every active
pgfoundry maintainer, and told them "we're migrating to a better and
easier to support system, but you'll lose all your active projects and
you'll have to move them yourself to the new host manually", votes would
still be at least 10:1 in favor of that over the status quo. I'd expect
that if you provisioned an officially sanctioned replacement candidate,
the most popular projects would migrate to it in a minute given the
opportunity. The idea that anyone is going to put more time into trying
to 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, and let a larger slice
of the rest of the world solve this problem. Seriously--the most
important criteria here is maximizing the odds that somebody else with a
much larger use base is going to maintain and extend the underlying code
of whatever solution is used so this project doesn't have to. A quick
glance at the page Robert suggested:

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

And sorting by real or estimated Alexa rank as a popularity estimate,
where lower is more popular:

Sourceforge 198
Google Code 1000 (estimated, but unsuitable anyway so who cares)
GitHub 2342
CodePlex 3334
Tigris.org 10896
Launchpad 12268

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.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

2009/12/30 Robert Treat <xzilla(at)users(dot)sourceforge(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

2009/12/31 Greg Smith <greg(at)2ndquadrant(dot)com>:
> Joshua D. Drake wrote:
>
> On Wed, 30 Dec 2009 22:05:41 +0100, Magnus Hagander <magnus(at)hagander(dot)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 extrapolation from those conversations, I would venture that if one took a survey of every active pgfoundry maintainer, and told them "we're migrating to a better and easier to support system, but you'll lose all your active projects and you'll have to move them yourself to the new host manually", votes would still be at least 10:1 in favor of that over the status quo.  I'd expect that if you provisioned an officially sanctioned replacement candidate, the most popular projects would migrate to it in a minute given the opportunity.  The idea that anyone is going to put more time into trying to 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, and let a larger slice of the rest of the world solve this problem.  Seriously--the most important criteria here is maximizing the odds that somebody else with a much larger use base is going to maintain and extend the underlying code of whatever 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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Wed, Dec 30, 2009 at 10:12 PM, Robert Treat
<xzilla(at)users(dot)sourceforge(dot)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(at)pgadmin(dot)org>:
> On Wed, Dec 30, 2009 at 10:12 PM, Robert Treat
> <xzilla(at)users(dot)sourceforge(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Thu, 31 Dec 2009 13:15:42 +0100, Magnus Hagander <magnus(at)hagander(dot)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(at)hagander(dot)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 it could go away. (At least with Git you always have a complete copy of the repository in your clones, so can easily move elsewhere 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, just that 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(at)justatheory(dot)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 it could go away. (At least with Git you always have a complete copy of the repository in your clones, so can easily move elsewhere 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(at)users(dot)sourceforge(dot)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(at)commandprompt(dot)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(at)2ndQuadrant(dot)com www.2ndQuadrant.com

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 need and 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.

Best,

David

On Thu, Dec 31, 2009 at 18:06, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> wrote:
> On Thu, Dec 31, 2009 at 1:15 PM, Magnus Hagander <magnus(at)hagander(dot)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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Sat, Jan 2, 2010 at 00:43, David E. Wheeler <david(at)justatheory(dot)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 need and 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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Sat, Jan 2, 2010 at 12:07 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Thu, Dec 31, 2009 at 18:06, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)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(at)commandprompt(dot)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 original tar.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 need and 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(at)gmx(dot)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(at)gmx(dot)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 are still "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 presence acquired 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-(at)postgresql(dot)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-(at)postgresql(dot)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-(at)postgresql(dot)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 you proposed 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.org on 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 think a 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 what you proposed with "hosting stuff elsewhere. Also a fair number of the above mentioned resources don't actually provide mailinglists.
>
> 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 certainly easier 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 complex mailinglist 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/umbrella service ;)

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 certainly easier 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 complex mailinglist 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/umbrella service ;)
>
> 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 (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.

I don't mean use the core mailman. I mean have a separate projects mailman, which is exactly what pgf does. Hell, one could keep 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 search data 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 ideas about 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-(at)postgresql(dot)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

-----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(at)turnstep(dot)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(at)2ndQuadrant(dot)com www.2ndQuadrant.com

On Tue, Jan 5, 2010 at 11:32 PM, Greg Smith <greg(at)2ndquadrant(dot)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-(at)postgresql(dot)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(at)2ndQuadrant(dot)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(at)turnstep(dot)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(at)turnstep(dot)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(at)kineticode(dot)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 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(at)2ndquadrant(dot)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(at)pgadmin(dot)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(at)2ndQuadrant(dot)com www.2ndQuadrant.com

On Thu, Jan 7, 2010 at 10:45 PM, Greg Smith <greg(at)2ndquadrant(dot)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(at)agliodbs(dot)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