Thread: Re: inclusions WAS: Increased company involvement

Re: inclusions WAS: Increased company involvement

From
Josh Berkus
Date:
Dave, all:

> This issue has come up before, and I opposed it then when the interfaces
> were removed from the main tarball.
> I really don't see the upside to reducing the size of the tarball at the
> expense of ease of use.  Seems to me we are
> bending over backwards to make it easy for people with dial up
> connections to download our "enterprise class"
> database.

Small tarball size isn't the *primary* reason for having our
"push-it-out-to-pgFoundry" attitude, it's the *tertiary* reason.  The main
two reasons are:

1) If we start including everything that's "useful", where do we stop?  There
are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and
others elsewhere.  And some of them probably conflict with each other.  Any
decision to include some projects and not others will alienate people and
possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind.

2) As long as we're using CVS, the only way to organize autonomous project
teams that have authority over their special areas but no ability to change
central code is to "push out" projects to separate CVS trees.

From my perspective, putting together a coherent "distribution" of PostgreSQL
with all the add-ins you want is the job of commercial distributors and
possibly OSS projects like Bizgres.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco


Re: inclusions WAS: Increased company involvement

From
"Andrew Dunstan"
Date:
Josh Berkus said:
> Dave, all:
>
>> This issue has come up before, and I opposed it then when the
>> interfaces were removed from the main tarball.
>> I really don't see the upside to reducing the size of the tarball at
>> the expense of ease of use. Â Seems to me we are
>> bending over backwards to make it easy for people with dial up
>> connections to download our "enterprise class"
>> database.
>
> Small tarball size isn't the *primary* reason for having our
> "push-it-out-to-pgFoundry" attitude, it's the *tertiary* reason.  The
> main  two reasons are:
>
> 1) If we start including everything that's "useful", where do we stop?
> There  are enough pg add-ins to fill a CD -- 200 projects on GBorg and
> pgFoundry and  others elsewhere.  And some of them probably conflict
> with each other.  Any  decision to include some projects and not others
> will alienate people and  possibly be a mis-evaluation; the
> libpq++/libpqxx mistake comes to mind.
>
> 2) As long as we're using CVS, the only way to organize autonomous
> project  teams that have authority over their special areas but no
> ability to change  central code is to "push out" projects to separate
> CVS trees.
>
>>From my perspective, putting together a coherent "distribution" of
>>PostgreSQL
> with all the add-ins you want is the job of commercial distributors and
>  possibly OSS projects like Bizgres.


This water-torture campaign is disappointing.

How many projects on gborg have any active maintenance? Our community is
still small - we can ill afford fragmentation.

Tom and others have already pointed out the good technical reasons for not
divorcing PLs at least from the core code.

I was not around at the time of the libpq++/libpqxx issue. But, honestly,
fear of making a wrong decision should not be a reason not to make one.

As for CVS - if we can't do development the way we want using it then it's
time to replace it. I have been convinced for quite a while that it is
living on borrowed time, but I am far less certain about what should be used
to replace it. But making macro content decisions on the basis of what we
can do with CVS is just crazy.

cheers

andrew




Re: inclusions WAS: Increased company involvement

From
James William Pye
Date:
On Tue, 2005-05-03 at 18:06 -0700, Josh Berkus wrote:
> 1) If we start including everything that's "useful", where do we stop?  There 
> are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and 
> others elsewhere.  And some of them probably conflict with each other.  Any 
> decision to include some projects and not others will alienate people and 
> possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind.

Mmm, just think of it. If enough projects get into core maybe, just
maybe, pg could compete with mozilla for the longest build time.
Wouldn't that be nice. ;)

[snip some stuff that I agree with]

With regards to PLs, there is a good argument for having them in core:
the volatility of the backend's APIs make it difficult to externally
maintain. I know this is the case, first hand. Although, if dynamically
loaded extensions are to be allowed, I think that that volatility should
be seen as a problem, and not so much as a reason to keep things in the
same tree. While I understand that it's likely to be difficult to give
interversion [source] compatibility without sacrificing general
improvement, I think it would be a good goal to have.

...
I asked on IRC and I'm still curious, does PG have a API styling
standard/guide? I see formatting and info about error messages, but
nothing about function/global/typedef naming.
-- 
Regards, James William Pye


Re: inclusions WAS: Increased company involvement

From
Josh Berkus
Date:
Andrew,

> I was not around at the time of the libpq++/libpqxx issue. But, honestly,
> fear of making a wrong decision should not be a reason not to make one.

OK, *you* choose.   I'm getting a little annoyed with how many people tell me 
"oh, it should be easy to pick the stuff to include with standard 
PostgreSQL", and then expect core to do the choosing.   Well, it's not easy, 
and core made choices.  If you don't like them, then make a proposal, 
including a set of objective criteria that can be used to evaluate future 
projects -- and even to evaluate when to drop one.

