Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f1wt4-0008E7-Or for pgsql-docs@arkaria.postgresql.org; Fri, 30 Mar 2018 16:28:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f1wt3-0001Sm-Cl for pgsql-docs@arkaria.postgresql.org; Fri, 30 Mar 2018 16:28:21 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1f1wt3-0001Sd-6X for pgsql-docs@lists.postgresql.org; Fri, 30 Mar 2018 16:28:21 +0000 Received: from mail-lf0-x22c.google.com ([2a00:1450:4010:c07::22c]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1f1wsz-0002sm-Mn for pgsql-docs@lists.postgresql.org; Fri, 30 Mar 2018 16:28:20 +0000 Received: by mail-lf0-x22c.google.com with SMTP id m200-v6so7411625lfm.4 for ; Fri, 30 Mar 2018 09:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WvD4SLxZVm9ndVDiKLAnpQIwbMf6yEnu94QFhEf152U=; b=H78nkgcQSEU7BcPeBWMkjgaLv/P7uBiOUf01PESRxJPPsnFsz4DMoh/7cJpie7G8Kq BsDBRJ5h2ihxrFEXAa6PzPghLQJkjd48bGaG75LjAlSoq+jv2hvOeVocpu5qRniD9O5B Ja5UAoMoT/yNvZH0b4XGTNIXf5KzrsA8HOLPxlAEHXub7tybYWJlSWsIyfafrckDHN3l SKUc0Cw0A2+muwrHg4r+TKecN2BSbbVF5Vbtaxl2s0oJ3IgdsvXmBpSVu9Zqe2VBCg8x zINPUY4lwxmtXG0/swzmwcv5kz1wrcttbIh5c+pvVuvJIGTuT0SI72tTOU2QbinJGaIX xyeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WvD4SLxZVm9ndVDiKLAnpQIwbMf6yEnu94QFhEf152U=; b=mHUhsfSa7i4fp9F2qdYk17JImNydlT5hJR9ZBmQFIazAWxMDdTxMIb5eYACgV/YlrV 4MHSrcGevEcxV04kuUjuslpyyIGn1PE0l4U2YQ8pGHcB4Zy6dOm7m5+g5NZa4VlIbEWd Kry1OAH6PQwR4NXxLkipVHEljdNyXQ32DdksxPTlGwVUsSAcISMYCH9JnEBYPQZhOHFn ASGD1zwtN45TU+9tf45mBdTy7B/qXm2r8ddF9d/IGtjv1lP1ss7LavATZ6DMmW5L+9SL RJKv0RLLTYp3ml42r8RNvxCgSmvvMeglhMRBheZhcbvlnkxk0kwPR+2oIFmqa/zUMBDe tYiA== X-Gm-Message-State: AElRT7E57+RG2I7TxsaCs7NAuy6DC3aTUECsGoRyCwKY5EUFqpybktIE orBIIGPf2Fj5NiaxitwfLiJ6MfxMzZYmQ1JrJHeByA== X-Google-Smtp-Source: AIpwx4+e/q+ek0uDkcs4lUortC1/Zrv5Jnd4pKOK+BFhwVGbA+mcWM+wC8XJuFQP5vU4d0QjBMDZbwHK6/5qbag6NRI= X-Received: by 2002:a19:8f13:: with SMTP id r19-v6mr8320668lfd.92.1522427296406; Fri, 30 Mar 2018 09:28:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:9748:0:0:0:0:0 with HTTP; Fri, 30 Mar 2018 09:28:15 -0700 (PDT) In-Reply-To: <20180330162604.GM8476@momjian.us> References: <152074343671.1853.18284519607571497106@wrigleys.postgresql.org> <20180330151828.GL8476@momjian.us> <20180330162604.GM8476@momjian.us> From: Magnus Hagander Date: Fri, 30 Mar 2018 18:28:15 +0200 Message-ID: Subject: Re: Documentation for varbit is missing size parameter To: Bruce Momjian Cc: Euler Taveira , scott.ure@caseware.com, pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000032f1d90568a3baef" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000032f1d90568a3baef Content-Type: text/plain; charset="UTF-8" On Fri, Mar 30, 2018 at 6:26 PM, Bruce Momjian wrote: > On Fri, Mar 30, 2018 at 05:39:46PM +0200, Magnus Hagander wrote: > > On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian wrote: > > > > On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Taveira wrote: > > > 2018-03-11 1:43 GMT-03:00 PG Doc comments form < > noreply@postgresql.org>: > > > > The documentation for the varbit data type is missing the size > > parameter "[ > > > > (n) ]". > > > > > > > Good catch! It seems to be an oversight in commit > > > 768b647ead78d0d63915c1708cad13c2468f9440. The attached patch adds > it. > > > > Wow, that commit is from 2004. Patch applied and backpatched to v10. > > > > > > If it goes all the way back to 2004, why not backpatch further? > > Uh, I am always debating how important it is to backpatck vs the churn > we require of translations of our docs. In this case, it didn't seem > worthwhile to have all of those translations try to deal with this > change for all those back branches. > > If it's a clean backpatch I'd say it is -- people who are using PostgreSQL 9.6 will be reading the documentation for 9.6 etc, so they will not know about the fix then. If it's not a clean backpatch I can certainly see considering it, but if it's not a lot of effort then I'd say it's definitely worth it. I really don't think considerations for translators of the *docs* are an issue here. If you don't backpatch it, then nobody gets the fix. If you backpatch it, then English readers do get the fix, and translated docs readers *might* get the fix, depending on how they are maintained. It's not like translatable strings where if they change in a backbranch they will revert to English unless the translation is updated -- for the docs, they just don't get the fix. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/ --00000000000032f1d90568a3baef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 30, 2018 at 6:26 PM, Bruce Momjian <bruce@momjian.us>= wrote:
On Fri, Mar 30, = 2018 at 05:39:46PM +0200, Magnus Hagander wrote:
> On Fri, Mar 30, 2018 at 5:18 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Fri, Mar 16, 2018 at 01:17:04AM -0300, Euler Tav= eira wrote:
>=C2=A0 =C2=A0 =C2=A0> 2018-03-11 1:43 GMT-03:00 PG Doc comments form= <noreply@postgresql.org&g= t;:
>=C2=A0 =C2=A0 =C2=A0> > The documentation for the varbit data typ= e is missing the size
>=C2=A0 =C2=A0 =C2=A0parameter "[
>=C2=A0 =C2=A0 =C2=A0> > (n) ]".
>=C2=A0 =C2=A0 =C2=A0> >
>=C2=A0 =C2=A0 =C2=A0> Good catch! It seems to be an oversight in com= mit
>=C2=A0 =C2=A0 =C2=A0> 768b647ead78d0d63915c1708cad13c2468f9440.= The attached patch adds it.
>
>=C2=A0 =C2=A0 =C2=A0Wow, that commit is from 2004.=C2=A0 Patch applied = and backpatched to v10.
>
>
> If it goes all the way back to 2004, why not backpatch further?

Uh, I am always debating how important it is to backpatck vs the chu= rn
we require of translations of our docs.=C2=A0 In this case, it didn't s= eem
worthwhile to have all of those translations try to deal with this
change for all those back branches.

<= br>
If it's a clean backpatch I'd say it is -- people who= are using PostgreSQL 9.6 will be reading the documentation for 9.6 etc, so= they will not know about the fix then.

If it's not a cle= an backpatch I can certainly see considering it, but if it's not a lot = of effort then I'd say it's definitely worth it.

I really don't think considerations for translators of the *docs= * are an issue here. If you don't backpatch it, then nobody gets the fi= x. If you backpatch it, then English readers do get the fix, and translated= docs readers *might* get the fix, depending on how they are maintained. It= 's not like translatable strings where if they change in a backbranch t= hey will revert to English unless the translation is updated -- for the doc= s, they just don't get the fix.=C2=A0


--
--00000000000032f1d90568a3baef--