Michael Paquier writes:
> On Thu, Dec 21, 2023 at 02:22:02PM -0500, Tom Lane wrote:
>> Here's a draft patch for this. Most of it is mechanical removal of
>> infrastructure for building the INSTALL file. If anyone wants to
>> bikeshed on the new wording of README
On Thu, Dec 21, 2023 at 02:22:02PM -0500, Tom Lane wrote:
> Here's a draft patch for this. Most of it is mechanical removal of
> infrastructure for building the INSTALL file. If anyone wants to
> bikeshed on the new wording of README, feel free.
Thanks for putting this togethe
oncrete patch proposal in a little
>> bit.
> Cool.
Here's a draft patch for this. Most of it is mechanical removal of
infrastructure for building the INSTALL file. If anyone wants to
bikeshed on the new wording of README, feel free.
regards, tom lane
diff -
Hi,
On 2023-12-21 10:46:02 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-12-21 10:22:49 -0500, Tom Lane wrote:
> >> We could make it version-specific,
> >> https://www.postgresql.org/docs/17/installation.html
> >> and task src/tools/version_stamp.pl with updating it. But that's
> >>
Andres Freund writes:
> On 2023-12-21 10:22:49 -0500, Tom Lane wrote:
>> We could make it version-specific,
>> https://www.postgresql.org/docs/17/installation.html
>> and task src/tools/version_stamp.pl with updating it. But that's
>> problematic for not-yet-released branches (there's no 17 today
Hi,
On 2023-12-21 10:22:49 -0500, Tom Lane wrote:
> I think the only real question is what URL to point at exactly. We can't
> simply say
>
> https://www.postgresql.org/docs/current/installation.html
>
> because that will be wrong for any version more than one major
> release back.
Right.
>
Andres Freund writes:
> On 2023-12-21 08:39:26 +0900, Michael Paquier wrote:
>> On Wed, Dec 20, 2023 at 11:36:28AM -0500, Tom Lane wrote:
>>> I thought the plan was to get rid of that file, in pursuit of making
>>> our distribution tarballs be more or less pure git pulls. Instead of
>>> expending
> On 21 Dec 2023, at 10:16, Andres Freund wrote:
>
> Hi,
>
> On 2023-12-20 15:28:56 +0100, Daniel Gustafsson wrote:
>> + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL
>> unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs
>> targets..
>
> Well, building the P
Hi,
On 2023-12-21 08:39:26 +0900, Michael Paquier wrote:
> On Wed, Dec 20, 2023 at 11:36:28AM -0500, Tom Lane wrote:
> > Andres Freund writes:
> >> We fairly regularly have commits breaking the generation of INSTALL. IIRC
> >> we
> >> recently discussed building it locally unconditionally, but I
Hi,
On 2023-12-20 15:28:56 +0100, Daniel Gustafsson wrote:
> + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL
> unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs
> targets..
Well, building the PDF takes a *long* time and is rarely required. I think
there's an
On 2023-12-21 08:44:33 +0900, Michael Paquier wrote:
> On Wed, Dec 20, 2023 at 03:28:56PM +0100, Daniel Gustafsson wrote:
> > + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL
> > unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs
> > targets..
>
> That seems rel
On Wed, Dec 20, 2023 at 03:28:56PM +0100, Daniel Gustafsson wrote:
> + time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL
> unrelated pet peeve: "make -C doc/src/sgml all" doesn't build all docs
> targets..
That seems relevant in terms of coverage. Why not just moving the
INSTALL bit
On Wed, Dec 20, 2023 at 11:36:28AM -0500, Tom Lane wrote:
> Andres Freund writes:
>> We fairly regularly have commits breaking the generation of INSTALL. IIRC we
>> recently discussed building it locally unconditionally, but I couldn't
>> immediately find that discussion. Until then, I think we s
Andres Freund writes:
> We fairly regularly have commits breaking the generation of INSTALL. IIRC we
> recently discussed building it locally unconditionally, but I couldn't
> immediately find that discussion. Until then, I think we should at least
> build it in CI so that cfbot can warn.
I thou
> On 20 Dec 2023, at 15:15, Andres Freund wrote:
> The attached patch had a slight bug. Also turned out that the CI environment
> didn't have pandoc installed. Fixed that.
LGTM.
+ time make -s -j${BUILD_JOBS} -C doc/src/sgml all INSTALL
unrelated pet peeve: "make -C doc/src/sgml all" doesn
Hi,
The attached patch had a slight bug. Also turned out that the CI environment
didn't have pandoc installed. Fixed that.
Greetings,
Andres Freund
>From 6a8157b2f14327351798c805a873e9e910f5cd67 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Wed, 20 Dec 2023 03:44:44 -0800
Subject: [PATCH v
Hi,
We fairly regularly have commits breaking the generation of INSTALL. IIRC we
recently discussed building it locally unconditionally, but I couldn't
immediately find that discussion. Until then, I think we should at least
build it in CI so that cfbot can warn.
Greetings,
Andres Freund
>From
On 4/6/19 3:18 AM, Andres Freund wrote:
Given nothing happened since then I think we ought to mark this as
returned with feedback? Will do so tomorrow.
Agreed, marked as Returned with Feedback.
Regards,
--
-David
da...@pgmasters.net
Hi,
On 2019-03-21 22:06:36 +0400, David Steele wrote:
> On 2/15/19 11:59 AM, Peter Eisentraut wrote:
> > On 14/02/2019 20:13, Andres Freund wrote:
> > > On 2019-02-04 11:02:44 +0900, Michael Paquier wrote:
> > > > +1. I have just looked at the patch, and my take is that listing all
> > > > the wa
Hi Andreas,
On 2/15/19 11:59 AM, Peter Eisentraut wrote:
On 14/02/2019 20:13, Andres Freund wrote:
On 2019-02-04 11:02:44 +0900, Michael Paquier wrote:
+1. I have just looked at the patch, and my take is that listing all
the ways to build Postgres directly in the README is just a
duplication
On 14/02/2019 20:13, Andres Freund wrote:
> On 2019-02-04 11:02:44 +0900, Michael Paquier wrote:
>> +1. I have just looked at the patch, and my take is that listing all
>> the ways to build Postgres directly in the README is just a
>> duplication of what we already have in the documentation. So I
Hi,
On 2019-02-04 11:02:44 +0900, Michael Paquier wrote:
> +1. I have just looked at the patch, and my take is that listing all
> the ways to build Postgres directly in the README is just a
> duplication of what we already have in the documentation. So I would
> just rip out all that and keep a
On Mon, Jan 28, 2019 at 10:21:03PM +0100, Peter Eisentraut wrote:
> I'm not in favor of listing all these versions here. It's one more
> thing to keep updated. The version requirements are not outrageous, so
> we can assume that someone with a reasonably up-to-date development
> machine has appro
On 03/11/2018 00:14, Andreas 'ads' Scherbaum wrote:
> GNU make, version 3.8 or newer
> ISO/ANSI C compilar (at least C99-compliant)
> Flex 2.5.31 or later, and Bison 1.875 or later (for building from git)
> Perl 5.8.3 (for building from git)
I'm not in favor of listing all these versions here. It
On 11/01/2019 22:05, Tom Lane wrote:
>> 2. If there's no pandoc, this coding silently produces a zero-size
>> INSTALL file. I do not find that acceptable.
>
> Seems like it might be sufficient for the rule to be
>
> $(PANDOC) $< -t plain > $@.tmp
&
Hi!
On Fri, Jan 11, 2019 at 1:05 PM Tom Lane wrote:
> Failure would leave a .tmp file behind, but I doubt we care enough
> about that to work harder than this.
Maybe just make sure that "make clean" removes it?
Mitar
--
http://mitar.tnode.com/
https://twitter.com/mitar_m
the following languages:
...
> 2. If there's no pandoc, this coding silently produces a zero-size
> INSTALL file. I do not find that acceptable.
Seems like it might be sufficient for the rule to be
$(PANDOC) $< -t plain > $@.tmp
$(ICONV) -f utf8 -t us-ascii//TRANS
Peter Eisentraut writes:
> On 09/01/2019 10:05, Mi Tar wrote:
>> I tested this. Patch applied cleanly and INSTALL file was produced.
>> Formatting looks differently from before, but I think that it looks better.
>> We lost central alignment of some headings, but many
On 09/01/2019 10:05, Mi Tar wrote:
> I tested this. Patch applied cleanly and INSTALL file was produced.
> Formatting looks differently from before, but I think that it looks better.
> We lost central alignment of some headings, but many code/command snippets
> are now better/correc
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, failed
Hi!
I tested this. Patch applied cleanly and INSTALL file was produced
On 03.11.18 18:06, Stephen Frost wrote:
Greetings,
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
On 02.11.18 01:38, Stephen Frost wrote:
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
How about the attached one? Picked up your draft, and cleaned it up a bit.
(unsurprisingly) this is looki
Greetings,
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
> On 02.11.18 01:38, Stephen Frost wrote:
> >* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
> >>How about the attached one? Picked up your draft, and cleaned it up a bit.
> >(unsurprisingly) this is looking pretty good to me.
> >
> >A few
On Fri, Nov 02, 2018 at 06:47:19AM -0400, Stephen Frost wrote:
> As for what's in the README on the master branch, I was saying that it
> *should* point to the development documentation, since that should be
> current with whatever is actually in the git repo (or only a day behind
> or such).
Defi
On 02.11.18 01:38, Stephen Frost wrote:
Greetings,
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
How about the attached one? Picked up your draft, and cleaned it up a bit.
(unsurprisingly) this is looking pretty good to me.
A few additional notes:
Incorporated. See the attached.
If that
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Nov 01, 2018 at 08:42:34PM -0400, Stephen Frost wrote:
> > If we go down this route, the master branch should probably link to the
> > regularly built devel documentation, so that if/when we do make such a
> > change, we'll point
On Thu, Nov 01, 2018 at 08:42:34PM -0400, Stephen Frost wrote:
> If we go down this route, the master branch should probably link to the
> regularly built devel documentation, so that if/when we do make such a
> change, we'll point people at the updated documentation too.
I don't know how others f
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Nov 01, 2018 at 01:41:33PM -0400, Stephen Frost wrote:
> > I'm not sure that I'm really following this, because we aren't pointing
> > to the development documentation, just the 'current' documentation, and
> > that seems fine, an
Greetings,
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
> How about the attached one? Picked up your draft, and cleaned it up a bit.
(unsurprisingly) this is looking pretty good to me.
A few additional notes:
> PostgreSQL Database Management System
> =
>
On Thu, Nov 01, 2018 at 01:41:33PM -0400, Stephen Frost wrote:
> I'm not sure that I'm really following this, because we aren't pointing
> to the development documentation, just the 'current' documentation, and
> that seems fine, and there's links on that page to the other versions of
> the page fo
On 01.11.18 18:41, Stephen Frost wrote:
Greetings,
* Andreas 'ads' Scherbaum (a...@pgug.de) wrote:
On 01.11.18 07:26, Michael Paquier wrote:
It includes links to the website, as well as the short version of the
installation instructions.
+The installation instructions are listed on the websit
The release process
> can replace this with links to the current version.
I'm not sure that I'm really following this, because we aren't pointing
to the development documentation, just the 'current' documentation, and
that seems fine, and there's links on that page to the other versions of
the page for each major version of PostgreSQL, in case someone pulled an
older branch or such.
In short, I think we're fine to just use the 'current' URLs in this
README.
I'd also update the 'Makefile' bit we have at the root to refer to the
README instead of the INSTALL file.
Thanks!
Stephen
signature.asc
Description: PGP signature
On 01.11.18 07:26, Michael Paquier wrote:
On Thu, Nov 01, 2018 at 01:32:09AM +0100, Andreas 'ads' Scherbaum wrote:
Picking up on this idea, attached is a first draft for changing the
README.
Why don't you add it to the upcoming commit fest? It would be good to
get some traction with a formal r
On Thu, Nov 01, 2018 at 01:32:09AM +0100, Andreas 'ads' Scherbaum wrote:
> Picking up on this idea, attached is a first draft for changing the
> README.
Why don't you add it to the upcoming commit fest? It would be good to
get some traction with a formal review.
> It includes links to the websit
On 01.11.18 01:29, Michael Paquier wrote:
On Wed, Oct 31, 2018 at 08:30:40AM -0400, Stephen Frost wrote:
Agreed, we should really improve the README by merging the README.git
into it and make the project, as a whole, more accessible to new
developers.
+1. I think as well that this approach wou
Hi,
On 2018-11-01 09:29:37 +0900, Michael Paquier wrote:
> On Wed, Oct 31, 2018 at 08:30:40AM -0400, Stephen Frost wrote:
> > Agreed, we should really improve the README by merging the README.git
> > into it and make the project, as a whole, more accessible to new
> > developers.
>
> +1. I think
On Wed, Oct 31, 2018 at 08:30:40AM -0400, Stephen Frost wrote:
> Agreed, we should really improve the README by merging the README.git
> into it and make the project, as a whole, more accessible to new
> developers.
+1. I think as well that this approach would be a good thing.
--
Michael
signat
d be to actually *remove* the currently confusing README from the
git repo in its current form and also generate it as part of the tarball
build, but that seems like it's going very much in the wrong direction.
> >>Right, thanks. That's why one of my proposals was to have an INSTALL
distributed tarball, while
README.git is
automatically removed when running "make distdir". Looking at
README is
the first thing I do when checking out any project or after
decompressing any source code tarball, so things could be better.
Right, thanks. That's why one of my propos
tically removed when running "make distdir". Looking at README is
the first thing I do when checking out any project or after
decompressing any source code tarball, so things could be better.
Right, thanks. That's why one of my proposals was to have an INSTALL
file in place,
README is
the first thing I do when checking out any project or after
decompressing any source code tarball, so things could be better.
Right, thanks. That's why one of my proposals was to have an INSTALL
file in place, and overwrite it during the tarball creation process.
This way the gene
>
> > That is not the first file people looking at. Especially not people
> looking
> > at the GitHub copy:
> >
> > https://github.com/postgres/postgres
> >
> > I understand that there is documentation, but for the casual developer
> > looking at this, it seems broken.
>
> FWIW, I think that people
On Mon, Oct 29, 2018 at 01:01:47PM +0100, Andreas 'ads' Scherbaum wrote:
> That is not the first file people looking at. Especially not people looking
> at the GitHub copy:
>
> https://github.com/postgres/postgres
>
> I understand that there is documentation, but for the casual developer
> looking
m: the README refers to an
"INSTALL" file, which is present in packages, but not in the source
repo. This is very confusing for beginners, and should be avoided.
There are a couple options to fix this:
1. Update the README, and remove the "INSTALL" reference
2. Creat
On 10/28/2018 08:13 AM, Andreas 'ads' Scherbaum wrote:
Hello,
while working with Google Code-In students, there is one task: "clone
PostgreSQL from git repository, and build from source".
This brought up an interesting problem: the README refers to an
"INSTALL&q
Hello,
while working with Google Code-In students, there is one task: "clone
PostgreSQL from git repository, and build from source".
This brought up an interesting problem: the README refers to an "INSTALL"
file, which is present in packages, but not in the source repo. Th
Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From dfed8d84d1738ecca6721e97b13e86cf481aaf6c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Mon, 23 Apr 2018 10:40:17 -0400
Subject: [PATCH] Create INSTALL file using Pandoc
Rep
56 matches
Mail list logo