Apache does this; they have a 5-step process for accepted projects that took 
Brian & co a year to work out.  And the process has its cost; evaluation of 
acceptance is highly political and not infrequently results in people getting 
pissed off and/or impatient with the bureaucracy and leaving Apache to start 
independent projects.  And even Apache doesn't tar up everything in one big 
package; mod_perl, geronimo, PHP, etc. are all separate.

The advantage of a "small kernel" approach is the independence it gives add-in 
projects.   You can start a pgFoundry project based on a weekend's 
enthusiasm; add whomever you want, use whatever OSS license you want, release 
on your own schedule.  It means that add-in developers can prove the 
usefulness of their code by demonstration rather than having to meet some 
qualification process.

Look at other large projects with lots of options.  Apache, Perl, Linux, Java, 
emacs, KDE, etc., all of them strike a balance between including stuff and 
leaving stuff as add-ins (some more narrowly than others), and exclude a lot 
of popular and useful stuff on a variety of criteria.  Our current balance is 
on the minimalist side, and somewhat arbitrary if you look at the /contrib 
directory.  If you think there's a better balance, propose it.  Seriously.

> As for CVS - if we can't do development the way we want using it then it's
> time to replace it. I have been convinced for quite a while that it is
> living on borrowed time, but I am far less certain about what should be
> used to replace it. But making macro content decisions on the basis of what
> we can do with CVS is just crazy.

Again, you're saying that you don't have a solution but you think it should be 
fixed.  Great.  I think it should be fixed, too.  Afaik, there is *no* 
versioning system that allows for both completely independent control of 
branches and directories while at the same time allowing for a cohesive 
build.  Maybe BK does, that would explain why Linus liked it so much.

I, personally, would *love* to find a way for the drivers to be included with 
the core build while still letting the various teams -- particularly JDBC and 
Python -- have control over their own groups.  And I think we need a way for 
add-ins to build in a completely integrated way with the backend, including 
building in docs.  But these are not technically easy problems.

(I hope people understand here that I'm speaking for me, personally)

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: inclusions WAS: Increased company involvement

From
Tom Lane
Date:
"Andrew Dunstan" <andrew@dunslane.net> writes:
> As for CVS - if we can't do development the way we want using it then it's
> time to replace it.

CVS's capabilities (or lack of same) are completely unrelated to the
matter in hand.  What we are talking about is packaging, ie what should
sensibly go out in the same shipped tarball.
        regards, tom lane


Re: inclusions WAS: Increased company involvement

From
Josh Berkus
Date:
Andrew,

> OK, *you* choose.   I'm getting a little annoyed with how many people tell
> me "oh, it should be easy to pick the stuff to include with standard
> PostgreSQL", and then expect core to do the choosing.  

Sorry, that came off kinda harsh.    Seriously, I personally would love to see 
a proposal of a coherent system of what should and should not get included.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: inclusions WAS: Increased company involvement

From
Dave Cramer
Date:
<br /><br /> Josh Berkus wrote: <blockquote cite="mid200505031806.28560.josh@agliodbs.com" type="cite"><pre
wrap="">Dave,all:
 
 </pre><blockquote type="cite"><pre wrap="">This issue has come up before, and I opposed it then when the interfaces
were removed from the main tarball.
I really don't see the upside to reducing the size of the tarball at the
expense of ease of use.  Seems to me we are
bending over backwards to make it easy for people with dial up
connections to download our "enterprise class"
database.   </pre></blockquote><pre wrap="">
Small tarball size isn't the *primary* reason for having our 
"push-it-out-to-pgFoundry" attitude, it's the *tertiary* reason.  The main 
two reasons are:

1) If we start including everything that's "useful", where do we stop?  There 
are enough pg add-ins to fill a CD -- 200 projects on GBorg and pgFoundry and 
others elsewhere.  And some of them probably conflict with each other.  Any 
decision to include some projects and not others will alienate people and 
possibly be a mis-evaluation; the libpq++/libpqxx mistake comes to mind. </pre></blockquote> My main concern was
pushingout existing code, not adding code that was not in the tarball.<br /> I would have to agree deciding which to
includewould be onerous.<br /><blockquote cite="mid200505031806.28560.josh@agliodbs.com" type="cite"><pre wrap="">
 
