On Wed, Jan 4, 2012 at 9:45 PM, Dave Fisher <[email protected]> wrote:
> > 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. 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/path.pm only effect changed > mappings. It's hard to see how changes to lib/view.pm are not > sledgehammers. Perhaps more of view.pm 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 "explanation.foo" exists in the content directory. When built > it becomes two files explanation.html and the original explanation.foo. > explanation.html is then the wrapper around explanation.foo. > > > > > FWIW, Subverison uses that. > > > > http://subversion.apache.org/ > > http://svn.apache.org/repos/asf/subversion/site/publish/ > > Interesting. > > 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? > I am SO looking forward to this. Right now, although I can kind of "guess" what happens with the setup stuff, I certainly would NOT feel confident in changing any of it. A low level tutorial would be wonderful! :) > > Regards, > Dave > > > > -- ---------------------------------------------------------------------------------------- MzK "You will always be lucky if you know how to make friends with strange cats." -- *Colonial American proverb*
