Thread: Re: [HACKERS] Increased company involvement
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: Monday, May 02, 2005 12:17 PM > To: PostgreSQL advocacy > Cc: Dave Held; PostgreSQL-development > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > > [...] > > Really? You have a different perspective than I see. I have > > seen patches be accepted that had no core buy-in. We accept > > patches based on group feedback, not some closed approval > > process. > > Let me also ask for you to provide an example of the behavior you > describe. Well, I think there's numerous examples where someone suggests some feature or idea, and Tom or one or two other core developers will say: "I don't like that idea", and then the proposer will more or less give up on it because it is clear that it won't go anywhere. So whether the process gets stopped at the patch submission level or the feature proposal level isn't really relevant. It seems pretty clear that a handful of people decide the direction of Postgres, and everyone else can either contribute to the features that have been agreed to be acceptable and relevant, or they can fork their own version. Just watching the hackers list suggests to me that this is the norm, rather than the exception. I guess I'm interested to see which patches have been accepted that the core developers opposed. Now don't get me wrong. Sometimes there are good technical reasons why feature A or B can't or shouldn't be added or even developed. And I don't suggest that patches lacking technical merit should not be rejected. But sometimes it seems that ideas with undetermined merit get passed over because of a quick judgement based on intuition, and only if the proposer actively fights for it for a while does it get reconsidered. Of course, it would be quite a bit of work for me to review the list and compile instances where I think this has occurred, but only because of the tedium involved to make a minor point...not because I think I would have difficulty finding evidence. I'm just saying that as an outsider, if I had a lot of resources to devote to contributing to Postgres, I would only consider working on approved TODO items or making sure I more or less had core buy-in before writing any code. I don't think it would be worth my time to work on something that non-core users/developers might like but core hackers don't. Like I said, that's not necessarily a bad thing. Postgres is a piece of software with many interacting components, and there needs to be some coordination to make sure it evolves in a sensible way. But I think that implies that there must be and is some de facto centralization of control, whether that is the published ideology or not. __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
> > Well, I think there's numerous examples where someone suggests some > feature or idea, and Tom or one or two other core developers will > say: "I don't like that idea", and then the proposer will more or > less give up on it because it is clear that it won't go anywhere. Well I think that is more perception than anything. Sometimes you have to fight for what you believe in. For example plPHP. I believe plPHP belongs in core as do some other people. There are members of core that are for it and against it. Command Prompt as the submitter needs to make a valid argument to sway core. We need to present code they would be happy with. We need to present reasons why. If you don't do that, then yes I can see why it would feel as if the proposer was at a loss once someone like Tom writes his opinion. However Tom isn't the final word, he just happens to have a lot of weight as anyone within the project of good standing who donates as much as he does would. Everything within the community is pretty much done as a vote and there are things that core really has nothing to do with (like pgFoundry). Sincerely, Joshua D. Drake Command Prompt, Inc. -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Dave Held wrote: > Just watching the hackers list suggests to me that this is the norm, > rather than the exception. I guess I'm interested to see which > patches have been accepted that the core developers opposed. Now > don't get me wrong. Sometimes there are good technical reasons why > feature A or B can't or shouldn't be added or even developed. And > I don't suggest that patches lacking technical merit should not be > rejected. But sometimes it seems that ideas with undetermined > merit get passed over because of a quick judgement based on > intuition, and only if the proposer actively fights for it for a > while does it get reconsidered. > > Of course, it would be quite a bit of work for me to review the > list and compile instances where I think this has occurred, but > only because of the tedium involved to make a minor point...not > because I think I would have difficulty finding evidence. I'm just Well, if there was an issue and you had been around for a minimal amount of time, I would think you could come up with at least one example. > saying that as an outsider, if I had a lot of resources to devote > to contributing to Postgres, I would only consider working on > approved TODO items or making sure I more or less had core buy-in > before writing any code. I don't think it would be worth my > time to work on something that non-core users/developers might > like but core hackers don't. Well, our developer's FAQ clearly states you should communicate your ideas to the hackers list before starting work to be sure you have _community_ buy-in, rather than core buy-in. And the TODO list is not a core list, it is accumulated from community suggestions and discussion. > Like I said, that's not necessarily a bad thing. Postgres is a > piece of software with many interacting components, and there > needs to be some coordination to make sure it evolves in a > sensible way. But I think that implies that there must be and > is some de facto centralization of control, whether that is the > published ideology or not. I will give you the example of adding a read-only table as an example. I am betting the idea will not be accepted because the costs outweight the gain, but I will post my opinions on the list and others will as well and we will come to some concensus. If X members feel something is bad, and 5X members think something is good, it almost always gets in --- it doesn't matter if all the core people are in X or not. Another example is the recent patch to check if there are orphaned file system files. That was submitted, Tom had questions, I posted why I thought it was valid, and the patch is going in today. Anyone has the ability to argue their point and try to sway the community, and any member has the right to request a vote on a specific issue. Perhaps we are more a replublic because we do defer our judgement to others who have looked into the area more thoroughly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Joshua D. Drake wrote: > > > > Well, I think there's numerous examples where someone suggests some > > feature or idea, and Tom or one or two other core developers will > > say: "I don't like that idea", and then the proposer will more or > > less give up on it because it is clear that it won't go anywhere. > > Well I think that is more perception than anything. Sometimes you have > to fight for what you believe in. For example plPHP. I believe plPHP > belongs in core as do some other people. There are members of core > that are for it and against it. > > Command Prompt as the submitter needs to make a valid argument to sway > core. We need to present code they would be happy with. We need to > present reasons why. I think the plan for plphp is to put the source in our CVS, but to require it to be compiled as a separate 'make' step after php is fully installed and using the new libpq. I think we had agreement on that solution. > If you don't do that, then yes I can see why it would feel as if > the proposer was at a loss once someone like Tom writes his opinion. > > However Tom isn't the final word, he just happens to have a lot of > weight as anyone within the project of good standing who donates as much > as he does would. > > Everything within the community is pretty much done as a vote and there > are things that core really has nothing to do with (like pgFoundry). Right, the point is that Tom has weight because he is Tom and people value his opinion, not because he is core. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Mon, 2 May 2005, Bruce Momjian wrote: > Joshua D. Drake wrote: >>> >>> Well, I think there's numerous examples where someone suggests some >>> feature or idea, and Tom or one or two other core developers will >>> say: "I don't like that idea", and then the proposer will more or >>> less give up on it because it is clear that it won't go anywhere. >> >> Well I think that is more perception than anything. Sometimes you have >> to fight for what you believe in. For example plPHP. I believe plPHP >> belongs in core as do some other people. There are members of core >> that are for it and against it. >> >> Command Prompt as the submitter needs to make a valid argument to sway >> core. We need to present code they would be happy with. We need to >> present reasons why. > > I think the plan for plphp is to put the source in our CVS, but to > require it to be compiled as a separate 'make' step after php is fully > installed and using the new libpq. I think we had agreement on that > solution. Last I read, both Tom and I were against it being in CVS (albeit for different reasons) ... and there hadn't been any discussions past the end of that thread that I've seen ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 2 May 2005, Bruce Momjian wrote: > > > Joshua D. Drake wrote: > >>> > >>> Well, I think there's numerous examples where someone suggests some > >>> feature or idea, and Tom or one or two other core developers will > >>> say: "I don't like that idea", and then the proposer will more or > >>> less give up on it because it is clear that it won't go anywhere. > >> > >> Well I think that is more perception than anything. Sometimes you have > >> to fight for what you believe in. For example plPHP. I believe plPHP > >> belongs in core as do some other people. There are members of core > >> that are for it and against it. > >> > >> Command Prompt as the submitter needs to make a valid argument to sway > >> core. We need to present code they would be happy with. We need to > >> present reasons why. > > > > I think the plan for plphp is to put the source in our CVS, but to > > require it to be compiled as a separate 'make' step after php is fully > > installed and using the new libpq. I think we had agreement on that > > solution. > > Last I read, both Tom and I were against it being in CVS (albeit for > different reasons) ... and there hadn't been any discussions past the end > of that thread that I've seen ... I posted this compromise and no one replied so I thought everyone was OK with it. It gets it into CVS, but has a separate compile stage to deal with the recursive dependency problem. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Mon, May 02, 2005 at 01:55:50PM -0400, Bruce Momjian wrote: > Dave Held wrote: > > Of course, it would be quite a bit of work for me to review the > > list and compile instances where I think this has occurred, but > > only because of the tedium involved to make a minor point...not > > because I think I would have difficulty finding evidence. I'm just > > Well, if there was an issue and you had been around for a minimal amount > of time, I would think you could come up with at least one example. I can help with that. Somebody posted a proposal and patch to shrink bloated btree indexes. It's a very interesting feature but nobody replied, so nothing happened. The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I haven't seen any indication that it may be merged. This doesn't mean I agree with Dave's argument :-) But there are times when no major contributor has time to "sponsor" a patch or feature, so it goes unnoticed and unmerged. -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) Voy a acabar con todos los humanos / con los humanos yo acabaré voy a acabar con todos / con todos los humanos acabaré (Bender)
On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote: > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: Monday, May 02, 2005 12:17 PM > > To: PostgreSQL advocacy > > Cc: Dave Held; PostgreSQL-development > > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement > > > > > [...] > > > Really? You have a different perspective than I see. I have > > > seen patches be accepted that had no core buy-in. We accept > > > patches based on group feedback, not some closed approval > > > process. > > > > Let me also ask for you to provide an example of the behavior you > > describe. > > Well, I think there's numerous examples where someone suggests some > feature or idea, and Tom or one or two other core developers will > say: "I don't like that idea", and then the proposer will more or > less give up on it because it is clear that it won't go anywhere. > So whether the process gets stopped at the patch submission level > or the feature proposal level isn't really relevant. It seems pretty > clear that a handful of people decide the direction of Postgres, > and everyone else can either contribute to the features that have > been agreed to be acceptable and relevant, or they can fork their > own version. I don't think it's valid to attribute this to the core team at all, but I do understand what you're saying. Part of this is that many people like to see data to back up a claim before adding complexity to the database. The current read-only table discussion is a good example. How much will it actually help to have a means to reduce the size of HeapHeaderData? The problem is many times it's very hard to come up with this data without actually coding something up and trying it. As Josh B. pointed out in another post, sometimes people will suggest something on -hackers and it just dies on the vine. This doesn't mean it wouldn't be useful, it means no one on hackers was interested. But for every user who's on hackers there's probably 10 than aren't and who knows how many who might become users if some feature was added. Personally, I think that the current process could do a better job of gauging how much user interest there is in changes that are in the gray area between 'wow, that's a great idea!' and 'wow, that's a horrid idea!'. There's also the issue of people making suggestions to try and address a larger problem. I think read-only tables is a good example; the real issue is that in many data-mining applications the 30 byte overhead on tuples is huge, and puts postgresql at a big disadvantage. Read-only tables would definately be difficult to implement, but they *could* provide a tremendous benefit to PostgreSQL performance in certain applications. Of course, there's other changes that could also provide benefits, such as a means to keep a table clustered (or nearly clustered). But these things have generally been shot-down in the past, and the data warehousing disadvantage continues. Now I'm not suggesting that the process is seriously broken, but I do think that the interests and experiences of the most active developers tend to keep us away from changes that would only help a subset of users (or potential users). I also think it would be better if that subset was heard better. Data warehousing is the current example that comes to mind, but I'm certain there are others. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
> > Another example is the recent patch to check if there are orphaned file > system files. That was submitted, Tom had questions, I posted why I > thought it was valid, and the patch is going in today. Anyone has the > ability to argue their point and try to sway the community, and any > member has the right to request a vote on a specific issue. > I know so maintainig of PostgreSQL isn't easy. And it's normal so everybody wont to see commit of your patch. The comunication with core developers is best, but some times I have opinion so some patches are lost - for example my little patch SQLSTATE, .. I remeber situation one year ago with named params of plpgsql function. Patch waited half of year. I don't wont to be negative :-)). PostgreSQL did big progress. Really. And last modification of plpgsql helped my in work. But its human natural. I looking for others nows. I am expectant for 2PC, hiearch queries, and ... PostgreSQL isn't only sw for me, it's more like idol :-) Best Regards, Pavel Stehule
On Mon, 2 May 2005, Alvaro Herrera wrote: > The 2PC patch by Heikki Linnakangas (sp?) is also waiting and so far I > haven't seen any indication that it may be merged. Actually, its one of the features we have planned to have merged for 8.1 ... :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664