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
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
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
-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
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
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 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
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 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
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
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
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
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
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
>
> 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
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
16 matches
Mail list logo
