incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: suggested CMS workflows for ooo-site
Date Thu, 05 Jan 2012 05:45:17 GMT

On Jan 4, 2012, at 5:00 PM, Daniel Shahaf wrote:

> Joe Schaefer wrote on Wed, Jan 04, 2012 at 16:55:02 -0800:
>> ----- Original Message -----
>>> From: Daniel Shahaf <>
>>> To: Joe Schaefer <>
>>> Cc: "" <>;
>>> Sent: Wednesday, January 4, 2012 6:57 PM
>>> Subject: Re: suggested CMS workflows for ooo-site
>>> Joe Schaefer wrote on Wed, Jan 04, 2012 at 09:52:39 -0800:
>>>> ----- Original Message -----
>>>>> From: Dave Fisher <>
>>>>> To:
>>>>> Cc: 
>>>>> Sent: Wednesday, January 4, 2012 12:40 PM
>>>>> Subject: Re: suggested CMS workflows for ooo-site 
>>>>> On Jan 4, 2012, at 9:29 AM, Joe Schaefer wrote:
>>>>>>   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 
>>>>> I do do that, but tend to wait for the email anyway. If there is no 
>>> reason to 
>>>>> wait that will save time.
>>>> Buildbot performs the commit back as the final step in the build,
>>>> so if buildbot thinks the build has completed successfully, you
>>>> do not need to wait for svnmailer to send out a notice to that effect.
>>>> My experience is that the turnaround between sledgehammer commits
>>>> and eventual publication is about 1 hour: ~20 min for each step
>>>> along the way, all because of svn committing or merging
>>> Instead of:
>>> % cd production-wc
>>> % svn merge $URL/to/staging
>>> can you:
>>> % svnmucc -mm rm $URL/to/production cp $somerev $URL/to/staging 
>>> $URL/to/production
>> Not too fond of that approach as we'd lose the history of the production tree
>> in the process.  Not every change to staging winds up being promoted.
> No we won't.  Just run 'svn log -qv' on the parent of the production tree.
>> There is an alternative approach that I am reluctant to mention but might
>> be the best solution for everyone: to use SSI as part of your templating system.
>> The downside is that it adds a bit of conceptual complexity to the CMS
>> as well as to people doing local builds as they will now need an SSI-enabled
>> server to inspect their build results.
>> The upside is that sledgehammer commits would be a thing of the past as
>> the Django templates would rarely need to be altered directly.  You'd just
>> be altering individual files in content/ containing (markdown-converted)
>> html fragments that the server would dynamically include into every page
>> based on the SSI calls in the Django templates.

I can see your vision. Each file in templates and content get converted into content in the
staging and production repos either assembled via SSI or as static "sledgehammer" content.
The SSI content translate into any change in templates and content causing only a few changes
in an SSI version of a built site. Changes to lib/ only effect changed mappings. It's
hard to see how changes to lib/ are not sledgehammers. Perhaps more of needs
to be moved into the cms directly. I know that you do pull features.

I was thinking about how to handle a certain class of files. swf, pdf, odt, xls whatever that
may be preferred to be single files in the repository but would be best be served up in an
html wrapper. (Even html files) This SSI pattern fits that solution better, I think.

A file say "" exists in the content directory. When built it becomes two files
explanation.html and the original explanation.html is then the wrapper around

> FWIW, Subverison uses that.


I've got putting together an mdtext page on ooo-site and the various new features and relevant
information. When I'm done sometime next week I'm interested in discussing more about an Apache
CMS "project". Where should we do that? infrastructure-dev?


View raw message