On 2/4/15 8:20 PM, Andrew Dunstan wrote:
>
> On 02/04/2015 06:53 PM, Tom Lane wrote:
>>> Or maybe use a make variable, like NO_DOC. I think that's preferable to
>>> adding more targets.
>> Unless we can come up with a new target name that obviously means
>> "world minus docs", the make-variable i
Andrew Dunstan writes:
> I'm not terribly keen on this. If you don't like "binworld", how about
> "world-no-docs"?
[ shrug... ] Doesn't bother me particularly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 02/04/2015 06:53 PM, Tom Lane wrote:
Or maybe use a make variable, like NO_DOC. I think that's preferable to
adding more targets.
Unless we can come up with a new target name that obviously means
"world minus docs", the make-variable idea may be the best.
I'm no
Peter Eisentraut writes:
> On 2/4/15 2:24 PM, Andrew Dunstan wrote:
>> On 02/03/2015 10:00 AM, David Fetter wrote:
>>> On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I realize this is slightly OT, but I wonder if it might be worth having
targets that build and install everything but the d
On 2/3/15 11:53 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Note also that you only need to present the release notes from the
>> latest stable release branch on the web site, as opposed to
>> documentation for each branch.
>
> Yeah, JD suggested the same upthread. If we went over to a sep
On 2/4/15 2:24 PM, Andrew Dunstan wrote:
>
> On 02/03/2015 10:00 AM, David Fetter wrote:
>> On Tue, Feb 03, 2015 at 09:08:45AM -0500, Andrew Dunstan wrote:
>>> On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I run `make -s -j4 world` on my i7 fairly often, and it is often
the doc build tha
On 02/03/2015 10:00 AM, David Fetter wrote:
On Tue, Feb 03, 2015 at 09:08:45AM -0500, Andrew Dunstan wrote:
On 02/03/2015 08:55 AM, Kevin Grittner wrote:
I run `make -s -j4 world` on my i7 fairly often, and it is often
the doc build that I wind up waiting for at the end.
I realize this is sli
> searchable version of the release notes.
Would be a wonderful thing if it happened.
Segregating the content by version would help -- finding lots of notes
about version 7 & 8 when I'm running 9.3/4 helps not at all.
--
Steven Lembark 3646 Flora P
> Disk space isn't the only consideration here; if it were I'd not be
> concerned about this. Processing time is an issue, and so is distribution
> size, and so is the length of the manual if someone decides to print it
> on dead trees. I also live in fear of the day that we hit some hard-to-
>
> -1. I find it very useful to be able to go back through all the
> release notes using grep, and have done so on multiple occasions. It
> sounds like this policy would make that harder, and I don't see what
> we get out of of it. It doesn't bother me that the SGML documentation
> of the releas
Peter Eisentraut writes:
> Note also that you only need to present the release notes from the
> latest stable release branch on the web site, as opposed to
> documentation for each branch.
Yeah, JD suggested the same upthread. If we went over to a separate
document containing all the historical
On 2/3/15 12:32 AM, Tom Lane wrote:
> It would not make that much of a difference in tarball size, agreed.
> It *would* make a difference in the build time and output size of the
> SGML docs --- as I mentioned at the outset, the release notes currently
> account for 25% of the SGML source linecount
Peter Eisentraut writes:
> On 2/3/15 10:11 AM, Marko Tiikkaja wrote:
>> And now that we're on the subject of ponies, it would be nice if the
>> relevant git hashes were included as well.
> That's probably not going to happen. A release-note entry is often the
> combination of many commits, and a
On 2/3/15 10:11 AM, Marko Tiikkaja wrote:
> And now that we're on the subject of ponies, it would be nice if the
> relevant git hashes were included as well.
That's probably not going to happen. A release-note entry is often the
combination of many commits, and accurately tracking those is a lot
On 2/3/15 4:04 PM, David Fetter wrote:
On Mon, Feb 02, 2015 at 08:56:19PM -, Greg Sabino Mullane wrote:
Robert Haas wrote:
but there are times when it's easier to find out what release
introduced a feature by looking at the release notes, and it's
certainly more useful if you want to send a
On Mon, Feb 02, 2015 at 08:56:19PM -, Greg Sabino Mullane wrote:
> Robert Haas wrote:
> > but there are times when it's easier to find out what release
> > introduced a feature by looking at the release notes, and it's
> > certainly more useful if you want to send a link to someone who
> > i
On Tue, Feb 03, 2015 at 09:08:45AM -0500, Andrew Dunstan wrote:
>
> On 02/03/2015 08:55 AM, Kevin Grittner wrote:
> >Tom Lane wrote:
> >>Josh Berkus writes:
> >>>On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
> I share the sentiment that the release notes *seem* too big, but the
> subse
On Tue, Feb 3, 2015 at 3:51 PM, Robert Haas wrote:
> On Mon, Feb 2, 2015 at 4:07 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
> >>> So I'm bemused by Robert's insistence that he wants that format to
> support
> >>> searches. As I said, I fin
On Mon, Feb 2, 2015 at 4:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
>>> So I'm bemused by Robert's insistence that he wants that format to support
>>> searches. As I said, I find it far more convenient to search the output
>>> of "git log" an
On 02/03/2015 08:55 AM, Kevin Grittner wrote:
Tom Lane wrote:
Josh Berkus writes:
On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
I share the sentiment that the release notes *seem* too big, but the
subsequent discussion shows that it's not clear why that's really a
problem. Exactly what p
Tom Lane wrote:
> Josh Berkus writes:
>> On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
>>> I share the sentiment that the release notes *seem* too big, but the
>>> subsequent discussion shows that it's not clear why that's really a
>>> problem. Exactly what problem are we trying to fix?
>>
>>
Josh Berkus writes:
> On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
>> I share the sentiment that the release notes *seem* too big, but the
>> subsequent discussion shows that it's not clear why that's really a
>> problem. Exactly what problem are we trying to fix?
> At a rough count of lines,
On 2/2/15 3:10 PM, Andres Freund wrote:
On February 2, 2015 9:38:43 PM CET, Robert Haas wrote:
On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
The existing release notes are not conveniently searchable, for sure;
they're not in a single file, and they don't show up on a single page
on the Web
On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
> On 2/1/15 11:10 PM, Tom Lane wrote:
>> I think it's time we changed the policy of including all release notes
>> back to the beginning in Appendix E.
>
> I share the sentiment that the release notes *seem* too big, but the
> subsequent discussion s
On Mon, Feb 2, 2015 at 6:40 PM, Peter Eisentraut-2 [via PostgreSQL] <
ml-node+s1045698n5836471...@n5.nabble.com> wrote:
> On 2/1/15 11:10 PM, Tom Lane wrote:
> > I think it's time we changed the policy of including all release notes
> > back to the beginning in Appendix E.
>
> I share the sentimen
On 2/1/15 11:10 PM, Tom Lane wrote:
> I think it's time we changed the policy of including all release notes
> back to the beginning in Appendix E.
I share the sentiment that the release notes *seem* too big, but the
subsequent discussion shows that it's not clear why that's really a
problem. Exa
On 02/02/2015 07:54 AM, Robert Haas wrote:
The last 5 branches only takes us back to 9.0, which isn't very far.
I would want to have at least the 8.x branches in the SGML build, and
maybe the 7.x branches as well. I would be happy to drop anything
pre-7.x from the docs build and just let the p
On February 2, 2015 9:38:43 PM CET, Robert Haas wrote:
>On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
>> The existing release notes are not conveniently searchable, for sure;
>> they're not in a single file, and they don't show up on a single page
>> on the Web, and I've never seen a PDF-search
Robert Haas writes:
> On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
>> So I'm bemused by Robert's insistence that he wants that format to support
>> searches. As I said, I find it far more convenient to search the output
>> of "git log" and/or src/tools/git_changelog --- I keep text files of t
On 02/02/2015 09:38 PM, Robert Haas wrote:
Well, maybe I'm the only one who is doing this and it's not worth
worrying about it just for me. But I do it, all the same.
I do the later quite often: link people to old release notes. For me it
would be fine to remove them from tar balls as long as
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Haas wrote:
> but there are times when it's easier to find out what release
> introduced a feature by looking at the release notes, and it's
> certainly more useful if you want to send a link to someone who
> is not git-aware illustrat
On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
> The existing release notes are not conveniently searchable, for sure;
> they're not in a single file, and they don't show up on a single page
> on the Web, and I've never seen a PDF-searching tool that didn't suck.
> So I'm bemused by Robert's insi
Josh Berkus writes:
> On 02/02/2015 07:54 AM, Robert Haas wrote:
>> The last 5 branches only takes us back to 9.0, which isn't very far.
>> I would want to have at least the 8.x branches in the SGML build, and
>> maybe the 7.x branches as well. I would be happy to drop anything
>> pre-7.x from th
On 02/02/2015 07:54 AM, Robert Haas wrote:
>> I could live with keeping the ancient-branch release note SGML files
>> > around in HEAD --- I'd hoped to reduce the size of tarballs a bit, but the
>> > savings by that measure would only be a few percent (at present anyway).
>> > What's more important
On Mon, Feb 2, 2015 at 10:43 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> Yeah, the PDF size is definitely someting to consider in this context. And
>> the limits.
>
>> But if we can find some good way to "archive" or preserve them *outside the
>> main docs* that should solve this problem, no
Magnus Hagander writes:
> Yeah, the PDF size is definitely someting to consider in this context. And
> the limits.
> But if we can find some good way to "archive" or preserve them *outside the
> main docs* that should solve this problem, no? We could keep them in SGML
> even, but make sure they a
On Mon, Feb 2, 2015 at 3:44 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
> >> I propose that we go over to a policy of keeping in HEAD only release
> >> notes for actively maintained branches, and that each back branch should
> >> retain notes o
Robert Haas writes:
> On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
>> I propose that we go over to a policy of keeping in HEAD only release
>> notes for actively maintained branches, and that each back branch should
>> retain notes only for branches that were actively maintained when it split
On Mon, Feb 2, 2015 at 9:57 PM, Robert Haas wrote:
> On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
>> I propose that we go over to a policy of keeping in HEAD only release
>> notes for actively maintained branches, and that each back branch should
>> retain notes only for branches that were ac
On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
> I think it's time we changed the policy of including all release notes
> back to the beginning in Appendix E. I seem to recall we debated this
> once before, and decided that we liked having all that project history
> visible. But Release 6.0 is
On 02/01/2015 08:10 PM, Tom Lane wrote:
> I propose that we go over to a policy of keeping in HEAD only release
> notes for actively maintained branches, and that each back branch should
> retain notes only for branches that were actively maintained when it split
> off from HEAD. This would keep a
Tom Lane-2 wrote
> I propose that we go over to a policy of keeping in HEAD only release
> notes for actively maintained branches, and that each back branch should
> retain notes only for branches that were actively maintained when it split
> off from HEAD. This would keep about five years worth o
I noticed that the release notes now constitute 25% of our SGML
documentation, by line count at least:
[postgres@sss1 sgml]$ wc *.sgml ref/*.sgml | tail -1
336338 1116259 11124003 total
[postgres@sss1 sgml]$ wc release-*.sgml | tail -1
85139 267417 2516545 total
Another way to measure it is
43 matches
Mail list logo