2) As long as we're using CVS, the only way to organize autonomous project 
teams that have authority over their special areas but no ability to change 
central code is to "push out" projects to separate CVS trees. </pre></blockquote> This has never been an issue before,
AFAIK,nobody with commit privliges in a separate<br /> package has ever changed the code where they weren't supposed
to.<br/><br /> To sum this up; the arguments presented are:<br /><br /> 1) The tarball is/was  too big however nobody
evercomplained.<br /> 2) CVS does not allow different groups to have commit privliges, but nobody has ever violated the
trust<br/><br /> Is this really the situation ? <br /><br /><blockquote cite="mid200505031806.28560.josh@agliodbs.com"
type="cite"><prewrap="">
 
>From my perspective, putting together a coherent "distribution" of PostgreSQL 
with all the add-ins you want is the job of commercial distributors and 
possibly OSS projects like Bizgres. </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">-- 
Dave Cramer
<a class="moz-txt-link-freetext" href="http://www.postgresintl.com">http://www.postgresintl.com</a>
519 939 0336
ICQ#14675561
</pre>

Re: inclusions WAS: Increased company involvement

From
Josh Berkus
Date:
Dave,

> My main concern was pushing out existing code, not adding code that was
> not in the tarball.
> I would have to agree deciding which to include would be onerous.

I personally am not proposing pushing stuff out, except some of the legacy 
(i.e. not maintained) contrib modules.

I do find it kind of funny that we include the PLs but not the server-side 
drivers, but that decision precedes my tenure on Core.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: inclusions WAS: Increased company involvement

From
Tom Lane
Date:
Josh Berkus <josh@agliodbs.com> writes:
> Look at other large projects with lots of options.  Apache, Perl,
> Linux, Java, emacs, KDE, etc., all of them strike a balance between
> including stuff and leaving stuff as add-ins (some more narrowly than
> others), and exclude a lot of popular and useful stuff on a variety of
> criteria.  Our current balance is on the minimalist side, and somewhat
> arbitrary if you look at the /contrib directory.  If you think there's
> a better balance, propose it.  Seriously.

I think quite a lot of the /contrib stuff is there on basically
historical reasons --- ie, it got in before we had gborg or pgfoundry as
alternatives, and no one has felt it worthwhile to crusade to remove it.
(You can't just "remove it" without at least setting up a working
pgfoundry version, so this isn't a zero-effort thing ... whereas leaving
it where it is is close to zero effort ...)

I'd not want to see contrib slimmed down to nothing, because it has good
use as a testbed for problems with our infrastructure for building
external modules.  But a few samples of each basic type of add-on would
be enough for that, I think.
        regards, tom lane


Re: inclusions WAS: Increased company involvement

From
Alvaro Herrera
Date:
On Tue, May 03, 2005 at 09:19:41PM -0700, Josh Berkus wrote:

> I do find it kind of funny that we include the PLs but not the server-side 
> drivers, but that decision precedes my tenure on Core.

Sorry, you lost me -- what are server-side drivers?

-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Postgres is bloatware by design: it was built to housePhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)


Re: inclusions WAS: Increased company involvement

From
Greg Stark
Date:
Josh Berkus <josh@agliodbs.com> writes:

> Look at other large projects with lots of options.  Apache, Perl, Linux, Java, 
> emacs, KDE, etc., all of them strike a balance between including stuff and 
> leaving stuff as add-ins (some more narrowly than others), and exclude a lot 
> of popular and useful stuff on a variety of criteria.  Our current balance is 
> on the minimalist side, and somewhat arbitrary if you look at the /contrib 
> directory.  If you think there's a better balance, propose it.  Seriously.

Well I think you inadvertently pointed out why the distinction between these
projects and Postgres. You described them as "projects with lots of options".
By comparison Postgres has a fairly small and manageable set of options.

modules.apache.org lists 393 Apache modules. Perl has 7,976 modules on CPAN,
and of course the number of applications for Linux isn't even worth counting.
pgfoundry has 88 projects.

All of these projects grew up gradually through a natural evolutionary
process. At first lots of stuff was included in any of these. It's only when
there are enough projects to make it worthwhile for anyone to look in these
outside repositories like CPAN or modules.apache.org that they hit critical
mass and become self-sustaining.

I'm not saying pgfoundry should be shut down. But trying to force projects out
into the sterile landscape where they get little use and little support is a
death warrant. And unnecessary.

I think what I would suggest is going through pgfoundry, and checking in the
stable release of any good looking project into the contrib directory of the
Postgres distribution.


-- 
greg



Re: inclusions WAS: Increased company involvement

From
Tom Lane
Date:
Greg Stark <gsstark@mit.edu> writes:
> I'm not saying pgfoundry should be shut down. But trying to force
> projects out into the sterile landscape where they get little use and
> little support is a death warrant. And unnecessary.

> I think what I would suggest is going through pgfoundry, and checking in the
> stable release of any good looking project into the contrib directory of the
> Postgres distribution.

In other words, decide that pgfoundry is a dead end that will never
work, and so instead we'll load that maintenance effort back onto the
core developers.

