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 1gr46p-0000rD-2I for pgsql-docs@arkaria.postgresql.org; Tue, 05 Feb 2019 17:02:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gr46m-0007A8-Kl for pgsql-docs@arkaria.postgresql.org; Tue, 05 Feb 2019 17:02:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr46m-0007A1-2v for pgsql-docs@lists.postgresql.org; Tue, 05 Feb 2019 17:02:04 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr46e-00018y-QE for pgsql-docs@lists.postgresql.org; Tue, 05 Feb 2019 17:02:02 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3051F22A92; Tue, 5 Feb 2019 12:01:56 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 05 Feb 2019 12:01:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=ec4dh8RpYi5rDEN/xhaRn+n2weW EdyiceujgL1iAVLA=; b=rOlsWZENn5BRUcPRdwbBvJTER2mk/xcAiP4ZMVCCIFM F5Z3Cml8ljtmABPZdAuxA90Pt6MbGyJXYbNTUcCB0abBOIglOhv3VoytBApGuiY6 8FNYCw/fdceaduoPFoILQd/E5vOeFRUNC4N/KWKmAccJFhE9pvOva0l3AFthq+e3 eHAgrZQJu8cA2BT7djfbZccnDZzIv8ZR9BeCHYvSnTEIrFTsxLAxpzVyKQX01XJE UJRFAEA9f5XLiglglG7pOgSwPpkbEhsnisoLIyKD9Maxe2vYQgGutA84Ao5A736v wrktq9emjZzM0zUauoLhWyEDOYEqq9TeMwwgcNxAOlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ec4dh8 RpYi5rDEN/xhaRn+n2weWEdyiceujgL1iAVLA=; b=kPf78e3/K6w66CJDuCu3p1 C3/wm7KVVUfPp8STypMGQ8xW1fF3dY97A0AkNEuiCiwKPf1yaYHkxrTLkGzcyY5R AtbH9CNMyh8K+7xCwNaYsNLoxCQ9T3nWid/2qT0m0G717ZpOtN01mYm9+x5MvPEa JYGAUkfm6tZ3Tx/S9bx6zwnJJU0h34R0pOVhIUNycuwsTwZwrcmbfD0oHoPHtci9 eAsWUvGC1RKTVEo4/c8Duv5wQ1dcIjOVwiEo2iq33ym/bL3a7qqKK9NdmnDlCOSl XbOkDTqnbZ/QHC66PzfS+12pML7BsxTDTZBjZ/v+4d6tOz+cjzY12msCR7a57Skw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeeigdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgg gtuggjsehttdertddttddvnecuhfhrohhmpeetnhgurhgvshcuhfhrvghunhguuceorghn ughrvghssegrnhgrrhgriigvlhdruggvqeenucffohhmrghinhepphhoshhtghhrvghsqh hlrdhorhhgnecukfhppeduvddurddvgeegrdduheegrdehvdenucfrrghrrghmpehmrghi lhhfrhhomheprghnughrvghssegrnhgrrhgriigvlhdruggvnecuvehluhhsthgvrhfuih iivgeptd X-ME-Proxy: Received: from intern.anarazel.de (unknown [121.244.154.52]) by mail.messagingengine.com (Postfix) with ESMTPA id B2B471031C; Tue, 5 Feb 2019 12:01:53 -0500 (EST) Date: Tue, 5 Feb 2019 09:01:50 -0800 From: Andres Freund To: "Jonathan S. Katz" Cc: Tom Lane , Bruce Momjian , Magnus Hagander , Peter Eisentraut , pgsql-docs@lists.postgresql.org Subject: Re: Release note trimming: another modest proposal Message-ID: <20190205170150.yim3w67sogqw2dg3@alap3.anarazel.de> References: <20190125233111.GE13803@momjian.us> <16080.1548459680@sss.pgh.pa.us> <20190125234614.GH13803@momjian.us> <8fd2ae88-49de-26f3-def3-e4381cb7e774@postgresql.org> <21920.1548515166@sss.pgh.pa.us> <20190205060201.jo3ejddklqxb5a4q@alap3.anarazel.de> <72f54463-6912-115e-cb89-1fb552659505@postgresql.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72f54463-6912-115e-cb89-1fb552659505@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote: > On 2/5/19 1:02 AM, Andres Freund wrote: > > Hi, > > > > On 2019-01-26 10:06:06 -0500, Tom Lane wrote: > >> "Jonathan S. Katz" writes: > >>> The one "caveat" I will bring up is that once pushed and applied to the > >>> site, we would bring introduce a lot of 404s into the website. > >> > >> Hm. In principle we could probably insert some redirects, but > >> I doubt it's worth the trouble. > >> > >> If I haven't heard objections, I'll see about making this happen > >> during the first week of Feb (after the CF closes, but before > >> it's time to do the February releases' notes). > > > > Gah, I'd skipped this thread, because I was OK, if not happy, about the > > original modest proposal (trimming to supported versions). My fault. > > > > For the record: I think this is a terrible idea. Makes it much harder to > > figure out what changed when, and requires per-branch incantations to > > grep through the log. That's not to speak of the fact that now it's > > just about impossible to reference all releasenotes on the website in a > > useful manner now. > > How frequently are you referencing release notes from older versions -- > and I don't mean ones that are just deprecated, but things like 8.2? Or > even minor versions such as 8.2.5? Not never, but acceptably rare. That's why I didn't protest loudly when Tom proposed cutting those; I like having them in tree, but Tom cares about not having too many, so that seemed like a reasonable compromise. But then this thread got a lot more extreme. > Is there a way to keep a balance on the code side: keep the source files > in but don't reference them to be built? That may not help with the > tarball size, but would certainly still help build times + lower > HTML/PDF output. Well, the still supported stuff actually makes a ton of sense to have in a release. E.g. looking up minor release notes of the old release when doing a pg_upgrade makes sense. > > For crying out loud, super prominent and often referenced URLs like > > https://www.postgresql.org/docs/devel/release-10.html > > are now broken, and soon URLs like > > https://www.postgresql.org/docs/current/release-10.html > > will be too. > > We can set up some redirect rules for this in pgweb. We have a record of > what the latest version is, so we can intercept anything going to > `/current/release-(1?[0-9]+(\.[0-9]?` (untested regex) and point it to > the correct version. > > The original thought process was to _not_ do that given the effort, but > if it's just for `/current/` it may not be so bad. I think it definitely should also be on /devel/, that's what's out there on blog posts and such. I am flummoxed that we're just giving up google juice by willy nilly returning 404 for stuff that's more widely linked than the average page. It's not like we are that good placed in searches (although that's primarily related to other things). Greetings, Andres Freund