incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: suggested CMS workflows for ooo-site
Date Thu, 05 Jan 2012 05:57:25 GMT
----- Original Message -----

> From: Dave Fisher <dave2wave@comcast.net>
> To: Daniel Shahaf <d.s@daniel.shahaf.name>
> Cc: Joe Schaefer <joe_schaefer@yahoo.com>; "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>;
"infrastructure@apache.org" <infrastructure@apache.org>
> Sent: Thursday, January 5, 2012 12:45 AM
> Subject: Re: suggested CMS workflows for ooo-site
> 
> 
> 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 <d.s@daniel.shahaf.name>
>>>>  To: Joe Schaefer <joe_schaefer@yahoo.com>
>>>>  Cc: "ooo-dev@incubator.apache.org" 
> <ooo-dev@incubator.apache.org>; infrastructure@apache.org
>>>>  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 <dave2wave@comcast.net>
>>>>>>  To: ooo-dev@incubator.apache.org
>>>>>>  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 
>>>>>>> 
>>>>>>> 
>>>>>>>   http://ci.apache.org/builders/ooo-site-site-staging
>>>>>> 
>>>>>>  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.

All I'm saying is that by adding a bit more indirection (ala a C-style pointer)
we can get better mileage out of the CMS for everyone.  So in templates/, you
no longer put any extensive html/markdown prose directly in there, just point
at it with an SSI include directive with a url path in say content/ssi/...
The prose goes in content/ssi, which can be included directly into the file
by httpd which will scan your template-generated content for those include
directives.

Changes to lib/* and templates/* will always have widespread effects on the generated
content and there's no way around that.  But we can stabilize those files a lot
more quickly, and reduce the need for such changes, if we can get the ever-changing
header and footer and nav *content* back into content/ssi/* and out of templates/*.

Do you see more clearly how I'm thinking now?

Mime
View raw message