Thread: Re: Unsupported 3rd-party solutions (Was: Few questions
Christopher, > > > It seems to me that some vital components have already been set up, > considering: > > a) pgxs provides a "build environment" to make it easier to add in > "third party extensions" without each of them having to have its > own full PG source tree. > > b) PGFoundry is getting set up as a hopefully-decent place to host > things that would be likely to fit into that "second tier" of > "Extensions that ought to be ubiquitous." > > Those can also play off against each other; for an extension to become > "ubiquitous," it is only reasonable for its developers to improve the > builds to make them play well with pgxs. > > The way I can see this head is for there to be a significant > population of projects on PGFoundry that, by virtue of using pgxs, > become as easy to add in as most of the contrib items are now, and > perhaps roughly as easy as the average BSD Port. > If this whas combined with Jan W. suggestion (community votes to create recommendations) it would be very close to what I had in mind in the first place. A project could be hosted on PGFoundry where the "verify" process could be explained, i.e. 1. your project must be pgxs compatible. 2. it must be hosted on pgFoundry. 3. it must have automatic regression testing built in (perhaps this is part of #1). 4. documentation must follow some guidelines so that it is easy to combine it with other docs. 5. someone must suggest it as a candidate for inclusion and give a good motivation. 6. there's a voting period and a minimum number of votes. 7. if the votes are in your favor, your project will be part of the supported configurations and you will be asked to participate in the integration work. This project could also host the voting mechanism and the supported configurations. My Concerns: Who is behind PGFoundry? Is performance ok now :-) This project might be perceived as a thirdparty add-on and thus, fail its purpose. The steering committee must stand behind this officially. Will you? What's your opinion about the suggestion? Any ideas what the project should be named? Regards, Thomas Hallgren
On Wed, 25 Aug 2004, Thomas Hallgren wrote: > 1. your project must be pgxs compatible. > 2. it must be hosted on pgFoundry. > 3. it must have automatic regression testing built in (perhaps this is part > of #1). > 4. documentation must follow some guidelines so that it is easy to combine it > with other docs. > 5. someone must suggest it as a candidate for inclusion and give a good > motivation. Now, inclusion into where? The list? > 6. there's a voting period and a minimum number of votes. This one, I would say, will be very difficult ... what if its a one of piece of software, that 2 ppl are using, but its very good at what it does? Or a one of piece of software, that sucks royally but is the only thing available, and 100 ppl are using? > 7. if the votes are in your favor, your project will be part of the > supported configurations and you will be asked to participate in the > integration work. Integration work ... where? > My Concerns: > Who is behind PGFoundry? Is performance ok now :-) Check it out ... just tested it from here and seems okay to me ... > This project might be perceived as a thirdparty add-on and thus, fail > its purpose. The steering committee must stand behind this officially. > Will you? What's your opinion about the suggestion? Behind what? A list on pgFoundry of recommended software? Sure ... integrating that list into the physical postgresql.tar.gz file that is the core server distribution? No ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: >> 1. your project must be pgxs compatible. >> 2. it must be hosted on pgFoundry. >> 3. it must have automatic regression testing built in (perhaps this >> is part of #1). >> 4. documentation must follow some guidelines so that it is easy to >> combine it with other docs. >> 5. someone must suggest it as a candidate for inclusion and give a >> good motivation. > > > Now, inclusion into where? The list? The idea is that my suggested project, (I henceforth refer to it as "this project") should maintain some number of packaged configurations. So what I mean is inclusion of the candidate project artifacts in some (or all) of those packages. >> 6. there's a voting period and a minimum number of votes. > > > This one, I would say, will be very difficult ... what if its a one of > piece of software, that 2 ppl are using, but its very good at what it > does? Or a one of piece of software, that sucks royally but is the > only thing available, and 100 ppl are using? You're right. This is not crystal clear. How about this: For the first category, an inclusion could be possible if the software has a potential to reach more users and can make the offering more complete in some respect. If that's not the case, it should be included. Most software that "sucks royally" will be filtered out in the first 4 steps. If it is not, and if a lot of people vote to get it in, well then it does not suck so bad after all, at least not according to the voters. So it's in provided nothing better exists already. It can still be replaced of course, should something better come along. >> 7. if the votes are in your favor, your project will be part of the >> supported configurations and you will be asked to participate in the >> integration work. > > > Integration work ... where? In two places. Most of it takes place in the candidate project but documentation overviews, composite configurations etc. must be updated in this project to include the artifacts from the new project. Such global changes can be made by the contributor in the form of patches. >> This project might be perceived as a thirdparty add-on and thus, fail >> its purpose. The steering committee must stand behind this >> officially. Will you? What's your opinion about the suggestion? > > > Behind what? A list on pgFoundry of recommended software? Sure ... > integrating that list into the physical postgresql.tar.gz file that is > the core server distribution? No ... The core server distribution is left untouched by all this. It would be really nice if this project could publish packages using your BitTorrent and ftp mirrors though. Regards, Thomas Hallgren
On Wed, 25 Aug 2004, Thomas Hallgren wrote:
> For the first category, an inclusion could be possible if the software
> has a potential to reach more users and can make the offering more
> complete in some respect. If that's not the case, it should be included.
>
> Most software that "sucks royally" will be filtered out in the first 4 steps.
> If it is not, and if a lot of people vote to get it in, well then it does not
> suck so bad after all, at least not according to the voters. So it's in
> provided nothing better exists already. It can still be replaced of course,
> should something better come along.
Sounds reasonable, and such policy could/would be fine tuned over time as
well ...
>> Behind what? A list on pgFoundry of recommended software? Sure ...
>> integrating that list into the physical postgresql.tar.gz file that is the
>> core server distribution? No ...
>
> The core server distribution is left untouched by all this.
Ah, then you've got me on side :)
> It would be really nice if this project could publish packages using
> your BitTorrent and ftp mirrors though.
Actually, pgfoundry can be found on
ftp://ftp.postgresql.org:/pub/projects/pgFoundry
I think BitTorrent might be a bit difficult though, since it isn't
auto-updated ... or is it? David?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On 8/25/2004 11:39 AM, Marc G. Fournier wrote: > On Wed, 25 Aug 2004, Thomas Hallgren wrote: >> This project might be perceived as a thirdparty add-on and thus, fail >> its purpose. The steering committee must stand behind this officially. >> Will you? What's your opinion about the suggestion? > > Behind what? A list on pgFoundry of recommended software? Sure ... > integrating that list into the physical postgresql.tar.gz file that is the > core server distribution? No ... Marc, what does "stand behind this officially" mean to you? In my book that means "I am willing to defend it as if it is my personal opinion". We, the core team, are the official voice of the PostgreSQL project. Like it or not, but people do expect us to tell them what the project recommends as tools and interfaces, that much should be clear from this whole discussion by now. And I don't see a darn difference in putting that "document" on pgFoundry, postgresql.org or right into the tarball. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Clinging to sanity, scrappy@postgresql.org ("Marc G. Fournier") mumbled into her beard:
>>> Behind what? A list on pgFoundry of recommended software? Sure
>>> ... integrating that list into the physical postgresql.tar.gz file
>>> that is the core server distribution? No ...
>>
>> The core server distribution is left untouched by all this.
>
> Ah, then you've got me on side :)
I think this is something that's mostly self-filtering.
You'd be likely to see things fall into two categories:
- Projects that are poorly supported, which will have a hard
time keeping working in this form;
- Projects that are well-supported where there are steadily
"working releases" that people are finding easy to use.
The step that takes place AFTER all that is thus...
Distribution makers (whether for RPMs, .debs, Ports, etc.) will find,
based on the above categorization, that some projects are easy to
build packages for and to keep up to date with the "true official PG
Core" packages.
And other third party projects will be difficult/impossible to so
support. Presumably the same ones that, from numerous other
perspectives, we'd regard as being dubious recommendations.
If what is provided is sufficiently akin to what CPAN and such do that
this allows the distribution makers to _AUTOMATE_ the way they
generate packages for the add-ins, that makes it way easier for people
to say...
"You're running Frobozz Linux? Well, they have RPMs for [these
extensions]; that'll surely make it easy for you to deploy
that..."
--
(reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/finances.html
I'M SORRY, LUSER, I CAN'T LET YOU DO THAT. WHY DON'T YOU LIE DOWN AND
TAKE A STRESS PILL? MY NAME IS LM1. I WAS MADE AT THE LISP MACHINE
FACTORY IN MASSACHUSETTS ON DECEMBER 12, 1992. MY TEACHER WAS MR.
WINSTON. HE TAUGHT ME A PROGRAM. WOULD YOU LIKE TO SEE IT? HERE IT
IS: