You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Ross Gardler <rg...@apache.org> on 2005/06/08 12:56:03 UTC
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Ross Gardler wrote:
> Yes, this is my biggest complaint about Daisy right now. Every single
> change gets the same "priority" in the version management system. So if
> I change a single letter, it create a new version and generates a commit
> mail.
>
> Wiki's deal with this by allowing you to mark something as a minor edit.
> But that doesn't work in my experience, people just don't bother (try
> subscribing to an active Wikipedia page for example).
indeed. i was hoping that the frequency would be reduced by only storing
approved versions in SVN.
> However, Nicola points out that if a committer creates a document
> directly in SVN it will not be present in the Lenya repo for editing.
> Lenya will have to address this, in the medium term, in some way. I'm
> not familiar enough with Lenya to make any suggestions though.
doug chestnut is working on WebDAV integration right now, which might
help with this. as a start, people could do their docs offline, and then
add them to lenya through webdav. lenya then takes care of checking
them in to the lenya revision control, doing workflow initialization,
and whatever else is required to make a document editable in lenya.
this wouldn't solve checking into SVN yet, but it might be a reasonable
start. at least you could edit docs offline with your favorite tools.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Ross Gardler wrote:
> Yes, this is my biggest complaint about Daisy right now. Every single
> change gets the same "priority" in the version management system. So if
> I change a single letter, it create a new version and generates a commit
> mail.
>
> Wiki's deal with this by allowing you to mark something as a minor edit.
> But that doesn't work in my experience, people just don't bother (try
> subscribing to an active Wikipedia page for example).
indeed. i was hoping that the frequency would be reduced by only storing
approved versions in SVN.
> However, Nicola points out that if a committer creates a document
> directly in SVN it will not be present in the Lenya repo for editing.
> Lenya will have to address this, in the medium term, in some way. I'm
> not familiar enough with Lenya to make any suggestions though.
doug chestnut is working on WebDAV integration right now, which might
help with this. as a start, people could do their docs offline, and then
add them to lenya through webdav. lenya then takes care of checking
them in to the lenya revision control, doing workflow initialization,
and whatever else is required to make a document editable in lenya.
this wouldn't solve checking into SVN yet, but it might be a reasonable
start. at least you could edit docs offline with your favorite tools.
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Gregor J. Rothfuss wrote:
> doug chestnut is working on WebDAV integration right now, which might
> help with this. as a start, people could do their docs offline, and then
> add them to lenya through webdav. lenya then takes care of checking
> them in to the lenya revision control, doing workflow initialization,
> and whatever else is required to make a document editable in lenya.
>
> this wouldn't solve checking into SVN yet, but it might be a reasonable
> start. at least you could edit docs offline with your favorite tools.
http://issues.apache.org/bugzilla/attachment.cgi?id=15359&action=view
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by Ross Gardler <rg...@apache.org>.
Gregor J. Rothfuss wrote:
> Nicola Ken Barozzi wrote:
>
>> Hmmm... wait a second. Let's say that I add myfile.xml to SVN... can
>> it be later edited in Lenya?
>
>
> that could be made to work. needs some initialization though, because
> lenya creates worfklow histories etc for each document.
Nicola raises an important point, we need to address this.
>> Also, is it good to bypass all the publishing workflow?
>
>
> presumably, a committer knows what they are doing,
Furthermore, we are not really bypassing the publishing workflow since
it is only committers who can publish to the final docs anyway. They are
just bypassing the initial review cycle.
It's the same as the the current code contribution workflow:
Non committers:
edit code -> submit patch -> committer review -> apply patch ->
community review
committers:
edit code -> apply patch -> community review
>> What is confusing me is the presence of two repos, and editing made
>> possible on the publishing one. Please excuse my ignorance, but can't
>> Lenya use just SVN as a repo?
>
>
> that is definitely a goal, too. it currently can't, yet. another point
> for two repos is that you dont want every little diff in SVN, just the
> ones that are being approved. lenya saves a version for every edit
> cycle, and there can be an unlimited number of those before someone
> decides to submit it for approval.
Yes, this is my biggest complaint about Daisy right now. Every single
change gets the same "priority" in the version management system. So if
I change a single letter, it create a new version and generates a commit
mail.
Wiki's deal with this by allowing you to mark something as a minor edit.
But that doesn't work in my experience, people just don't bother (try
subscribing to an active Wikipedia page for example).
However, Nicola points out that if a committer creates a document
directly in SVN it will not be present in the Lenya repo for editing.
Lenya will have to address this, in the medium term, in some way. I'm
not familiar enough with Lenya to make any suggestions though.
Ross
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Nicola Ken Barozzi wrote:
> Hmmm... wait a second. Let's say that I add myfile.xml to SVN... can it
> be later edited in Lenya?
that could be made to work. needs some initialization though, because
lenya creates worfklow histories etc for each document.
> Also, is it good to bypass all the publishing
> workflow?
presumably, a committer knows what they are doing,
> What is confusing me is the presence of two repos, and editing made
> possible on the publishing one. Please excuse my ignorance, but can't
> Lenya use just SVN as a repo?
that is definitely a goal, too. it currently can't, yet. another point
for two repos is that you dont want every little diff in SVN, just the
ones that are being approved. lenya saves a version for every edit
cycle, and there can be an unlimited number of those before someone
decides to submit it for approval.
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Gregor J. Rothfuss wrote:
> Ross Gardler wrote:
>
>> -------- committers ------------. .---- Non-Committers ---
>> | |
>> | |
>> +---------+ +---------+ +-------+ +----------+
>> | Forrest |<---| SVN |<---| Lenya |--->|Lenya Repo|
>> +---------+ +---------+ +-------+ +----------+
>> . /|\ |
>> /|\ |___________|
>> |
>> +------------+
>> | Committers |
>> | Tools |
>> +------------+
>
...
>> 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.
Hmmm... wait a second. Let's say that I add myfile.xml to SVN... can it
be later edited in Lenya? Also, is it good to bypass all the publishing
workflow?
What is confusing me is the presence of two repos, and editing made
possible on the publishing one. Please excuse my ignorance, but can't
Lenya use just SVN as a repo?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
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 ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Forrest + Lenya (Re: [PROPOSAL] A CMS for our Docs)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
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 ;)