incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: suggested CMS workflows for ooo-site
Date Wed, 04 Jan 2012 17:29:51 GMT
Also Dave get in the habit of checking buildbot for the
build status of sledgehammer commits instead of waiting
for svnmailer to figure out what to do with the massive
diff it's trying to make sense of.  The url is

You may want to turn this thread into some basic cms
usage documentation on the incubator/openofficeorg site.

----- Original Message -----
> From: Joe Schaefer <>
> To: "" <>
> Cc: 
> Sent: Wednesday, January 4, 2012 11:51 AM
> Subject: Re: suggested CMS workflows for ooo-site 
> You can always mimic exactly what the staging site
> does with its builds, namely target the build to
> a checkout of
> When the build finishes you can just svn diff that
> tree to see what you actually changed, but *please*
> do not commit back those changes yourself.  You
> can nuke all your changes to that tree with svn revert -R
> so it's handy for testing different types of sledgehammers.
>> ________________________________
>>  From: Dave Fisher <>
>> To: 
>> Sent: Wednesday, January 4, 2012 11:46 AM
>> Subject: Re: suggested CMS workflows for ooo-site 
>> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>>>  Given that the size of ooo-site is around 9GB, there
>>>  are some unique challenges here in dealing with the CMS.
>>>  For the most part tho, the typical workflow of editing
>>>  a few pages on the site, committing them, and publishing
>>>  them can all be done reasonably effectively using the CMS
>>>  website.
>>>  OTOH, people who need to monkey with templates/** or lib/**
>>>  files will trigger full site builds and their changes may
>>>  materially impact every file on the site.  While I've now
>>>  reduced the build time to around 4 minutes, the bottleneck
>>>  now remains squarely in the time it takes svn to commit back
>>>  those changes and to deal with merging those changes during
>>>  publication requests.
>> Thanks for your improvements. 
>>>  In those circumstances I strongly advise you to use the
>>> script on to review and if
>>>  ok publish your changes.  This will eliminate the chances
>>>  that your browser times out a direct publish request to the
>>>  CMS site, which is a real hassle given that it takes ~15
>>>  minutes for a largeish publish request to be processed.
>> I always use when I use my sledgehammer ;-)
>> I usually test my changes with local or
>> My observation is that the biggest bottleneck is more in the creation of the 
> email reports. Particularly after returns.
>>>  In the near future we will be upgrading svn to 1.7 on the CMS
>>>  server which will bring in better performance along with
>>>  full support for deletions via svn, but I don't expect the
>>>  performance changes to significantly alter the workflow I'm
>>>  recommending here.
>>>  And please for the sake of others who want to work on minor
>>>  changes to the site, don't make a sledgehammer type commit
>>>  without following up with an eventual publish request, because
>>>  publish requests are an all-or-nothing type deal.  That means
>>>  a sledgehammer commit will cause unreasonable delays for people
>>>  who are trying to publish minor changes to the site, until
>>>  the person who did the sledgehammer commit follows thru and
>>>  publishes everything.
>> I would recommend that larger template and skeleton changes with the whole 
> ooo-site are done locally and fully tested before committing to svn..
>> Do you have any recommendations for comparing a locally built site with 
> current production in order to understand how big a sledgehammer is being built?
>> Regards,
>> Dave
>>>  HTH

View raw message