Re: pgFoundry Download URLs

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