NO, THANK YOU.

It's entirely likely that we haven't figured out how to make pgfoundry
work yet.  But figure it out we must, or the project-as-a-whole will die
of its own weight.  Not everything can be part of the core.

This isn't directly applicable to the PLs, since those are large efforts
(and thereby relatively few in number) and they tend to have very
high-bandwidth linkages to the core server.  But to treat everything as
having those same needs is a recipe for failure.
        regards, tom lane


Re: inclusions WAS: Increased company involvement

From
Greg Stark
Date:
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > I'm not saying pgfoundry should be shut down. But trying to force
> > projects out into the sterile landscape where they get little use and
> > little support is a death warrant. And unnecessary.
> 
> > I think what I would suggest is going through pgfoundry, and checking in the
> > stable release of any good looking project into the contrib directory of the
> > Postgres distribution.
> 
> In other words, decide that pgfoundry is a dead end that will never
> work, and so instead we'll load that maintenance effort back onto the
> core developers.
> 
> NO, THANK YOU.

Er. No that's not what I'm saying at all.

What I'm saying is that pgfoundry will eventually happen. It will eventually
be the case that there are enough projects that people will look there when
they need something instead of just assuming it doesn't exist.

But you can't just snap your fingers and make it happen. If all you have is a
couple dozen packages and you banish them to some place nobody knows about
then all that will accomplish is killing them off.

I don't really see the contrib directory taking up much "maintenance effort"
in the recent past. Even major projects like GiST don't really mean Core has
to take the main brunt of the maintenance. It just means that people have a
chance of finding tsearch et al and the upstream maintainers.

I'm mainly thinking about server modules like all of the contrib directories.
I don't see any obvious way to integrate things like pgpool into the same
model.

> It's entirely likely that we haven't figured out how to make pgfoundry
> work yet.  But figure it out we must, or the project-as-a-whole will die
> of its own weight.  Not everything can be part of the core.

Eventually. But that's not the case today. The existing contrib directory
hasn't killed the project with its weight. And neither will adding half a
dozen more files. 

Note that the existence of pgfoundry doesn't mean that the core distribution
won't grow either. Perl has more packages in its core distribution than
Postgres has including contrib and pgfoundry. Many of those packages are also
on CPAN but are included in a base install.

-- 
greg



Re: inclusions WAS: Increased company involvement

From
Andrew Dunstan
Date:

Tom Lane wrote:

>"Andrew Dunstan" <andrew@dunslane.net> writes:
>  
>
>>As for CVS - if we can't do development the way we want using it then it's
>>time to replace it.
>>    
>>
>
>CVS's capabilities (or lack of same) are completely unrelated to the
>matter in hand.  What we are talking about is packaging, ie what should
>sensibly go out in the same shipped tarball.
>
>  
>
I agree. I was responding to Josh's suggestion that CVS limitations were 
driving policy, but your response is more apposite ;-)

cheers

andrew


Re: inclusions WAS: Increased company involvement

From
Christopher Browne
Date:
Centuries ago, Nostradamus foresaw when josh@agliodbs.com (Josh Berkus) would write:
> Look at other large projects with lots of options.  Apache, Perl, Linux, Java, 
> emacs, KDE, etc., all of them strike a balance between including stuff and 
> leaving stuff as add-ins (some more narrowly than others), and exclude a lot 
> of popular and useful stuff on a variety of criteria.  Our current balance is 
> on the minimalist side, and somewhat arbitrary if you look at the /contrib 
> directory.  If you think there's a better balance, propose it.  Seriously.

There have been efforts in 7.4 and ongoing to make it easier to have
more software behave rather like the /contrib stuff.

The thing that has been a Real Pain is when extensions required a full
source tree simply because of needing access to a few extra #includes
and such.

In v8, the expansion of the default #includes means that what used to
require a tarball can now just point to #includes and libraries,
making it way easier to live outside /contrib.

This is a Good Thing, particularly for those building .deb and .rpm
packages, as they can build these without needing some
near-arbitrarily-big PG build tree.

>> As for CVS - if we can't do development the way we want using it
>> then it's time to replace it. I have been convinced for quite a
>> while that it is living on borrowed time, but I am far less certain
>> about what should be used to replace it. But making macro content
>> decisions on the basis of what we can do with CVS is just crazy.

> Again, you're saying that you don't have a solution but you think it
> should be fixed.  Great.  I think it should be fixed, too.  Afaik,
> there is *no* versioning system that allows for both completely
> independent control of branches and directories while at the same
> time allowing for a cohesive build.  Maybe BK does, that would
> explain why Linus liked it so much.

Of course, he's in the process of "git'ting" to a new system called
"git."

And it's worth observing that BK/git/whatever are only being used to
manage the Linux kernel.

