Thread: pgsql-patches considered harmful

pgsql-patches considered harmful

From
Greg Stark
Date:
Pursuant to a conversation this evening I would like to a suggestion:
BIRT pgsql-patches should be abolished in favour of something else thataccomplishes the bandwidth-reduction aspect
withoutthe downsides.
 

My complaint is that -patches serves to

a) siphon off some of the most technical discussion from -hackers to somewhere  where fewer hackers read regularly
leavinga lower signal-to-noise ratio on  -hackers. 
 

b) partition the discussions in strange ways making it harder to carry on  coherent threads or check past discussions
forconclusions. 
 

c) encourages patches to sit in queues until a committer can review it rather  than have non-committers eyeballing it
oreven applying it locally and  using it before it's ready to be committed to HEAD.
 

The only defence I've heard for the existence of -patches is that it avoids
large attachments filling people's inboxes.

To that end I would suggest replacing it with a script on the mail server to
strip out attachments and replace them with a link to some place where they
can be downloaded.

This could conceivably evolve into some sort of simple patch queue system
where committers could view a list of patches and mark them when they get
rejected or committed. I'm not suggesting anything like a bug tracking system,
just a simple page should suffice.

I fear by sending this I may have just volunteered to execute it. But if it's
the case that people support my suggestion I would be happy to do so.

-- 
greg



Re: pgsql-patches considered harmful

From
"Joshua D. Drake"
Date:
On Sunday 09 July 2006 20:00, Greg Stark wrote:
> Pursuant to a conversation this evening I would like to a suggestion:
>
>  BIRT pgsql-patches should be abolished in favour of something else that
>  accomplishes the bandwidth-reduction aspect without the downsides.

Alternatively, people could just use patches for patch submission and keep all
discussion on hackers.

Joshua D. Drake

--   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240  Providing the most comprehensive  PostgreSQL
solutionssince 1997            http://www.commandprompt.com/
 




Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Mon, 9 Jul 2006, Greg Stark wrote:

>
> Pursuant to a conversation this evening I would like to a suggestion:
>
> BIRT pgsql-patches should be abolished in favour of something else that
> accomplishes the bandwidth-reduction aspect without the downsides.
>
> My complaint is that -patches serves to
>
> a) siphon off some of the most technical discussion from -hackers to somewhere
>   where fewer hackers read regularly leaving a lower signal-to-noise ratio on
>   -hackers.
>
> b) partition the discussions in strange ways making it harder to carry on
>   coherent threads or check past discussions for conclusions.
>
> c) encourages patches to sit in queues until a committer can review it rather
>   than have non-committers eyeballing it or even applying it locally and
>   using it before it's ready to be committed to HEAD.
>
> The only defence I've heard for the existence of -patches is that it avoids
> large attachments filling people's inboxes.
>
> To that end I would suggest replacing it with a script on the mail server to
> strip out attachments and replace them with a link to some place where they
> can be downloaded.
>
> This could conceivably evolve into some sort of simple patch queue system
> where committers could view a list of patches and mark them when they get
> rejected or committed. I'm not suggesting anything like a bug tracking system,
> just a simple page should suffice.
>
> I fear by sending this I may have just volunteered to execute it. But if it's
> the case that people support my suggestion I would be happy to do so.

I, for one, would be interested in something like that ... somehow, this 
'stripping' would have to be done within Majordomo2 itself, or ...

Leave pgsql-patches@ as an alias that is "the stripper", with the end 
result forwarded over to the pgsql-hackers@ list?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664


Re: pgsql-patches considered harmful

From
Tom Lane
Date:
"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Sunday 09 July 2006 20:00, Greg Stark wrote:
>> BIRT pgsql-patches should be abolished in favour of something else that
>> accomplishes the bandwidth-reduction aspect without the downsides.

> Alternatively, people could just use patches for patch submission and keep all
> discussion on hackers.

If this is chosen as the preferred path, we could get the list bot to
add "Reply-To: pghackers" in pgsql-patches postings to help push
discussions there.  I'd vote for doing the same in pgsql-committers,
which also gets its share of non-null discussion content.
        regards, tom lane


Re: pgsql-patches considered harmful

