Thread: New mailing list?
Hi folks I'm hoping to apply for a new mailing list hosted on the .org infrastructure, a project list "bdr-users", for the bi-directional replication project. Is -www the right place to ask? -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 06/19/2014 11:16 AM, Craig Ringer wrote: > Hi folks > > I'm hoping to apply for a new mailing list hosted on the .org > infrastructure, a project list "bdr-users", for the bi-directional > replication project. hmm why would we need a mailinglist for a specific feature, we dont have lists for other features either. So what would be "on topic" on that list that does not fit others? > > Is -www the right place to ask? its fine to ask here Stefan
On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote: > On 06/19/2014 11:16 AM, Craig Ringer wrote: >> Hi folks >> >> I'm hoping to apply for a new mailing list hosted on the .org >> infrastructure, a project list "bdr-users", for the bi-directional >> replication project. > > hmm why would we need a mailinglist for a specific feature, we dont have > lists for other features either. So what would be "on topic" on that > list that does not fit others? BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and parts have been merged already. However, the patch is ready for real world use now, and requires only very minimal changes to 9.4 - sufficiently so that it'll shortly have a script to just convert a 9.4 datadir for use with the BDR patch, or vice versa. Given the level of user interest I've been seeing I'd like to have somewhere for users to communicate about it, discuss it, report issues, etc, so that we have a much more solid feature for merging into 9.5 and 9.6. I'm aware of people who intend to put this into production, not just test with it, so there'll be more than just some chat about it on -hackers. While it's possible to just use -hackers and -general, there'll be a group of people running a separate patchset and it might get confusing. Hence the request for a bdr-users list. Also, -hackers discussion will be more concerned with individual parts of BDR to be merged, not with the operation of the as-yet-uncommitted parts. I'm not sure a bunch of extra discussion about BDR would be entirely welcome, and it might detract from the focus on the bits that need merging in any given release cycle. Because this _is_ a feature that's aimed at being 100% merged into PostgreSQL, and _not_ a "new product" or fork, I'd strongly prefer to keep any such mailing list on the postgresql.org infrastructure where it's discoverable and clearly part of PostgreSQL. But, because it's also likely to take a while to get it fully merged, I'd like to provide somewhere for people using it to keep an eye on things and discuss it. Thoughts? -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Jun 20, 2014 at 3:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote: >> On 06/19/2014 11:16 AM, Craig Ringer wrote: >>> Hi folks >>> >>> I'm hoping to apply for a new mailing list hosted on the .org >>> infrastructure, a project list "bdr-users", for the bi-directional >>> replication project. >> >> hmm why would we need a mailinglist for a specific feature, we dont have >> lists for other features either. So what would be "on topic" on that >> list that does not fit others? > > BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and > parts have been merged already. > > However, the patch is ready for real world use now, and requires only > very minimal changes to 9.4 - sufficiently so that it'll shortly have a > script to just convert a 9.4 datadir for use with the BDR patch, or vice > versa. > > Given the level of user interest I've been seeing I'd like to have > somewhere for users to communicate about it, discuss it, report issues, > etc, so that we have a much more solid feature for merging into 9.5 and > 9.6. I'm aware of people who intend to put this into production, not > just test with it, so there'll be more than just some chat about it on > -hackers. We've traditionally shied away from having per-feature mailing lists as they end up fragmenting discussion, and typically most of the interested parties are on both lists anyway. In a (very) recent discussion on -core on the topic of having feature lists, it was very clear that it is not something the majority of us want to do. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2014-06-20 08:59:52 +0100, Dave Page wrote: > On Fri, Jun 20, 2014 at 3:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > > On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote: > >> On 06/19/2014 11:16 AM, Craig Ringer wrote: > >>> Hi folks > >>> > >>> I'm hoping to apply for a new mailing list hosted on the .org > >>> infrastructure, a project list "bdr-users", for the bi-directional > >>> replication project. > >> > >> hmm why would we need a mailinglist for a specific feature, we dont have > >> lists for other features either. So what would be "on topic" on that > >> list that does not fit others? > > > > BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and > > parts have been merged already. > > > > However, the patch is ready for real world use now, and requires only > > very minimal changes to 9.4 - sufficiently so that it'll shortly have a > > script to just convert a 9.4 datadir for use with the BDR patch, or vice > > versa. > > > > Given the level of user interest I've been seeing I'd like to have > > somewhere for users to communicate about it, discuss it, report issues, > > etc, so that we have a much more solid feature for merging into 9.5 and > > 9.6. I'm aware of people who intend to put this into production, not > > just test with it, so there'll be more than just some chat about it on > > -hackers. > > We've traditionally shied away from having per-feature mailing lists > as they end up fragmenting discussion, and typically most of the > interested parties are on both lists anyway. In a (very) recent > discussion on -core on the topic of having feature lists, it was very > clear that it is not something the majority of us want to do. But it's not really a 'per feature' mailing list. BDR is a PGDG licenced extension (including some patches to postgres) that allows to do logical replication, including multimaster, today. Using 9.4. I doubt an eventual in-core facility will have the same UI, so BDR will continue to live for a while independently anyway. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Jun 20, 2014 at 9:14 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-06-20 08:59:52 +0100, Dave Page wrote: >> On Fri, Jun 20, 2014 at 3:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote: >> > On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote: >> >> On 06/19/2014 11:16 AM, Craig Ringer wrote: >> >>> Hi folks >> >>> >> >>> I'm hoping to apply for a new mailing list hosted on the .org >> >>> infrastructure, a project list "bdr-users", for the bi-directional >> >>> replication project. >> >> >> >> hmm why would we need a mailinglist for a specific feature, we dont have >> >> lists for other features either. So what would be "on topic" on that >> >> list that does not fit others? >> > >> > BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and >> > parts have been merged already. >> > >> > However, the patch is ready for real world use now, and requires only >> > very minimal changes to 9.4 - sufficiently so that it'll shortly have a >> > script to just convert a 9.4 datadir for use with the BDR patch, or vice >> > versa. >> > >> > Given the level of user interest I've been seeing I'd like to have >> > somewhere for users to communicate about it, discuss it, report issues, >> > etc, so that we have a much more solid feature for merging into 9.5 and >> > 9.6. I'm aware of people who intend to put this into production, not >> > just test with it, so there'll be more than just some chat about it on >> > -hackers. >> >> We've traditionally shied away from having per-feature mailing lists >> as they end up fragmenting discussion, and typically most of the >> interested parties are on both lists anyway. In a (very) recent >> discussion on -core on the topic of having feature lists, it was very >> clear that it is not something the majority of us want to do. > > But it's not really a 'per feature' mailing list. BDR is a PGDG licenced > extension (including some patches to postgres) that allows to do logical > replication, including multimaster, today. Using 9.4. I doubt an > eventual in-core facility will have the same UI, so BDR will continue to > live for a while independently anyway. That seems to be somewhat at odds with Craig's justification - at least as I read it - where he seems to be saying that the purpose of the list is to refine the design for inclusion in 9.5/9.6. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2014-06-20 09:28:46 +0100, Dave Page wrote: > On Fri, Jun 20, 2014 at 9:14 AM, Andres Freund <andres@2ndquadrant.com> wrote: > > On 2014-06-20 08:59:52 +0100, Dave Page wrote: > >> On Fri, Jun 20, 2014 at 3:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > >> > On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote: > >> >> On 06/19/2014 11:16 AM, Craig Ringer wrote: > >> >>> Hi folks > >> >>> > >> >>> I'm hoping to apply for a new mailing list hosted on the .org > >> >>> infrastructure, a project list "bdr-users", for the bi-directional > >> >>> replication project. > >> >> > >> >> hmm why would we need a mailinglist for a specific feature, we dont have > >> >> lists for other features either. So what would be "on topic" on that > >> >> list that does not fit others? > >> > > >> > BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and > >> > parts have been merged already. > >> > > >> > However, the patch is ready for real world use now, and requires only > >> > very minimal changes to 9.4 - sufficiently so that it'll shortly have a > >> > script to just convert a 9.4 datadir for use with the BDR patch, or vice > >> > versa. > >> > > >> > Given the level of user interest I've been seeing I'd like to have > >> > somewhere for users to communicate about it, discuss it, report issues, > >> > etc, so that we have a much more solid feature for merging into 9.5 and > >> > 9.6. I'm aware of people who intend to put this into production, not > >> > just test with it, so there'll be more than just some chat about it on > >> > -hackers. > >> > >> We've traditionally shied away from having per-feature mailing lists > >> as they end up fragmenting discussion, and typically most of the > >> interested parties are on both lists anyway. In a (very) recent > >> discussion on -core on the topic of having feature lists, it was very > >> clear that it is not something the majority of us want to do. > > > > But it's not really a 'per feature' mailing list. BDR is a PGDG licenced > > extension (including some patches to postgres) that allows to do logical > > replication, including multimaster, today. Using 9.4. I doubt an > > eventual in-core facility will have the same UI, so BDR will continue to > > live for a while independently anyway. > > That seems to be somewhat at odds with Craig's justification - at > least as I read it - where he seems to be saying that the purpose of > the list is to refine the design for inclusion in 9.5/9.6. Yes, we want all the features in core. But given how postgresql development works it neither will be integrated tomorrow nor will it look exactly what we already have right now. So having something ready now is rather worthwile - and that's what we've done. There already have been people asking questions about BDR on -hackers and on -bugs. That's not been, say, welcomed with open arms, since the majority of the audience there won't be interested in that. This list is supposed to be about the usage and bugs in bdr. The design of the in-core facilities should (and will) happen on -hackers just like the logical decoding facilities et al were designed there. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Jun 20, 2014 at 9:37 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-06-20 09:28:46 +0100, Dave Page wrote: >> On Fri, Jun 20, 2014 at 9:14 AM, Andres Freund <andres@2ndquadrant.com> wrote: >> > On 2014-06-20 08:59:52 +0100, Dave Page wrote: >> >> On Fri, Jun 20, 2014 at 3:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote: >> >> > On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote: >> >> >> On 06/19/2014 11:16 AM, Craig Ringer wrote: >> >> >>> Hi folks >> >> >>> >> >> >>> I'm hoping to apply for a new mailing list hosted on the .org >> >> >>> infrastructure, a project list "bdr-users", for the bi-directional >> >> >>> replication project. >> >> >> >> >> >> hmm why would we need a mailinglist for a specific feature, we dont have >> >> >> lists for other features either. So what would be "on topic" on that >> >> >> list that does not fit others? >> >> > >> >> > BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and >> >> > parts have been merged already. >> >> > >> >> > However, the patch is ready for real world use now, and requires only >> >> > very minimal changes to 9.4 - sufficiently so that it'll shortly have a >> >> > script to just convert a 9.4 datadir for use with the BDR patch, or vice >> >> > versa. >> >> > >> >> > Given the level of user interest I've been seeing I'd like to have >> >> > somewhere for users to communicate about it, discuss it, report issues, >> >> > etc, so that we have a much more solid feature for merging into 9.5 and >> >> > 9.6. I'm aware of people who intend to put this into production, not >> >> > just test with it, so there'll be more than just some chat about it on >> >> > -hackers. >> >> >> >> We've traditionally shied away from having per-feature mailing lists >> >> as they end up fragmenting discussion, and typically most of the >> >> interested parties are on both lists anyway. In a (very) recent >> >> discussion on -core on the topic of having feature lists, it was very >> >> clear that it is not something the majority of us want to do. >> > >> > But it's not really a 'per feature' mailing list. BDR is a PGDG licenced >> > extension (including some patches to postgres) that allows to do logical >> > replication, including multimaster, today. Using 9.4. I doubt an >> > eventual in-core facility will have the same UI, so BDR will continue to >> > live for a while independently anyway. >> >> That seems to be somewhat at odds with Craig's justification - at >> least as I read it - where he seems to be saying that the purpose of >> the list is to refine the design for inclusion in 9.5/9.6. > > Yes, we want all the features in core. But given how postgresql > development works it neither will be integrated tomorrow nor will it > look exactly what we already have right now. So having something ready > now is rather worthwile - and that's what we've done. > > There already have been people asking questions about BDR on -hackers > and on -bugs. That's not been, say, welcomed with open arms, since the > majority of the audience there won't be interested in that. > > This list is supposed to be about the usage and bugs in bdr. The design > of the in-core facilities should (and will) happen on -hackers just like > the logical decoding facilities et al were designed there. That certainly makes more sense. We do have other projects with their own lists (like pgAdmin of course), so I have no problem with that in general. My only concern is that this would be a relatively short-lived list. Interested to hear what others think... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 2014-06-20 09:44:17 +0100, Dave Page wrote: > My only concern is that this would be a relatively short-lived list. Hehe, 9.5, 9.6 aren't that close from my POV :). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Jun 20, 2014 at 9:47 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On 2014-06-20 09:44:17 +0100, Dave Page wrote: >> My only concern is that this would be a relatively short-lived list. > > Hehe, 9.5, 9.6 aren't that close from my POV :). Ahh, you youngsters :-). The pgAdmin hackers list is approaching its 13th birthday! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 06/20/2014 10:44 AM, Dave Page wrote:
> On Fri, Jun 20, 2014 at 9:37 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>> On 2014-06-20 09:28:46 +0100, Dave Page wrote:
>>> On Fri, Jun 20, 2014 at 9:14 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>>>> On 2014-06-20 08:59:52 +0100, Dave Page wrote:
>>>>> On Fri, Jun 20, 2014 at 3:06 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>>>>>> On 06/20/2014 01:12 AM, Stefan Kaltenbrunner wrote:
>>>>>>> On 06/19/2014 11:16 AM, Craig Ringer wrote:
>>>>>>>> Hi folks
>>>>>>>>
>>>>>>>> I'm hoping to apply for a new mailing list hosted on the .org
>>>>>>>> infrastructure, a project list "bdr-users", for the bi-directional
>>>>>>>> replication project.
>>>>>>>
>>>>>>> hmm why would we need a mailinglist for a specific feature, we dont have
>>>>>>> lists for other features either. So what would be "on topic" on that
>>>>>>> list that does not fit others?
>>>>>>
>>>>>> BDR is on track to be a feature in PostgreSQL core - in 9.5 or 9.6 - and
>>>>>> parts have been merged already.
>>>>>>
>>>>>> However, the patch is ready for real world use now, and requires only
>>>>>> very minimal changes to 9.4 - sufficiently so that it'll shortly have a
>>>>>> script to just convert a 9.4 datadir for use with the BDR patch, or vice
>>>>>> versa.
>>>>>>
>>>>>> Given the level of user interest I've been seeing I'd like to have
>>>>>> somewhere for users to communicate about it, discuss it, report issues,
>>>>>> etc, so that we have a much more solid feature for merging into 9.5 and
>>>>>> 9.6. I'm aware of people who intend to put this into production, not
>>>>>> just test with it, so there'll be more than just some chat about it on
>>>>>> -hackers.
>>>>>
>>>>> We've traditionally shied away from having per-feature mailing lists
>>>>> as they end up fragmenting discussion, and typically most of the
>>>>> interested parties are on both lists anyway. In a (very) recent
>>>>> discussion on -core on the topic of having feature lists, it was very
>>>>> clear that it is not something the majority of us want to do.
>>>>
>>>> But it's not really a 'per feature' mailing list. BDR is a PGDG licenced
>>>> extension (including some patches to postgres) that allows to do logical
>>>> replication, including multimaster, today. Using 9.4. I doubt an
>>>> eventual in-core facility will have the same UI, so BDR will continue to
>>>> live for a while independently anyway.
>>>
>>> That seems to be somewhat at odds with Craig's justification - at
>>> least as I read it - where he seems to be saying that the purpose of
>>> the list is to refine the design for inclusion in 9.5/9.6.
>>
>> Yes, we want all the features in core. But given how postgresql
>> development works it neither will be integrated tomorrow nor will it
>> look exactly what we already have right now. So having something ready
>> now is rather worthwile - and that's what we've done.
>>
>> There already have been people asking questions about BDR on -hackers
>> and on -bugs. That's not been, say, welcomed with open arms, since the
>> majority of the audience there won't be interested in that.
>>
>> This list is supposed to be about the usage and bugs in bdr. The design
>> of the in-core facilities should (and will) happen on -hackers just like
>> the logical decoding facilities et al were designed there.
>
> That certainly makes more sense. We do have other projects with their
> own lists (like pgAdmin of course), so I have no problem with that in
> general. My only concern is that this would be a relatively
> short-lived list.
>
> Interested to hear what others think...
well I'm skeptic on the general idea of doing short lived lists and I
dont think pgadmin is a good example because it is an entirely seperate
project.
The only references we have that seems close enough to the "long term
project will take years to integrate" thing that bdr-users seems to be
wanted for is more like pgsql-hackers-pitr (seems like thise one was a
failure in terms of uptake/use), pgsql-ports (long running eventually
folded into -hackers) and hackers-win32(fairly active at times).
However all of those were -hacker related lists not user related ones
and I think having bdr-users will confuse people over time ("should I
ask something there or on -general?" or "where to report a bug?") as
features get moved/folded into main postgresql or changed and people are
not sure whether they use a patch-set or the version in upstream.
Could we see what the proposed "description" of that list would be(as in
second column of: http://www.postgresql.org/list/)?
Stefan
Hi,
On 2014-06-20 15:22:00 +0200, Stefan Kaltenbrunner wrote:
> well I'm skeptic on the general idea of doing short lived lists and I
> dont think pgadmin is a good example because it is an entirely seperate
> project.
> The only references we have that seems close enough to the "long term
> project will take years to integrate" thing that bdr-users seems to be
> wanted for is more like pgsql-hackers-pitr (seems like thise one was a
> failure in terms of uptake/use), pgsql-ports (long running eventually
> folded into -hackers) and hackers-win32(fairly active at times).
I don't think bdr-users can well be compared with those development
lists - BDR as is is something that can actually be used by users. It's
much more like psycopg (and yes, pgadmin) or such lists.
> However all of those were -hacker related lists not user related ones
> and I think having bdr-users will confuse people over time ("should I
> ask something there or on -general?" or "where to report a bug?") as
> features get moved/folded into main postgresql or changed and people are
> not sure whether they use a patch-set or the version in upstream.
I don't think the core feature will end up being named BDR - for pretty
much that reason...
It might also be important to know that 90% of the code in bdr isn't
patching postgres, but just extension code using existing
facilities. That part isn't gone super fast just because the patches
have been merged. At some point BDR won't be better than what's in core,
and then users will stop using it.
> Could we see what the proposed "description" of that list would be(as in
> second column of: http://www.postgresql.org/list/)?
I'd list it among the 'Project Lists'. Something like 'User oriented
list for the BDR replication project. Both bug reports and questions
about BDR are appriate.'.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
On 06/20/2014 04:28 PM, Andres Freund wrote:
> Hi,
>
> On 2014-06-20 15:22:00 +0200, Stefan Kaltenbrunner wrote:
>> well I'm skeptic on the general idea of doing short lived lists and I
>> dont think pgadmin is a good example because it is an entirely seperate
>> project.
>
>> The only references we have that seems close enough to the "long term
>> project will take years to integrate" thing that bdr-users seems to be
>> wanted for is more like pgsql-hackers-pitr (seems like thise one was a
>> failure in terms of uptake/use), pgsql-ports (long running eventually
>> folded into -hackers) and hackers-win32(fairly active at times).
>
> I don't think bdr-users can well be compared with those development
> lists - BDR as is is something that can actually be used by users. It's
> much more like psycopg (and yes, pgadmin) or such lists.
yeah but in the end it is going to be used for something that
will/should in some form (or name) or another end up in -core which
neither psycopg or pgadmin ever will or are aiming for...
>
>> However all of those were -hacker related lists not user related ones
>> and I think having bdr-users will confuse people over time ("should I
>> ask something there or on -general?" or "where to report a bug?") as
>> features get moved/folded into main postgresql or changed and people are
>> not sure whether they use a patch-set or the version in upstream.
>
> I don't think the core feature will end up being named BDR - for pretty
> much that reason...
> It might also be important to know that 90% of the code in bdr isn't
> patching postgres, but just extension code using existing
> facilities. That part isn't gone super fast just because the patches
> have been merged. At some point BDR won't be better than what's in core,
> and then users will stop using it.
could be - I however still predict that people will be confused but time
will tell...
>
>> Could we see what the proposed "description" of that list would be(as in
>> second column of: http://www.postgresql.org/list/)?
>
> I'd list it among the 'Project Lists'. Something like 'User oriented
> list for the BDR replication project. Both bug reports and questions
> about BDR are appriate.'.
s/appriate/appropriate I assume ;)
I think in the end this ties down to how far we want or should go in
providing mailinglist services in general to projects in the wider
postgresql.org ecosystem and if "yes" in what way...
Anyway for this request I still dont think it is a good idea but given
nobody else seems to share my concerns I wont object further.
Stefan
On 06/20/2014 05:39 PM, Stefan Kaltenbrunner wrote: > I think in the end this ties down to how far we want or should go in > providing mailinglist services in general to projects in the wider > postgresql.org ecosystem and if "yes" in what way... > > Anyway for this request I still dont think it is a good idea but given > nobody else seems to share my concerns I wont object further. I also do not believe it is a good idea and cast my vote against it. -- Vik
On 06/20/2014 12:59 AM, Dave Page wrote: >> However, the patch is ready for real world use now, and requires only >> very minimal changes to 9.4 - sufficiently so that it'll shortly have a >> script to just convert a 9.4 datadir for use with the BDR patch, or vice >> versa. >> >> Given the level of user interest I've been seeing I'd like to have >> somewhere for users to communicate about it, discuss it, report issues, >> etc, so that we have a much more solid feature for merging into 9.5 and >> 9.6. I'm aware of people who intend to put this into production, not >> just test with it, so there'll be more than just some chat about it on >> -hackers. > > We've traditionally shied away from having per-feature mailing lists > as they end up fragmenting discussion, and typically most of the > interested parties are on both lists anyway. In a (very) recent > discussion on -core on the topic of having feature lists, it was very > clear that it is not something the majority of us want to do. True, but this is different. This is in some sense a separate project from core (for now) and as it is usable now, the users will be different. I don't see many -hackers caring a whole lot about this list except those that are doing the actual development. What this list will do is reduce noise for people wanting to help in the dogfooding of this feature. I am a +1 for a short lived (~ 2 years) dogfood list for this feature. JD -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, @cmdpromptinc "If we send our children to Caesar for their education, we should not be surprised when they come back as Romans."
On 06/20/2014 08:39 AM, Stefan Kaltenbrunner wrote: > I think in the end this ties down to how far we want or should go in > providing mailinglist services in general to projects in the wider > postgresql.org ecosystem and if "yes" in what way... So when WWW decided to de-support pgFoundry, one of the services which pgFoundry was supplying which was discontinued is having mailing lists for satellite projects for PostgreSQL. At the time we made that decision, several people on this list gave the impression that mailing lists would be created more liberally in the future in order to pick up the slack. However, that is not what has happened. Every time someone has requested a new mailing list here they've had to extensively justify their request for the list. The impression I get is that there's a lot of support infrastructure associated with each list for the infra team, which is fueling their objections. However, the result is that people who were enthusiastic about doing something with PostgreSQL get frustrated and discouraged, or go off and set up a forum on some website not even associated with postgresql.org, making it hard/impossible for users to find. At this point, I have active lists still running on Marc's pgfoundry because I've been discouraged from moving them over. If adding new lists to majordomo is painful (and I can imagine it might be), can we please set up a low-SLA mailman instance somewhere on postgresql.org so that every list request doesn't have to turn into an argument? If this is a PITA for the infra team, can we ask OSUOSL for one? > Anyway for this request I still dont think it is a good idea but given > nobody else seems to share my concerns I wont object further. Personally, I have enough trust in Craig/Andres that if they say they need a list, they need a list. And if the list doesn't get used, it'll be shut down. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Josh,
* Josh Berkus (josh@agliodbs.com) wrote:
> On 06/20/2014 08:39 AM, Stefan Kaltenbrunner wrote:
> > I think in the end this ties down to how far we want or should go in
> > providing mailinglist services in general to projects in the wider
> > postgresql.org ecosystem and if "yes" in what way...
>
> So when WWW decided to de-support pgFoundry, one of the services which
> pgFoundry was supplying which was discontinued is having mailing lists
> for satellite projects for PostgreSQL. At the time we made that
> decision, several people on this list gave the impression that mailing
> lists would be created more liberally in the future in order to pick up
> the slack.
I wasn't here for that, but I find it to be, generally, a good thing
that there is a discussion regarding the need for a list, rather than
just rubber-stamping or automating the process.
> However, that is not what has happened. Every time someone has
> requested a new mailing list here they've had to extensively justify
> their request for the list. The impression I get is that there's a lot
> of support infrastructure associated with each list for the infra team,
> which is fueling their objections. However, the result is that people
> who were enthusiastic about doing something with PostgreSQL get
> frustrated and discouraged, or go off and set up a forum on some website
> not even associated with postgresql.org, making it hard/impossible for
> users to find.
This happens *just as much* (if not more..) for users who find an
inactive and/or useless list. We have -general for a reason and I would
argue that we should be happier about having individuals discuss things
on that list and only look to create an alternative list when the
traffic for that specific topic has enough traffic to warrent it.
> At this point, I have active lists still running on Marc's pgfoundry
> because I've been discouraged from moving them over.
Are they active? Which ones are they? I don't think anyone has a
problem with moving actually active lists over- but what we ware not
interested in supporting are 100 lists which all get less than one email
a month. It becomes a real headache which simply isn't worth it.
> If adding new lists to majordomo is painful (and I can imagine it might
> be), can we please set up a low-SLA mailman instance somewhere on
> postgresql.org so that every list request doesn't have to turn into an
> argument? If this is a PITA for the infra team, can we ask OSUOSL for one?
OSUOSL has not been a good source of resources for us. We have tried
(I've spoken with Lance personally a couple of times) and they are more
overwhelmed than we are, generally speaking. Email, sadly, is a time
consuming business to be in.
> > Anyway for this request I still dont think it is a good idea but given
> > nobody else seems to share my concerns I wont object further.
>
> Personally, I have enough trust in Craig/Andres that if they say they
> need a list, they need a list. And if the list doesn't get used, it'll
> be shut down.
This *does not happen*. Look at all of the PUG lists which we have and
can't be shut down because someone, somewhere, might email them some day
(and end up, most likely, not getting any reply- but that doesn't
matter). The idea that mailing lists somehow provide "validation" for a
project simply needs to stop- it doesn't and it's better to have an
active-but-busy list with a lot of different discussions than lots of
low/no-traffic lists where people ask for help and get zero responses
back.
Thanks,
Stephen
On 06/24/2014 05:55 PM, Stephen Frost wrote: > OSUOSL has not been a good source of resources for us. We have tried > (I've spoken with Lance personally a couple of times) and they are more > overwhelmed than we are, generally speaking. Email, sadly, is a time > consuming business to be in. Oh, too bad. This is also probably why most third parties have stopped supplying ML support for communities. >> Personally, I have enough trust in Craig/Andres that if they say they >> need a list, they need a list. And if the list doesn't get used, it'll >> be shut down. > > This *does not happen*. Look at all of the PUG lists which we have and > can't be shut down because someone, somewhere, might email them some day > (and end up, most likely, not getting any reply- but that doesn't > matter). Point taken. It's hard to kill off lists which are largely traffic-free today for political reasons. Maybe we should have an auto-kill so that it doesn't have to be discussed? > The idea that mailing lists somehow provide "validation" for a > project simply needs to stop- it doesn't and it's better to have an > active-but-busy list with a lot of different discussions than lots of > low/no-traffic lists where people ask for help and get zero responses > back. That depends on the purposes of those lists. Sometimes somebody just wants to collaborate with others without the "noise" of hackers or general, including collaborating with people who aren't interested in joining a 100-post-per-day mailing list because their interest in PostgreSQL is fairly peripheral and specific. For example, with the pgsql-pkg-docker mailing list I just requested, I need to invite a couple folks from the docker project who will NOT join -hackers because they mainly work on docker. In that particular case, a more general pgsql-pkg mailing list would be fine -- it just needs to be something low-traffic. The alternative is for all of these folks to leave the postgresql.org infrastructure, which may be a win for the infra team, but it's not a win for the community. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
* Josh Berkus (josh@agliodbs.com) wrote:
> > This *does not happen*. Look at all of the PUG lists which we have and
> > can't be shut down because someone, somewhere, might email them some day
> > (and end up, most likely, not getting any reply- but that doesn't
> > matter).
>
> Point taken. It's hard to kill off lists which are largely traffic-free
> today for political reasons. Maybe we should have an auto-kill so that
> it doesn't have to be discussed?
Generally, I like the idea. Sadly, it's not straight-forward to
implement, and it's fraught with danger of a political sense. Far
better to avoid creating them in the first place (though, I agree, it'd
be great if we could create and remove them at need...). We also get
push-back from community members for new lists (many of the folks on
-hackers don't want to be on *another* list, but if we put up one for a
popular feature, they're going to feel obligated to also be on that
list..).
> > The idea that mailing lists somehow provide "validation" for a
> > project simply needs to stop- it doesn't and it's better to have an
> > active-but-busy list with a lot of different discussions than lots of
> > low/no-traffic lists where people ask for help and get zero responses
> > back.
>
> That depends on the purposes of those lists. Sometimes somebody just
> wants to collaborate with others without the "noise" of hackers or
> general, including collaborating with people who aren't interested in
> joining a 100-post-per-day mailing list because their interest in
> PostgreSQL is fairly peripheral and specific.
There are very few cases where I've seen this work. I'm not saying it's
a great situation, but you're essentially asking someone else to filter
and sort your emails for you into the right email boxes that work for
you- and, really, that's just rock mangagement. No one can know exactly
what you're interested in and what's relevant to you. Things on
-hackers could be very relevant to BDR, but are discussed on -hackers
instead of some BDR list for a variety of reasons. Perhaps someone will
think to include the bdr list, but I tend to doubt that's how it'll end
up happening.
> For example, with the pgsql-pkg-docker mailing list I just requested, I
> need to invite a couple folks from the docker project who will NOT join
> -hackers because they mainly work on docker. In that particular case, a
> more general pgsql-pkg mailing list would be fine -- it just needs to be
> something low-traffic.
Perhaps that would work for the specifics of how PG is packaged for
docker (though I have my doubts- ALTER SYSTEM is a capability that
packagers should be very interested in understanding and dealing with,
but we have not gotten nearly the interest around that feature from
packagers as I would have hoped.. It's starting to happen now, with a
new release coming, but it's really far later than some of these
discussions should have happened; and I don't think posting about these
things to the packagers list would have helped, but even if it would
have, no one *did*...).
> The alternative is for all of these folks to leave the postgresql.org
> infrastructure, which may be a win for the infra team, but it's not a
> win for the community.
Yeah, I'm really not buying off on this. Their alternative should be to
use an existing list rather than pollluting the pg.org namespace with
lists for every little thing. If they go off and create their
not-popular and not-used list on another provider, well, I don't think
the community or anyone else really ends up losing out on much of
anything.
Thanks,
Stephen
On Wed, Jun 25, 2014 at 1:21 AM, Josh Berkus <josh@agliodbs.com> wrote: > On 06/20/2014 08:39 AM, Stefan Kaltenbrunner wrote: >> I think in the end this ties down to how far we want or should go in >> providing mailinglist services in general to projects in the wider >> postgresql.org ecosystem and if "yes" in what way... > > So when WWW decided to de-support pgFoundry, one of the services which > pgFoundry was supplying which was discontinued is having mailing lists > for satellite projects for PostgreSQL. At the time we made that > decision, several people on this list gave the impression that mailing > lists would be created more liberally in the future in order to pick up > the slack. Yes. > However, that is not what has happened. Every time someone has > requested a new mailing list here they've had to extensively justify > their request for the list. Definitely. > The impression I get is that there's a lot > of support infrastructure associated with each list for the infra team, > which is fueling their objections. Not a huge amount of work. On the few occasions when it happens (I can only actually think of a handful off-hand), it's typically because there is significant overlap with another list, usually -hackers - and as you know, we (core, and many other hackers) don't want lists that overlap like that because many believe it's unnecessary and leads to fragmented discussions. > However, the result is that people > who were enthusiastic about doing something with PostgreSQL get > frustrated and discouraged, or go off and set up a forum on some website > not even associated with postgresql.org, making it hard/impossible for > users to find. Can you give some examples of where that has happened please? > At this point, I have active lists still running on Marc's pgfoundry > because I've been discouraged from moving them over. What are they? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Jun 25, 2014 at 2:55 AM, Stephen Frost <sfrost@snowman.net> wrote:
(I'm gonig to stick to a technical comment, since Stephen and Dave have already said most of the things I'd otherwise say on the policies anyway. I do, fwiw, agree that there is a problem here that we need to find a way to solve)
> If adding new lists to majordomo is painful (and I can imagine it might> be), can we please set up a low-SLA mailman instance somewhere on
> postgresql.org so that every list request doesn't have to turn into an
> argument? If this is a PITA for the infra team, can we ask OSUOSL for one?
Unfortunately, it is not that simple. There is no such thing as a siple "low-SLA" mailman the way mailman works today. There's a reason (ok there's more than one reason) that the mailman integration with pgfoundry was such horrible crap. And there's really not any good way around that the way it works today. And mj2 is even worse.
I do have some foolish hope in mailman3 when it comes to this. They do, actually, support postgresql backends for example, and they have an API. And by some miracle, development seems to have picked up again recently and they're now in beta (though they haven't even managed to update their own website to reflect that info even though it's months ago).
It's not something we can use now, but I hope it gets there at some point.
That still only solves part of the problem though. Just dealing with bounce management and abuse and whatnot still takes time. But at least with the right tools, you have a better choice.
Email, sadly, is a time consuming business to be in.
+infinity on that.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 25 June 2014 09:03, Magnus Hagander <magnus@hagander.net> wrote: > I'm gonig to stick to a technical comment, since Stephen and Dave have > already said most of the things I'd otherwise say on the policies anyway. Friends, Policies are great, but it doesn't move us towards getting a mailing list. The last time someone in 2ndQuadrant set up a project and a mailing list external to postgresql.org the result was roundly and deeply critiscised. The attempt here is to "do the right thing", assuming that the last attempt was not it. Given that we must also consider issues of copyright and legal issues surrounding right-to-contribute, this may be more than just an ML discussion. Anyway, I don't have too much opinion here, other than JFDI, or at least within the next 7 days tops. Please advise where we should create the mailing list for the case being discussed (BDR). -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 06/24/2014 09:56 PM, Stephen Frost wrote: >> The alternative is for all of these folks to leave the postgresql.org >> infrastructure, which may be a win for the infra team, but it's not a >> win for the community. > > Yeah, I'm really not buying off on this. Their alternative should be to > use an existing list rather than pollluting the pg.org namespace with > lists for every little thing. If they go off and create their > not-popular and not-used list on another provider, well, I don't think > the community or anyone else really ends up losing out on much of > anything. What Josh is talking about is USERS not HACKERS. The docker packaging is a perfect example. If I were a docker hacker that was trying to work with PostgreSQL, I would have exactly -100 desire to join any current list on PostgreSQL. It isn't relevant. I am trying to solve a very specific problem. I don't want the noise of -hackers or -general. However, the problem I am trying to solve would be continual as versions change etc. Therefore I would want a dedicate place to work through the issue. It may not be very active, but I want the resource there. It has context and purpose. Why in all that is holy and great in this eternal universe of Open Source zealotry would I want to sign up for -hackers to solve that problem? I am not looking to re-enter the garden of eden, I am just trying to sow my patch of land. Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, @cmdpromptinc "If we send our children to Caesar for their education, we should not be surprised when they come back as Romans."
errr: postgresql.us -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, @cmdpromptinc "If we send our children to Caesar for their education, we should not be surprised when they come back as Romans."
On Wed, Jun 25, 2014 at 4:33 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > On 06/24/2014 09:56 PM, Stephen Frost wrote: > >>> The alternative is for all of these folks to leave the postgresql.org >>> infrastructure, which may be a win for the infra team, but it's not a >>> win for the community. >> >> >> Yeah, I'm really not buying off on this. Their alternative should be to >> use an existing list rather than pollluting the pg.org namespace with >> lists for every little thing. If they go off and create their >> not-popular and not-used list on another provider, well, I don't think >> the community or anyone else really ends up losing out on much of >> anything. > > > What Josh is talking about is USERS not HACKERS. The docker packaging is a > perfect example. If I were a docker hacker that was trying to work with > PostgreSQL, I would have exactly -100 desire to join any current list on > PostgreSQL. It isn't relevant. I am trying to solve a very specific problem. > I don't want the noise of -hackers or -general. > > However, the problem I am trying to solve would be continual as versions > change etc. Therefore I would want a dedicate place to work through the > issue. It may not be very active, but I want the resource there. It has > context and purpose. > > Why in all that is holy and great in this eternal universe of Open Source > zealotry would I want to sign up for -hackers to solve that problem? I am > not looking to re-enter the garden of eden, I am just trying to sow my patch > of land. I don't think anyone is objecting to the docker list. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 06/25/2014 08:35 AM, Dave Page wrote: >> What Josh is talking about is USERS not HACKERS. The docker packaging is a >> perfect example. If I were a docker hacker that was trying to work with >> PostgreSQL, I would have exactly -100 desire to join any current list on >> PostgreSQL. It isn't relevant. I am trying to solve a very specific problem. >> I don't want the noise of -hackers or -general. >> >> However, the problem I am trying to solve would be continual as versions >> change etc. Therefore I would want a dedicate place to work through the >> issue. It may not be very active, but I want the resource there. It has >> context and purpose. >> >> Why in all that is holy and great in this eternal universe of Open Source >> zealotry would I want to sign up for -hackers to solve that problem? I am >> not looking to re-enter the garden of eden, I am just trying to sow my patch >> of land. > > I don't think anyone is objecting to the docker list. > Then the bdr-users list should be fine as well. The difference being of course that the feature may one day get into core. That doesn't obsolete the list (although it could), it may actually enforce a greater need for it. It is a rather specific use case feature. Joshua D. Drake -- Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579 PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, @cmdpromptinc "If we send our children to Caesar for their education, we should not be surprised when they come back as Romans."
On 06/25/2014 01:57 AM, Simon Riggs wrote: > The last time someone in 2ndQuadrant set up a project and a mailing > list external to postgresql.org the result was roundly and deeply > critiscised. The attempt here is to "do the right thing", assuming > that the last attempt was not it. Given that we must also consider > issues of copyright and legal issues surrounding right-to-contribute, > this may be more than just an ML discussion. Wait ... if you're going to cover that stuff, doesn't it have to be a closed ML? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Jun 25, 2014 at 10:57 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 25 June 2014 09:03, Magnus Hagander <magnus@hagander.net> wrote:Friends,
> I'm gonig to stick to a technical comment, since Stephen and Dave have
> already said most of the things I'd otherwise say on the policies anyway.
Policies are great, but it doesn't move us towards getting a mailing list.
The last time someone in 2ndQuadrant set up a project and a mailing
list external to postgresql.org the result was roundly and deeply
critiscised. The attempt here is to "do the right thing", assuming
that the last attempt was not it. Given that we must also consider
issues of copyright and legal issues surrounding right-to-contribute,
this may be more than just an ML discussion.
Anyway, I don't have too much opinion here, other than JFDI, or at
least within the next 7 days tops.
Please advise where we should create the mailing list for the case
being discussed (BDR).
Why not just use -general, in order not to fragment our userbase even more. It's already got declining voiume, so adding a little bit more to it shouldn't be a big problem.
Then *if and when* the volume of BDR questions on that list become large enough to notice, should that even happen, we can create a new list *at that time*. That would decrease the risk that people are worried about which is that we create a list that will be extremely low volume yet "hard to get rid of" in the future.
(And as before, using -hackers for discussions about the actual development of the postgres parts)
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 2014-06-25 19:33:06 +0200, Magnus Hagander wrote: > Why not just use -general, in order not to fragment our userbase even more. > It's already got declining voiume, so adding a little bit more to it > shouldn't be a big problem. Because people complain when other people post stuff that's not 'core postgres' on -hackers/-general/-bugs. That already has happened a couple of times. > (And as before, using -hackers for discussions about the actual development > of the postgres parts) Yea, obviously. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Jun 25, 2014 at 7:47 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2014-06-25 19:33:06 +0200, Magnus Hagander wrote:Because people complain when other people post stuff that's not 'core
> Why not just use -general, in order not to fragment our userbase even more.
> It's already got declining voiume, so adding a little bit more to it
> shouldn't be a big problem.
postgres' on -hackers/-general/-bugs. That already has happened a couple
of times.
So now that will just change to complaints that they are posting to the wrong list... The difference being that they could now, in theory, get sent a link to the proper list. And if it *is* the official channel, then that would actually be less likely to happen. But people will complain either way.
Anyway. I still think it would be better to give that a try and create a list if we know it is needed, rather than preemptively create one. Mainly because it's so much easier to create one than to remove one. But if people are absolutely against that, I guess we should create it - it's definitely a project we'll want to promote I believe.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/