A fairer comparison would be the BSD core systems.  I believe that
most of them have a considerably larger set of stuff in the "central
CVS"...

> I, personally, would *love* to find a way for the drivers to be
> included with the core build while still letting the various teams
> -- particularly JDBC and Python -- have control over their own
> groups.  And I think we need a way for add-ins to build in a
> completely integrated way with the backend, including building in
> docs.  But these are not technically easy problems.
>
> (I hope people understand here that I'm speaking for me, personally)

Of course.  For me, these _are_ technically easy problems ;-).  

Just kidding!  Those sound like potentially valuable things that are
doubtless difficult to achieve...
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/emacs.html
MICROS~1:  Where do you  want to  go today?   Linux: Been  there, done
that.


Re: inclusions WAS: Increased company involvement

From
Christopher Browne
Date:
The world rejoiced as andrew@dunslane.net ("Andrew Dunstan") wrote:
> As for CVS - if we can't do development the way we want using it
> then it's time to replace it. I have been convinced for quite a
> while that it is living on borrowed time, but I am far less certain
> about what should be used to replace it. But making macro content
> decisions on the basis of what we can do with CVS is just crazy.

No, I don't think that's the point.

(Aside: There are people messing about with alternatives to CVS, so
when rumbles get loud enough, there should be some experiences to
point at...  For instance, there's at least one darcs repository
tracking CVS...)

The point is of how much should get bundled together as a single
release.  When it _is_ so bundled, some degree of testing needs to be
done to make sure that what is in that bundle "holds together as one."
I don't think it makes sense for that to be a bundle of near-infinite
size; that makes it of near-infinite cost to do the testing.
-- 
let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/lisp.html
"Language shapes the  way we think   and determines what we can  think
about." -- Benjamin Whorf


Re: inclusions WAS: Increased company involvement

From
Dave Cramer
Date:
OK, so the real issue is how do we make pgfoundry work.<br /><br /> My issue is that by pushing all collateral
projectsoff to another site makes it difficult for people<br /> who are not familiar with the project to find what they
arelooking for or even to know what there is to look for.<br /><br /> I'm sure there are other issues as well?<br /><br
/>I think it would be useful if we could increase the visibility of core interfaces such as odbc/jdbc, etc.<br />    
1)add in the README the rest of the interface locations<br />     2) create a page on pgfoundry for interfaces. This
wasproposed when the interfaces were removed and <br /> somehow did not get done.<br /><br /> I think there's
considerableroom for creativity here, including some kind of smart installer that would pull binaries, and or<br />
sourcefrom each sub-projects respective locations, but I can also see that keeping this up to date will be
difficult.<br/><br /> Dave<br /> Tom Lane wrote: <blockquote cite="mid14876.1115184056@sss.pgh.pa.us" type="cite"><pre
wrap="">GregStark <a class="moz-txt-link-rfc2396E" href="mailto:gsstark@mit.edu"><gsstark@mit.edu></a> writes:
</pre><blockquotetype="cite"><pre wrap="">I'm not saying pgfoundry should be shut down. But trying to force
 
projects out into the sterile landscape where they get little use and
little support is a death warrant. And unnecessary.   </pre></blockquote><pre wrap=""> </pre><blockquote
type="cite"><prewrap="">I think what I would suggest is going through pgfoundry, and checking in the
 
stable release of any good looking project into the contrib directory of the
Postgres distribution.   </pre></blockquote><pre wrap="">
In other words, decide that pgfoundry is a dead end that will never
work, and so instead we'll load that maintenance effort back onto the
core developers.

NO, THANK YOU.

It's entirely likely that we haven't figured out how to make pgfoundry
work yet.  But figure it out we must, or the project-as-a-whole will die
of its own weight.  Not everything can be part of the core.

This isn't directly applicable to the PLs, since those are large efforts
(and thereby relatively few in number) and they tend to have very
high-bandwidth linkages to the core server.  But to treat everything as
having those same needs is a recipe for failure.
        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

 </pre></blockquote><br /><pre class="moz-signature" cols="72">-- 
Dave Cramer
<a class="moz-txt-link-freetext" href="http://www.postgresintl.com">http://www.postgresintl.com</a>
519 939 0336
ICQ#14675561
</pre>

Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Christopher Browne wrote:

> A fairer comparison would be the BSD core systems.  I believe that most 
> of them have a considerably larger set of stuff in the "central CVS"...

Yup, and *everyone* with commit accesss has access to *everything* ... I 
could intruduce a 1 bit change to one of the kernel sources and there is a 
chance that nobody would ever notice it ... and this includes (or, at 
least, the last time I did any work) port committers ...