From
Martijn van Oosterhout
Date:
On Mon, Jul 10, 2006 at 01:04:09AM -0300, Marc G. Fournier wrote:
> I, for one, would be interested in something like that ... somehow, this
> 'stripping' would have to be done within Majordomo2 itself, or ...
>
> Leave pgsql-patches@ as an alias that is "the stripper", with the end
> result forwarded over to the pgsql-hackers@ list?

I have in the past had a script that took email, pushed the attachments
to disk and forwarded the email on. It's not spectacularly intelligent
though, but I was thinking it could be used as a sort of patch queue.

However, I think the other suggestions of having the listbot mangle the
reply-tos of -patches and -committers to be -hackers would probably be
good too. I myself subscribe to -committers in digest form (where I
look at the summary to see if it's interesting) and read -patches
occasionally via the archives to see if anything is there...

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Re: pgsql-patches considered harmful

From
Josh Berkus
Date:
Martjin, Greg, Marc, etc.:

> However, I think the other suggestions of having the listbot mangle the
> reply-tos of -patches and -committers to be -hackers would probably be
> good too. I myself subscribe to -committers in digest form (where I
> look at the summary to see if it's interesting) and read -patches
> occasionally via the archives to see if anything is there...

I agree that mangling the reply-tos would be the least complex (and thus 
probably best) solution.  Unlike attachment stripping, this is supported 
by majordomo.

However, to save on spam filtering, the reply-to should add -hackers 
*also*, not instead.

--Josh Berkus


Re: pgsql-patches considered harmful

From
Josh Berkus
Date:
Marc,

> You've lost me on that last point ... how does that save on spam filtering?

Many spam filters give points for "reply-to address does not match from 
address".

--Josh


Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Mon, 10 Jul 2006, Josh Berkus wrote:

> Martjin, Greg, Marc, etc.:
>
>> However, I think the other suggestions of having the listbot mangle the
>> reply-tos of -patches and -committers to be -hackers would probably be
>> good too. I myself subscribe to -committers in digest form (where I
>> look at the summary to see if it's interesting) and read -patches
>> occasionally via the archives to see if anything is there...
>
> I agree that mangling the reply-tos would be the least complex (and thus 
> probably best) solution.  Unlike attachment stripping, this is supported by 
> majordomo.
>
> However, to save on spam filtering, the reply-to should add -hackers *also*, 
> not instead.

You've lost me on that last point ... how does that save on spam 
filtering?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664


Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Mon, 10 Jul 2006, Tom Lane wrote:

> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> On Sunday 09 July 2006 20:00, Greg Stark wrote:
>>> BIRT pgsql-patches should be abolished in favour of something else that
>>> accomplishes the bandwidth-reduction aspect without the downsides.
>
>> Alternatively, people could just use patches for patch submission and keep all
>> discussion on hackers.
>
> If this is chosen as the preferred path, we could get the list bot to
> add "Reply-To: pghackers" in pgsql-patches postings to help push
> discussions there.  I'd vote for doing the same in pgsql-committers,
> which also gets its share of non-null discussion content.

that is a very easy and quick change ... but wasn't doing that brought up 
before and alot of ppl were against that?

If nobody objects within, say, the next 24 hours ... ?  I'll enabled that 
one both ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664


Re: pgsql-patches considered harmful

From
Bruce Momjian
Date:
Marc G. Fournier wrote:
> On Mon, 10 Jul 2006, Josh Berkus wrote:
> 
> > Martjin, Greg, Marc, etc.:
> >
> >> However, I think the other suggestions of having the listbot mangle the
> >> reply-tos of -patches and -committers to be -hackers would probably be
> >> good too. I myself subscribe to -committers in digest form (where I
> >> look at the summary to see if it's interesting) and read -patches
> >> occasionally via the archives to see if anything is there...
> >
> > I agree that mangling the reply-tos would be the least complex (and thus 
> > probably best) solution.  Unlike attachment stripping, this is supported by 
> > majordomo.
> >
> > However, to save on spam filtering, the reply-to should add -hackers *also*, 
> > not instead.
> 
> You've lost me on that last point ... how does that save on spam 
> filtering?

He is saying that other mail servers might think our email is spam, but
I think the risk is worth it.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: pgsql-patches considered harmful

From
Andrew Dunstan
Date:
Marc G. Fournier wrote:
>>
>> If this is chosen as the preferred path, we could get the list bot to
>> add "Reply-To: pghackers" in pgsql-patches postings to help push
>> discussions there.  I'd vote for doing the same in pgsql-committers,
>> which also gets its share of non-null discussion content.
>
> that is a very easy and quick change ... but wasn't doing that brought 
> up before and alot of ppl were against that?
>
> If nobody objects within, say, the next 24 hours ... ?  I'll enabled 
> that one both ...
>

Don't be surprised if there are objections - this is one of those things 
like emacs vs vi that stirs up religious debate.

cheers

andrew


Re: pgsql-patches considered harmful

From
Bruce Momjian
Date:
Andrew Dunstan wrote:
> Marc G. Fournier wrote:
> >>
> >> If this is chosen as the preferred path, we could get the list bot to
> >> add "Reply-To: pghackers" in pgsql-patches postings to help push
> >> discussions there.  I'd vote for doing the same in pgsql-committers,
> >> which also gets its share of non-null discussion content.
> >
> > that is a very easy and quick change ... but wasn't doing that brought 
> > up before and alot of ppl were against that?
> >
> > If nobody objects within, say, the next 24 hours ... ?  I'll enabled 
> > that one both ...
> >
> 
> Don't be surprised if there are objections - this is one of those things 
> like emacs vs vi that stirs up religious debate.

If we change Reply-To:, does it prevent replies to the original author? 
If so, that seems like a problem, particularly if they are not
subscribed to the patches list.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: pgsql-patches considered harmful

From
Bruce Momjian
Date:
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> >> Don't be surprised if there are objections - this is one of those things 
> >> like emacs vs vi that stirs up religious debate.
> >>     
> >
> > If we change Reply-To:, does it prevent replies to the original author? 
> > If so, that seems like a problem, particularly if they are not
> > subscribed to the patches list.
> >
> >   
> 
> Depends on the MUA. See both sides of the debate here: 
> http://marc.merlins.org/netrants/listreplyto.html . We use reply-to for 
> the pgfoundry admins list, but that's a closed list. For open lists that 
> often accept non-member posts it is much more of a problem, not least 
> for the reason you suggest.

Let's add the author and the hackers list to the reply-to.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


Re: pgsql-patches considered harmful

From
Andrew Dunstan
Date:
Bruce Momjian wrote:
>> Don't be surprised if there are objections - this is one of those things 
>> like emacs vs vi that stirs up religious debate.
>>     
>
> If we change Reply-To:, does it prevent replies to the original author? 
> If so, that seems like a problem, particularly if they are not
> subscribed to the patches list.
>
>   

Depends on the MUA. See both sides of the debate here: 
http://marc.merlins.org/netrants/listreplyto.html . We use reply-to for 
the pgfoundry admins list, but that's a closed list. For open lists that 
often accept non-member posts it is much more of a problem, not least 
for the reason you suggest.

cheers

andrew



Re: pgsql-patches considered harmful

From
Greg Stark
Date:
Andrew Dunstan <andrew@dunslane.net> writes:

> Marc G. Fournier wrote:
> >
> > If nobody objects within, say, the next 24 hours ... ?  I'll enabled that one
> > both ...
> 
> Don't be surprised if there are objections - this is one of those things like
> emacs vs vi that stirs up religious debate.

Indeed. The usual issue is that if someone hits "personal reply" their
personal note to the author will go to the mailing list. Some lists have
problems with people sending personal replies inappropriately but I doubt
that's the case for -patches or -committers. 

I have the additional complaint that this doesn't actually solve most of my
original complaints and might reduce the pressure to find a better solution.
The patches announcements themselves would still be basically invisible within
the community.

Even if someone isn't going to read or apply the actual patch I think there is
an enormous benefit to be gained from having everyone at least know it went
by. Much as I'm sure not everyone reads every line of every message on
-hackers but they are aware of what topics are under discussion.

-- 
greg



Re: pgsql-patches considered harmful

From
Stephen Frost
Date:
* Greg Stark (gsstark@mit.edu) wrote:
> I have the additional complaint that this doesn't actually solve most of my
> original complaints and might reduce the pressure to find a better solution.
> The patches announcements themselves would still be basically invisible within
> the community.

I'm with Greg on this one.  I felt his original complaint made alot of
sense and this doesn't really deal with it.  I'd much rather see
-patches go away or maybe become an alias to -hackers.  If the patch is
too big then perhaps either compress it or provide a link to it when
it's submitted.  If hosting for patches is an issue then perhaps provide
a way for patches to be hosted on a PG server.  Honestly, I'd be happy
to put up any PG patches sent to me on a well connected server.  I'm not
sure how easy it'd be to automate that though (and prevent
spammers/etc), but perhaps people have some suggestions?
Thanks,
    Stephen

Re: pgsql-patches considered harmful

From
"Greg Sabino Mullane"
Date:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message



One thing that came up in the discussion here was the idea of a
weekly (or other time period) digest of patches posts, stripped
of attachments, but with a link to the patches email, which will
have both the attachment and follow-up posts for those that are
interested. Proof of concept below my sig.

--
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200607111416
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8


Weekly PostgreSQL patches summary:


http://archives.postgresql.org/pgsql-patches/2006-07/msg00018.php
From: Neil Conway <neilc@samurai.com>
Subject: [PATCHES] CREATE TRIGGER locking
Date: 2:25 AM on Tuesday, July 04, 2006

Last year, I questioned why CREATE TRIGGER acquires an
AccessExclusiveLock on its target table:
   http://archives.postgresql.org/pgsql-hackers/2005-03/msg00764.php

Acquiring an ExclusiveLock should be sufficient: we can safely allow
concurrent SELECTs on the table. (The -hackers thread discusses both
CREATE TRIGGER and ALTER TABLE ADD FK; the latter might require some
more consideration, so I'll tackle that later.)

This patch implements this change, and updates the documentation.

Barring any objections, I'll apply this in a day or two.

-Neil


---------------------------(end of broadcast)---------------------------



http://archives.postgresql.org/pgsql-patches/2006-07/msg00021.php

From: Tom Lane <tgl@sss.pgh.pa.us>
Subject: [PATCHES] Draft patch for bug: ALTER TYPE ... USING(NULL) / NOT NULL violation
Date: 6:37 PM on Tuesday, July 04, 2006

Attached is a rather hurried patch for Alexander Pravking's report that
ALTER TABLE fails to check pre-existing NOT NULL constraints properly:
http://archives.postgresql.org/pgsql-bugs/2006-07/msg00015.php

It seems to work but I'm out of time to do more with it, and am leaving
for Toronto in the morning.  Anyone want to look it over, generate
back-patches as appropriate, and apply?
                       regards, tom lane


---------------------------(end of broadcast)---------------------------



http://archives.postgresql.org/pgsql-patches/2006-07/msg00031.php

From: Greg Stark <gsstark@mit.edu>
Subject: [PATCHES] BTree tid operators and opclass
Date: 6:53 PM on Thursday, July 06, 2006

Here's a small patch to add the full suite of btree operators for tids and the
corresponding btree opclass. This came up a while back on -hackers and a few
people were interested in it at the time. I just had a need for it again so I
added it.

I'm not sure how to allocate OIDs. I just looked for the greatest one in the
various .h files and started from there. It leads to some strange
discontinuities since there were existing = and <> operators.



--
greg

---------------------------(end of broadcast)---------------------------



http://archives.postgresql.org/pgsql-patches/2006-07/msg00035.php

From: "Magnus Hagander" <mha@sollentuna.net>
Subject: [PATCHES] Win32 DEF file error
Date: 11:30 AM on Monday, July 10, 2006

The Win32 DEF files that are generated for libpq contain the attribute
"DESCRIPTION", which is actually only allowed for device drivers. The
compilers ignore it with a warning - if we remove them, we get rid of
the warning.

(ref
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/
html/_core_description.asp)

//Magnus

---------------------------(end of broadcast)---------------------------



http://archives.postgresql.org/pgsql-patches/2006-07/msg00037.php

From: "Dave Page" <dpage@vale-housing.co.uk>
Subject: [PATCHES] Minor ipv6/Win32 fix
Date: 7:42 PM on Monday, July 10, 2006

The attached patch reverses ws2tcpip.h and winsock2.h to avoid an
undefined symbol error when building under VC2k5.

Regards, Dave

---------------------------(end of broadcast)---------------------------



http://archives.postgresql.org/pgsql-patches/2006-07/msg00038.php

From: James Gates <jim.gates@sun.com>
Subject: [PATCHES] Patch to "configure" to enable PostgreSQL build with Kerberos 5 on Solaris 11
Date: 7:50 PM on Monday, July 10, 2006

Included below are extracts from an earlier email thread (on
pgsql-ports) discussing the problem.

Attached are the context diffs for configure.in.

This change has no impact unless the "--with-krb5" option is used with
"configure". If the option *is* used, configure will now only search for
function krb5_sendauth(), instead of looking for both krb5_encrypt() and
krb5_sendauth().

I've tested (i.e. built using --with-krb5) with version 8.1.4 on Solaris
11 only. This change should have no negative impact for builds on other
platforms since:

a) The check for krb5_sendauth() remains, which is sufficient to
determine the presence of Kerberos 5

and

b) None of the PostgreSQL code uses krb5_encrypt() anyway


James Gates wrote:> Prior to Solaris 11 (Nevada), the full Kerberos 5 API was never exposed> (only the gss interface),
sobuilding PostgreSQL with the "--with-krb5"> option is a problem.>> In Nevada, Sun has exposed the full MIT Kerberos 5
API(v1.4.0). So> building PostgreSQL with Kerberos should be possible/easy. If I try to> build 8.1.4 though, it fails
withthe following error:>> $ ./configure --with-krb5 --without-readline> checking build system type...
sparc-sun-solaris2.11>checking host system type... sparc-sun-solaris2.11> ... snip ...> checking for library containing
com_err...-lkrb5> checking for library containing krb5_encrypt... no> configure: error: could not find function
'krb5_encrypt'required for> Kerberos 5>> This is because in krb5 v1.4.0, the krb5_encrypt() function is>
deprecated/removed,so doesn't exist anywhere in the Solaris libraries.> It is replaced by krb5_c_encrypt() (I think
thischange occurred> sometime between krb5 v1.2.1 and v1.4.0)>> But looking more closely at the PostgreSQL 8.1.4 code,
Isee that it> never even uses the krb5_encrypt() function anyway! So although it's> presence might be a useful method
fordetecting the presence of Kerberos> 5 (pre v1.4.0), it seems unnecessary for the successful operation of>
PostgreSQL.>>By simply removing the check for krb5_encrypt() from the configure> script, I can successfully build
PostgreSQLwith krb5 on Nevada.>> Does anyone know why the check for krb5_encrypt() exists in configure> when the code
doesn'tuse it? And would absence of a good reason> indicate this is a bug (and the check should be removed)?
 

Tom Lane wrote:> James Gates <James.Gates@Sun.COM> writes:>> Does anyone know why the check for krb5_encrypt() exists
inconfigure>> when the code doesn't use it?>> At the time it was chosen, it was probably a reasonable choice of>
functionto probe for to make sure Kerberos libraries are present.> Do you have a better suggestion?>>
  regards, tom lane
 

James Gates wrote:> The configure script already checks for krb5_sendauth() as well as> krb5_encrypt(). The libpq code
*does*use krb5_sendauth(), which is not> deprecated (and I know of no plans to make it so).>> I discussed this problem
lastnight with Magnus Hagander, and we're both> of the opinion that the search for krb5_sendauth() alone is sufficient>
todetermine if krb5 is present on your system.>> Magus suspects that at some point in the past, PostgreSQL did use>
krb5_encrypt(),and it was changed (maybe in anticipation of the> function becoming deprecated?). Whoever made the
change,>forgot/neglected to remove the check from the configure script.>> I propose that we remove the check for
krb5_encrypt()from the configure> script, leaving just the check for krb5_sendauth().>> Note - krb5_encrypt() is
replacedby krb5_c_encrypt() in the latest> implementation of krb5. We could change the configure script to check> for
thisas well, but as mentioned above, I think this is unnecessary.
 

$ runsocks cvs diff -c configure.in
Index: configure.in
===================================================================
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.467
diff -c -r1.467 configure.in
*** configure.in        18 Jun 2006 18:30:20 -0000      1.467
--- configure.in        10 Jul 2006 20:56:44 -0000
***************
*** 671,678 ****   if test "$PORTNAME" != "win32"; then      AC_SEARCH_LIBS(com_err, [krb5 'krb5 -ldes -lasn1 -lroken'
com_err],[],                     [AC_MSG_ERROR([could not find function 'com_err' required for Kerberos 5])])
 
-      AC_SEARCH_LIBS(krb5_encrypt, [krb5 'krb5 -ldes -lasn1 -lroken' crypto k5crypto], [],
-                     [AC_MSG_ERROR([could not find function 'krb5_encrypt' required for Kerberos 5])])
AC_SEARCH_LIBS(krb5_sendauth,[krb5 'krb5 -ldes -lasn1 -lroken'], [],                     [AC_MSG_ERROR([could not find
function'krb5_sendauth' required for Kerberos 5])])   else
 
--- 671,676 ----

---------------------------(end of broadcast)---------------------------



http://archives.postgresql.org/pgsql-patches/2006-07/msg00039.php

From: "Charles Duffy" <charles.duffy@gmail.com>
Subject: [PATCHES] putting CHECK_FOR_INTERRUPTS in qsort_comparetup()
Date: 3:53 AM on Tuesday, July 11, 2006

Hi,

We came up with this patch in response to a problem reported to us by a
client. They had a query which took an unacceptably long time to respond
to a cancel request (SIGINT). The client uses 8.1.4, so the patch is
against that.

Their work_mem setting was rather large (1000000). We determined that when it
received SIGINT, the backend was always inside qsort(), so it wouldn't
call ProcessInterrupts() again until it finished this large in-memory
sort. Upon entering tuplesort_performsort(), state->memtupcount was
29247.

The patch puts a CHECK_FOR_INTERRUPTS in qsort_comparetup. This solves
their problem, at the cost of checking InterruptPending a lot. The
"unlikely()" gcc directive might help there a bit.

I'm not sure if this patch has general applicability - but it seems to
solve the problem for our client. Does anyone think it might introduce
any new problems?

Thanks,


--
Charles Duffy

---------------------------(end of broadcast)---------------------------




-----BEGIN PGP SIGNATURE-----

iD8DBQFEs+0OvJuQZxSWSsgRAhJ9AKCBNzurWPdlG5u2U4OeXpB8rsWsMgCgmaqx
iCJyswtFr6OIULjXz0C8uGY=
=2ari
-----END PGP SIGNATURE-----




Re: pgsql-patches considered harmful

From
Greg Stark
Date:
Bruce Momjian <bruce@momjian.us> writes:

> Let's add the author and the hackers list to the reply-to.

I think reply-to is just a single address. It may work in some mailers though.

Regardless the issue is that someone may send a personal message and be
surprised when it's broadcast. You can always resent a message accidentally
sent personally but you can't unsend one that should not have seen wider
distribution.

-- 
greg



Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Tue, 11 Jul 2006, Bruce Momjian wrote:

> Andrew Dunstan wrote:
>> Marc G. Fournier wrote:
>>>>
>>>> If this is chosen as the preferred path, we could get the list bot to
>>>> add "Reply-To: pghackers" in pgsql-patches postings to help push
>>>> discussions there.  I'd vote for doing the same in pgsql-committers,
>>>> which also gets its share of non-null discussion content.
>>>
>>> that is a very easy and quick change ... but wasn't doing that brought
>>> up before and alot of ppl were against that?
>>>
>>> If nobody objects within, say, the next 24 hours ... ?  I'll enabled
>>> that one both ...
>>>
>>
>> Don't be surprised if there are objections - this is one of those things
>> like emacs vs vi that stirs up religious debate.
>
> If we change Reply-To:, does it prevent replies to the original author?
> If so, that seems like a problem, particularly if they are not
> subscribed to the patches list.

The Reply-To: header is added to other heads ... in Pine, at least, I have 
the option to honor, or disregard, the Reply-To ... I generally honor it, 
but there is nothing stop'ng someone from disregarding it, and sending to 
the original poster ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664


Re: pgsql-patches considered harmful

From
David Fetter
Date:
On Tue, Jul 11, 2006 at 06:28:31PM -0000, Greg Sabino Mullane wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> NotDashEscaped: You need GnuPG to verify this message
> 
> One thing that came up in the discussion here was the idea of a
> weekly (or other time period) digest of patches posts, stripped of
> attachments, but with a link to the patches email, which will have
> both the attachment and follow-up posts for those that are
> interested. Proof of concept below my sig.

I've done a little bit of this in the form of short summaries in the
Weekly News, and I'd be delighted to do more of it.  I'd need some
help, though :)

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!


Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Tue, 11 Jul 2006, Greg Stark wrote:

> I have the additional complaint that this doesn't actually solve most of 
> my original complaints and might reduce the pressure to find a better 
> solution. The patches announcements themselves would still be basically 
> invisible within the community.

How do you deal with the case where someone posts a patch, but it isn't an 
attachment?  Its part of the actual text?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664


Re: pgsql-patches considered harmful

From
"Magnus Hagander"
Date:
> > I have the additional complaint that this doesn't actually
> solve most
> > of my original complaints and might reduce the pressure to
> find a better solution.
> > The patches announcements themselves would still be basically
> > invisible within the community.
>
> I'm with Greg on this one.  I felt his original complaint
> made alot of sense and this doesn't really deal with it.  I'd
> much rather see -patches go away or maybe become an alias to
> -hackers.  If the patch is too big then perhaps either
> compress it or provide a link to it when it's submitted.  If
> hosting for patches is an issue then perhaps provide a way
> for patches to be hosted on a PG server.  Honestly, I'd be
> happy to put up any PG patches sent to me on a well connected
> server.  I'm not sure how easy it'd be to automate that
> though (and prevent spammers/etc), but perhaps people have
> some suggestions?

There are list servers out there capable of simply ripping any
attachments to a message (possibly over a certain size) and stick it on
a website, replacing it with a link in the email. Is majordomo one of
them?

If that was done, we could just have patches be sent to -hackers, and
get rid of -patches completely.

//Magnus


Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Wed, 12 Jul 2006, Magnus Hagander wrote:

> There are list servers out there capable of simply ripping any 
> attachments to a message (possibly over a certain size) and stick it on 
> a website, replacing it with a link in the email. Is majordomo one of 
> them?

Majordomo2 has a 'hook' for it, but, like most OSS software, nobody has 
had the requirement to actually code it ... any perl experts here 
interested in doing it?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664


Re: pgsql-patches considered harmful

From
Hannu Krosing
Date:
Ühel kenal päeval, K, 2006-07-12 kell 23:04, kirjutas Marc G. Fournier:
> On Wed, 12 Jul 2006, Magnus Hagander wrote:
> 
> > There are list servers out there capable of simply ripping any 
> > attachments to a message (possibly over a certain size) and stick it on 
> > a website, replacing it with a link in the email. Is majordomo one of 
> > them?
> 
> Majordomo2 has a 'hook' for it, but, like most OSS software, nobody has 
> had the requirement to actually code it ... any perl experts here 
> interested in doing it?

Does it have to be perl ?

I can do it in python in an hour or two.

> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email . scrappy@hub.org                              MSN . scrappy@hub.org
> Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com




Re: pgsql-patches considered harmful

From
"Marc G. Fournier"
Date:
On Fri, 14 Jul 2006, Hannu Krosing wrote:

> Ühel kenal päeval, K, 2006-07-12 kell 23:04, kirjutas Marc G. Fournier:
>> On Wed, 12 Jul 2006, Magnus Hagander wrote:
>>
>>> There are list servers out there capable of simply ripping any
>>> attachments to a message (possibly over a certain size) and stick it on
>>> a website, replacing it with a link in the email. Is majordomo one of
>>> them?
>>
>> Majordomo2 has a 'hook' for it, but, like most OSS software, nobody has
>> had the requirement to actually code it ... any perl experts here
>> interested in doing it?
>
> Does it have to be perl ?

To tie into the list manager, it has to be perl, yes ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email . scrappy@hub.org                              MSN . scrappy@hub.org
Yahoo . yscrappy               Skype: hub.org        ICQ . 7615664

Re: pgsql-patches considered harmful

From
Josh Berkus
Date:
All,

Several of us hashed this out at the Code Sprint.  While the solution we 
arrived at doesn't completely satisfy Greg, several others would be fine with 
just having a version of pgsql-patches (pgsql-patches-lite?) that we could 
subscribe to to get the messages without the attachments.

Also, Greg pointed out the need to post periodic summaries of what 
features/patches had been committed.   So I guess I'll have to start doing 
that for PWN.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco