Re: suggested CMS workflows for ooo-site

[Kay Schenk <ka...@gmail.com>]

On Wed, Jan 4, 2012 at 8:46 AM, Dave Fisher <da...@comcast.net> wrote:

>
> 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
> > publish.pl script on people.apache.org 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 publish.pl when I use my sledgehammer ;-)
>

Well I haven't been using a sledgehammer at all, I think, but routinely use
the following URL for publishing:

 https://cms.apache.org/openofficeorg/publish

you need to login to use it, however. Just a web interface to publish.pl I
think.


> I usually test my changes with local build_site.pl or build_file.pl.
>
> My observation is that the biggest bottleneck is more in the creation of
> the email reports. Particularly after publish.pl 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..
>

Probably a VERY good idea...but I'm just as happy to have a limited set of
folks (Dave!), dealing with site-wide template changes. Despite the fact
that I've looked over the templates and tried to figure them out,
well...I'm not real confident about making changes to them. :/ Unless, in
your *free* time, you might work up a nice tutorial on them. :)


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


-- 
----------------------------------------------------------------------------------------
MzK

"You will always be lucky if you know how to make friends
 with strange cats."
                                                  -- *Colonial American
proverb*

Re: suggested CMS workflows for ooo-site

[Joe Schaefer <jo...@yahoo.com>]

----- Original Message -----

> From: Kay Schenk <ka...@gmail.com>
> To: ooo-dev@incubator.apache.org
> Cc: 
> Sent: Wednesday, January 4, 2012 12:43 PM
> Subject: Re: suggested CMS workflows for ooo-site
> 
> On Wed, Jan 4, 2012 at 8:46 AM, Dave Fisher <da...@comcast.net> wrote:
> 
>> 
>>  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
>>  > publish.pl script on people.apache.org 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 publish.pl when I use my sledgehammer ;-)
>> 
> 
> Well I haven't been using a sledgehammer at all, I think, but routinely use
> the following URL for publishing:
> 
> https://cms.apache.org/openofficeorg/publish
> 
> you need to login to use it, however. Just a web interface to publish.pl I
> think.

Yes, the publish.pl script uses the same url, but it's a bit faster
there because it's delivering raw JSON content versus templatized,
markdown-enabled HTML content.  Normally the difference is negligible,
but with multimegabyte change-sets caused by slegehammer commits
the difference becomes suddenly appreciable.

> 
> 
>>  I usually test my changes with local build_site.pl or build_file.pl.
>> 
>>  My observation is that the biggest bottleneck is more in the creation of
>>  the email reports. Particularly after publish.pl returns.

FYI Dave the same advice applies here: once publish.pl completes succesfully,
the commit has been made and you don't need to wait for further confirmation
from svnmailer.


>> 
>>  >
>>  > 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..
>> 
> 
> Probably a VERY good idea...but I'm just as happy to have a limited set of
> folks (Dave!), dealing with site-wide template changes. Despite the fact
> that I've looked over the templates and tried to figure them out,
> well...I'm not real confident about making changes to them. :/ Unless, in
> your *free* time, you might work up a nice tutorial on them. :)

Just documenting my remarks in this thread on the site somewhere would be
wise IMO.  All I'm trying to point out is that a 9GB site requires more
cms usage documentation than the more typically sized <<100MB site we host.

HTH

> 
> 
>>  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
>> 
>> 
> 
> 
> -- 
> ----------------------------------------------------------------------------------------
> MzK
> 
> "You will always be lucky if you know how to make friends
> with strange cats."
>                                                   -- *Colonial American
> proverb*
>