And, as Josh pointed out, one of the goals with pgfoundry was/is to make 
it easy for 'Project Admin' to add commit access to whomever they wish, 
whenever they wish, something that doesn't happen with FreeBSD ... its 
relatively rare that you see a new committer added, and not on a whim ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
Christopher Kings-Lynne
Date:
> Yup, and *everyone* with commit accesss has access to *everything* ... I 
> could intruduce a 1 bit change to one of the kernel sources and there is 
> a chance that nobody would ever notice it ... and this includes (or, at 
> least, the last time I did any work) port committers ...

Using cvsacls could deal with that particular problem.  Take the PHP 
project's 1500 committers, and how they can only modify particular files.

Of course, having 1500 committers has made PHP a steaming pile of junk, 
so don't think I support that :)

Being a committer is like that famous saying, "I would never join any 
club that would have me as a member" :D

Chris


Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Dave Cramer wrote:

> OK, so the real issue is how do we make pgfoundry work.
>
> My issue is that by pushing all collateral projects off to another site makes 
> it difficult for people
> who are not familiar with the project to find what they are looking for or 
> even to know what there is to look for.
>
> I'm sure there are other issues as well?
>
> I think it would be useful if we could increase the visibility of core 
> interfaces such as odbc/jdbc, etc.
>   1) add in the README the rest of the interface locations

Agreed, and I believe this was suggested before ... the only thing 
stopping this from happening, I believe, is for the project admins to 
submit patches to add their interface ... ?

>   2) create a page on pgfoundry for interfaces. This was proposed when the 
> interfaces were removed and
> somehow did not get done.

You mean:
    http://pgfoundry.org/softwaremap/trove_list.php?form_cat=310

the more 'highly visible projects' that get moved onto pgfoundry, the more 
visible pgfoundry itself will become, and the 'defacto standard place to 
look' ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Andrew Dunstan wrote:

>
>
> Tom Lane wrote:
>
>> "Andrew Dunstan" <andrew@dunslane.net> writes:
>> 
>>> As for CVS - if we can't do development the way we want using it then it's
>>> time to replace it.
>>> 
>> 
>> CVS's capabilities (or lack of same) are completely unrelated to the
>> matter in hand.  What we are talking about is packaging, ie what should
>> sensibly go out in the same shipped tarball.
>> 
>> 
> I agree. I was responding to Josh's suggestion that CVS limitations were 
> driving policy, but your response is more apposite ;-)

Just curious here ... but do any of the version control systems provide 
"per directory user restrictions"?  Where I could give CVS access to 
Joshua, for instance, just to the plphp directory?

Serious question here, since I don't know, I only know CVS can't (or, 
rather, not that I've ever been able to find in the docs) ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Dave Cramer wrote:

>> 2) As long as we're using CVS, the only way to organize autonomous project 
>> teams that have authority over their special areas but no ability to change 
>> central code is to "push out" projects to separate CVS trees.
>> 
> This has never been an issue before, AFAIK, nobody with commit privliges 
> in a separate package has ever changed the code where they weren't 
> supposed to.

It isn't so much that as allowing 'project teams' arbitrarily 
adding/removing their own committers, instead of having "one central 
committer for a project" that everything went through ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Alvaro Herrera wrote:

> On Tue, May 03, 2005 at 09:19:41PM -0700, Josh Berkus wrote:
>
>> I do find it kind of funny that we include the PLs but not the server-side
>> drivers, but that decision precedes my tenure on Core.
>
> Sorry, you lost me -- what are server-side drivers?

Oh, good ... I ended up sending Josh an email offlist asking this, cause I 
figured I was missing something ... but now I feel vindicated(?) knowing 
I'm not the only one confused by this one :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Christopher Kings-Lynne wrote:

>> Yup, and *everyone* with commit accesss has access to *everything* ... I 
>> could intruduce a 1 bit change to one of the kernel sources and there is a 
>> chance that nobody would ever notice it ... and this includes (or, at 
>> least, the last time I did any work) port committers ...
>
> Using cvsacls could deal with that particular problem.  Take the PHP 
> project's 1500 committers, and how they can only modify particular files.

cvsacls?  got a URL for that that I can read?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
Shridhar Daithankar
Date:
On Wednesday 04 May 2005 8:18 pm, Marc G. Fournier wrote:
> Just curious here ... but do any of the version control systems provide
> "per directory user restrictions"?  Where I could give CVS access to
> Joshua, for instance, just to the plphp directory?

Subversion does.

http://svnbook.red-bean.com/en/1.0/ch06s04.html#svn-ch-6-sect-4.4.2
Shridhar


Re: inclusions WAS: Increased company involvement

From
Andrew Dunstan
Date:

Marc G. Fournier wrote:

