Thread: PostgreSQL committer history?
Hello everyone, I'm trying to understand the social structure of the PostgreSQL project. Is there a documented history of who became a committer and when? That you could point me to? Thanks! Dirk Dirk Riehle, ph: +49 172 184 8755, web: http://www.riehle.org Interested in wiki research? Please see http://www.wikisym.org!
On Wed, 2006-03-08 at 13:28 +0100, Dirk Riehle wrote: > I'm trying to understand the social structure of the PostgreSQL > project. Is there a documented history of who became a committer and > when? Not as far as I know -- the website has a list of current committers, but that doesn't include past committers or the date the commit bit was given out. You should be able to determine this information fairly easily by looking at the date of the first commit made by each committer in CVS. -Neil
Thanks! I want to run some statistical analysis (not just on pgsql but other OSS projects as well) on changes in committer population. How could I figure out whether anyone ever left? (Or does one just become dormant?) My guess is that in most OSS projects, the number of committers increases over time, but the rate of contributor to committer conversion declines. May sound obvious, but of course there are other factors, like pace of development and need for people that influences this. Thanks again, Dirk PS: I guessed that pgsql-advocacy was a proper place to ask these question. If not, please let me know. (And where to go, possibly.) At 08.03.2006, Neil Conway wrote: >On Wed, 2006-03-08 at 13:28 +0100, Dirk Riehle wrote: > > I'm trying to understand the social structure of the PostgreSQL > > project. Is there a documented history of who became a committer and > > when? > >Not as far as I know -- the website has a list of current committers, >but that doesn't include past committers or the date the commit bit was >given out. You should be able to determine this information fairly >easily by looking at the date of the first commit made by each committer >in CVS. > >-Neil
Dirk Riehle wrote: > Hello everyone, > > I'm trying to understand the social structure of the PostgreSQL > project. Is there a documented history of who became a committer and > when? That you could point me to? Uh, we don't have a very formal organization, so this information doesn't really exist. MIT did a study about our open source community. You might find that useful, but I don't have the URL. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
Dirk Riehle wrote: > Thanks! I want to run some statistical analysis (not just on pgsql > but other OSS projects as well) on changes in committer population. > How could I figure out whether anyone ever left? (Or does one just > become dormant?) > > My guess is that in most OSS projects, the number of committers > increases over time, but the rate of contributor to committer > conversion declines. May sound obvious, but of course there are other > factors, like pace of development and need for people that influences this. Keep in mind that many patches developed by others are applied by a committer, so you can't assume the person committing the patch wrote the patch. There is a name in the commit message when this happens though. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
On Wed, 2006-03-08 at 10:37, Neil Conway wrote:
> On Wed, 2006-03-08 at 13:28 +0100, Dirk Riehle wrote:
> > I'm trying to understand the social structure of the PostgreSQL
> > project. Is there a documented history of who became a committer and
> > when?
>
> Not as far as I know -- the website has a list of current committers,
It does? Where is that?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Wed, Mar 08, 2006 at 01:12:41PM -0500, Bruce Momjian wrote: > Dirk Riehle wrote: > > Hello everyone, > > > > I'm trying to understand the social structure of the PostgreSQL > > project. Is there a documented history of who became a committer and > > when? That you could point me to? > > Uh, we don't have a very formal organization, so this information > doesn't really exist. MIT did a study about our open source community. > You might find that useful, but I don't have the URL. This would be Karim Lakhani from MIT. You can google for his excellent papers. --elein > > -- > Bruce Momjian http://candle.pha.pa.us > SRA OSS, Inc. http://www.sraoss.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
Thanks! What's out there in terms of economics research has largely been compiled here: http://opensource.mit.edu Maybe not coincidentely, that site is maintained by the aforementioned Karim Lakhani. Dirk At 08.03.2006, Bruce Momjian wrote: >Dirk Riehle wrote: > > Hello everyone, > > > > I'm trying to understand the social structure of the PostgreSQL > > project. Is there a documented history of who became a committer and > > when? That you could point me to? > >Uh, we don't have a very formal organization, so this information >doesn't really exist. MIT did a study about our open source community. >You might find that useful, but I don't have the URL. > >-- > Bruce Momjian http://candle.pha.pa.us > SRA OSS, Inc. http://www.sraoss.com > > + If your life is a hard drive, Christ can be your backup. +
Dirk, To sum up the answers to your question: it's possible to get the information you want, but it would require someone to spend several dozen hours compliling raw data and correlating it (you need to check the CVS logs and comments against the archives of the COMMITTERS and PATCHES mailing lists). --Josh Josh Berkus Aglio Database Solutions San Francisco
On Mar 8, 2006, at 2:35 PM, Josh Berkus wrote: > Dirk, > > To sum up the answers to your question: it's possible to get the > information you want, but it would require someone to spend several > dozen > hours compliling raw data and correlating it (you need to check the > CVS > logs and comments against the archives of the COMMITTERS and PATCHES > mailing lists). Or a simple matter of perl... Any reason we can't make the raw CVS repository (which would contain all this info) available somewhere? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Wed, 2006-03-08 at 15:37 -0600, Jim Nasby wrote: > Any reason we can't make the raw CVS repository (which would contain > all this info) available somewhere? All the CVS information *is* available (e.g. via cvsup), it is just difficult to correlate a given CVS commit with the actual contributor who worked on the patch. Getting the raw data out of CVS for commits is fairly straightforward: when working with Karim, I actually wrote a bunch of scripts to transform CVS metadata into data stored in a PostgreSQL database, and then generated the data that Karim needed via a few queries. (If anyone wants the scripts, I'd be happy to send you a copy, although they are somewhat dirty.) -Neil
On Wed, 2006-03-08 at 13:57 -0500, Robert Treat wrote: > On Wed, 2006-03-08 at 10:37, Neil Conway wrote: > > Not as far as I know -- the website has a list of current committers, > > It does? Where is that? Oh, I thought http://www.postgresql.org/developer/bios had it, but it doesn't. There's a case to be made for publicizing this information more clearly: having the commit bit is a moderately important social indicator among CVS-using open source projects. -Neil
Neil Conway wrote: > On Wed, 2006-03-08 at 13:57 -0500, Robert Treat wrote: > > On Wed, 2006-03-08 at 10:37, Neil Conway wrote: > > > Not as far as I know -- the website has a list of current committers, > > > > It does? Where is that? > > Oh, I thought http://www.postgresql.org/developer/bios had it, but it > doesn't. There's a case to be made for publicizing this information more > clearly: having the commit bit is a moderately important social > indicator among CVS-using open source projects. Committers go through the same approval process as non-committers, so it is only the physical commit action that separates committers from non-committers, so for us, commit privileges aren't a good indicator. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
On Wed, 2006-03-08 at 17:07 -0500, Bruce Momjian wrote: > Committers go through the same approval process as non-committers No, they don't: committers can commit changes directly to CVS, whereas non-committers need to send them to -patches and have someone else review and apply them. That significantly lowers the barriers to modifying Postgres. Of course, there is still oversight by other developers: someone else is liable to review your code once it's in the tree, and it is considered bad practise for the non-core committers (e.g. me) to commit major patches without sending them to -patches first. But the fact remains that there is a significant difference in the workflow between committers and non-committers (particularly when it takes several weeks or months for a patch to be applied, as can sometimes be the case). > so it is only the physical commit action that separates committers from > non-committers, so for us, commit privileges aren't a good indicator. Sure they are: having the commit bit partly reflects the degree of trust that the developer has earned based on their prior contributions. The significance of having commit privileges depends on the project: in Postgres it typically takes a *long* time for an individual to become a committer, whereas other projects are more liberal about it. But that's a matter of degree: in both cases having the commit bit infers something about the project's trust in a contributor. -Neil
Let me say then that _ideally_ committers and non-committers should go through the same process. --------------------------------------------------------------------------- Neil Conway wrote: > On Wed, 2006-03-08 at 17:07 -0500, Bruce Momjian wrote: > > Committers go through the same approval process as non-committers > > No, they don't: committers can commit changes directly to CVS, whereas > non-committers need to send them to -patches and have someone else > review and apply them. That significantly lowers the barriers to > modifying Postgres. Of course, there is still oversight by other > developers: someone else is liable to review your code once it's in the > tree, and it is considered bad practise for the non-core committers > (e.g. me) to commit major patches without sending them to -patches > first. But the fact remains that there is a significant difference in > the workflow between committers and non-committers (particularly when it > takes several weeks or months for a patch to be applied, as can > sometimes be the case). > > > so it is only the physical commit action that separates committers from > > non-committers, so for us, commit privileges aren't a good indicator. > > Sure they are: having the commit bit partly reflects the degree of trust > that the developer has earned based on their prior contributions. The > significance of having commit privileges depends on the project: in > Postgres it typically takes a *long* time for an individual to become a > committer, whereas other projects are more liberal about it. But that's > a matter of degree: in both cases having the commit bit infers something > about the project's trust in a contributor. > > -Neil > > -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
On Wednesday 08 March 2006 17:26, Neil Conway wrote:
> On Wed, 2006-03-08 at 17:07 -0500, Bruce Momjian wrote:
> > so it is only the physical commit action that separates committers from
> > non-committers, so for us, commit privileges aren't a good indicator.
>
> Sure they are: having the commit bit partly reflects the degree of trust
> that the developer has earned based on their prior contributions. The
> significance of having commit privileges depends on the project: in
> Postgres it typically takes a *long* time for an individual to become a
> committer, whereas other projects are more liberal about it.
I think Bruce's take is more accurate. For example, look at folks like Dave,
Magnus, Teodor, or myself; none of us have commit (afaik) but I would like to
think we would all be trusted not to screw things up if we had it.
OTOH I guess there might be more people like you who look at it like a trust
thing, and I just haven't been told about this since I'm not trusted. :-)
Given the amount of access I have to other things, I doubt that's the case
though. Or at least I'll keep telling myself that.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Wed, 2006-03-08 at 17:52 -0500, Robert Treat wrote: > I think Bruce's take is more accurate. For example, look at folks like Dave, > Magnus, Teodor, or myself; none of us have commit (afaik) but I would like to > think we would all be trusted not to screw things up if we had it. Teodor does have the commit bit, but only for GiST, tsearch, and related code. It's not up to me, but to be frank I *wouldn't* trust you, Dave, or Teodor with the commit bit for the bulk of the Postgres tree because IMHO you haven't modified the tree enough to deserve that degree of trust. (I'd personally be happy giving Magnus the commit bit, but core tend to be conservative about handing it out.) > OTOH I guess there might be more people like you who look at it like a trust > thing, and I just haven't been told about this since I'm not trusted. :-) Well, on what basis do you think -core hand out the commit bit? > Given the amount of access I have to other things, I doubt that's the case > though. Access to other things is irrelevant: we're talking about the right to directly change the source code. There is no reason why the people who are trusted to maintain the website ought to be trusted to commit unreviewed patches, or vice versa. -Neil
Neil, Robert, > Access to other things is irrelevant: we're talking about the right to > directly change the source code. There is no reason why the people who > are trusted to maintain the website ought to be trusted to commit > unreviewed patches, or vice versa. Right. I don't have the commit bit, for example, because my C sucks and CVS baffles me. So I think even if someone gave it to me I might conveniently lose the password. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Wednesday 08 March 2006 18:52, Neil Conway wrote:
> On Wed, 2006-03-08 at 17:52 -0500, Robert Treat wrote:
> > I think Bruce's take is more accurate. For example, look at folks like
> > Dave, Magnus, Teodor, or myself; none of us have commit (afaik) but I
> > would like to think we would all be trusted not to screw things up if we
> > had it.
>
> Teodor does have the commit bit, but only for GiST, tsearch, and related
> code.
>
Woops.. is it Oleg who doesn't have it? ISTR one of those guys didn't. But
more to the point, we don't have granular commit bits as your implying afaik.
> It's not up to me, but to be frank I *wouldn't* trust you, Dave, or
> Teodor with the commit bit for the bulk of the Postgres tree because
> IMHO you haven't modified the tree enough to deserve that degree of
> trust.
That seems goofy IMHO. If the commit bit is to signify "trust", then ISTM
that you would give it to those people whom you trust not to screw something
up. Taking myself for example, if you give me commit I'm not going to start
trying to sneak optimizer changes in. Really there probably isn't any of the
C code that I would change without first sending a patch... but I think I
have modified enough of the doc code and faq's to be comfortable
committing... although even there I might send patches in... heck I still
send in patches for phpPgAdmin some times just because I think it is good
practice. There are a few minor things like typos and what not that I have
seen that I wouldn't waste the time on to send in a patch that I would fix if
I had commit...
> (I'd personally be happy giving Magnus the commit bit, but core
> tend to be conservative about handing it out.)
>
Yeah, sometimes I wonder if giving a few more people commit would be a bonus.
Not so much that we're all feeling constrained that we can't get are favorite
sort methods put in, but for picking up some of the little things; there's a
number of people whom I would trust not to screw things up, and anyway
everything can be reversed and commit can be taken away if you need; we're
all publicly accountable in that regard.
> > OTOH I guess there might be more people like you who look at it like a
> > trust thing, and I just haven't been told about this since I'm not
> > trusted. :-)
>
> Well, on what basis do you think -core hand out the commit bit?
>
Something along the lines of frequency of work on the main trunk? Where it is
more practical for a developer to just have commit than for them to funnel
through core, core hands out the bit.
> > Given the amount of access I have to other things, I doubt that's the
> > case though.
>
> Access to other things is irrelevant: we're talking about the right to
> directly change the source code. There is no reason why the people who
> are trusted to maintain the website ought to be trusted to commit
> unreviewed patches, or vice versa.
>
It all depends on what your trusting. If its a trust in someones technical
ability, then I would agree with you, the two are really orthogonal. That
said I don't recall Marc (sorry Marc) being the flex/bison wizard, so it
really must be more than that eh? That's why I say if it was really about
trust, it should be trusting them to contribute in a meaningful way without
screwing things up. There are a number of people who manage servers who
could cause far more havoc than just getting the commit bit on the source
code, really that's almost minor. I mean there aren't any secrets here...
any change you make to cvs is going to be mailed out to a public mailing list
and archive. If you screw things up, your access is going to get yanked.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert, > > Well, on what basis do you think -core hand out the commit bit? > > Something along the lines of frequency of work on the main trunk? Where > it is more practical for a developer to just have commit than for them > to funnel through core, core hands out the bit. Four criteria AFAIK: 1) how long you've been with the community; 2) how many patches you submit regularly; 3) whether or not your code is good enough that it doesn't need editing; 4) whether you have known legal entanglements that might cause issues for the project. Frankly, I don't know that Magnus has come up on Core, one way or another. I think one of the committers proposes someone when they get tired of checking in that person's patches. Also, I can point out that there are a *lot* of people who don't have commit on the core distro but do have commit on key add-ons, such as JDBC, DBD::Pg, pgAdmin, or phpPgAdmin, which we need to make Postgres usable. I personally wouldn't want to draw a line between them. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Wed, 8 Mar 2006, Robert Treat wrote: > On Wednesday 08 March 2006 18:52, Neil Conway wrote: >> On Wed, 2006-03-08 at 17:52 -0500, Robert Treat wrote: >>> I think Bruce's take is more accurate. For example, look at folks like >>> Dave, Magnus, Teodor, or myself; none of us have commit (afaik) but I >>> would like to think we would all be trusted not to screw things up if we >>> had it. >> >> Teodor does have the commit bit, but only for GiST, tsearch, and related >> code. >> > > Woops.. is it Oleg who doesn't have it? ISTR one of those guys didn't. But > more to the point, we don't have granular commit bits as your implying afaik. No, we don't ... we trust Teodor to restrict his commits to those areas related to his work, and that he values his commit bit enough not to 'stray' :) >> Well, on what basis do you think -core hand out the commit bit? > > Something along the lines of frequency of work on the main trunk? Where > it is more practical for a developer to just have commit than for them > to funnel through core, core hands out the bit. This is generally how it works ... someone has been with the project long enough, and has consistently submitted "clean patches" regularly enough that its easier to just let them commit directly instead of through a 'middle man' ... ---- 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, 8 Mar 2006, Robert Treat wrote: > > > On Wednesday 08 March 2006 18:52, Neil Conway wrote: > >> On Wed, 2006-03-08 at 17:52 -0500, Robert Treat wrote: > >>> I think Bruce's take is more accurate. For example, look at folks like > >>> Dave, Magnus, Teodor, or myself; none of us have commit (afaik) but I > >>> would like to think we would all be trusted not to screw things up if we > >>> had it. > >> > >> Teodor does have the commit bit, but only for GiST, tsearch, and related > >> code. > >> > > > > Woops.. is it Oleg who doesn't have it? ISTR one of those guys didn't. But > > more to the point, we don't have granular commit bits as your implying afaik. > > No, we don't ... we trust Teodor to restrict his commits to those areas > related to his work, and that he values his commit bit enough not to > 'stray' :) > > >> Well, on what basis do you think -core hand out the commit bit? > > > > Something along the lines of frequency of work on the main trunk? Where > > it is more practical for a developer to just have commit than for them > > to funnel through core, core hands out the bit. > > This is generally how it works ... someone has been with the project long > enough, and has consistently submitted "clean patches" regularly enough > that its easier to just let them commit directly instead of through a > 'middle man' ... Right. It is a case where the volume of patches just overwhelms us and we give them commit access. It isn't "trust", and the only downside I see to commit vs. non-commit users is the delay in getting things into CVS. The delay used to be 24-48 hours, but as my responsibilities have grown, the delay has grown as well. I am not sure how to fix that. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Right. It is a case where the volume of patches just overwhelms us and > we give them commit access. It isn't "trust", and the only downside I > see to commit vs. non-commit users is the delay in getting things into > CVS. The delay used to be 24-48 hours, but as my responsibilities have > grown, the delay has grown as well. I am not sure how to fix that. Delegate that responsibility to the others that have commit access. If that's not enough, grant some more people commit access so they can apply the already approved patches. And stop traveling all over the world so much. :) - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200603082358 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFED7ZcvJuQZxSWSsgRAoT4AKDJj2CcbMT7izuLkefLeFf0pCQ1swCfQrEj qyOW+GInRNZaEOUDFFgaYbo= =9Gv0 -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: [ There is text before PGP section. ] > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Right. It is a case where the volume of patches just overwhelms us and > > we give them commit access. It isn't "trust", and the only downside I > > see to commit vs. non-commit users is the delay in getting things into > > CVS. The delay used to be 24-48 hours, but as my responsibilities have > > grown, the delay has grown as well. I am not sure how to fix that. > > Delegate that responsibility to the others that have commit access. If > that's not enough, grant some more people commit access so they can > apply the already approved patches. And stop traveling all over the > world so much. :) The patch queues are open and committers are encourages to apply them. Neil and Tom do it sometimes. I then remove the item and update any TODO entries. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 9 Mar 2006, Bruce Momjian wrote: > Greg Sabino Mullane wrote: > [ There is text before PGP section. ] >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >>> Right. It is a case where the volume of patches just overwhelms us and >>> we give them commit access. It isn't "trust", and the only downside I >>> see to commit vs. non-commit users is the delay in getting things into >>> CVS. The delay used to be 24-48 hours, but as my responsibilities have >>> grown, the delay has grown as well. I am not sure how to fix that. >> >> Delegate that responsibility to the others that have commit access. If >> that's not enough, grant some more people commit access so they can >> apply the already approved patches. And stop traveling all over the >> world so much. :) > > The patch queues are open and committers are encourages to apply them. > Neil and Tom do it sometimes. I then remove the item and update any > TODO entries. Is it as simple as "if nobody objects within 24 hours, apply"? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 2006-03-09 at 01:38 -0400, Marc G. Fournier wrote: > Is it as simple as "if nobody objects within 24 hours, apply"? I don't think the bottleneck is in patch *application* -- applying a patch without inspecting its contents doesn't take very much time, and there's quite a few community members who could do it. The shortage is of people who have the skills to review patches, and I don't see an easy way to resolve that. -Neil
Marc G. Fournier wrote: > On Thu, 9 Mar 2006, Bruce Momjian wrote: > > >The patch queues are open and committers are encourages to apply them. > >Neil and Tom do it sometimes. I then remove the item and update any > >TODO entries. > > Is it as simple as "if nobody objects within 24 hours, apply"? No, it isn't. Consider a time when the reviewers are in vacation or something. Also nobody has the time to review all the patches that are posted. Bruce doesn't do a quality assessment, as far as I know, when he adds a patch to the queue. So I wouldn't expect a non-coding core person like yourself to blindly apply any patch that makes it into the patch queue. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Marc G. Fournier wrote: > > On Thu, 9 Mar 2006, Bruce Momjian wrote: > > > > >The patch queues are open and committers are encourages to apply them. > > >Neil and Tom do it sometimes. I then remove the item and update any > > >TODO entries. > > > > Is it as simple as "if nobody objects within 24 hours, apply"? > > No, it isn't. Consider a time when the reviewers are in vacation or > something. Also nobody has the time to review all the patches that are > posted. Bruce doesn't do a quality assessment, as far as I know, when > he adds a patch to the queue. So I wouldn't expect a non-coding core > person like yourself to blindly apply any patch that makes it into the > patch queue. Patches go into the queue if no one objects, and if the idea seems sound, and I usually eyeball the patch. I don't review the patch fully until it is in the queue. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 2006-03-09 at 01:19, Neil Conway wrote:
> On Thu, 2006-03-09 at 01:38 -0400, Marc G. Fournier wrote:
> > Is it as simple as "if nobody objects within 24 hours, apply"?
>
> I don't think the bottleneck is in patch *application* -- applying a
> patch without inspecting its contents doesn't take very much time, and
> there's quite a few community members who could do it. The shortage is
> of people who have the skills to review patches, and I don't see an easy
> way to resolve that.
>
I've often wondered how much it would help to have more committers for
the purpose of having people review & apply smaller patches on their
own, there by reducing the "busy work" from Tom, Bruce, et al who we
really would rather focus on bigger patches. Ie. many of us could
probably review patches for programs like psql, createdb, etc..., is it
really more helpful for those patches to have a followup email from
someone saying "looks good"? Wouldn't it be more productive to have that
follow up email to be a "patch applied" message?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > On Thu, 2006-03-09 at 01:19, Neil Conway wrote: > > On Thu, 2006-03-09 at 01:38 -0400, Marc G. Fournier wrote: > > > Is it as simple as "if nobody objects within 24 hours, apply"? > > > > I don't think the bottleneck is in patch *application* -- applying a > > patch without inspecting its contents doesn't take very much time, and > > there's quite a few community members who could do it. The shortage is > > of people who have the skills to review patches, and I don't see an easy > > way to resolve that. > > > > I've often wondered how much it would help to have more committers for > the purpose of having people review & apply smaller patches on their > own, there by reducing the "busy work" from Tom, Bruce, et al who we > really would rather focus on bigger patches. Ie. many of us could > probably review patches for programs like psql, createdb, etc..., is it > really more helpful for those patches to have a followup email from > someone saying "looks good"? Wouldn't it be more productive to have that > follow up email to be a "patch applied" message? The small patches are easy to apply. It is the complex ones that take time. I basically do two things, first, pull out patches that have been submitted that have no negative feedback and add those to the queue, and then review/apply them, unless someone else does first. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 2006-03-09 at 09:22 -0500, Robert Treat wrote: > I've often wondered how much it would help to have more committers for > the purpose of having people review & apply smaller patches on their > own, there by reducing the "busy work" from Tom, Bruce, et al who we > really would rather focus on bigger patches. There's nothing stopping you -- most code review is done on pgsql-patches via email. If you or anyone else wants to contribute, please go right ahead -- participating in code review certainly doesn't require commit privileges. -Neil
On Thu, 2006-03-09 at 11:01, Neil Conway wrote:
> On Thu, 2006-03-09 at 09:22 -0500, Robert Treat wrote:
> > I've often wondered how much it would help to have more committers for
> > the purpose of having people review & apply smaller patches on their
> > own, there by reducing the "busy work" from Tom, Bruce, et al who we
> > really would rather focus on bigger patches.
>
> There's nothing stopping you -- most code review is done on
> pgsql-patches via email. If you or anyone else wants to contribute,
> please go right ahead -- participating in code review certainly doesn't
> require commit privileges.
>
Sure... but my thought was more if it would be helpful to get the
patches that Bruce says are "easy to do" out of the way. On some of
those patches the amount of time save from eyeballing a patch to reading
an email saying someone eyeballed it doesn't seem worth it if you still
have to apply & commit it; the time saving would be in not having to
deal with it at all (thinking in aggregate values here).
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > There are a few minor things like typos and what not that I have > seen that I wouldn't waste the time on to send in a patch that I would fix if > I had commit... Yipes. Is committing really easier than submitting patches? I would have thought that sending in a patch is at least as a light an activity than doing a commit. IIRC, the mechanics of sending a patch is 1. typing "cvs diff" 1b. reading carefully to make sure all's OK 2. emailing it to patches with an explanation. Correct me if I'm wrong, but I would expect the mechanics of committing to be 1. typing "cvs diff" to see what changed, and 1b. reading *extremely* carefully 2. typing "cvs commit" with the same explanation. If committing is really easier than submitting patches, it seems someone should either make committing harder or make submitting patches easier.
> > Correct me if I'm wrong, but I would expect the mechanics > of committing to be > 1. typing "cvs diff" to see what changed, and > 1b. reading *extremely* carefully > 2. typing "cvs commit" with the same explanation. > > If committing is really easier than submitting patches, > it seems someone should either make committing harder or > make submitting patches easier. The difference is anyone can send a patch. Only a handful can commit. Joshua D. Drae > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/
Neil Conway wrote: > > There's nothing stopping you -- most code review is done on > pgsql-patches via email. If you or anyone else wants to contribute, > please go right ahead -- participating in code review certainly doesn't > require commit privileges. I'm guessing that that's a good way for people to qualify for a commit bit as well. If core sees someone making intelligent sounding comments on patches across a wide area of the code, I bet that'd go a long way to making them want to give the guy a commit bit. Especially if (when a patch looked good) the reviewer left subtle hints like "I'd check it in if I had a commit bit" and if core agreed with the reviewer almost every time he said that.
Dirk Riehle wrote: > Thanks! What's out there in terms of economics research has largely > been compiled here: > > http://opensource.mit.edu > > Maybe not coincidentely, that site is maintained by the > aforementioned Karim Lakhani. Can anyone point to the PostgreSQL-releted papers on that web site? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Dirk Riehle wrote: > I didn't see any. However, from an economics research perspective, > MySQL vs PostgreSQL might be a good case study because it seems much > less complicated a comparison than other OSS projects. --Dirk I know Karim did a lot of research on PostgreSQL, so where is it? --------------------------------------------------------------------------- > > At 24.04.2006, Bruce Momjian wrote: > >Dirk Riehle wrote: > > > Thanks! What's out there in terms of economics research has largely > > > been compiled here: > > > > > > http://opensource.mit.edu > > > > > > Maybe not coincidentely, that site is maintained by the > > > aforementioned Karim Lakhani. > > > >Can anyone point to the PostgreSQL-releted papers on that web site? > > > >-- > > Bruce Momjian http://candle.pha.pa.us > > EnterpriseDB http://www.enterprisedb.com > > > > + If your life is a hard drive, Christ can be your backup. + > -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I didn't see any. However, from an economics research perspective, MySQL vs PostgreSQL might be a good case study because it seems much less complicated a comparison than other OSS projects. --Dirk At 24.04.2006, Bruce Momjian wrote: >Dirk Riehle wrote: > > Thanks! What's out there in terms of economics research has largely > > been compiled here: > > > > http://opensource.mit.edu > > > > Maybe not coincidentely, that site is maintained by the > > aforementioned Karim Lakhani. > >Can anyone point to the PostgreSQL-releted papers on that web site? > >-- > Bruce Momjian http://candle.pha.pa.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. +
On Mon, Apr 24, 2006 at 01:10:33PM -0400, Bruce Momjian wrote: > Dirk Riehle wrote: > > I didn't see any. However, from an economics research perspective, > > MySQL vs PostgreSQL might be a good case study because it seems much > > less complicated a comparison than other OSS projects. --Dirk > > I know Karim did a lot of research on PostgreSQL, so where is it? It folded into his thesis and papers. His subject was open source in general and we were one of the projects he studied closely. The conclusions he drew were based on conversations with us and other open source projects as well as statistics from sourceforge. --elein > > --------------------------------------------------------------------------- > > > > > > At 24.04.2006, Bruce Momjian wrote: > > >Dirk Riehle wrote: > > > > Thanks! What's out there in terms of economics research has largely > > > > been compiled here: > > > > > > > > http://opensource.mit.edu > > > > > > > > Maybe not coincidentely, that site is maintained by the > > > > aforementioned Karim Lakhani. > > > > > >Can anyone point to the PostgreSQL-releted papers on that web site? > > > > > >-- > > > Bruce Momjian http://candle.pha.pa.us > > > EnterpriseDB http://www.enterprisedb.com > > > > > > + If your life is a hard drive, Christ can be your backup. + > > > > -- > Bruce Momjian http://candle.pha.pa.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >
Bruce Momjian wrote: > Dirk Riehle wrote: > >> Thanks! What's out there in terms of economics research has largely >> been compiled here: >> >> http://opensource.mit.edu >> >> Maybe not coincidentely, that site is maintained by the >> aforementioned Karim Lakhani. >> > > Can anyone point to the PostgreSQL-releted papers on that web site? > > I believe this site is important for another reason. I seem to recall at least one master's thesis analyzed all sourceforge projects and concluded on the basis of empirical data that BSD/Apache/MIT licenses (re:least restrictive licenses) produce more successful projects faster than the GPL, which kind of acts as a contrapuntal serenade to recent Linux Journal meanderings. Michael L. Dean