----- Original Message ----- > From: Dave Fisher <[email protected]> > To: Daniel Shahaf <[email protected]> > Cc: Joe Schaefer <[email protected]>; "[email protected]" > <[email protected]>; "[email protected]" > <[email protected]> > 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 <[email protected]> >>>> To: Joe Schaefer <[email protected]> >>>> Cc: "[email protected]" > <[email protected]>; [email protected] >>>> 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 <[email protected]> >>>>>> To: [email protected] >>>>>> 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?
