forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregor J. Rothfuss" <gre...@apache.org>
Subject Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Date Wed, 08 Jun 2005 13:57:45 GMT
Ross Gardler wrote:

> -------- committers ------------. .---- Non-Committers ---
>                                 | |
>                                 | |
> +---------+    +---------+    +-------+    +----------+
> | Forrest |<---| SVN     |<---| Lenya |--->|Lenya Repo|
> +---------+    +---------+    +-------+    +----------+
>                    .               /|\          |
>                   /|\               |___________|
>                    |
>               +------------+
>               | Committers |
>               | Tools      |
>               +------------+
> 

nice diagram!

> 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?

lenya uses pessimistic offline locking. with svn 1.2, there is now lock 
support, so this should'nt be a problem.


>> 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)

+1

>> 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).

exactly.

>> 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.

the mail workflow becomes important once there is such a huge amount of 
changes that approval needs to be super-efficient. i'm glad if we get to 
a level where we have such problems ;)

Mime
View raw message