Peter Eisentraut wrote:
Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane:
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put the docs under the noses of people who have
*not* installed or even heard of the modules. So "it's not in the docs
Am Donnerstag, 30. August 2007 15:26 schrieb Tom Lane:
> I thought a large part of the desire was to improve the visibility of
> the contrib docs, ie, put the docs under the noses of people who have
> *not* installed or even heard of the modules. So "it's not in the docs
> unless you installed it"
Am Donnerstag, 30. August 2007 15:13 schrieb Andrew Dunstan:
> What? No it doesn't. You have missed the key word in the sentence above:
> "standard". The idea is that the docs will describe the *standard*
> modules, i.e. those that ship with the PostgreSQL core distribution
> (because they are curr
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> If you want to design a pluggable documentation system then go for it,
> but it's not required by what I understand is the consensus plan for
> contrib.
I thought a large part of the desire was to improve the visibility of
the contrib docs, ie, put th
Peter Eisentraut wrote:
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
Also, let's recall what has previously been discussed for contrib,
namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modularized.
Am Mittwoch, 29. August 2007 20:27 schrieb Andrew Dunstan:
> Also, let's recall what has previously been discussed for contrib,
> namely that we break it out into standard modules
But that would also mean that the documentation system is somewhat
modularized. That is, if I deinstall some module,
Am Mittwoch, 29. August 2007 20:18 schrieb Neil Conway:
> I wonder if it would be possible to keep the master version of the
> contrib docs as SGML, and generate plaintext READMEs from it during the
> documentation build.
Using asciidoc you could do it the other way around.
--
Peter Eisentraut
h
Andrew Dunstan a écrit :
>
>
> Albert Cervera i Areny wrote:
>>> I'm very strongly in favor of having this documentation. However, I
>>> think
>>> it might make sense to put "Contrib Modules" as a section under either
>>> "Reference" or "Appendices". Also, I don't think it's necessary to make
>
Albert Cervera i Areny wrote:
I'm very strongly in favor of having this documentation. However, I think
it might make sense to put "Contrib Modules" as a section under either
"Reference" or "Appendices". Also, I don't think it's necessary to make
each command option a separate subchapter, but
>
> I'm very strongly in favor of having this documentation. However, I think
> it might make sense to put "Contrib Modules" as a section under either
> "Reference" or "Appendices". Also, I don't think it's necessary to make
> each command option a separate subchapter, but I can see how that woul
Josh Berkus <[EMAIL PROTECTED]> writes:
> Further, you know we don't finish the docs until beta. Ever.
Right, working on docs is a standard beta-period activity. I think
Greg is suggesting that right now is not the time to think about
improving contrib docs --- right now is the time to keep our
On 8/29/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Scott Marlowe escribió:
>
> > Could the contrib README files couldn't be generated from the same
> > source as the docs (i.e. sgml) and then put into the appropriate
> > contrib/module/ directory.
>
> Sure they can. We already do that for INS
On Wed, 29 Aug 2007, Josh Berkus wrote:
Further, you know we don't finish the docs until beta. Ever.
In that context, as long as the documentation cleanup doesn't slow the
schedule for when beta starts I think it would be a great thing to slip
into 8.3. In fact, if those are going higher-p
Scott Marlowe escribió:
> Could the contrib README files couldn't be generated from the same
> source as the docs (i.e. sgml) and then put into the appropriate
> contrib/module/ directory.
Sure they can. We already do that for INSTALL for example.
--
Alvaro Herrera
Josh Berkus wrote:
Having the contrib stuff in the main docs would remove one of the largest barriers
to people knowing about the contrib features.
Using PostgreSQL since Version 7.1.3 and reading this List since - I
dont't know exactly but my current archives start in 2003 which was the
la
Josh Berkus wrote:
Greg,
Are you suggesting to add an additional piece of work to the already
behind schedule 8.3 timeline when there's already this idea floating
around to overhaul the entire contrib structure in 8.4, which may very
well make much of that work redundant? Albert's work is
Greg,
> Are you suggesting to add an additional piece of work to the already
> behind schedule 8.3 timeline when there's already this idea floating
> around to overhaul the entire contrib structure in 8.4, which may very
> well make much of that work redundant? Albert's work is cool and all, but
On Aug 29, 2007, at 13:27 , Andrew Dunstan wrote:
Also, let's recall what has previously been discussed for contrib,
namely that we break it out into standard modules (think Perl
standard modules) and other tools, and that we abandon the wholly
misleading "contrib" name altogether. I reall
On 8/29/07, Mario Gonzalez <[EMAIL PROTECTED]> wrote:
> On 29/08/2007, Neil Conway <[EMAIL PROTECTED]> wrote:
> >
> > I wonder if it would be possible to keep the master version of the
> > contrib docs as SGML, and generate plaintext READMEs from it during the
> > documentation build.
> >
>
> Hel
On Wed, 29 Aug 2007, Josh Berkus wrote:
Guys, would it be out of the question to do this in 8.3? Please please?
Are you suggesting to add an additional piece of work to the already
behind schedule 8.3 timeline when there's already this idea floating
around to overhaul the entire contrib str
On 29/08/2007, Neil Conway <[EMAIL PROTECTED]> wrote:
>
> I wonder if it would be possible to keep the master version of the
> contrib docs as SGML, and generate plaintext READMEs from it during the
> documentation build.
>
Hello Neil, I think I'm doing something similar but not with README
file
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
If we go ahead with this, I'll commit to doing a contrib README
cleanup so the doc system works better.
Why wouldn't we just remove the README files altogether? I can't
see maintaining duplicate sets of documentation.
Ri
On Wed, 2007-08-29 at 13:53 -0400, Tom Lane wrote:
> Why wouldn't we just remove the README files altogether? I can't
> see maintaining duplicate sets of documentation.
I agree that duplication is bad, but I think README files in the
individual contrib directories is useful and worth keeping: if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> If we go ahead with this, I'll commit to doing a contrib README
>> cleanup so the doc system works better.
>
> Why wouldn't we just remove the README files altogether? I can't
> see maintai
Josh Berkus <[EMAIL PROTECTED]> writes:
> If we go ahead with this, I'll commit to doing a contrib README
> cleanup so the doc system works better.
Why wouldn't we just remove the README files altogether? I can't
see maintaining duplicate sets of documentation.
regards, t
On Wed, Aug 29, 2007 at 10:09:07AM -0700, Josh Berkus wrote:
> Albert,
>
> (crossed over to -docs, where it really belongs)
>
> > I've been working on converting the current README files for all contrib
> > modules into sgml and add it to the documentation. There are still some
> > fixes to do bu
Albert,
(crossed over to -docs, where it really belongs)
> I've been working on converting the current README files for all contrib
> modules into sgml and add it to the documentation. There are still some
> fixes to do but i'd like to have some feedback. Indeed, it wasn't agreed to
> have all if
There is a problem with line feeds for contrib/xml2:
http://www.nan-tic.com/ftp/pgdoc/xml2.html
As for idea itself, I find it very useful (besides usability
improvements, it would help to promote Postgres advanced features).
On 8/29/07, Albert Cervera i Areny <[EMAIL PROTECTED]> wrote:
> I've bee
I've been working on converting the current README files for all contrib
modules into sgml and add it to the documentation. There are still some fixes
to do but i'd like to have some feedback. Indeed, it wasn't agreed to have
all if any of the modules together with the core documentation.
You c
29 matches
Mail list logo
