Thread: Re: inclusions WAS: Increased company involvement
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
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
<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>
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
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)
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
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.
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
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>
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? > > ---- > 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
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&group_id=1#top Chris