Thread: Time to scale up?
Dear Community, The core development team has a strong and well motivated urge to keep the PostgreSQL code base focused. They don't want it to grow much and they don't want to maintain code that is written in other languages then C. This is the way it has been for a long time and I'm in no way questioning what has been accomplished so far. Question is, is that the way to go forward? Controversial question perhaps but nevertheless worth debating. Especially given the latest discussions regarding inclusion of pl/java and pl/ruby in core. A direct consequence of todays organization is that very useful functionality is scattered in several places with a significant level of uncertainty as to what is released and stable and what is just a prototype. PostgreSQL takes a beating in database comparisons and the community must time after another correct journalists that tend to "forget" the plethora of add-on modules that exists. Another consequence is that when using PostgreSQL, you are encouraged to use stored procedure languages that can be implemented with a few lines of code and in pure C. A user would probably rather see criterion's like feature richness and standards conformant. These problems persist although a number of actors bundle PostgreSQL with various modules today. A resolution to the problem would be to allow the core team to scale up. More people are needed to support a more comprehensive set of features. So why not create specialized teams that are part of the core-development trust? Teams that specialize in replication, in Java, and in other areas where the core team feel that their knowledge and/or resources are too limited. It seems to me that the community already have people that could step right in and take on this responsibility. We could ask people from the most prominent replication solutions to merge and form a team that would maintain a well defined replication portfolio. The developers that maintain the jdbc driver + people from pl/java and pl/j could do the same for Java. There are a few more areas where this would make a lot of sense. It's all about restructuring the management of the core parts of PostgreSQL in order to make it scale resource wise. It cannot, and will not, be solved by creating yet another project on PgFoundry. I know I brought this up in 'hackers' a week ago. I got no response there. I bring it up again here partly because that was the wrong forum but also because I feel that the current way to add features to the core is less then perfect and needs to be discussed. I feel that a good resolution to my concerns is extremely important for the future success of a great database. Perhaps everything that I've said so far is self-evident and thoroughly debated already. In that case, please excuse my rambling and point me in the right direction. Kind Regards, Thomas Hallgren
Am Montag, 24. Juli 2006 13:12 schrieb Thomas Hallgren: > A resolution to the problem would be to allow the core team to scale up. > More people are needed to support a more comprehensive set of features. > So why not create specialized teams that are part of the > core-development trust? I don't think trust or scaling or implementation languages are the real issue. It has been established that for a variety of reasons, smalls tools that can be combined work better than one big tool. That is why the Linux kernel does not contain a windowing system. The issue you are facing is an issue of perception. There are a number of ways to fix that, only one of which is including PL/Java into the PostgreSQL source distribution. I was on the other side of the debate when we kicked out the JDBC driver, but today I think this was the best thing that could have happened, to both sides. If you see any measures that we could take to make PL/Java look as good in the public eye as the JDBC driver -- certainly that is a reasonable comparison -- then I'm sure we can address them. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > I don't think trust or scaling or implementation languages are the real issue. > It has been established that for a variety of reasons, smalls tools that can > be combined work better than one big tool. That is why the Linux kernel does > not contain a windowing system. > > I fully agree with this and I'm not suggesting that we create one big tool. > The issue you are facing is an issue of perception. Yes, but that's only one part of it. > There are a number of > ways to fix that, only one of which is including PL/Java into the PostgreSQL > source distribution. I was on the other side of the debate when we kicked > out the JDBC driver, but today I think this was the best thing that could > have happened, to both sides. Separate source distributions and delegated responsibilities must be maintained. I'm a big fan of those. I'm arguing that you can keep them and still benefit from a more elaborated core organization. > If you see any measures that we could take to > make PL/Java look as good in the public eye as the JDBC driver -- certainly > that is a reasonable comparison -- then I'm sure we can address them. > > We could achieve a number of pros that doesn't relate to perception: - Far better synergies and incentive to create a coherent portfolio - More elaborated build farm support - Common, configurable documentation - Shared server infrastructure But perception is of course extremely important. I think that mature and stable add-on modules that have an established user-base should be visible as part of PostgreSQL. They should be represented on the PostgreSQL main web-site and not as links to PgFoundry, Gborg, Codehause, Sourceforge, and what have you. Important things that relate to perception is: - Web site outlook. Seamless navigation between core and add-ons. - Maintainer. Core or third-party? - Packaging. Part of core or bundled by commercial or other vendor? - Status. Stable? Released? (who claims it's stable?) - Mailing lists. Is it xxx@postgresql.org or something else? Take a look at the 9 bullets above. Now, given the current organization, consider the impact of adding versus rejecting an add-on module. I'm still convinced that the only solution to that dilemma is to change the organization. Kind Regards, Thomas Hallgren
On Mon, 24 Jul 2006, Peter Eisentraut wrote: > Am Montag, 24. Juli 2006 13:12 schrieb Thomas Hallgren: >> A resolution to the problem would be to allow the core team to scale up. >> More people are needed to support a more comprehensive set of features. >> So why not create specialized teams that are part of the >> core-development trust? > > I don't think trust or scaling or implementation languages are the real issue. > It has been established that for a variety of reasons, smalls tools that can > be combined work better than one big tool. That is why the Linux kernel does > not contain a windowing system. > > The issue you are facing is an issue of perception. There are a number of > ways to fix that, only one of which is including PL/Java into the PostgreSQL > source distribution. I was on the other side of the debate when we kicked > out the JDBC driver, but today I think this was the best thing that could > have happened, to both sides. If you see any measures that we could take to > make PL/Java look as good in the public eye as the JDBC driver -- certainly > that is a reasonable comparison -- then I'm sure we can address them. One thing that has been talked to death many times, but nobody ever seems to come up with a solution to, is pgFoundry, and how badly it is advertised / promoted ... so software packages over there seem relegated to a sort of 'no mans land' ... I was just thinking of it, and kinda surprised nobody else has ... why not add a section to http://www.postgresql.org's main page for it? We have two sections now: Latest News and Upcoming Events ... why not add a third one under that includes Latest News from pgFoundry? that way, when a release happens, or project is added, its very prominently displayed on our main page? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> > I was just thinking of it, and kinda surprised nobody else has ... why > not add a section to http://www.postgresql.org's main page for it? We > have two sections now: Latest News and Upcoming Events ... why not add a > third one under that includes Latest News from pgFoundry? that way, > when a release happens, or project is added, its very prominently > displayed on our main page? Honestly, until it carries a postgresql.org domain, ..... it will always be a second class citizen except to those in the know. Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > > > >I was just thinking of it, and kinda surprised nobody else has ... why > >not add a section to http://www.postgresql.org's main page for it? We > >have two sections now: Latest News and Upcoming Events ... why not add a > >third one under that includes Latest News from pgFoundry? that way, > >when a release happens, or project is added, its very prominently > >displayed on our main page? > > Honestly, until it carries a postgresql.org domain, ..... it will always > be a second class citizen except to those in the know. You mean like http://planetpostgresql.org? I've been wondering a long time why it isn't http://planet.postgresql.org/ like every other project I know. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Joshua D. Drake wrote: >>> I was just thinking of it, and kinda surprised nobody else has ... why >>> not add a section to http://www.postgresql.org's main page for it? We >>> have two sections now: Latest News and Upcoming Events ... why not add a >>> third one under that includes Latest News from pgFoundry? that way, >>> when a release happens, or project is added, its very prominently >>> displayed on our main page? >> Honestly, until it carries a postgresql.org domain, ..... it will always >> be a second class citizen except to those in the know. > > You mean like http://planetpostgresql.org? I've been wondering a long > time why it isn't http://planet.postgresql.org/ like every other project > I know. > Well that is a very good point, because I have always considered planetpostgresql not a part of the PostgreSQL project. I hadn't even considered that it is a postgresql project until just now. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
On Mon, 24 Jul 2006, Joshua D. Drake wrote: >> >> I was just thinking of it, and kinda surprised nobody else has ... why not >> add a section to http://www.postgresql.org's main page for it? We have two >> sections now: Latest News and Upcoming Events ... why not add a third one >> under that includes Latest News from pgFoundry? that way, when a release >> happens, or project is added, its very prominently displayed on our main >> page? > > Honestly, until it carries a postgresql.org domain, ..... it will always be a > second class citizen except to those in the know. 'k, so point the links to projects.postgresql.org ... both works ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Mon, 24 Jul 2006, Joshua D. Drake wrote: > Alvaro Herrera wrote: >> Joshua D. Drake wrote: >>>> I was just thinking of it, and kinda surprised nobody else has ... why >>>> not add a section to http://www.postgresql.org's main page for it? We >>>> have two sections now: Latest News and Upcoming Events ... why not add a >>>> third one under that includes Latest News from pgFoundry? that way, when >>>> a release happens, or project is added, its very prominently displayed on >>>> our main page? >>> Honestly, until it carries a postgresql.org domain, ..... it will always >>> be a second class citizen except to those in the know. >> >> You mean like http://planetpostgresql.org? I've been wondering a long >> time why it isn't http://planet.postgresql.org/ like every other project >> I know. >> > > Well that is a very good point, because I have always considered > planetpostgresql not a part of the PostgreSQL project. I hadn't even > considered that it is a postgresql project until just now. Just curious, but why does it have to be *.postgresql.org to be considered official? Isn't official what we make it ... ? It should be prominently linked *from* the main web site, but shouldn't *have* to be a subdomain of ... pgFoundry should have, I think, a more prominent link in the Weekly News stuff ... we could also add the various web sites, individually, and with short blurbs, to the mailing list tips ... The thing is, everyone spends their time putting pgFoundry down as being 'second class' ... of course everyone else is going to consider it such also ... it isn't second class, nor was it ever meant to be ... if ppl promoted, pushed and advertised it more, it would be as 'second class' as common to go to as CPAN is for Perl ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
>> >> Well that is a very good point, because I have always considered >> planetpostgresql not a part of the PostgreSQL project. I hadn't even >> considered that it is a postgresql project until just now. > > Just curious, but why does it have to be *.postgresql.org to be > considered official? Isn't official what we make it ... ? Absolutely not (unfortunately). Official is what people "perceive" is official. For a case and point, go to http://www.ximian.com or http://www.suse.com . You will note that they no longer exist and have been absorbed into Novell.com. The reason for this is to show an official integration, so that people are comfortable with the respective brands because they are comfortable with Novell. The same applies for our sub projects, until they are recognized under the official project domain name. They will always be considered third party. > The thing is, everyone spends their time putting pgFoundry down as being > 'second class' ... of course everyone else is going to consider it such > also ... it isn't second class, nor was it ever meant to be ... if ppl > promoted, pushed and advertised it more, it would be as 'second class' > as common to go to as CPAN is for Perl ... Perhaps the fact that everyone is putting down pgFoundry as second class is telling to the point that we need to promote it's perception? E.g; get it under projects.postgresql.org where it really belongs. And as Alvaro mentioned, the same should go for planet.postgresql.org . Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
> I know I brought this up in 'hackers' a week ago. I got no response
> there. I bring it up again here partly because that was the wrong forum
> but also because I feel that the current way to add features to the core
> is less then perfect and needs to be discussed. I feel that a good
> resolution to my concerns is extremely important for the future success
> of a great database. Perhaps everything that I've said so far is
> self-evident and thoroughly debated already. In that case, please excuse
> my rambling and point me in the right direction.
I seriously doubt you are going to see movement in this direction for a
couple of reasons.
1. A good portion of this is already done by outside packagers
2. There are very good reasons why things are done the way they are done
3. PostgreSQL.Org is a database, not a distribution, just as linux is a
kernel not a distribution.
4. In order for this to be, all coders would have to agree to adhere to
PostgreSQL.Org coding conventions. That is pretty much a deal breaker
right there.
5. You seem to miss the point that your argument about plJava wasn't
shot down by core. It was shot down by a LOT of people, of which a
couple are in core.
There are only 7 (I think that's right) members of core.
As for plruby, as far as I can tell the argument is not over yet. Plruby
does not suffer nearly from the same objects that pljava does. Namely it
is written in C. It would need to be cleaned up to adhere to the
guidelines but that is about it.
Joshua D. Drake
>
> Kind Regards,
> Thomas Hallgren
>
>
> ---------------------------(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. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Marc G. Fournier wrote: > On Mon, 24 Jul 2006, Joshua D. Drake wrote: > >>> >>> I was just thinking of it, and kinda surprised nobody else has ... >>> why not add a section to http://www.postgresql.org's main page for >>> it? We have two sections now: Latest News and Upcoming Events ... >>> why not add a third one under that includes Latest News from >>> pgFoundry? that way, when a release happens, or project is added, >>> its very prominently displayed on our main page? >> >> Honestly, until it carries a postgresql.org domain, ..... it will >> always be a second class citizen except to those in the know. > > 'k, so point the links to projects.postgresql.org ... both works ... It also needs to be the primary name on pgfoundry. It is all about seamless integration. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/
On Mon, 24 Jul 2006, Joshua D. Drake wrote: > Marc G. Fournier wrote: >> On Mon, 24 Jul 2006, Joshua D. Drake wrote: >> >>>> >>>> I was just thinking of it, and kinda surprised nobody else has ... why >>>> not add a section to http://www.postgresql.org's main page for it? We >>>> have two sections now: Latest News and Upcoming Events ... why not add a >>>> third one under that includes Latest News from pgFoundry? that way, when >>>> a release happens, or project is added, its very prominently displayed on >>>> our main page? >>> >>> Honestly, until it carries a postgresql.org domain, ..... it will always >>> be a second class citizen except to those in the know. >> >> 'k, so point the links to projects.postgresql.org ... both works ... > > It also needs to be the primary name on pgfoundry. It is all about seamless > integration. Odd, do you want to have a quick peak to see what I'm missing? UseCanonicalName is turned Off, but if you go to projects.postgresql.org, it is being redirected to pgfoundry.org, instead of serving up pages ... might be something internal to gforge though ... Be nice if both could work at the same time, so that all of the search engines still finds everything :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Joshua D. Drake wrote: > 1. A good portion of this is already done by outside packagers So? Doesn't that mean that a lot of work could be saved if it was done in one place? > > 2. There are very good reasons why things are done the way they are done I'm sure there is. But the community has grown significantly over the last couple of years and that trend is fairly stable. No organization remains the same when growing. Some try and the die. > > 3. PostgreSQL.Org is a database, not a distribution, just as linux is > a kernel not a distribution. Perhaps to you it is. But to the vast majority of users that compare PostgreSQL to MySQL or Oracle, it's much more then that. People rarely talk about the "Linux kernel" as such. They use RHEL, Fedora, Novell, etc. In contrast, people rarely talk about the distributions that the outside packagers you mention make available. > > 4. In order for this to be, all coders would have to agree to adhere > to PostgreSQL.Org coding conventions. That is pretty much a deal > breaker right there. > Why would that be such a big deal? I wouldn't bother me one second. In fact, I think that would be a good thing that could encourage developers to broaden their knowledge of other parts of the code. > 5. You seem to miss the point that your argument about plJava wasn't > shot down by core. It was shot down by a LOT of people, of which a > couple are in core. > Was it? Funny, when I go back and read that thread I see a different picture. Tom expressed concerns about the #lines of code and code not written in C. Some of the other core members shared his concern. A LOT of other people liked the idea and very few besides the core members were against it. Just goes to prove that perception is everything I guess. > As for plruby, as far as I can tell the argument is not over yet. > Plruby does not suffer nearly from the same objects that pljava does. > Namely it is written in C. It would need to be cleaned up to adhere to > the guidelines but that is about it. > That's unfair. There where two objections to PL/Java. #lines and some code not written in C. It does not however suffer from coding convention or licensing issues ;-) Seriously. This is one of my main points. Adding pl/ruby just because it is written in a language that the core members are comfortable with have somewhat serious implications. Contributions to PostgreSQL should be recognized on merits such as stability, feature richness, user base, etc. A huge number of PostgreSQL users are using technology that the core team doesn't want to manage. That's why it's time to change the organization and let people in that are willing to take on such responsibilities. Regards, Thomas Hallgren
Am Montag, 24. Juli 2006 16:35 schrieb Marc G. Fournier: > One thing that has been talked to death many times, but nobody ever seems > to come up with a solution to, is pgFoundry, and how badly it is > advertised / promoted ... so software packages over there seem relegated > to a sort of 'no mans land' ... The challenge is to distinguish random garbage from the good, important projects on pgFoundry. It seems that what this really comes down to is that what need a committee that decides what the good/important/maintained/endorsed projects are. Those projects can then get more prominent URLs, links, etc. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Mon, 24 Jul 2006, Thomas Hallgren wrote: > Joshua D. Drake wrote: >> 1. A good portion of this is already done by outside packagers > > So? Doesn't that mean that a lot of work could be saved if it was done in one > place? No, because its not always (or usually?) the same packager doing the core rdbms as the add ons ... even in those cases where the 'addons' are *part* of the core distribution ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Hi, On Mon, 2006-07-24 at 09:04 -0700, Joshua D. Drake wrote: > And as Alvaro mentioned, the same should go for > planet.postgresql.org . Why? We offer blogging area to PostgreSQL people there. However we don't control (that's our policy) what those people write to their blogs. What if those people write something that is not acceptable for PostgreSQL? This site is not a part of PostgreSQL project. At least it was not designed so. That's what I thought when I got this domain 2 years ago. Personally I'm against this, because I don't feel Planet as a part of main PostgreSQL project... ... and I don't care for other planets, like kde, etc. Regards, -- 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, plPerlNG - http://www.commandprompt.com/
Attachment
Devrim GUNDUZ wrote: > Hi, > > On Mon, 2006-07-24 at 09:04 -0700, Joshua D. Drake wrote: > > And as Alvaro mentioned, the same should go for > > planet.postgresql.org . > > Why? > > We offer blogging area to PostgreSQL people there. However we don't > control (that's our policy) what those people write to their blogs. What > if those people write something that is not acceptable for PostgreSQL? I don't understand why you think we should control what people write on their blogs just so we can say that the Planet is a community resource. If they write something unacceptable, well, it's their opinion anyway, so why should we care? Has anyone done so anyway? Did anyone post how he adores Larry's database already? > This site is not a part of PostgreSQL project. At least it was not > designed so. That's what I thought when I got this domain 2 years ago. Well, it's got the "postgresql" string on it, and it contains only blogs related to very PostgreSQL-related people. I don't understand what on it makes it not be "part of PostgreSQL project". > Personally I'm against this, because I don't feel Planet as a part of > main PostgreSQL project... > > ... and I don't care for other planets, like kde, etc. I'm not saying you should care. I'm just putting them as examples. They gladly host blogs of people on their community, without any kind of obnoxious restrictions you seem to want for a "PostgreSQL-community planet". -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
I think there are some very good points in this, and in this thread in general. Atleast worth a few thoughts. First about the different domains. Yes, it is very much like different brands. And what is good or bad in it? Well, those projects that are not under the PostgreSQL umbrella, are not that official, and not consider part of the "package". But, on the other hand, it could be beneficial for the main project, if the "package" would contain things like PgAdmin, Slony etc. I believe, that it would make the total package more "valuable" in business terms. But, if those parts would be in the same package, then that would mean more responsibility for the core. Someone would need to say that this is beta, and this is ready. But that would be important for the users, so it could be worth it. How it would be done, that would require some talks between all those projects. But I can see, that the current core could focus on the database itself, and then there could be another organ that would look at all the joining parts. When those projects are clearly separate, it also means that there are a lot of brands. And if we want to promote all these projects, it will require additional effort. So, instead of making one strong brand, we kind of try to make one brand, and then we try to promote also many other brands that are necessary for the one brand. No focus. From the advocacy perspective I see joining projects under a common umbrella as a very good idea. Of course, those other projects should also see it beneficial, and it would probably require a lot of work to make these projects more connected. But I am quite sure, that it would at least make the advocacy part a lot easier. There would be more to talk about, and the links would not be pointed out to third party websites. Rgs, Jussi Joshua D. Drake wrote: > >>> >>> Well that is a very good point, because I have always considered >>> planetpostgresql not a part of the PostgreSQL project. I hadn't even >>> considered that it is a postgresql project until just now. >> >> Just curious, but why does it have to be *.postgresql.org to be >> considered official? Isn't official what we make it ... ? > > Absolutely not (unfortunately). Official is what people "perceive" is > official. > > For a case and point, go to http://www.ximian.com or > http://www.suse.com . You will note that they no longer exist and have > been absorbed into Novell.com. > > The reason for this is to show an official integration, so that people > are comfortable with the respective brands because they are > comfortable with Novell. > > The same applies for our sub projects, until they are recognized under > the official project domain name. They will always be considered third > party. > >> The thing is, everyone spends their time putting pgFoundry down as >> being 'second class' ... of course everyone else is going to consider >> it such also ... it isn't second class, nor was it ever meant to be >> ... if ppl promoted, pushed and advertised it more, it would be as >> 'second class' as common to go to as CPAN is for Perl ... > > Perhaps the fact that everyone is putting down pgFoundry as second > class is telling to the point that we need to promote it's perception? > E.g; get it under projects.postgresql.org where it really belongs. > > And as Alvaro mentioned, the same should go for planet.postgresql.org . > > Sincerely, > > Joshua D. Drake > > >
Newbie alert.... What if we tried to merge ALL of the different Postgres auxiliary projects into a forge site like sugarforge.org? For those of us that are "new", it seems illogical for projects to be scattered all over the place... I am not implying that they should be part of the physical Postgres package, but co-location of all of these tools makes them more accessible and gives "one-stop shopping" for those who are Postgres users.... If we could get the resources to create a repository like SugarForge it would also have many indirect benefits: 1. A single repository for everyone to go consolidates many varied projects and might reduce redundancy 2. Let's outsiders see just how big the Postgres community really is 3. Might entice others to get involved 4. Raises the Postgres profile in the market 5. Gives a more "professional" face to Postgres which it needs to jump to the next level Now, I understand the efforts involved in this, but I wanted to at least plant the seed. Derek Derek M. Rodner Director, Marketing EnterpriseDB Corporation 33 Wood Avenue, Second Floor Iselin, NJ 08830 732.331.1333 Jussi Mikkola wrote: > I think there are some very good points in this, and in this thread in > general. Atleast worth a few thoughts. > > First about the different domains. Yes, it is very much like different > brands. And what is good or bad in it? Well, those projects that are > not under the PostgreSQL umbrella, are not that official, and not > consider part of the "package". But, on the other hand, it could be > beneficial for the main project, if the "package" would contain things > like PgAdmin, Slony etc. I believe, that it would make the total > package more "valuable" in business terms. > > But, if those parts would be in the same package, then that would mean > more responsibility for the core. Someone would need to say that this > is beta, and this is ready. But that would be important for the users, > so it could be worth it. How it would be done, that would require some > talks between all those projects. But I can see, that the current core > could focus on the database itself, and then there could be another > organ that would look at all the joining parts. > > When those projects are clearly separate, it also means that there are > a lot of brands. And if we want to promote all these projects, it will > require additional effort. So, instead of making one strong brand, we > kind of try to make one brand, and then we try to promote also many > other brands that are necessary for the one brand. No focus. > > From the advocacy perspective I see joining projects under a common > umbrella as a very good idea. Of course, those other projects should > also see it beneficial, and it would probably require a lot of work to > make these projects more connected. But I am quite sure, that it would > at least make the advocacy part a lot easier. There would be more to > talk about, and the links would not be pointed out to third party > websites. > > Rgs, > > Jussi > > > Joshua D. Drake wrote: >> >>>> >>>> Well that is a very good point, because I have always considered >>>> planetpostgresql not a part of the PostgreSQL project. I hadn't >>>> even considered that it is a postgresql project until just now. >>> >>> Just curious, but why does it have to be *.postgresql.org to be >>> considered official? Isn't official what we make it ... ? >> >> Absolutely not (unfortunately). Official is what people "perceive" is >> official. >> >> For a case and point, go to http://www.ximian.com or >> http://www.suse.com . You will note that they no longer exist and >> have been absorbed into Novell.com. >> >> The reason for this is to show an official integration, so that >> people are comfortable with the respective brands because they are >> comfortable with Novell. >> >> The same applies for our sub projects, until they are recognized >> under the official project domain name. They will always be >> considered third party. >> >>> The thing is, everyone spends their time putting pgFoundry down as >>> being 'second class' ... of course everyone else is going to >>> consider it such also ... it isn't second class, nor was it ever >>> meant to be ... if ppl promoted, pushed and advertised it more, it >>> would be as 'second class' as common to go to as CPAN is for Perl ... >> >> Perhaps the fact that everyone is putting down pgFoundry as second >> class is telling to the point that we need to promote it's >> perception? E.g; get it under projects.postgresql.org where it really >> belongs. >> >> And as Alvaro mentioned, the same should go for planet.postgresql.org . >> >> Sincerely, >> >> Joshua D. Drake >> >> >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend >
You mean like PgFoundry? On Jul 24, 2006, at 3:30 PM, Derek M. Rodner wrote: > Newbie alert.... > > What if we tried to merge ALL of the different Postgres auxiliary > projects into a forge site like sugarforge.org? > > For those of us that are "new", it seems illogical for projects to > be scattered all over the place... I am not implying that they > should be part of the physical Postgres package, but co-location of > all of these tools makes them more accessible and gives "one-stop > shopping" for those who are Postgres users.... > > If we could get the resources to create a repository like > SugarForge it would also have many indirect benefits: > 1. A single repository for everyone to go consolidates many varied > projects and might reduce redundancy > 2. Let's outsiders see just how big the Postgres community really is > 3. Might entice others to get involved > 4. Raises the Postgres profile in the market > 5. Gives a more "professional" face to Postgres which it needs to > jump to the next level > > Now, I understand the efforts involved in this, but I wanted to at > least plant the seed. > > Derek > > > Derek M. Rodner > Director, Marketing > EnterpriseDB Corporation > 33 Wood Avenue, Second Floor > Iselin, NJ 08830 > 732.331.1333 > > > > > Jussi Mikkola wrote: >> I think there are some very good points in this, and in this >> thread in general. Atleast worth a few thoughts. >> >> First about the different domains. Yes, it is very much like >> different brands. And what is good or bad in it? Well, those >> projects that are not under the PostgreSQL umbrella, are not that >> official, and not consider part of the "package". But, on the >> other hand, it could be beneficial for the main project, if the >> "package" would contain things like PgAdmin, Slony etc. I believe, >> that it would make the total package more "valuable" in business >> terms. >> >> But, if those parts would be in the same package, then that would >> mean more responsibility for the core. Someone would need to say >> that this is beta, and this is ready. But that would be important >> for the users, so it could be worth it. How it would be done, that >> would require some talks between all those projects. But I can >> see, that the current core could focus on the database itself, and >> then there could be another organ that would look at all the >> joining parts. >> >> When those projects are clearly separate, it also means that there >> are a lot of brands. And if we want to promote all these projects, >> it will require additional effort. So, instead of making one >> strong brand, we kind of try to make one brand, and then we try to >> promote also many other brands that are necessary for the one >> brand. No focus. >> >> From the advocacy perspective I see joining projects under a >> common umbrella as a very good idea. Of course, those other >> projects should also see it beneficial, and it would probably >> require a lot of work to make these projects more connected. But I >> am quite sure, that it would at least make the advocacy part a lot >> easier. There would be more to talk about, and the links would not >> be pointed out to third party websites. >> >> Rgs, >> >> Jussi >> >> >> Joshua D. Drake wrote: >>> >>>>> >>>>> Well that is a very good point, because I have always >>>>> considered planetpostgresql not a part of the PostgreSQL >>>>> project. I hadn't even considered that it is a postgresql >>>>> project until just now. >>>> >>>> Just curious, but why does it have to be *.postgresql.org to be >>>> considered official? Isn't official what we make it ... ? >>> >>> Absolutely not (unfortunately). Official is what people >>> "perceive" is official. >>> >>> For a case and point, go to http://www.ximian.com or http:// >>> www.suse.com . You will note that they no longer exist and have >>> been absorbed into Novell.com. >>> >>> The reason for this is to show an official integration, so that >>> people are comfortable with the respective brands because they >>> are comfortable with Novell. >>> >>> The same applies for our sub projects, until they are recognized >>> under the official project domain name. They will always be >>> considered third party. >>> >>>> The thing is, everyone spends their time putting pgFoundry down >>>> as being 'second class' ... of course everyone else is going to >>>> consider it such also ... it isn't second class, nor was it ever >>>> meant to be ... if ppl promoted, pushed and advertised it more, >>>> it would be as 'second class' as common to go to as CPAN is for >>>> Perl ... >>> >>> Perhaps the fact that everyone is putting down pgFoundry as >>> second class is telling to the point that we need to promote it's >>> perception? E.g; get it under projects.postgresql.org where it >>> really belongs. >>> >>> And as Alvaro mentioned, the same should go for >>> planet.postgresql.org . >>> >>> Sincerely, >>> >>> Joshua D. Drake >>> >>> >>> >> >> >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 6: explain analyze is your friend >> > > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
Derek M. Rodner wrote:
> Newbie alert....
>
> What if we tried to merge ALL of the different Postgres auxiliary
> projects into a forge site like sugarforge.org?
www.pgfoundry.org
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> What if we tried to merge ALL of the different Postgres auxiliary >> projects into a forge site like sugarforge.org? > www.pgfoundry.org Not quite: Pl/R, Slony, pgAdmin, pygresql, psycopg, plphp, postgis, etc. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200607242012 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFExWJmvJuQZxSWSsgRAhW0AKCZLq+MQaaez1B6l6HwihsjHDd4ugCgt5sy vLwRL2GfGBquFeMKJX0Erhg= =cRFC -----END PGP SIGNATURE-----
Well it's up to the individual project people if they want to use PgFoundry, but that's what it's there for. Ideally we'd move everyone off of GForge soon too. One of the items on my to-do list is to change PgFoundry to look like www.postgresql.org theme wise, which will help the brand image and make it look more official. Gavin On Jul 24, 2006, at 5:16 PM, Greg Sabino Mullane wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>> What if we tried to merge ALL of the different Postgres auxiliary >>> projects into a forge site like sugarforge.org? > >> www.pgfoundry.org > > Not quite: Pl/R, Slony, pgAdmin, pygresql, psycopg, plphp, postgis, > etc. > > - -- > Greg Sabino Mullane greg@turnstep.com > PGP Key: 0x14964AC8 200607242012 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -----BEGIN PGP SIGNATURE----- > > iD8DBQFExWJmvJuQZxSWSsgRAhW0AKCZLq+MQaaez1B6l6HwihsjHDd4ugCgt5sy > vLwRL2GfGBquFeMKJX0Erhg= > =cRFC > -----END PGP SIGNATURE----- > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
On Monday 24 July 2006 17:20, Gavin M. Roy wrote: > Well it's up to the individual project people if they want to use > PgFoundry, but that's what it's there for. Ideally we'd move > everyone off of GForge soon too. One of the items on my to-do list > is to change PgFoundry to look like www.postgresql.org theme wise, > which will help the brand image and make it look more official. If I'm not mistaken there are a few people looking at what it will take to smoothen the transition for some projects that would like to preserve the bugs list etc. Once this has been figured out I think it will be a lot easier to require people to move to foundry. > > Gavin > > On Jul 24, 2006, at 5:16 PM, Greg Sabino Mullane wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > >>> What if we tried to merge ALL of the different Postgres auxiliary > >>> projects into a forge site like sugarforge.org? > >> > >> www.pgfoundry.org > > > > Not quite: Pl/R, Slony, pgAdmin, pygresql, psycopg, plphp, postgis, > > etc. > > > > - -- > > Greg Sabino Mullane greg@turnstep.com > > PGP Key: 0x14964AC8 200607242012 > > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > > -----BEGIN PGP SIGNATURE----- > > > > iD8DBQFExWJmvJuQZxSWSsgRAhW0AKCZLq+MQaaez1B6l6HwihsjHDd4ugCgt5sy > > vLwRL2GfGBquFeMKJX0Erhg= > > =cRFC > > -----END PGP SIGNATURE----- > > > > > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Darcy Buskermolen Wavefire Technologies Corp. http://www.wavefire.com ph: 250.717.0200 fx: 250.763.1759
Thomas, > A direct consequence of todays organization is that very useful > functionality is scattered in several places with a significant level of > uncertainty as to what is released and stable and what is just a > prototype. PostgreSQL takes a beating in database comparisons and the > community must time after another correct journalists that tend to > "forget" the plethora of add-on modules that exists. Another consequence > is that when using PostgreSQL, you are encouraged to use stored > procedure languages that can be implemented with a few lines of code and > in pure C. A user would probably rather see criterion's like feature > richness and standards conformant. These problems persist although a > number of actors bundle PostgreSQL with various modules today. What you're talking about is creating a "distribution" of PostgreSQL in the same way that there are distributions of Linux. Traditionally, we've left this to commercial distributors, and OS packagers of PostgreSQL to do this. Other people have explained this strategy on this thread. > A resolution to the problem would be to allow the core team to scale up. > More people are needed to support a more comprehensive set of features. > So why not create specialized teams that are part of the > core-development trust? Teams that specialize in replication, in Java, > and in other areas where the core team feel that their knowledge and/or > resources are too limited. I don't see that this is the role of the Core team -- Core takes care of releasing the PostgreSQL "kernel" and one of the ways we've kept PostgreSQL "good" is by minimizing the amount of central, inalienable code. I don't think it's a coincidence that we have both less lines of code than MySQL and significantly less bugs. I *can* see the value in someone putting together an official "community package" of PostgreSQL plus add-ons. We've talked about this before as the "kitchen sink" PostgreSQL (KSPG). However, I think you need to be realistic about the amount of work this would involve: 1) Assembling a trusted, qualified "jury" of PostgreSQL community members to vote on the list of add-ons to be included. 2) Crafting a fair and public review process for "mature" PostgreSQL add-ins. 3) Developing a build system which can handle add-ins with external dependencies. 4) Working out the multiple different licenses which add-ins are under and informing the users of which parts of the KSPG are differently licensed, as well as deciding which licenses may prohibit add-ins from being included. All of the above is worthwhile, but we're talking a *lot* of work. Note that (3) would be worthwhile on its own, and if the build system were interactive/online, a lot of the necessity for a KSPG would be erased since people could easily roll their own. --Josh
Josh Berkus wrote: > Thomas Hallgren wrote: >> A user would probably rather see criterion's like >> feature richness and standards conformant. These problems persist >> although a number of actors bundle PostgreSQL with various modules >> today. > > What you're talking about is creating a "distribution" of PostgreSQL > in the same way that there are distributions of Linux. > Traditionally, we've left this to commercial distributors, and > OS packagers of PostgreSQL to do this. Other people have > explained this strategy on this thread. There is an element of "code centric-ness" in this whole argument which inverts the order of operations involved in coming to know and understand a project from the outside. If we want PostgreSQL to "look bigger" from the outside, it is not necessary to actually *make* it bigger, "looking" bigger is sufficient. Imagine a download page that included: postgresql-database-8.1.4 postgresql-replication-1.0.2 postgresql-gis-1.1.3 postgresql-pooling-1.0.3 Hey, the postgresql database has replication, a spatial extension, a connection pooler, and everything! What a slick project! And, hopefully, when I went to the documentation page, I would find a similar split: PostgreSQL Database Documentation PostgreSQL Replication Documentation PostgreSQL GIS Documentation And so on. It does not require rolling a larger distribution, just making all the components available from one place. Perhaps some cajoling, etc, to get the components to follow some documentation standards so that integrated documentation is possible. Maybe some cajoling to get things named in a boring generic way as the examples above. All the bits are there, they don't need to be *put* together, just *presented* together. People can put them together themselves relatively easily, given the right documentation. Paul PS - Which is not to say I am volunteering, it's still more work than just maintaining the core pages, but it is at least largely restricted to web site activities, not code activities.
> If we want PostgreSQL to "look bigger" from the outside, it is not
> necessary to actually *make* it bigger, "looking" bigger is sufficient.
>
> Imagine a download page that included:
>
> postgresql-database-8.1.4
> postgresql-replication-1.0.2
> postgresql-gis-1.1.3
> postgresql-pooling-1.0.3
You mean like www.mammothpostgresql.org?
As mentioned previously. PostgreSQL is similar to a kernel. It is not a
distribution.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
On Tue, 25 Jul 2006, Darcy Buskermolen wrote: > On Monday 24 July 2006 17:20, Gavin M. Roy wrote: >> Well it's up to the individual project people if they want to use >> PgFoundry, but that's what it's there for. Ideally we'd move >> everyone off of GForge soon too. One of the items on my to-do list >> is to change PgFoundry to look like www.postgresql.org theme wise, >> which will help the brand image and make it look more official. > > If I'm not mistaken there are a few people looking at what it will take to > smoothen the transition for some projects that would like to preserve the > bugs list etc. Once this has been figured out I think it will be a lot > easier to require people to move to foundry. That is correct .. between the conference and oscon (well, the summer months tend to be hell period), things have been delayed somewhat ... > > >> >> Gavin >> >> On Jul 24, 2006, at 5:16 PM, Greg Sabino Mullane wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>>>> What if we tried to merge ALL of the different Postgres auxiliary >>>>> projects into a forge site like sugarforge.org? >>>> >>>> www.pgfoundry.org >>> >>> Not quite: Pl/R, Slony, pgAdmin, pygresql, psycopg, plphp, postgis, >>> etc. >>> >>> - -- >>> Greg Sabino Mullane greg@turnstep.com >>> PGP Key: 0x14964AC8 200607242012 >>> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 >>> -----BEGIN PGP SIGNATURE----- >>> >>> iD8DBQFExWJmvJuQZxSWSsgRAhW0AKCZLq+MQaaez1B6l6HwihsjHDd4ugCgt5sy >>> vLwRL2GfGBquFeMKJX0Erhg= >>> =cRFC >>> -----END PGP SIGNATURE----- >>> >>> >>> >>> ---------------------------(end of >>> broadcast)--------------------------- >>> TIP 2: Don't 'kill -9' the postmaster >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly > > -- > Darcy Buskermolen > Wavefire Technologies Corp. > > http://www.wavefire.com > ph: 250.717.0200 > fx: 250.763.1759 > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Yes, that's what I mean, only at www.postgresql.org and with integrated documentation as well as packaging. The "PostgreSQL is a kernel" metaphor breaks down pretty fast, given that PostgreSQL sans add-ons is quite useful, to the extent that (as many many people have previously written) the fact that add-ons even *exist* is news to lots of PostgreSQL users. This is not a misconception someone trying to use "Linux" (just the kernel) would ever run into. I think any honest assessment of the "software evaluation experience" around PostgreSQL would have to admit that (a) people start at the main PostgreSQL web site and (b) the existence and overall utility of the various add-ons are pretty well hidden and (c) if they were less well hidden people might have a better initial impression of the available capabilities of the overall product. Pointing out that your site over there does a better job of it does not make the main site any less unhelpful. P Joshua D. Drake wrote: > >> If we want PostgreSQL to "look bigger" from the outside, it is not >> necessary to actually *make* it bigger, "looking" bigger is sufficient. >> >> Imagine a download page that included: >> >> postgresql-database-8.1.4 >> postgresql-replication-1.0.2 >> postgresql-gis-1.1.3 >> postgresql-pooling-1.0.3 > > You mean like www.mammothpostgresql.org? > > As mentioned previously. PostgreSQL is similar to a kernel. It is not a > distribution. > > > > Joshua D. Drake >
You know what, I take it back, www.postgreql.org is really quite acceptable. The "About" text is not necessarily well focused, but in general the information organization is leaps-and-bounds better than it used to be, to the point that anyone who really wants to find something has little excuse not to unless they are a drooling miscreant. My apologies. P Paul Ramsey wrote: > Yes, that's what I mean, only at www.postgresql.org and with integrated > documentation as well as packaging. > > The "PostgreSQL is a kernel" metaphor breaks down pretty fast, given > that PostgreSQL sans add-ons is quite useful, to the extent that (as > many many people have previously written) the fact that add-ons even > *exist* is news to lots of PostgreSQL users. This is not a > misconception someone trying to use "Linux" (just the kernel) would ever > run into. > > I think any honest assessment of the "software evaluation experience" > around PostgreSQL would have to admit that (a) people start at the main > PostgreSQL web site and (b) the existence and overall utility of the > various add-ons are pretty well hidden and (c) if they were less well > hidden people might have a better initial impression of the available > capabilities of the overall product. > > Pointing out that your site over there does a better job of it does not > make the main site any less unhelpful. > > P > > Joshua D. Drake wrote: >> >>> If we want PostgreSQL to "look bigger" from the outside, it is not >>> necessary to actually *make* it bigger, "looking" bigger is sufficient. >>> >>> Imagine a download page that included: >>> >>> postgresql-database-8.1.4 >>> postgresql-replication-1.0.2 >>> postgresql-gis-1.1.3 >>> postgresql-pooling-1.0.3 >> >> You mean like www.mammothpostgresql.org? >> >> As mentioned previously. PostgreSQL is similar to a kernel. It is not >> a distribution. >> >> >> >> Joshua D. Drake >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend
On Tue, 25 Jul 2006, Paul Ramsey wrote: > Josh Berkus wrote: >> Thomas Hallgren wrote: >>> A user would probably rather see criterion's like >>> feature richness and standards conformant. These problems persist >>> although a number of actors bundle PostgreSQL with various modules >>> today. >> >> What you're talking about is creating a "distribution" of PostgreSQL >> in the same way that there are distributions of Linux. >> Traditionally, we've left this to commercial distributors, and >> OS packagers of PostgreSQL to do this. Other people have >> explained this strategy on this thread. > > > There is an element of "code centric-ness" in this whole argument which > inverts the order of operations involved in coming to know and understand a > project from the outside. > > If we want PostgreSQL to "look bigger" from the outside, it is not necessary > to actually *make* it bigger, "looking" bigger is sufficient. > > Imagine a download page that included: > > postgresql-database-8.1.4 > postgresql-replication-1.0.2 Which version of Replication do we throw in here? > postgresql-gis-1.1.3 Is there more then just PostGIS? Wait, how does that work if we go and rebrand someone else's project? > postgresql-pooling-1.0.3 Same as gis ... is there only one pooling(?)?, and, if so, you are again talking about 'rebranding' someone else's project ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Tue, 25 Jul 2006, Paul Ramsey wrote: > Yes, that's what I mean, only at www.postgresql.org and with integrated > documentation as well as packaging. > > The "PostgreSQL is a kernel" metaphor breaks down pretty fast, given that > PostgreSQL sans add-ons is quite useful, to the extent that (as many many > people have previously written) the fact that add-ons even *exist* is news to > lots of PostgreSQL users. This is not a misconception someone trying to use > "Linux" (just the kernel) would ever run into. > > I think any honest assessment of the "software evaluation experience" around > PostgreSQL would have to admit that (a) people start at the main PostgreSQL > web site and (b) the existence and overall utility of the various add-ons are > pretty well hidden and (c) if they were less well hidden people might have a > better initial impression of the available capabilities of the overall > product. > > Pointing out that your site over there does a better job of it does not make > the main site any less unhelpful. Actually, using the 'kernel vs add ons' metaphor, it would make more sense to make a series of smaller 'distributions', tailored to specific markets ... ie. a Java distribution that includes JDBC+PL/Java, but doesn't include the other PLs ... or a Ruby package that includes the Ruby interface and pl/ruby ... or a ... etc ... Not one distribution for all tastes, but individual distributions tailored to specific groups / programmers ... > > P > > Joshua D. Drake wrote: >> >>> If we want PostgreSQL to "look bigger" from the outside, it is not >>> necessary to actually *make* it bigger, "looking" bigger is sufficient. >>> >>> Imagine a download page that included: >>> >>> postgresql-database-8.1.4 >>> postgresql-replication-1.0.2 >>> postgresql-gis-1.1.3 >>> postgresql-pooling-1.0.3 >> >> You mean like www.mammothpostgresql.org? >> >> As mentioned previously. PostgreSQL is similar to a kernel. It is not a >> distribution. >> >> >> >> Joshua D. Drake >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > Actually, using the 'kernel vs add ons' metaphor, it would make more > sense to make a series of smaller 'distributions', tailored to specific > markets ... ie. a Java distribution that includes JDBC+PL/Java, but > doesn't include the other PLs ... or a Ruby package that includes the > Ruby interface and pl/ruby ... or a ... etc ... > > Not one distribution for all tastes, but individual distributions > tailored to specific groups / programmers ... Spoken like a true programmer. :) I have been amazed by the power of the simple optimization rule "remove barriers to entry", and how it has worked. The Windows port of PgSQL and associated installer (itself a "distribution" in the kernel-metaphor sense, only carried on the main PostgreSQL site) has had a huge affect on PostGIS usage, so I assume the same holds true for PgSQL in general. But such an approach (one size fits all, click the big green button for download) is basically the diametric opposite of what you suggest. P
Paul, Speaking of which, what have you been up to? I've not heard from you or anyone from PostGIS for ages. I invited PostGIS to the Anniversary Summit and got no response. I'm not at OSCON and there are a bunch of OpenGeo people here, but nobody from GIS. When will we see you again? --Josh
Marc, > Actually, using the 'kernel vs add ons' metaphor, it would make more > sense to make a series of smaller 'distributions', tailored to specific > markets ... ie. a Java distribution that includes JDBC+PL/Java, but > doesn't include the other PLs ... heh. Guess what I'm planning for PostgreSQL for Solaris. --Josh
Paul, > I have been amazed by the power of the simple optimization rule "remove > barriers to entry", and how it has worked. The Windows port of PgSQL > and associated installer (itself a "distribution" in the kernel-metaphor > sense, only carried on the main PostgreSQL site) has had a huge affect > on PostGIS usage, so I assume the same holds true for PgSQL in general. > > But such an approach (one size fits all, click the big green button for > download) is basically the diametric opposite of what you suggest. Well, for example we *can't* do a one-size-fits all including PostGIS unless you get it re-licensed. However, I've been talking about build systems here at the conference again. While it's a technical barrier there may be open source software we can borrow. The best of all possible worlds would be to have: pg_install > install base .... done > install gis Package GIS is GPL licensed. Package GIS requires x, y, z. Proceed? if that's not possible, then having more clear packages would be the next best thing. Given a shortage of labor, though, I think that it might be better to just provide documentation to the OS build engineers and vendors about add-ins they might be interested in and how to find and build them. --Josh
Paul Ramsey wrote: > Yes, that's what I mean, only at www.postgresql.org and with integrated > documentation as well as packaging. > > The "PostgreSQL is a kernel" metaphor breaks down pretty fast, given > that PostgreSQL sans add-ons is quite useful, to the extent that (as > many many people have previously written) the fact that add-ons even > *exist* is news to lots of PostgreSQL users. This is not a > misconception someone trying to use "Linux" (just the kernel) would ever > run into. > > I think any honest assessment of the "software evaluation experience" > around PostgreSQL would have to admit that (a) people start at the main > PostgreSQL web site and (b) the existence and overall utility of the > various add-ons are pretty well hidden and (c) if they were less well > hidden people might have a better initial impression of the available > capabilities of the overall product. > Very well put. This covers the perception aspect of it. Josh Berkus wrote: > I *can* see the value in someone putting together an official "community > package" of PostgreSQL plus add-ons. We've talked about this before as > the "kitchen sink" PostgreSQL (KSPG). However, I think you need to be > realistic about the amount of work this would involve: > > 1) Assembling a trusted, qualified "jury" of PostgreSQL community > members to vote on the list of add-ons to be included. > > 2) Crafting a fair and public review process for "mature" PostgreSQL > add-ins. > > 3) Developing a build system which can handle add-ins with external > dependencies. > > 4) Working out the multiple different licenses which add-ins are under > and informing the users of which parts of the KSPG are differently > licensed, as well as deciding which licenses may prohibit add-ins from > being included. > Great set of action items! Add some item that resolves the issues that Paul mentions and this would address all of my concerns. Well, given that (3) also covered inclusion of add-ons in the build-farm. IMHO, the work that we put into this will be hours very well spent. I'm of course biased being an add-on author, but I don't think it would be too hard to muster the resources for it. And, as you suggest, some items have a value of their own. If we put together a plan that clearly expresses the intents to go this route then my guess is that more such items would be exposed. Kind Regards, Thomas Hallgren
Marc G. Fournier wrote: > > Which version of Replication do we throw in here? > IMHO, the current players should be encouraged create a joint portfolio that makes sense. This goes for other projects as well. A qualified community jury would have the final vote. Today there is very little incentive to join forces and in many cases that's bad both for the add-ons and for the PostgreSQL image as a whole. We should strive to establish a distribution containing no ambiguities and the process that we put in place should establish incentives to make that happen. The 'specialized teams' that I mentioned in my original suggestion are intended to do this. I also think that we need more conferences to break the ice and make such merges happen. Kind Regards, Thomas Hallgren
What about using the live CD as one way to answer this problem? Just create a live CD that installs everything under thesun (pun intended) On July 26, 2006 02:16 am, Josh Berkus wrote: > Paul, > > > I have been amazed by the power of the simple optimization rule "remove > > barriers to entry", and how it has worked. The Windows port of PgSQL > > and associated installer (itself a "distribution" in the kernel-metaphor > > sense, only carried on the main PostgreSQL site) has had a huge affect > > on PostGIS usage, so I assume the same holds true for PgSQL in general. > > > > But such an approach (one size fits all, click the big green button for > > download) is basically the diametric opposite of what you suggest. > > Well, for example we *can't* do a one-size-fits all including PostGIS > unless you get it re-licensed. > > However, I've been talking about build systems here at the conference > again. While it's a technical barrier there may be open source software > we can borrow. The best of all possible worlds would be to have: > > pg_install > > > install base > > .... done > > > install gis > > Package GIS is GPL licensed. Package GIS requires x, y, z. Proceed? > > if that's not possible, then having more clear packages would be the > next best thing. Given a shortage of labor, though, I think that it > might be better to just provide documentation to the OS build engineers > and vendors about add-ins they might be interested in and how to find > and build them. >
Thomas Hallgren wrote:
> Marc G. Fournier wrote:
>>
>> Which version of Replication do we throw in here?
>>
> IMHO, the current players should be encouraged create a joint portfolio
> that makes sense.
All due respect but that is a pipe dream.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Joshua D. Drake wrote: > Thomas Hallgren wrote: > >Marc G. Fournier wrote: > >> > >>Which version of Replication do we throw in here? > >> > >IMHO, the current players should be encouraged create a joint portfolio > >that makes sense. > > All due respect but that is a pipe dream. Why? The current players list reduces to 1. Slony-I So it's not that difficult to get them to agree with themselves. The other possible players are all excused: - DBmirror: the author considers it obsolete - Postgres-R: it's still under development - erServer: obsolete, abandoned, inferior to Slony-I anyway - Mammoth Replicator: proprietary Am I missing anyone? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Joshua D. Drake wrote: > Thomas Hallgren wrote: >> Marc G. Fournier wrote: >>> >>> Which version of Replication do we throw in here? >>> >> IMHO, the current players should be encouraged create a joint >> portfolio that makes sense. > > All due respect but that is a pipe dream. > Given todays organization yes. Given a more elaborated organization that encourages efforts like that, absolutely not. Assume that we had something called the "PostgreSQL utility portfolio". I.e. an official set of utilities published in such a way that there's no doubt that they are endorsed by a PostgreSQL community board. Add a process where proposals for inclusion can be turned in for review. Finally assume that the community board, when similar proposals arrive, will encourage the proposing parties to merge on the thesis that cooperation is far more productive than a beauty contest (well most of the time anyway). I promise you that a) it would have the desired effect and b) it is not just a dream. Other projects do this already. Why would it be so impossible for us? Kind Regards, Thomas Hallgren
On Wed, 26 Jul 2006, Joshua D. Drake wrote: > Thomas Hallgren wrote: >> Marc G. Fournier wrote: >>> >>> Which version of Replication do we throw in here? >>> >> IMHO, the current players should be encouraged create a joint portfolio >> that makes sense. > > All due respect but that is a pipe dream. Agreed ... as has been stated many many times already concerning replication ... the reason why we *don't* have an built in replication system is that none of us truly believes that there is such thing as a "one size fits all" replication solution ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Wed, 26 Jul 2006, Thomas Hallgren wrote: > Joshua D. Drake wrote: >> Thomas Hallgren wrote: >>> Marc G. Fournier wrote: >>>> >>>> Which version of Replication do we throw in here? >>>> >>> IMHO, the current players should be encouraged create a joint portfolio >>> that makes sense. >> >> All due respect but that is a pipe dream. >> > Given todays organization yes. Given a more elaborated organization that > encourages efforts like that, absolutely not. > > Assume that we had something called the "PostgreSQL utility portfolio". I.e. > an official set of utilities published in such a way that there's no doubt > that they are endorsed by a PostgreSQL community board. > > Add a process where proposals for inclusion can be turned in for review. > > Finally assume that the community board, when similar proposals arrive, will > encourage the proposing parties to merge on the thesis that cooperation is > far more productive than a beauty contest (well most of the time anyway). > > I promise you that a) it would have the desired effect and b) it is not just > a dream. Other projects do this already. Why would it be so impossible for > us? 'k, so ... why don't you form this "community board"? Bring in like minded individuals, set up a project on pgFoundry to organize it and do exactly what you are proposing? The point is ... nobody is stopping anyone from doing this, so why hasn't anyone done it? Why haven't you run with it and done it? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > Agreed ... as has been stated many many times already concerning > replication ... the reason why we *don't* have an built in replication > system is that none of us truly believes that there is such thing as a > "one size fits all" replication solution ... > A joint portfolio doesn't mean one single replication solution. It means a sane set of solutions, preferably with a common API, but that is not a necessity. Regards, Thomas Hallgren
Marc G. Fournier wrote: > > 'k, so ... why don't you form this "community board"? Bring in like > minded individuals, set up a project on pgFoundry to organize it and > do exactly what you are proposing? > > The point is ... nobody is stopping anyone from doing this, so why > hasn't anyone done it? Why haven't you run with it and done it? Right. Yet another project on PgFoundry is the solution to all problems in the world. How would that solve *any* of the issues that I bring up here? Regards, Thomas Hallgren
Thomas, > Finally assume that the community board, when similar proposals > arrive, will encourage the proposing parties to merge on the thesis > that cooperation is far more productive than a beauty contest (well > most of the time anyway). Ah, so you're planning on merging with PL/J? The different solutions are different because of technical decisions which they made differently, usually for very good reasons. Slony-I is trigger-based, Mammoth is log-based, and no matter which you prefer they're not going to merge code. BTW, our replication/clustering solutions include: Slony-I pgPool Mammoth* Postgres-R pgCluster Sequoia/p|cluster* dbMirror/eRserv/other older solutions ExtenDB* Bizgres MPP* Windows/Red Hat/Solaris clustered FS* (*=proprietary/external) I think any community packaged distribution should encourage this diversity, not try to crush it. Josh Berkus PostgreSQL @ Sun San Francisco 415-752-2500
Josh Berkus wrote: > Thomas, > > >> Finally assume that the community board, when similar proposals >> arrive, will encourage the proposing parties to merge on the thesis >> that cooperation is far more productive than a beauty contest (well >> most of the time anyway). >> > > Ah, so you're planning on merging with PL/J? > > That would be a natural consequence, yes. Some synergies with the JDBC client driver should also be exploited. > The different solutions are different because of technical decisions > which they made differently, usually for very good reasons. Slony-I > is trigger-based, Mammoth is log-based, and no matter which you prefer > they're not going to merge code. > > They don't need to. Please read my previous postings on this. I'm not talking about merging code. Sure, when synergies exists, they should be exploited and when a coherent API can be created that span multiple solutions, that's great. But that's not the main point. The main point is to get rid of ambiguities and create a stable, endorsed portfolio that contains all functionality that is available today. > BTW, our replication/clustering solutions include: > > Slony-I > pgPool > Mammoth* > Postgres-R > pgCluster > Sequoia/p|cluster* > dbMirror/eRserv/other older solutions > ExtenDB* > Bizgres MPP* > Windows/Red Hat/Solaris clustered FS* > > (*=proprietary/external) > > Proprietary solutions must be ruled out unless they change their license and give everything away. That might be an option that would appeal to some. I know it has happened in other projects. In exchange for an official contributor status, you give your stuff away. But there's no place where you can do that today. Submitting your project to PgFoundry where you compete with other projects ranging from early prototypes to well established solutions does not give you the right incentives. > I think any community packaged distribution should encourage this > diversity, not try to crush it. > > Although diversity can be great in many situations, it's also known to introduce ambiguities. And that is a pain for the end-user. Especially when you don't know the quality of the solutions. So, although I agree that nothing should be "crushed", I still think it's important to encourage quality, collaboration, communication, and cooperation and discourage head-on competition. 10 replication solutions is a terrible waste of resources IMHO. No one size fits all of course, but how many sizes is really needed? Regards, Thomas Hallgren
Hi all, FWIW, I didn't think myself pgFoundry was the official home for PostgreSQL related projects before I began to follow PostgreSQL development. Marc G. Fournier wrote: > Odd, do you want to have a quick peak to see what I'm missing? > UseCanonicalName is turned Off, but if you go to > projects.postgresql.org, it is being redirected to pgfoundry.org, > instead of serving up pages ... might be something internal to gforge > though ... Yes, the redirection is made by GForge ($sys_default_domain). You can define a $sys_fallback_domain or we can even remove the redirect directly in the code if needed. The problem is that in emails generated by GForge or when GForge uses the complete url, it's the $sys_default_domain which is used. And it's not a good idea to have two domains for one unique site. > Be nice if both could work at the same time, so that all of the search > engines still finds everything :( This can be done easily via a rewrite rule. We can redirect any pgfoundry link to his new whatever.postgresql.org without losing anything (and a 301 redirect is better). It's quite simple and I can provide the rules we usually use for that if needed. I also really think we should have a more "postgresqlized" theme for pgFoundry instead of the current one. I'm not a graphic designer but I made several GForge themes for our customers and I know pretty well GForge internals so I can help with this one if people think it's a good idea and if someone volunteers for graphical work and ideas. -- Guillaume
On 7/24/06, Peter Eisentraut <peter_e@gmx.net> wrote: > Am Montag, 24. Juli 2006 16:35 schrieb Marc G. Fournier: > > One thing that has been talked to death many times, but nobody ever seems > > to come up with a solution to, is pgFoundry, and how badly it is > > advertised / promoted ... so software packages over there seem relegated > > to a sort of 'no mans land' ... > > The challenge is to distinguish random garbage from the good, important > projects on pgFoundry. It seems that what this really comes down to is that > what need a committee that decides what the > good/important/maintained/endorsed projects are. Those projects can then get > more prominent URLs, links, etc. I'd like to weigh in on our experiences in Joomla-land. We're getting our forge at forge.joomla.org generously hosted and maintained by VA Software, and it is a full-blown SourceForge Enterprise Edition on several machines. At present there are 35,000 registered users on the forge, and we have 45,000 registered users on the forums. We assume that most of those accounts are the same people, i.e. a developer with a forum account, and so on. The forge is most definitely *not* suitable for your garden variety end user that is looking for a photo album or some such. SFEE was just not up to the task for the kinds of wholesale changes that we were wanting, so we setup extensions.joomla.org instead. Now, developers have a place to host their projects, and there is also a place where people can browse for additional packages based on category - and each item has ratings, comments, and metadata (home URL, etc). Like a very very user friendly freshmeat.net, but just for Joomla applications. This site was created specifically for the end user, and provides the kind of community-driven interaction so you can see which projects are not ready for prime time, and which ones are must-haves, etc. You guys could certainly do that here in PostgreSQL-land, and it wouldn't force you to make wholesale changes to your PgFoundry site. There must be community members out there that would love to help setup and launch such a service, as it would be a huge step regarding advocacy and the mainstream. Every time I present Joomla I hear how important the extensions site is to the community, and I suspect the same thing could be said here too, if one were made available. Just my $.02 though, from experience on another project. :-) -- Mitch