>
> Just curious here ... but do any of the version control systems 
> provide "per directory user restrictions"? Where I could give CVS 
> access to Joshua, for instance, just to the plphp directory?
>
> Serious question here, since I don't know, I only know CVS can't (or, 
> rather, not that I've ever been able to find in the docs) ...
>

check out http://cvsacl.sourceforge.net/

I haven't used it but it looks like it does exactly what you're asking for.

cheers


andrew


Re: inclusions WAS: Increased company involvement

From
Dennis Bjorklund
Date:
On Wed, 4 May 2005, Marc G. Fournier wrote:

> Just curious here ... but do any of the version control systems provide 
> "per directory user restrictions"?  Where I could give CVS access to 
> Joshua, for instance, just to the plphp directory?

Just how many incidents where people change the wrong files do you except. 
Maybe it's just easier to handle one such case every third year than to 
set up some system to prevent it.

-- 
/Dennis Björklund



Re: inclusions WAS: Increased company involvement

From
"Joshua D. Drake"
Date:
Dennis Bjorklund wrote:
> On Wed, 4 May 2005, Marc G. Fournier wrote:
> 
> 
>>Just curious here ... but do any of the version control systems provide 
>>"per directory user restrictions"?  Where I could give CVS access to 
>>Joshua, for instance, just to the plphp directory?
> 
> 
> Just how many incidents where people change the wrong files do you except. 
> Maybe it's just easier to handle one such case every third year than to 
> set up some system to prevent it.

The number of incidents isn't the issue, the fact that it could happen 
at all is.

This isn't a web browser. This is a system that companies, very - very 
big companies rely on. We must have a controlled, documented process for 
comitters.

Sincerely,

Joshua D. Drake



> 



Re: inclusions WAS: Increased company involvement

From
Dennis Bjorklund
Date:
On Wed, 4 May 2005, Joshua D. Drake wrote:

> > Just how many incidents where people change the wrong files do you except. 
> > Maybe it's just easier to handle one such case every third year than to 
> > set up some system to prevent it.
> 
> The number of incidents isn't the issue, the fact that it could happen 
> at all is.
> 
> This isn't a web browser.

Du you have anything against browsers? :-)

> This is a system that companies, very - very big companies rely on. We
> must have a controlled, documented process for comitters.

And?

If you tell someone he/she is just allowed to commit in the pl/foo
subproject then that's probably more then enough. The nice thing with cvs
is that old things are not lost and all the commits are sent out on a
mailinglist. I don't see how this is any different just because some very
- very big companies are involved.

If it's easy to do, fine. I just don't see it as a very important thing.

Anyway. I think it's a good thing that postgresql do as little as possible
and stuff that can be handled separately are.

-- 
/Dennis Björklund



Re: inclusions WAS: Increased company involvement

From
Josh Berkus
Date:
Folks,

> > Sorry, you lost me -- what are server-side drivers?
>
> Oh, good ... I ended up sending Josh an email offlist asking this, cause I
> figured I was missing something ... but now I feel vindicated(?) knowing
> I'm not the only one confused by this one :)

Drivers that get used on the server at least some of the time, like libpqxx 
and JDBC, as opposed to drivers which are strictly client-only, like pgODBC.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Josh Berkus wrote:

> Folks,
>
>>> Sorry, you lost me -- what are server-side drivers?
>>
>> Oh, good ... I ended up sending Josh an email offlist asking this, cause I
>> figured I was missing something ... but now I feel vindicated(?) knowing
>> I'm not the only one confused by this one :)
>
> Drivers that get used on the server at least some of the time, like libpqxx
> and JDBC, as opposed to drivers which are strictly client-only, like pgODBC.

JDBC gets used on the server?  Where?  Same with libpqxx ... where is that 
used on the server side?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
"Joshua D. Drake"
Date:
Marc G. Fournier wrote:
> On Wed, 4 May 2005, Josh Berkus wrote:
> 
>> Folks,
>>
>>>> Sorry, you lost me -- what are server-side drivers?
>>>
>>>
>>> Oh, good ... I ended up sending Josh an email offlist asking this, 
>>> cause I
>>> figured I was missing something ... but now I feel vindicated(?) knowing
>>> I'm not the only one confused by this one :)
>>
>>
>> Drivers that get used on the server at least some of the time, like 
>> libpqxx
>> and JDBC, as opposed to drivers which are strictly client-only, like 
>> pgODBC.
> 
> 
> JDBC gets used on the server?  Where?  Same with libpqxx ... where is 
> that used on the server side?

The app server is where it would be used. The app server may also be the 
database server but in all if you look at it from the paradigm of 
PostgreSQL is the server, there is no server side driver. Only client 
side. Where the app server is the client.

Confusing enough?


> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster



Re: inclusions WAS: Increased company involvement

