You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2008/01/16 12:43:52 UTC
[Summary] IRC session: Managing our website with Lenya
Hi Lenya devs,
here's a summary of the IRC session. The IRC log can be viewed at
http://wiki.apache.org/lenya/IrcLogDocuPublication
The topic was the migration of our website to Lenya.
There was a consensus among the participants that we should migrate to
Lenya, mainly for the following reasons:
- Test scenario for collaborative editing (eat our own dogfood)
- Marketing
Conditions:
===========
- The content must be stored in the SVN repository.
- We can't commit from the zones server.
- We can't allow public access.
Issues:
=======
The central question is if we should run Lenya on the zones server or on
the local machine.
Advantages and disadvantages of the zones server:
(+) Testing scenario for collaborative work
(+) No synchronization via SVN after each change necessary
(-) Difficult SVN commit scenario
(-) It's hard to let the author of a change be the committer
Apparently most people could live with the circumstance that the author
of a change is not the committer.
When running the app on the zones, every once in a while someone would
have to commit the content:
- Copy the content from the zones server to the local sandbox via scp
- Commit the changes from your local sandbox
- Do an SVN update on the zones server
It would be discouraged to edit locally, so that SVN conflicts on the
zones server can be avoided. If conflicts occur, they would have to be
resolved manually on the zones server.
Another issue is revision control. One option would be to set Lenya's
revision history length to 0 (i.e. no backups). This means that only SVN
is used for versioning. Rolling back would mean (a) doing it manually in
the SVN sandbox on the zones server or (b) paste old content in the
source editor.
Please add more information in case I forgot something. TIA!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] IRC session: Managing our website with Lenya
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2008-01-16 at 14:35 +0100, Jörn Nettingsmeier wrote:
> ...
>> thorsten, i'm not too familiar with apache.org's security policy - would
>> the following be acceptable?:
>>
>> a lenya server runs on zones. every doc contributor gets access. to
>> reduce headache and discourage jokesters, ssl is mandatory.
>>
>> a cronjob on another machine will wget -r the live area of the zones
>> server every hour or so and copy the stuff into a local svn sandbox
>> (some minor wizardry would be needed to correctly "svn add" and "delete"
>> files, but it shouldn't be too hard).
>> when the wget is done, it either "svn commit"s the stuff automatically,
>> or a local webserver makes the repo visible as a web site that can be
>> inspected by a committer who then triggers a manual update (maybe after
>> discussion on the mailing list).
>
> I just finished a rewrite of Apache Droids a labs project
> http://labs.apache.org/labs.html that can do all of the above for us.
need to check that out, but didn't find the time yet.
> Regarding the architecture that meets the policy of the ASF AFAIK.
good to know.
> However the problem of local vs. public editing described by Andreas
> remains.
>
>> alternatively, the content could be wgotten locally and rsync'ed to the
>> other machine (i.e. manual push instead of pull at regular intervals)
>>
>
> IMO having the zones server as our docu server with a real case test of
> lenya 2.0 is preferable to local editing of our docu till we find a
> solution.
you mean running lenya.apache.org directly off a jetty? will the
infrastructure guys swallow that?
as to authoring, maybe i did not make myself all too clear: i definitely
want a test case and there would be one common lenya authoring
environment on zones, no "local editing" at all.
but since zones must not commit to svn for obvious security reasons, we
need a third machine. it can then pull the live site from zones via wget
and additionally skim the current revisions from the lenya repository on
zones (and only the current ones! stacking svn and our own version
control will make disk usage explode...) so that we have a backup of the
documentation sources in case something goes wrong with zones.
then both the live html pages and the raw data are auto-committed to
their respective svn branches.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] IRC session: Managing our website with Lenya
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2008-01-16 at 14:35 +0100, Jörn Nettingsmeier wrote:
...
> thorsten, i'm not too familiar with apache.org's security policy - would
> the following be acceptable?:
>
> a lenya server runs on zones. every doc contributor gets access. to
> reduce headache and discourage jokesters, ssl is mandatory.
>
> a cronjob on another machine will wget -r the live area of the zones
> server every hour or so and copy the stuff into a local svn sandbox
> (some minor wizardry would be needed to correctly "svn add" and "delete"
> files, but it shouldn't be too hard).
> when the wget is done, it either "svn commit"s the stuff automatically,
> or a local webserver makes the repo visible as a web site that can be
> inspected by a committer who then triggers a manual update (maybe after
> discussion on the mailing list).
I just finished a rewrite of Apache Droids a labs project
http://labs.apache.org/labs.html that can do all of the above for us.
Regarding the architecture that meets the policy of the ASF AFAIK.
However the problem of local vs. public editing described by Andreas
remains.
>
> alternatively, the content could be wgotten locally and rsync'ed to the
> other machine (i.e. manual push instead of pull at regular intervals)
>
IMO having the zones server as our docu server with a real case test of
lenya 2.0 is preferable to local editing of our docu till we find a
solution.
> i can offer a virtual server for that job. the scripts, documentation
> and configuration would be stored in our svn so that someone else can
> take over easily if i go missing or get hit by a bus. every committer
> who takes an interest gets sufficient sudo rights, and the root password
> is given to the pmc chair.
>
> wdyt?
I like the idea. wdot?
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] IRC session: Managing our website with Lenya
Posted by Bob Harner <bo...@gmail.com>.
On Jan 16, 2008 8:35 AM, Jörn Nettingsmeier <ne...@apache.org> wrote:
> Andreas Hartmann wrote:
> > http://wiki.apache.org/lenya/IrcLogDocuPublication
>
> thanks. sorry again for missing the session...
>
> > There was a consensus among the participants that we should migrate to
> > Lenya, mainly for the following reasons:
> >
> > - Test scenario for collaborative editing (eat our own dogfood)
> > - Marketing
>
> +1
>
> > Conditions:
> > ===========
> > - The content must be stored in the SVN repository.
> > - We can't commit from the zones server.
> > - We can't allow public access.
>
> no public access is a good thing.
>
> iiuc, all apache web content is static. that means we won't get load
> testing for our lenya deployment, and only use it as an "internal"
> editing environment that only committers and doc contributors would have
> access to, right?
>
>
> > Issues:
> > =======
> >
> > The central question is if we should run Lenya on the zones server or on
> > the local machine.
>
> local machine means mine, yours, everybody's?
>
> if that's the case, i'm -1, because that means we don't benefit from
> lenya's locking capabilities and would have to resolve clashes manually,
> which sucks. and we don't get a feeling for concurrency bugs that way -
> i shudder when i recall the huge pile of f&%$ups richard found during
> lab testing. our lenya server should serve as a test bed for concurrency.
>
> > Advantages and disadvantages of the zones server:
> > (+) Testing scenario for collaborative work
> > (+) No synchronization via SVN after each change necessary
> > (-) Difficult SVN commit scenario
> > (-) It's hard to let the author of a change be the committer
> >
> > Apparently most people could live with the circumstance that the author
> > of a change is not the committer.
>
> ok for me.
>
> > When running the app on the zones, every once in a while someone would
> > have to commit the content:
> > - Copy the content from the zones server to the local sandbox via scp
>
> yuck.
>
> > - Commit the changes from your local sandbox
>
> doubleyuck.
>
> > - Do an SVN update on the zones server
>
> omg.
>
> > It would be discouraged to edit locally, so that SVN conflicts on the
> > zones server can be avoided. If conflicts occur, they would have to be
> > resolved manually on the zones server.
>
> -1
>
> thorsten, i'm not too familiar with apache.org's security policy - would
> the following be acceptable?:
>
> a lenya server runs on zones. every doc contributor gets access. to
> reduce headache and discourage jokesters, ssl is mandatory.
>
> a cronjob on another machine will wget -r the live area of the zones
> server every hour or so and copy the stuff into a local svn sandbox
> (some minor wizardry would be needed to correctly "svn add" and "delete"
> files, but it shouldn't be too hard).
> when the wget is done, it either "svn commit"s the stuff automatically,
> or a local webserver makes the repo visible as a web site that can be
> inspected by a committer who then triggers a manual update (maybe after
> discussion on the mailing list).
>
> alternatively, the content could be wgotten locally and rsync'ed to the
> other machine (i.e. manual push instead of pull at regular intervals)
>
> i can offer a virtual server for that job. the scripts, documentation
> and configuration would be stored in our svn so that someone else can
> take over easily if i go missing or get hit by a bus. every committer
> who takes an interest gets sufficient sudo rights, and the root password
> is given to the pmc chair.
>
> wdyt?
>
> > Another issue is revision control. One option would be to set Lenya's
> > revision history length to 0 (i.e. no backups). This means that only SVN
> > is used for versioning. Rolling back would mean (a) doing it manually in
> > the SVN sandbox on the zones server or (b) paste old content in the
> > source editor.
>
> -1
>
> we want to test lenya's revision control.
> i think we should put as many features of lenya to daily use as possible
> (even if it means our site has some unnecessary bells and whistles).
> i'd also love to use proxying and see some load on the lenya server, but
> that is obviously not possible due to asf policy. we might artificially
> generate some load on zones by not updating the main site too frequently
> and putting a link on the front page for "bleeding edge documentation" >:->
>
>
> i hope i'm not overlooking or rehashing stuff that's been handled in the
> IRC session... comments welcome.
>
>
> jörn
>
>
>
> --
> Jörn Nettingsmeier
>
> "One of my most productive days was throwing away 1000 lines of code."
> - Ken Thompson.
>
What do the Coocoon folks do? The same Apache rules apply to them,
and yet they seem to use Daisy to manage their documentation (or am I
wrong and they use Forest?).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] IRC session: Managing our website with Lenya
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> http://wiki.apache.org/lenya/IrcLogDocuPublication
thanks. sorry again for missing the session...
> There was a consensus among the participants that we should migrate to
> Lenya, mainly for the following reasons:
>
> - Test scenario for collaborative editing (eat our own dogfood)
> - Marketing
+1
> Conditions:
> ===========
> - The content must be stored in the SVN repository.
> - We can't commit from the zones server.
> - We can't allow public access.
no public access is a good thing.
iiuc, all apache web content is static. that means we won't get load
testing for our lenya deployment, and only use it as an "internal"
editing environment that only committers and doc contributors would have
access to, right?
> Issues:
> =======
>
> The central question is if we should run Lenya on the zones server or on
> the local machine.
local machine means mine, yours, everybody's?
if that's the case, i'm -1, because that means we don't benefit from
lenya's locking capabilities and would have to resolve clashes manually,
which sucks. and we don't get a feeling for concurrency bugs that way -
i shudder when i recall the huge pile of f&%$ups richard found during
lab testing. our lenya server should serve as a test bed for concurrency.
> Advantages and disadvantages of the zones server:
> (+) Testing scenario for collaborative work
> (+) No synchronization via SVN after each change necessary
> (-) Difficult SVN commit scenario
> (-) It's hard to let the author of a change be the committer
>
> Apparently most people could live with the circumstance that the author
> of a change is not the committer.
ok for me.
> When running the app on the zones, every once in a while someone would
> have to commit the content:
> - Copy the content from the zones server to the local sandbox via scp
yuck.
> - Commit the changes from your local sandbox
doubleyuck.
> - Do an SVN update on the zones server
omg.
> It would be discouraged to edit locally, so that SVN conflicts on the
> zones server can be avoided. If conflicts occur, they would have to be
> resolved manually on the zones server.
-1
thorsten, i'm not too familiar with apache.org's security policy - would
the following be acceptable?:
a lenya server runs on zones. every doc contributor gets access. to
reduce headache and discourage jokesters, ssl is mandatory.
a cronjob on another machine will wget -r the live area of the zones
server every hour or so and copy the stuff into a local svn sandbox
(some minor wizardry would be needed to correctly "svn add" and "delete"
files, but it shouldn't be too hard).
when the wget is done, it either "svn commit"s the stuff automatically,
or a local webserver makes the repo visible as a web site that can be
inspected by a committer who then triggers a manual update (maybe after
discussion on the mailing list).
alternatively, the content could be wgotten locally and rsync'ed to the
other machine (i.e. manual push instead of pull at regular intervals)
i can offer a virtual server for that job. the scripts, documentation
and configuration would be stored in our svn so that someone else can
take over easily if i go missing or get hit by a bus. every committer
who takes an interest gets sufficient sudo rights, and the root password
is given to the pmc chair.
wdyt?
> Another issue is revision control. One option would be to set Lenya's
> revision history length to 0 (i.e. no backups). This means that only SVN
> is used for versioning. Rolling back would mean (a) doing it manually in
> the SVN sandbox on the zones server or (b) paste old content in the
> source editor.
-1
we want to test lenya's revision control.
i think we should put as many features of lenya to daily use as possible
(even if it means our site has some unnecessary bells and whistles).
i'd also love to use proxying and see some load on the lenya server, but
that is obviously not possible due to asf policy. we might artificially
generate some load on zones by not updating the main site too frequently
and putting a link on the front page for "bleeding edge documentation" >:->
i hope i'm not overlooking or rehashing stuff that's been handled in the
IRC session... comments welcome.
jörn
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] IRC session: Managing our website with Lenya
Posted by Bob Harner <bo...@gmail.com>.
On Jan 16, 2008 6:43 AM, Andreas Hartmann <an...@apache.org> wrote:
> Hi Lenya devs,
>
> here's a summary of the IRC session. The IRC log can be viewed at
> http://wiki.apache.org/lenya/IrcLogDocuPublication
>
> The topic was the migration of our website to Lenya.
>
> There was a consensus among the participants that we should migrate to
> Lenya, mainly for the following reasons:
>
> - Test scenario for collaborative editing (eat our own dogfood)
> - Marketing
>
> Conditions:
> ===========
> - The content must be stored in the SVN repository.
> - We can't commit from the zones server.
> - We can't allow public access.
>
> Issues:
> =======
>
> The central question is if we should run Lenya on the zones server or on
> the local machine.
>
> Advantages and disadvantages of the zones server:
> (+) Testing scenario for collaborative work
> (+) No synchronization via SVN after each change necessary
> (-) Difficult SVN commit scenario
> (-) It's hard to let the author of a change be the committer
>
> Apparently most people could live with the circumstance that the author
> of a change is not the committer.
>
> When running the app on the zones, every once in a while someone would
> have to commit the content:
> - Copy the content from the zones server to the local sandbox via scp
> - Commit the changes from your local sandbox
> - Do an SVN update on the zones server
>
> It would be discouraged to edit locally, so that SVN conflicts on the
> zones server can be avoided. If conflicts occur, they would have to be
> resolved manually on the zones server.
>
> Another issue is revision control. One option would be to set Lenya's
> revision history length to 0 (i.e. no backups). This means that only SVN
> is used for versioning. Rolling back would mean (a) doing it manually in
> the SVN sandbox on the zones server or (b) paste old content in the
> source editor.
>
> Please add more information in case I forgot something. TIA!
>
>
> -- Andreas
>
>
> --
> Andreas Hartmann, CTO
> BeCompany GmbH
> http://www.becompany.ch
> Tel.: +41 (0) 43 818 57 01
>
>
Why set Lenya's revision history length to 0 (i.e. no backups)? Just
to save disk space?
Also, will there be e-mail notification to the dev mailing list
whenever somebody publishes a change? (I hope so)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org