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 06:39:28 GMT
Staging and production will both do SSI if
you tell them to via a top-level .htaccess
file.  Trafficserver does this right now
with the CMS.



----- Original Message -----
> From: Dave Fisher <dave2wave@comcast.net>
> To: Joe Schaefer <joe_schaefer@yahoo.com>
> Cc: Daniel Shahaf <d.s@daniel.shahaf.name>; "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>;
"infrastructure@apache.org" <infrastructure@apache.org>
> Sent: Thursday, January 5, 2012 1:37 AM
> Subject: Re: suggested CMS workflows for ooo-site
> 
> 
> On Jan 4, 2012, at 9:57 PM, Joe Schaefer wrote:
> 
>>  ----- 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?
> 
> I think so. Essentially we would move out most mdtext and html content from 
> templates leaving skeleton.html more of a list of includes. It would totally be 
> possible to pull almost all the changeable content out of templates and lib.
> 
> How would you mix using SSI vs. static content on the staging and production 
> servers? Or does production also do SSI?
> 
> Regards,
> Dave
> 

Mime
View raw message