From
"Marc G. Fournier"
Date:
On Wed, 4 May 2005, Joshua D. Drake wrote:

> Marc G. Fournier wrote:
>> On Wed, 4 May 2005, Josh Berkus wrote:
>> 
>>> Folks,
>>> 
>>>>> Sorry, you lost me -- what are server-side drivers?
>>>> 
>>>> 
>>>> Oh, good ... I ended up sending Josh an email offlist asking this, cause 
>>>> I
>>>> figured I was missing something ... but now I feel vindicated(?) knowing
>>>> I'm not the only one confused by this one :)
>>> 
>>> 
>>> Drivers that get used on the server at least some of the time, like 
>>> libpqxx
>>> and JDBC, as opposed to drivers which are strictly client-only, like 
>>> pgODBC.
>> 
>> 
>> JDBC gets used on the server?  Where?  Same with libpqxx ... where is that 
>> used on the server side?
>
> The app server is where it would be used. The app server may also be the 
> database server but in all if you look at it from the paradigm of PostgreSQL 
> is the server, there is no server side driver. Only client side. Where the 
> app server is the client.
>
> Confusing enough?

Not really, since that is exactly as *I* thought it was ... a client side 
connector, not server side :)  If both the JDBC and DB server are on the 
same physical machine, that is a design choice, but if we go by that as 
making it a 'server side driver', then pretty much any add on for 
PostgreSQL (DBD::Pg, php4-pgsql, etc) would fall under the same realm ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


Re: inclusions WAS: Increased company involvement

From
"Joshua D. Drake"
Date:
  > It's entirely likely that we haven't figured out how to make pgfoundry
> work yet.  But figure it out we must, or the project-as-a-whole will die
> of its own weight.  Not everything can be part of the core.

PgFoundry is coming along in its own right. I see three main problems 
with it at current:

1. It looks like a separate project from PostgreSQL (website, name, etc...)

2. Stability and speed (which is currently being resolved)

3. Gborg still exists (which is going away once number 2 is resolved).

The traffic on pgFoundry is increasing as are the projects being 
submitted. I don't think there is an issue of pgFoundry being a success 
as much as an issue of it being a success as part of the PostgreSQL 
project itself.

Sincerely,

Joshua D. Drake




Re: inclusions WAS: Increased company involvement

From
"Gavin M. Roy"
Date:
Joshua D. Drake wrote:

>
> PgFoundry is coming along in its own right. I see three main problems 
> with it at current:
>
> 1. It looks like a separate project from PostgreSQL (website, name, 
> etc...)

I've been working on porting the site to use a derived theme from the 
main PostgreSQL site.  My main issue right now is finding the right font 
for the header as Omar and Emily don't have access to it from what I've 
been told.

Regards,

Gavin


[ catching up... ]

James William Pye <pgsql@jwp.name> writes:
> I asked on IRC and I'm still curious, does PG have a API styling
> standard/guide? I see formatting and info about error messages, but
> nothing about function/global/typedef naming.

Nothing official, but here's a few random thoughts collected from my
experience:

There's no project-wide standards for names.  Given the number of people
who have worked on the code and used different styles, it's probably
hopeless to settle on just one style.  I do advise trying to "be like
what you see around you" when working within any existing section of
code.

There is plenty of precedent in the code for both MultiWordName and
multi_word_name, so no one will complain if you use either.  There
isn't much of any "Hungarian notation" (that is, using a name like
"iFoo" to denote that the object is of integer type), and personally
I don't care for that so I'd not encourage its introduction.

Macros should usually be named in ALL_CAPS to remind users that they
are macros not functions.  This is particularly critical if the macro
doesn't have exact function-call-like semantics (ie, exactly one
evaluation of each argument).  If it is a function call equivalent
then it's probably okay to name it like a function.

We're not very consistent about whether symbolic constants (enum values,
paramless constant macros, etc) are in all caps or not.

Avoid exporting stuff that you don't absolutely have to --- eg, make
functions "static" if at all possible.  One fairly common exception to
this is that many modules export struct definitions that they maybe
don't have to.  I get the impression that this was conventional during
the Berkeley phase of the project, possibly for debugging reasons, but
now I think it's bad style.  Export an abstract "struct foo" typedef
instead, if you can.

A somewhat related point: avoid defining APIs in ways that force
widely-used headers to include lesser-used headers.  The fewer
#includes in headers the better IMHO, since otherwise you end up
with a completely flat namespace ...
        regards, tom lane


Re: inclusions WAS: Increased company involvement

From
Christopher Kings-Lynne
Date:
>> Using cvsacls could deal with that particular problem.  Take the PHP 
>> project's 1500 committers, and how they can only modify particular files.
> 
> cvsacls?  got a URL for that that I can read?

http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#top

Chris