pll@lanminds.com writes:
> The problem is that this same information is needed in several places.
> I found that to be true of a lot of information contained in
> releases.txt. So, the thought I has was, can certain pieces of
> information be coerced into m4 macros such that we can change it in 1
> place, but it gets updated everywhere it's needed?
>
> This would allow for having very explicit developer docs, while also
> providing for ease of maintenance of these docs. The only down side
> I can see is that in order to actually make use of these docs, you'd
> be required at the very least, to ./configure and make (though,
> perhaps we can create a new make target dev-docs?).
>
> Thoughts/comments?
I think this is backwards.
The real issue here is the assumption that one can be "just" a release
maintainer, without being familiar with building testing Subversion.
The release manager must be comfortable building Subversion, and
comfortable running the tests (including 'make svncheck' and 'make
davcheck'), same as any other developer. One acquires such knowledge
by reading the appropriate docs: INSTALL, subversion/testing/README,
etc. Ideally, the release manager is also comfortable building the
documentation in doc/book.
All these things are background knowledge the release manager is
presumed to have. Then notes/releases.txt describes the *remaining*
stuff, stuff that's specific to releasing but not to regular
installation or development (i.e., it's a delta against the background
knowledge).
Sure, if some of those background documents are badly located or
reduntant anyway, then they can be tweaked until better. But that's
an independent issue, it has nothing to do with releases. There
shouldn't be _any_ release-manager-specific tweaks necessary.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 22:49:34 2003