incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: suggested CMS workflows for ooo-site
Date Thu, 05 Jan 2012 17:20:17 GMT
On Wed, Jan 4, 2012 at 9:45 PM, Dave Fisher <dave2wave@comcast.net> 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 <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. 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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message