Nicola Ken Barozzi wrote:
(cc'd to Lenya Dev for their comments as well - please reply-all)
...
Looking at the Doco document [1] I see that Lenya and Forrest are not
directly interacting, as both talk to a common repository.
Right now, what we have is:
--- committers ---. .---- Non-Committers ---
| |
| |
+---------+ +-------+ +----------+
| Forrest |<---| Lenya |<-->|Lenya Repo|
+---------+ +-------+ +----------+
(I've simplified by ignoring other repository types, but we should
remember Forrest can now integrate content from multiple repositories,
for example, Tim has the Locationmap working with a slide repo and you
know that we have Daisy too)
This architecture does not allow for committers to write docs with their
preferred tools via SVN, as has been requested. Nor does it keep the
published artifacts in SVN as is desired on Apache projects. So I see
the target architecture like this:
-------- committers ------------. .---- Non-Committers ---
| |
| |
+---------+ +---------+ +-------+ +----------+
| Forrest |<---| SVN |<---| Lenya |--->|Lenya Repo|
+---------+ +---------+ +-------+ +----------+
. /|\ |
/|\ |___________|
|
+------------+
| Committers |
| Tools |
+------------+
So non-committers edit freely in the Lenya repo but cannot publish
within Lenya. When an edit is reviewed and published by a committer,
that change is propagated to SVN.
Committers can use whatever tool they prefer, working directly with SVN
or with Lenya.
In this model there is the potential for conflict between edits in the
Lenya Repo that have not yet been published and edits by committers
working directly with SVN. In my view this is no more of a problem than
the potential for conflicts between in progress edits on individual
checked out copies of SVN, or at least if we stay on top of publishing
changes to Lenya this should be the case. What do others think about this?
What do you think about this architecture, is it really needed? I'm not
sure it's *that* different from asking Lenya to get the docs for us, as
it's a simple URL request. Basically, Lenya would be doing what the
SLIDE+LENYA combo does in the graphic, thus removing the need for DASL
that only Slide at Apache has, making us use Subversion.
I agree. The above is very similar to the original proposal minus the
mail workflow)
What remains to do are diffs.
The above gives us diffs of published documents but Lenya does not
publish good diffs of edits of its own repository. However, the Lenya
community are addressing this (I have a Summer of Code applicant who has
expressed interest in this aspect and a couple of Lenya devs have agreed
to co-mentor).
I'm not sure that the mail workflow is
something we really need ATM. IMHO just adding editors that cannot
publish, along with diffs, is something that gives us enough control.
I agree. The mail workflow is a nice have. It would be wonderful to be
able to publish simple changes by replying to a mail as is proposed in
[1]. But we can manage with the diffs and a link to an URL to publish
the changes, and another to reject the changes.
Ross
[1] http://wiki.apache.org/cocoon/Doco
