Thread: When should be advocate external projects?
Hello,
There has been a lot of back and forth about when we (as a community)
should advocate external projects as well as where we should advocate
external projects. It seems the more advocacy minded individuals would
like to be more inclusive whilst the -hackers and old school folks don't
want to bother with it at all (this is not exclusive, I know there are
exceptions).
I think we need to come up with some guidelines. I have my own ideas of
what those should be:
* Must be released under an OSI approved license
* Must have source downloadable without barrier (no registration for
example)
* Must have a way to file bug reports
There are others but they may be controversial so I will leave them for now.
One example that I just recently looked at was PgBadger. PgBader is
primarily developed by Dalibo but:
* It is released under an OSI approved license
* Has source downloadable without barrier
* Has a way to file bug reports
* Has an open mailing list
* An explicit link to how to contribute
It does make it a point of highlighting Dalibo as the support provider
but it also links directly to:
http://www.postgresql.org/support/professional_support
And shows those professionals respect too.[1]
Sincerely,
Joshua D. Drake
1. http://dalibo.github.io/pgbadger/
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
On 05/12/2016 02:18 AM, Joshua D. Drake wrote: > Hello, > > There has been a lot of back and forth about when we (as a community) > should advocate external projects as well as where we should advocate > external projects. It seems the more advocacy minded individuals would > like to be more inclusive whilst the -hackers and old school folks don't > want to bother with it at all (this is not exclusive, I know there are > exceptions). > > I think we need to come up with some guidelines. I have my own ideas of > what those should be: > > * Must be released under an OSI approved license > * Must have source downloadable without barrier (no registration for > example) > * Must have a way to file bug reports > > There are others but they may be controversial so I will leave them for > now. To avoid proliferation, I think we should also limit them by exclusivity. There are no other real contenders for the belts that pgBadger, check_postgres, and pgAdmin hold, so all of those should be promoted. That could perhaps be extended from one to two, which would allow us to promote both PgBackRest and Barman. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On 05/11/2016 05:29 PM, Vik Fearing wrote: > On 05/12/2016 02:18 AM, Joshua D. Drake wrote: >> Hello, >> >> There has been a lot of back and forth about when we (as a community) >> should advocate external projects as well as where we should advocate >> external projects. It seems the more advocacy minded individuals would >> like to be more inclusive whilst the -hackers and old school folks don't >> want to bother with it at all (this is not exclusive, I know there are >> exceptions). >> >> I think we need to come up with some guidelines. I have my own ideas of >> what those should be: >> >> * Must be released under an OSI approved license >> * Must have source downloadable without barrier (no registration for >> example) >> * Must have a way to file bug reports >> >> There are others but they may be controversial so I will leave them for >> now. > > To avoid proliferation, I think we should also limit them by > exclusivity. There are no other real contenders for the belts that > pgBadger, check_postgres, and pgAdmin hold, so all of those should be > promoted. I am not sure about PgAdmin, especially as of version 4 but you have good points with pgBader and check_postgres. > > That could perhaps be extended from one to two, which would allow us to > promote both PgBackRest and Barman. > I would need to look into the similarities and differences. I admit I know more about PgBackRest than I do Barman. On the other hand, why don't we want proliferation? Obviously we don't want to list 20 tools in a release but we can certainly point to a "tools" page where the FOSS tools are given precedence. JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Wed, May 11, 2016 at 8:18 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > There has been a lot of back and forth about when we (as a community) should > advocate external projects as well as where we should advocate external > projects. It seems the more advocacy minded individuals would like to be > more inclusive whilst the -hackers and old school folks don't want to bother > with it at all (this is not exclusive, I know there are exceptions). > > I think we need to come up with some guidelines. I have my own ideas of what > those should be: > > * Must be released under an OSI approved license > * Must have source downloadable without barrier (no registration for > example) > * Must have a way to file bug reports > > There are others but they may be controversial so I will leave them for now. > > One example that I just recently looked at was PgBadger. PgBader is > primarily developed by Dalibo but: > > * It is released under an OSI approved license > * Has source downloadable without barrier > * Has a way to file bug reports > * Has an open mailing list > * An explicit link to how to contribute > > It does make it a point of highlighting Dalibo as the support provider but > it also links directly to: > > http://www.postgresql.org/support/professional_support > > And shows those professionals respect too.[1] I like the idea of having a page on postgresql.org where we say "here are a list of other great open source tools that you should check out and use with PostgreSQL". It could be grouped by category. I think a "drivers" category would be really good - like why should people have to use Google to find a node.js driver for PostgreSQL? And there can be a "replication" category that lists pglogical, Slony, Londiste, Bucardo. And a "middleware" category for pgpool and pgbouncer. There may be some cases where it's not clear whether something qualifies, so, yeah, we might need some guidelines for that. But I'm +1 on the concept. I am -1 on promoting pglogical over every other thing out there but I am +1 for promoting it as one of several widely-used replication tools for PostgreSQL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On May 12, 2016 16:09, "Robert Haas" <robertmhaas@gmail.com> wrote:
>
> On Wed, May 11, 2016 at 8:18 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> > There has been a lot of back and forth about when we (as a community) should
> > advocate external projects as well as where we should advocate external
> > projects. It seems the more advocacy minded individuals would like to be
> > more inclusive whilst the -hackers and old school folks don't want to bother
> > with it at all (this is not exclusive, I know there are exceptions).
> >
> > I think we need to come up with some guidelines. I have my own ideas of what
> > those should be:
> >
> > * Must be released under an OSI approved license
> > * Must have source downloadable without barrier (no registration for
> > example)
> > * Must have a way to file bug reports
> >
> > There are others but they may be controversial so I will leave them for now.
> >
> > One example that I just recently looked at was PgBadger. PgBader is
> > primarily developed by Dalibo but:
> >
> > * It is released under an OSI approved license
> > * Has source downloadable without barrier
> > * Has a way to file bug reports
> > * Has an open mailing list
> > * An explicit link to how to contribute
> >
> > It does make it a point of highlighting Dalibo as the support provider but
> > it also links directly to:
> >
> > http://www.postgresql.org/support/professional_support
> >
> > And shows those professionals respect too.[1]
>
> I like the idea of having a page on postgresql.org where we say "here
> are a list of other great open source tools that you should check out
> and use with PostgreSQL". It could be grouped by category. I think a
> "drivers" category would be really good - like why should people have
> to use Google to find a node.js driver for PostgreSQL? And there can
> be a "replication" category that lists pglogical, Slony, Londiste,
> Bucardo. And a "middleware" category for pgpool and pgbouncer.
>
> There may be some cases where it's not clear whether something
> qualifies, so, yeah, we might need some guidelines for that. But I'm
> +1 on the concept. I am -1 on promoting pglogical over every other
> thing out there but I am +1 for promoting it as one of several
> widely-used replication tools for PostgreSQL.
That's basically what the software catalogue does, isn't it? It needs to be revamped to be more user friendly, and more promoted, but as a basis?
/Magnus
On Thu, May 12, 2016 at 11:30 AM, Magnus Hagander <magnus@hagander.net> wrote: >> I like the idea of having a page on postgresql.org where we say "here >> are a list of other great open source tools that you should check out >> and use with PostgreSQL". It could be grouped by category. I think a >> "drivers" category would be really good - like why should people have >> to use Google to find a node.js driver for PostgreSQL? And there can >> be a "replication" category that lists pglogical, Slony, Londiste, >> Bucardo. And a "middleware" category for pgpool and pgbouncer. >> >> There may be some cases where it's not clear whether something >> qualifies, so, yeah, we might need some guidelines for that. But I'm >> +1 on the concept. I am -1 on promoting pglogical over every other >> thing out there but I am +1 for promoting it as one of several >> widely-used replication tools for PostgreSQL. > > That's basically what the software catalogue does, isn't it? It needs to be > revamped to be more user friendly, and more promoted, but as a basis? Sure, that kind of idea. I'd forgotten we had that. I think that we should go to a format with just one line for each piece of software, though, instead of a big box. And try to get it all one one page. And remove all of the proprietary products or put them in a separate section. And include only stuff that's actually reasonably widely used. Maybe we should just go stand up a wiki page to start. What's in the software catalog right now looks useless to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05/12/2016 08:44 AM, Robert Haas wrote: > On Thu, May 12, 2016 at 11:30 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> I like the idea of having a page on postgresql.org where we say "here >>> are a list of other great open source tools that you should check out >>> and use with PostgreSQL". It could be grouped by category. I think a >>> "drivers" category would be really good - like why should people have >>> to use Google to find a node.js driver for PostgreSQL? And there can >>> be a "replication" category that lists pglogical, Slony, Londiste, >>> Bucardo. And a "middleware" category for pgpool and pgbouncer. >>> >>> There may be some cases where it's not clear whether something >>> qualifies, so, yeah, we might need some guidelines for that. But I'm >>> +1 on the concept. I am -1 on promoting pglogical over every other >>> thing out there but I am +1 for promoting it as one of several >>> widely-used replication tools for PostgreSQL. >> >> That's basically what the software catalogue does, isn't it? It needs to be >> revamped to be more user friendly, and more promoted, but as a basis? > > Sure, that kind of idea. I'd forgotten we had that. I think that we > should go to a format with just one line for each piece of software, > though, instead of a big box. And try to get it all one one page. > And remove all of the proprietary products or put them in a separate > section. And include only stuff that's actually reasonably widely > used. This is the part I see is going to be the biggest problem, who is going to curate this stuff? As you mention below the information is of dubious value as it stands now. While the idea of including third party stuff on the site is noble, I have yet to see an actual plan to ensure that it is handled in a timely manner and with accuracy. > > Maybe we should just go stand up a wiki page to start. What's in the > software catalog right now looks useless to me. -- Adrian Klaver adrian.klaver@aklaver.com
On 05/12/2016 07:09 AM, Robert Haas wrote: > On Wed, May 11, 2016 at 8:18 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > There may be some cases where it's not clear whether something > qualifies, so, yeah, we might need some guidelines for that. But I'm > +1 on the concept. I am -1 on promoting pglogical over every other Agreed except under this definition: No other open source tool provides the solution. Right now for logical replication that uses the logical decoding API that PostgreSQL provides there is exactly "1" solution and that is PgLogical. That doesn't mean their aren't other Logical Replication solutions (Slony for example) but nobody in their right mind can say that Slony is the better choice for "standard master/slave" replication. And FTR: I am not saying Slony is a bad tool, it isn't but the services it provides are far beyond what the average person would be looking for if they were considering something like PgLogical. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 05/12/2016 08:54 AM, Adrian Klaver wrote: > On 05/12/2016 08:44 AM, Robert Haas wrote: >> On Thu, May 12, 2016 at 11:30 AM, Magnus Hagander >> Sure, that kind of idea. I'd forgotten we had that. I think that we >> should go to a format with just one line for each piece of software, >> though, instead of a big box. And try to get it all one one page. >> And remove all of the proprietary products or put them in a separate >> section. And include only stuff that's actually reasonably widely >> used. > > This is the part I see is going to be the biggest problem, who is going > to curate this stuff? As you mention below the information is of dubious > value as it stands now. While the idea of including third party stuff on > the site is noble, I have yet to see an actual plan to ensure that it is > handled in a timely manner and with accuracy. There are several different ways to make sure this stuff is curated correctly but that isn't the problem. At least not the immediate one. The problem is a lack of leadership driving the content. Any project whether documentation, code, web, social etc... without leadership is destined to fall by the wayside due to people focusing on other things. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 12 May 2016, at 15:09, Robert Haas <robertmhaas@gmail.com> wrote: <snip> > I like the idea of having a page on postgresql.org where we say "here > are a list of other great open source tools that you should check out > and use with PostgreSQL". It could be grouped by category. Kind of like an updated/modernised version of this? https://web.archive.org/web/20050301084849/http://techdocs.postgresql.org/oresources.php The Software Catalog as mentioned in the thread seems to be along the same lines, although more formalised, possibly less engaging. + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Thu, May 12, 2016 at 11:44:17AM -0400, Robert Haas wrote:
> > That's basically what the software catalogue does, isn't it? It needs to be
> > revamped to be more user friendly, and more promoted, but as a basis?
>
> Sure, that kind of idea. I'd forgotten we had that. I think that we
> should go to a format with just one line for each piece of software,
> though, instead of a big box. And try to get it all one one page.
> And remove all of the proprietary products or put them in a separate
> section. And include only stuff that's actually reasonably widely
> used.
>
> Maybe we should just go stand up a wiki page to start. What's in the
> software catalog right now looks useless to me.
I think our wiki page that lists all the FDWs is great, so why can't we
do this for other external software?
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, May 12, 2016 at 11:44:17AM -0400, Robert Haas wrote: >>> That's basically what the software catalogue does, isn't it? It needs to be >>> revamped to be more user friendly, and more promoted, but as a basis? >> >> Sure, that kind of idea. I'd forgotten we had that. I think that we >> should go to a format with just one line for each piece of software, >> though, instead of a big box. And try to get it all one one page. >> And remove all of the proprietary products or put them in a separate >> section. And include only stuff that's actually reasonably widely >> used. >> >> Maybe we should just go stand up a wiki page to start. What's in the >> software catalog right now looks useless to me. > > I think our wiki page that lists all the FDWs is great, so why can't we > do this for other external software? > > https://wiki.postgresql.org/wiki/Foreign_data_wrappers That page does seem well put together. Guess the main question now is "who will drive this initiative?" + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: > On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: > > On Thu, May 12, 2016 at 11:44:17AM -0400, Robert Haas wrote: > >>> That's basically what the software catalogue does, isn't it? It needs to be > >>> revamped to be more user friendly, and more promoted, but as a basis? > >> > >> Sure, that kind of idea. I'd forgotten we had that. I think that we > >> should go to a format with just one line for each piece of software, > >> though, instead of a big box. And try to get it all one one page. > >> And remove all of the proprietary products or put them in a separate > >> section. And include only stuff that's actually reasonably widely > >> used. > >> > >> Maybe we should just go stand up a wiki page to start. What's in the > >> software catalog right now looks useless to me. > > > > I think our wiki page that lists all the FDWs is great, so why can't we > > do this for other external software? > > > > https://wiki.postgresql.org/wiki/Foreign_data_wrappers > > That page does seem well put together. Guess the main question now is > "who will drive this initiative?" Yep, it is a big job but would be a big win. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 12 May 2016, at 21:58, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: >> On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: >>> On Thu, May 12, 2016 at 11:44:17AM -0400, Robert Haas wrote: >>>>> That's basically what the software catalogue does, isn't it? It needs to be >>>>> revamped to be more user friendly, and more promoted, but as a basis? >>>> >>>> Sure, that kind of idea. I'd forgotten we had that. I think that we >>>> should go to a format with just one line for each piece of software, >>>> though, instead of a big box. And try to get it all one one page. >>>> And remove all of the proprietary products or put them in a separate >>>> section. And include only stuff that's actually reasonably widely >>>> used. >>>> >>>> Maybe we should just go stand up a wiki page to start. What's in the >>>> software catalog right now looks useless to me. >>> >>> I think our wiki page that lists all the FDWs is great, so why can't we >>> do this for other external software? >>> >>> https://wiki.postgresql.org/wiki/Foreign_data_wrappers >> >> That page does seem well put together. Guess the main question now is >> "who will drive this initiative?" > > Yep, it is a big job but would be a big win. Wish I had time for it, but I'm learning C++ & Qt at the moment to add some needed features for another project. :( + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On 05/12/2016 02:02 PM, Justin Clift wrote: > On 12 May 2016, at 21:58, Bruce Momjian <bruce@momjian.us> wrote: >> On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: >>> On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: >>>> I think our wiki page that lists all the FDWs is great, so why can't we >>>> do this for other external software? >>>> >>>> https://wiki.postgresql.org/wiki/Foreign_data_wrappers >>> >>> That page does seem well put together. Guess the main question now is >>> "who will drive this initiative?" IMO: A much better solution is to rework the software catalogue to properly highly open source "projects" versus "products" and allow people to manage via a moderated interface their own listings. It will be consistent, provide a central place within the primary domain and be lower overhead than a wiki. JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Thu, May 12, 2016 at 02:15:15PM -0700, Joshua Drake wrote: > On 05/12/2016 02:02 PM, Justin Clift wrote: > >On 12 May 2016, at 21:58, Bruce Momjian <bruce@momjian.us> wrote: > >>On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: > >>>On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: > > >>>>I think our wiki page that lists all the FDWs is great, so why can't we > >>>>do this for other external software? > >>>> > >>>> https://wiki.postgresql.org/wiki/Foreign_data_wrappers > >>> > >>>That page does seem well put together. Guess the main question now is > >>>"who will drive this initiative?" > > IMO: > > A much better solution is to rework the software catalogue to properly > highly open source "projects" versus "products" and allow people to manage > via a moderated interface their own listings. It will be consistent, provide > a central place within the primary domain and be lower overhead than a wiki. The nice thing about a wiki is anyone can go in and improve it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On 05/12/2016 02:16 PM, Bruce Momjian wrote: > On Thu, May 12, 2016 at 02:15:15PM -0700, Joshua Drake wrote: >> On 05/12/2016 02:02 PM, Justin Clift wrote: >>> On 12 May 2016, at 21:58, Bruce Momjian <bruce@momjian.us> wrote: >>>> On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: >>>>> On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: >> >>>>>> I think our wiki page that lists all the FDWs is great, so why can't we >>>>>> do this for other external software? >>>>>> >>>>>> https://wiki.postgresql.org/wiki/Foreign_data_wrappers >>>>> >>>>> That page does seem well put together. Guess the main question now is >>>>> "who will drive this initiative?" >> >> IMO: >> >> A much better solution is to rework the software catalogue to properly >> highly open source "projects" versus "products" and allow people to manage >> via a moderated interface their own listings. It will be consistent, provide >> a central place within the primary domain and be lower overhead than a wiki. > > The nice thing about a wiki is anyone can go in and improve it. Agreed but I think that is a downside here. Keep in mind we have a locked down wiki that we only allow update if you ask edit permission. JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On 05/12/2016 11:18 AM, Joshua D. Drake wrote: > On 05/12/2016 08:54 AM, Adrian Klaver wrote: >> On 05/12/2016 08:44 AM, Robert Haas wrote: >>> On Thu, May 12, 2016 at 11:30 AM, Magnus Hagander > >>> Sure, that kind of idea. I'd forgotten we had that. I think that we >>> should go to a format with just one line for each piece of software, >>> though, instead of a big box. And try to get it all one one page. >>> And remove all of the proprietary products or put them in a separate >>> section. And include only stuff that's actually reasonably widely >>> used. >> >> This is the part I see is going to be the biggest problem, who is going >> to curate this stuff? As you mention below the information is of dubious >> value as it stands now. While the idea of including third party stuff on >> the site is noble, I have yet to see an actual plan to ensure that it is >> handled in a timely manner and with accuracy. > > There are several different ways to make sure this stuff is curated > correctly but that isn't the problem. At least not the immediate one. > The problem is a lack of leadership driving the content. Actually I think the problem is the other way around, too many leaders not enough worker bees. As has been pointed out in this thread a lot of the content already exists, it is just in various states of disrepair due to lack of hands to keep it up to date. Ideas are the easy part, implementing them is the hard part and I still see no framework to hang the content on or show of hands willing to due the grunt work of filling the framework. Until that happens this is only an interesting idea like the previous interesting ideas that take up basically defunct pages on the main site and the Wiki. Sorry for the buzz kill, but I have not seen anything that convinces me this latest idea will fair any better. > > Any project whether documentation, code, web, social etc... without > leadership is destined to fall by the wayside due to people focusing on > other things. > > Sincerely, > > JD > > > -- Adrian Klaver adrian.klaver@aklaver.com
On Fri, May 13, 2016 at 6:16 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, May 12, 2016 at 02:15:15PM -0700, Joshua Drake wrote: >> On 05/12/2016 02:02 PM, Justin Clift wrote: >> >On 12 May 2016, at 21:58, Bruce Momjian <bruce@momjian.us> wrote: >> >>On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: >> >>>On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: >> >> >>>>I think our wiki page that lists all the FDWs is great, so why can't we >> >>>>do this for other external software? >> >>>> >> >>>> https://wiki.postgresql.org/wiki/Foreign_data_wrappers >> >>> >> >>>That page does seem well put together. Guess the main question now is >> >>>"who will drive this initiative?" >> >> IMO: >> >> A much better solution is to rework the software catalogue to properly >> highly open source "projects" versus "products" and allow people to manage >> via a moderated interface their own listings. It will be consistent, provide >> a central place within the primary domain and be lower overhead than a wiki. > > The nice thing about a wiki is anyone can go in and improve it. As much as I can see from this thread, the original complain is a lack of visibility of external projects in the in-core docs. So why not updating the in-core docs to a wiki page in wiki.postgresql.org where those external projects are listed? Listing them by category is then up to the wiki, and not the in-core docs. -- Michael
On 12/05/2016 09:48, Joshua D. Drake wrote: > Hello, > > There has been a lot of back and forth about when we (as a community) > should advocate external projects as well as where we should advocate > external projects. It seems the more advocacy minded individuals would > like to be more inclusive whilst the -hackers and old school folks don't > want to bother with it at all (this is not exclusive, I know there are > exceptions). > > I think we need to come up with some guidelines. I have my own ideas of > what those should be: > > * Must be released under an OSI approved license > * Must have source downloadable without barrier (no registration > for example) There is one main fact about pglogical that makes it different to other projects that I haven't seen mentioned. As stated on http://2ndquadrant.com/en/resources/pglogical/ and in pglogicals README.md -- > pglogical is fully open source, released under the PostgreSQL licence > with copyright novated to the PostgreSQL Development Group Each source file contains - > * > * Copyright (c) 2015, PostgreSQL Global Development Group > * 2ndquadrent is only mentioned in the README as the source of initial development and testing. So if the code is owned by the PostgreSQL Global Development Group, is it an external project or an official project? Does the location of the source code repository define a project as unofficial or external? This could be a time to specify that PGDG will not accept copyright of external projects before they are accepted into the core repositories. What discussions/expectations have there been (on or off list) about the possibility of pglogical being accepted into core? How is the external development of pglogical different from any feature that is initially developed in a branch other than master in the official postgresql repository? At what point does a new feature change from being someone's personal project to a planned new core feature? -- Shane Ambler pgSQL (at) Sheeky (dot) Biz
On 05/12/2016 08:28 PM, Shane Ambler wrote: > > What discussions/expectations have there been (on or off list) about > the possibility of pglogical being accepted into core? The expectation is that it will be in core in the next major version, barring an unexpected halt to development. That's the reason why I was in favor of doing a "please test this" in the announcement. However, we ran out of time for discussion of that, and omitting it was the default choice without consensus. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
> From: pgsql-advocacy-owner@postgresql.org > On Thu, May 12, 2016 at 11:44:17AM -0400, Robert Haas wrote: > > Maybe we should just go stand up a wiki page to start. What's in the > > software catalog right now looks useless to me. > > I think our wiki page that lists all the FDWs is great, so why can't we > do this for other external software? That'a wonderful page, because users can not only know the existance of FDW but also get information on how to use them. But it seems to tell us the difficulty of maintaining the software and/or information on the software. The status of FDWfor JDBC/ODBC is described as follows... This description keeps people from adopting the JDBC/ODBC FDW. And we cannotknow whether it is still correct (JDBC/ODBC FDW may work with the latest PostgreSQL) nor how new it is. "Does not compile with PostgreSQL >= 9.2! " "A patched, but completely untested version " "Not maintained ? " Anyway, it's good to know that such a page exists. Similar software listings are scattered here and there. Maybe we arebetter off integrating those information in a single place. PGECons also has a commercial product listing on their website, which is in Japanese only. Community Guide to PostgreSQL GUI Tools https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Open Source Projects Using PostgreSQL https://wiki.postgresql.org/wiki/OpenSource_Projects_Using_PostgreSQL Regards Takayuki Tsunakawa
> From: pgsql-advocacy-owner@postgresql.org > On Thu, May 12, 2016 at 02:15:15PM -0700, Joshua Drake wrote: > > IMO: > > > > A much better solution is to rework the software catalogue to properly > > highly open source "projects" versus "products" and allow people to > > manage via a moderated interface their own listings. It will be > > consistent, provide a central place within the primary domain and be lower > overhead than a wiki. > > The nice thing about a wiki is anyone can go in and improve it. I'm not sure yet whether the current Software Catalog style or wiki is better, but can't we get both benefits? * Take the wiki style, which allows everyone to edit. * Place the link to the wiki page on the main web site. (The current location of the Software Catalog is not easy to find.) * To make the software entries look consistent, specify the entry format in the editing guideline page. Regards Takayuki Tsunakawa
> From: pgsql-advocacy-owner@postgresql.org > On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: > > That page does seem well put together. Guess the main question now is > > "who will drive this initiative?" > > Yep, it is a big job but would be a big win. I don't know how the community website is operated, and of course I'm not confident I can drive the initiative, but I'd behappy to do that. As I consulted you in pgsql-advocacy in the past two months, I want (and need) to visualize and expandPostgreSQL ecosystem. I'll consider the issues and approach. Could you give me your opinions and information on how I should start? Regards Takayuki Tsunakawa
Le 12.05.2016 22:58, Bruce Momjian a écrit : > On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: >> On 12 May 2016, at 21:24, Bruce Momjian <bruce@momjian.us> wrote: >> > On Thu, May 12, 2016 at 11:44:17AM -0400, Robert Haas wrote: >> >>> That's basically what the software catalogue does, isn't it? It needs to be >> >>> revamped to be more user friendly, and more promoted, but as a basis? >> >> >> >> Sure, that kind of idea. I'd forgotten we had that. I think that we >> >> should go to a format with just one line for each piece of software, >> >> though, instead of a big box. And try to get it all one one page. >> >> And remove all of the proprietary products or put them in a separate >> >> section. And include only stuff that's actually reasonably widely >> >> used. >> >> >> >> Maybe we should just go stand up a wiki page to start. What's in the >> >> software catalog right now looks useless to me. >> > >> > I think our wiki page that lists all the FDWs is great, so why can't we >> > do this for other external software? >> > >> > https://wiki.postgresql.org/wiki/Foreign_data_wrappers >> >> That page does seem well put together. Guess the main question now is >> "who will drive this initiative?" > > Yep, it is a big job but would be a big win. > hey guys, I don't have a strong opinion on this "external project advocacy" question so I'm remaining silent on this thread. However I've done some work on FDW page so here's my feedback about it : - First, in the long run it's not that much work really. The FDW wiki has 150 revisions over 6 years (see below) and I take approx. 1 hour every 2 month to refresh it... https://wiki.postgresql.org/index.php?title=Foreign_data_wrappers&offset=&limit=250&action=history - Second, Starting a page or reformating it the only big task. I launched a complete overhaul of the FDW page in 2015 (link below) and as much I recall I think it took me 5 or 6 hours over 1 month.... It's not very hard to do. You just need to have a good vision of the PostgreSQL community and spend time mostly on github to collect information on each project. The rest is just handling wiki syntax, which is an incredibly dull job but in the end it's ego-rewarding because you see the page growing step by step and it's a very positive effort :) http://www.postgresql.org/message-id/flat/55DB0C4F.1050508@dalibo.info#55DB0C4F.1050508@dalibo.info - Third, the format is everything. In general, wiki pages contain either too few (see link A ) or too much information (see link B). Finding the right balance is the key. A : https://wiki.postgresql.org/wiki/GUI_Database_Design_Tools B : https://wiki.postgresql.org/wiki/Monitoring My experience is that each wiki page that is "a list of things" needs to define 4 or 6 type of required information and apply the same format to each projet. In general, that would be : name + website + license + author + a **tiny** description. For anything else let the projet speak for itself and let the user find out the information he/she needs and evaluate the project. To be more concrete, once you've defined the 4-6 information required for each project, you can easily put it in a wiki table and new editors of the page will follow the same format, giving the whole page a simpler and cleaner look... You can even parse the wiki syntax if you want to extract stats from the page... - Four, yes this very different from the pg.org software catalog (link below) because the format is flexible (you can restructure the page if needed) and it's way more easier for anyone to edit/add/fix the page. http://www.postgresql.org/download/product-categories/ If some people are interested, maybe we can try starting a new wiki page ( providing a listing of all the extensions would be nice I think) or restructure an existing one ( the monitring page is a mess for instance ). However I won't be able to maintain it in the long run as I'm already involved on the FDW and forks pages... -- -- Damien Clochard
On 13 May 2016, at 08:05, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: >> From: pgsql-advocacy-owner@postgresql.org >> On Thu, May 12, 2016 at 09:46:25PM +0100, Justin Clift wrote: >>> That page does seem well put together. Guess the main question now is >>> "who will drive this initiative?" >> >> Yep, it is a big job but would be a big win. > > I don't know how the community website is operated, and of course I'm not confident I can drive the initiative, but I'dbe happy to do that. As I consulted you in pgsql-advocacy in the past two months, I want (and need) to visualize andexpand PostgreSQL ecosystem. > > I'll consider the issues and approach. Could you give me your opinions and information on how I should start? Generally the best way to get started with serious wiki editing is to create an account on the wiki itself, make sure you have Edit permission (so you can add/change content)... and then just start. Start anywhere you want, and branch out from there. With wiki editing, it's often a good idea to do a brain dump or initial notes first, and then go back to fix/revise/update/adjust the content until you are happy with it. Some people want everything to be perfect from their first edit. Don't do that. Just get the info on there however you want, then beat it into shape as needed. Damien's email, right after yours, gives some good advice too. Does that help enough to get you started? :) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On 13-05-2016 02:31, Josh berkus wrote: > That's the reason why I was in favor of doing a "please test this" in > the announcement. However, we ran out of time for discussion of that, > and omitting it was the default choice without consensus. > Why not a separate announce? "It is not in core" that was the most used argument. Instead, let's polish it and do a separate announce saying that it is target for 9.6+ and explain that we expect to incorporate that code in the next version. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On Thu, May 12, 2016 at 2:11 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > Agreed except under this definition: > > No other open source tool provides the solution. > > Right now for logical replication that uses the logical decoding API that > PostgreSQL provides there is exactly "1" solution and that is PgLogical. > That doesn't mean their aren't other Logical Replication solutions (Slony > for example) but nobody in their right mind can say that Slony is the better > choice for "standard master/slave" replication. Well, this is exactly why it's hard to reach agreement on what should be in a software catalog. pglogical hit version 1.0 just 15 days ago, and you're ready to say that anyone who thinks they might instead want to use a tool that's been in production use for 10 years is crazy. I'm going to say I disagree. I do not believe people using pglogical are crazy, and I don't believe people who are using Slony or Bucardo or Londiste are crazy either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 13/05/16 16:55, Robert Haas wrote: > On Thu, May 12, 2016 at 2:11 PM, Joshua D. Drake <jd@commandprompt.com> wrote: >> Agreed except under this definition: >> >> No other open source tool provides the solution. >> >> Right now for logical replication that uses the logical decoding API that >> PostgreSQL provides there is exactly "1" solution and that is PgLogical. >> That doesn't mean their aren't other Logical Replication solutions (Slony >> for example) but nobody in their right mind can say that Slony is the better >> choice for "standard master/slave" replication. > > Well, this is exactly why it's hard to reach agreement on what should > be in a software catalog. pglogical hit version 1.0 just 15 days ago, Pglogical reached 1.1 15 days ago, it was in 1.0 stage since sometime in January (mainly because it evolved from UDR which existed for more than a year before then). > and you're ready to say that anyone who thinks they might instead want > to use a tool that's been in production use for 10 years is crazy. > I'm going to say I disagree. I do not believe people using pglogical > are crazy, and I don't believe people who are using Slony or Bucardo > or Londiste are crazy either. Agreed. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 05/13/2016 06:04 AM, Euler Taveira wrote: > On 13-05-2016 02:31, Josh berkus wrote: >> That's the reason why I was in favor of doing a "please test this" in >> the announcement. However, we ran out of time for discussion of that, >> and omitting it was the default choice without consensus. >> > Why not a separate announce? "It is not in core" that was the most used > argument. Instead, let's polish it and do a separate announce saying > that it is target for 9.6+ and explain that we expect to incorporate > that code in the next version. > > Well, I was planning on that too, but 2Q did their own announcement. -- -- Josh Berkus Red Hat OSAS (any opinions are my own)
On Fri, May 13, 2016 at 1:05 PM, Petr Jelinek <petr@2ndquadrant.com> wrote: > Pglogical reached 1.1 15 days ago, it was in 1.0 stage since sometime in > January (mainly because it evolved from UDR which existed for more than a > year before then). Huh, I guess I misread the tag on the github repository. Sorry 'bout that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Hello, Damien and Justin, Thank you for giving me your experience and advice. I'll check them and consider the framework. As Adrian pointed out, the biggest challenge should be the framework to maintain the pages, especially the shortage of workerbees. I'm willing to be one of those worker bees, but I don't want to be the only bee. I hope I could know any successfulcommunity which keeps their ecosystem info up-to-date. Regards Takayuki Tsunakawa
On 17 May 2016, at 01:52, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: > Hello, Damien and Justin, > > Thank you for giving me your experience and advice. I'll check them and consider the framework. > > As Adrian pointed out, the biggest challenge should be the framework to maintain the pages, especially the shortage ofworker bees. I'm willing to be one of those worker bees, but I don't want to be the only bee. I hope I could know anysuccessful community which keeps their ecosystem info up-to-date. Qt seems to, if that helps. :) + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Hello, I've created a wiki page to list software interoperable with PostgreSQL. https://wiki.postgresql.org/wiki/Ecosystem:PostgreSQL_ecosystem I'd like to hear opinions on the items and appearance. For a sample entry, click "Data integration" under "Software exclusivelyfor PostgreSQL" section. Advice on refinement of English expression is also appreciated, as I'm not fluent inEnglish. The page is presently almost empty. After soliciting the opinions on the page, I'll start adding software entries. I identifiedabout 280 products that is or is likely to be interoperable with PostgreSQL, and publicize the wiki page on pgsql-advocacyand Planet PostgreSQL. Then, I'll try actually running the software with the latest PostgreSQL (now 9.5). I could not figure out a clever idea on how to keep the information fresh effectively. But I'll give it a try by becomingthe work bee... I'll also collect software from the following existing pages. But I will exclude software which I think is old or less usefull. One of such software would be phpPgAdmin, which is not released for nearly three years and expected to be substitutedwith pgAdmin 4. SoftwareCatalog http://www.postgresql.org/download/product-categories/ Clustering https://wiki.postgresql.org/wiki/Clustering Replication, Clustering, and Connection Pooling https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling Monitoring https://wiki.postgresql.org/wiki/Monitoring GUI Database Design Tools https://wiki.postgresql.org/wiki/GUI_Database_Design_Tools Community Guide to PostgreSQL GUI Tools https://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools Database Administration, Reporting, and Light application development http://www.postgresonline.com/journal/index.php?/archives/133-Database-Administration,-Reporting,-and-Light-application-development.html Test Frameworks https://wiki.postgresql.org/wiki/Test_Frameworks The exception is the foreign data wrappers. I just made a link to the following page. Foreign data wrappers https://wiki.postgresql.org/wiki/Foreign_data_wrappers Regards Takayuki Tsunakawa
From: Tsunakawa, Takayuki/綱川 貴之 > I've created a wiki page to list software interoperable with PostgreSQL. > > https://wiki.postgresql.org/wiki/Ecosystem:PostgreSQL_ecosystem > > I'd like to hear opinions on the items and appearance. For a sample entry, > click "Data integration" under "Software exclusively for PostgreSQL" > section. Advice on refinement of English expression is also appreciated, > as I'm not fluent in English. > > The page is presently almost empty. After soliciting the opinions on the > page, I'll start adding software entries. I identified about 280 products > that is or is likely to be interoperable with PostgreSQL, and publicize > the wiki page on pgsql-advocacy and Planet PostgreSQL. Then, I'll try > actually running the software with the latest PostgreSQL (now 9.5). > > I could not figure out a clever idea on how to keep the information fresh > effectively. But I'll give it a try by becoming the work bee... Status update. I listed about 280 software products that are likely to interoperate with PostgreSQL. I verified 8 products by running theirregression tests (Distributed cache, ORM for Java), and added information for 4 products without running the software(Mail). I'll continue to verify other software and fill in the entries. Then I'd like to make other 500 productsto interoperate with PostgreSQL. But I don't know how long this will take... I want to solicit for cooperation. I'm going to ask for help here in Japan. RegardsT Takayuki Tsunakawa
On 28 Oct 2016, at 04:13, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote: <snip> > Status update. > > I listed about 280 software products that are likely to interoperate with PostgreSQL. I verified 8 products by runningtheir regression tests (Distributed cache, ORM for Java), and added information for 4 products without running thesoftware (Mail). I'll continue to verify other software and fill in the entries. Then I'd like to make other 500 productsto interoperate with PostgreSQL. > > But I don't know how long this will take... I want to solicit for cooperation. I'm going to ask for help here in Japan. This is heroic effort! Well done! :D Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi