Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs8p6-0006dD-T2 for pgsql-www@arkaria.postgresql.org; Fri, 08 Feb 2019 16:16:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gs8p5-0003jH-K0 for pgsql-www@arkaria.postgresql.org; Fri, 08 Feb 2019 16:16:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs8p5-0003j9-AO for pgsql-www@lists.postgresql.org; Fri, 08 Feb 2019 16:16:15 +0000 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs8p2-00044Q-BX for pgsql-www@postgresql.org; Fri, 08 Feb 2019 16:16:14 +0000 Received: by mail-lf1-x141.google.com with SMTP id f5so2892759lfc.13 for ; Fri, 08 Feb 2019 08:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=N2TQ4znljcbuk4naGLUbx0jJbP/ikrdBNQYF6tBBLss=; b=arrsx48gC05ctnoU98tY57dlZHvpD6Zz/c9/9CZQWnjNjpREP63u26YVtEtRZsE8DB 7W2Admed5mQfADBNXqFIB32m/aeryRu+/KtM0kMR4A5FlYZw6OCQPZjrqIlW/Nv2/KgT vVt/bGWPCcn42zP8Oq6oTwBthsELLK5zFijaPuXJWiErVyvmw71gMtRLwuL02Am91pOp b9hp3U4Kv6F20C7L4ph18TJQm2LxZQkUU9/Qk9zi78aFD3jIgO0X1MZyX8sthaQlP5K4 IM0veeMVXV+jp+Z7AEzzza1aUrRlqvblFK9BOLfxv3/o4eMkvZm3FwEww0DgAD+MIUyt wzlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N2TQ4znljcbuk4naGLUbx0jJbP/ikrdBNQYF6tBBLss=; b=AR0MR+732XogPF2d4crN+uS72KPajPX3HMuUv9dyo6qA3K9wGYQttLsWfTIG3Z9Lfk RX9Gi7OUrBkZI/od1sSssy2wjhKrW58ngCraMXLV7bfRBUR7ISqDKKcta1CQxr6wXPoF BBQO+Z1ilbe+DrNv7kVKuxFYRkgX+os/Pevlj3jUt8qSHJ4oDd9hUqnsrqlnVCHQ78Qa gZbIVVJZvxeMHIOvJn5a0lt4c8/2U80AMoAC3H7emL4ixshYlwOXvC5/J/5DZsL1o2/O CARscuwmcyDlAdcIBtnEBekxxC96AyO1TW+2DsU1rIpZOgDIAbpslmVNo3nQkm1zFYqh 6RPA== X-Gm-Message-State: AHQUAuacJxKZi6vnp9UCig8ErpNqR7VnSTqaj5ouQHmkBZ4Vm+FHCU/t fZoMfPtMOPNhC2q5HvA7ucJ05zu7uNEOnUrcm+FUZA== X-Google-Smtp-Source: AHgI3IZPIH6chRPPjG2Dv3nqd5Nsb9R+hO4VG2u6SYyeQTs9FqY38Suvlhykg6RerRzW2MKJ1UeSq2brLdhOvvGnSjM= X-Received: by 2002:ac2:55b3:: with SMTP id y19mr14657290lfg.28.1549642569588; Fri, 08 Feb 2019 08:16:09 -0800 (PST) MIME-Version: 1.0 References: <20190119144923.GQ2528@tamriel.snowman.net> <20190206164106.GA23132@alvherre.pgsql> <20190207114507.GD6197@tamriel.snowman.net> In-Reply-To: <20190207114507.GD6197@tamriel.snowman.net> From: Magnus Hagander Date: Fri, 8 Feb 2019 16:41:57 +0100 Message-ID: Subject: Re: mailing list redirect for bug numbers? To: Stephen Frost Cc: Alvaro Herrera , Tom Lane , Dimitri Fontaine , Andres Freund , "Jonathan S. Katz" , PostgreSQL WWW Content-Type: multipart/alternative; boundary="000000000000e3d6a80581644687" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000e3d6a80581644687 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 7, 2019 at 12:45 PM Stephen Frost wrote: > Greetings, > > * Magnus Hagander (magnus@hagander.net) wrote: > > On Thu, Feb 7, 2019 at 1:26 AM Alvaro Herrera > > wrote: > > > On 2019-Jan-19, Stephen Frost wrote: > > > > I didn't come to the conclusion that we just should leave everything > > > > as-is. I was hoping to either get to a point where either we come up > > > > with a sensible way to provide a bug number or other identifier for > > > > things we typically want to link to from commits, or decide that the > bug > > > > number isn't really all that useful and get rid of it. > > > > > > Well, we already have bug numbers in bugs submitted via the website and > > > they seem to work pretty well. > > This really depends on what the expectations are. There's certainly a > lot of people who would say that our bug handling system is rather.. > lacking. I agree that we are doing a pretty good job just assigning a > bug number to bugs submitted via the web form, but that's a really low > bar and doesn't do things we want. > Yeah, no shit. We are regularly up as examples of a crazy community that way :) > > What if we add an email interface that creates bugs with IDs, but > > > nothing more than that? I'm thinking a special address such as > > > pgsql-create-bug@postgresql.org that creates the bug ID and resends to > > > pgsql-bugs@postgresql.org CCing the bug reporter, after changing > Subject > > > to include the bug ID and the From/Sender to an address under our > > > control (to avoid DKIM problems with the reporter's domain). It would > > > work normally using pgsql-bugs from that point on. > > Yes, this could possibly work, and would be an independent application > which wouldn't require hacking up pglister, which addresses one of the > concerns raised. > Yes, and it would be reasonably easy to "police". > > If we have our system preserve References/In-Reply-To headers, I think > > > it would even work to add a CC the special address in the middle of a > > > regular thread in a mailing list (any mailing list, not just > pgsql-bugs) > > > to spawn a new bug. > > > > We could do something like that yes, and we've discussed doing it before. > > Right. > > > It would work as long as we have some sort of "moderation queue" on it, > > otherwise we'll be assigning and reposting a lot of spam. > > One thing I really don't want to do is make the moderators of some list > like this the ones who have to make the decision about if a report is > really a bug or not. For one thing, it's at least sometimes useful to > have the question asked and answered for the archives, whatever it is, > even if it isn't a bug. > Right, but that's a problem we *already* have. We will have to keep assigning those bug ids. The idea is we need to block pure spam. Just like moderators of the bug form and of the docs form have to do that *today*. Except it's likely going ot be more if it is a public email address. The reason being that once we resend it from *our* address, it will otherwise bypass all spam filters, and *our* addresses will start getting penalized for the spam. Given that for this to work we have to change the sender/from to be noreply@postgresql.org (or similar), like we do with docs and bugs today. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --000000000000e3d6a80581644687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Feb 7, 2019 at 12:45 PM Stephen F= rost <sfrost@snowman.net> w= rote:
Greetings,

* Magnus Hagander (magnus@hagander.net) wrote:
> On Thu, Feb 7, 2019 at 1:26 AM Alvaro Herrera <alvherre@2ndquadrant.com><= br> > wrote:
> > On 2019-Jan-19, Stephen Frost wrote:
> > > I didn't come to the conclusion that we just should leav= e everything
> > > as-is.=C2=A0 I was hoping to either get to a point where eit= her we come up
> > > with a sensible way to provide a bug number or other identif= ier for
> > > things we typically want to link to from commits, or decide = that the bug
> > > number isn't really all that useful and get rid of it. > >
> > Well, we already have bug numbers in bugs submitted via the websi= te and
> > they seem to work pretty well.

This really depends on what the expectations are.=C2=A0 There's certain= ly a
lot of people who would say that our bug handling system is rather..
lacking.=C2=A0 I agree that we are doing a pretty good job just assigning a=
bug number to bugs submitted via the web form, but that's a really low<= br> bar and doesn't do things we want.

= Yeah, no shit. We are regularly up as examples of a crazy community that wa= y :)


> > What if we add an email interface that creates bugs with IDs, but=
> > nothing more than that?=C2=A0 I'm thinking a special address = such as
> > pgsql-create-bug@postgresql.org that creates the bug ID and resends= to
> > pg= sql-bugs@postgresql.org CCing the bug reporter, after changing Subject<= br> > > to include the bug ID and the From/Sender to an address under our=
> > control (to avoid DKIM problems with the reporter's domain).= =C2=A0 It would
> > work normally using pgsql-bugs from that point on.

Yes, this could possibly work, and would be an independent application
which wouldn't require hacking up pglister, which addresses one of the<= br> concerns raised.

Yes, and it would be r= easonably easy to "police".



> > If we have our system preserve References/In-Reply-To headers, I = think
> > it would even work to add a CC the special address in the middle = of a
> > regular thread in a mailing list (any mailing list, not just pgsq= l-bugs)
> > to spawn a new bug.
>
> We could do something like that yes, and we've discussed doing it = before.

Right.

> It would work as long as we have some sort of "moderation queue&q= uot; on it,
> otherwise we'll be assigning and reposting a lot of spam.

One thing I really don't want to do is make the moderators of some list=
like this the ones who have to make the decision about if a report is
really a bug or not.=C2=A0 For one thing, it's at least sometimes usefu= l to
have the question asked and answered for the archives, whatever it is,
even if it isn't a bug.

Right, but = that's a problem we *already* have.

We will ha= ve to keep assigning those bug ids. The idea is we need to block pure spam.= Just like moderators of the bug form and of the docs form have to do that = *today*. Except it's likely going ot be more if it is a public email ad= dress.

The reason being that once we resend it fro= m *our* address, it will otherwise bypass all spam filters, and *our* addre= sses will start getting penalized for the spam. Given that for this to work= we have to change the sender/from to be noreply@postgresql.org (or similar), like we do with docs and b= ugs today.

--=C2=A0
=C2=A0Magnus Hagander
= =C2=A0Me: https://ww= w.hagander.net/
=C2=A0Work: https://www.redpill-linpro.com/
<= /div> --000000000000e3d6a80581644687--