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
---(end
[ catching up... ]
James William Pye <[EMAIL PROTECTED]> 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 thoug
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
> 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:
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 vindic
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 confus
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
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 serv
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
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 peopl
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
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.
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, n
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
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,
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
On Wed, 4 May 2005, Andrew Dunstan wrote:
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> 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 ta
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 i
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 d
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
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 o
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 tha
The world rejoiced as [EMAIL PROTECTED] ("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
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> 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
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> 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
Greg Stark <[EMAIL PROTECTED]> 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 ch
Josh Berkus 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
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 (<[EMAIL PROTECTED]>)
"Postgr
Josh Berkus 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 variet
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 i
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
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 p
"Andrew Dunstan" <[EMAIL PROTECTED]> 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 o
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 sta
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
> de
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 t
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 w
37 matches
Mail list logo
