Jerome Louvel wrote:
Hi Marc,
It sounds like I should do an effort to make you stick to Daisy :-)
(as in even for the designer/development discussions )
I think that handling our community wiki, especially the developer guide is
a great opportunity to discover more deeply Daisy. If in the future, Daisy
proposes a set of integrated developer tools similar to Trac, I would be
happy to extend our usage to the www.restlet.net site too, especially if
Daisy could run directly on Restlets :)
wouldn't that be great!
ok let me be brutally ambitious here: such is not far from my nirvana
either, but there is a fair road to travel to be honest :-)
While I check with Rob and our hosting infrastructure to find
a hosting spot to land this, we can discuss a minimal
documentation-structure to
be set up.
For the hosting I'm thinking about using the Restlet.org server. However as
I have a single IP address, I'll need to set-up a Restlet redirector to
tunnel requests to the Daisy's Jetty instance.
hm, there is a fair amount of links you'll need to be rewriting I'm
afraid...
might be easier to just allocate the dns entry docs.restlet.org to point
to the actual hosting environment that Rob has made avaialble...
Here is what I have in mind:
[1] Main/Entry
[...]
[2] Documentation ! PER RELEASE
That looks very good to me!
I've started on this, as soon as ports become public I'll let you peek
(and participate)
Additionally:
* We need to agree on the level of branching: for which kind
of releases
do we build/unify documentation releases? (for every patch-release?
1.0.4, 1.0.5, ... or rather for every minor release: one doc
for 1.0.x?
Yes, one very for every minor version. The changes log should be enough to
document the patch release, at least in a first time.
ok cool
this means I should be setting up now for 1.0 or 1.1?
typical advise: to keep up I would guess the number of documented
releases should not exceed 2 per year.)
So far, we are more one a one release per year mode.
ok
* Daisy allows for setting up notification emails (similar to
commit-mails)
Do we set this up to be sending mails to one of the lists or do we
expect anyone to do that for themselves (actually there are also rss
feeds with changes available)
I think we could send those emails to [EMAIL PROTECTED] which is
also used for SVN commit emails.
will do so after the initial setup, doesn't make sense sending the
current preparation noise to the list yet
* Next to that we might agree on marking emails on this list that
discuss the documentation with the label [book]
Yes, that sounds good. If the amount of exchanges justify it, we could also
start a dedicated mailing list or at least a developers mailing list.
* I will need some time to work out the docbook thingy (basically it
will boil down to some xslt to convert the daisy-book-xml to docbook.
Any input from someody knowledgeable to docbook to craft out the
template-output is appreciated.
The main need for docbook was to have a standard format and to be able to
publish a static HTML files or PDF or something else easily. As Daisy
already supports this based on its own XML format, that seems sufficient for
me.
ok cool
* One of my colleagues built some extension to link up to existing
javadoc. I need to copy that over and install it, but of course only
makes sense
That could be interesting indeed. Do you have a demo or more documentation
about this feature?
as it turns out it's just xslt link-rewriting: you just add a link of
type a/@href="javadoc:full.class.Name" in the docs and tzadaam when it's
up on display in the browser it will point to
http://prefix-for-published-javadoc/version/correct-path
PS: don't worry: there is an automated task in daisy to make a new
branch of your documents based on the old one (I am not suggesting to
rewrite everything from scratch for eveery release :-))
Excellent!
Best regards,
Jerome
regards,
-marc=
