Re: inclusions WAS: Increased company involvement

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

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

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

"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

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

Josh Berkus wrote:

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.

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.

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.

To sum this up; the arguments presented are:

1) The tarball is/was too big however nobody ever complained.
2) CVS does not allow different groups to have commit privliges, but
nobody has ever violated the trust

Is this really the situation ?

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.

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

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

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

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

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.

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 house
PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)

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

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

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

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

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
2) create a page on pgfoundry for interfaces. This was proposed when
the interfaces were removed and
somehow did not get done.

I think there's considerable room for creativity here, including some
kind of smart installer that would pull binaries, and or
source from each sub-projects respective locations, but I can also see
that keeping this up to date will be difficult.

Dave
Tom Lane wrote:

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

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

--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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&amp;group_id=1#top

Chris