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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
