Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dave2wave@comcast.net
 designates 76.96.30.80 as permitted sender)
Subject: Re: suggested CMS workflows for ooo-site
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Dave Fisher <dave2wave@comcast.net>
In-Reply-To: <20120105010030.GC30066@daniel3.local>
Date: Wed, 4 Jan 2012 21:45:17 -0800
Cc: Joe Schaefer <joe_schaefer@yahoo.com>,
 "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>,
 "infrastructure@apache.org" <infrastructure@apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <68E66C91-7FAC-4C6D-BEB2-BD59269190D8@comcast.net>
References: <1325694487.26057.YahooMailNeo@web160903.mail.bf1.yahoo.com>
 <B8893114-C716-41F4-9061-0E56F951E4AA@comcast.net>
 <1325695906.80326.YahooMailNeo@web160906.mail.bf1.yahoo.com>
 <1325698191.35878.YahooMailNeo@web160901.mail.bf1.yahoo.com>
 <F3B7A813-BE0E-4AAD-B8AB-6E48AC6435CB@comcast.net>
 <1325699559.19044.YahooMailNeo@web160904.mail.bf1.yahoo.com>
 <20120104235740.GA28956@daniel3.local>
 <1325724902.55434.YahooMailNeo@web160904.mail.bf1.yahoo.com>
 <20120105010030.GC30066@daniel3.local>
To: Daniel Shahaf <d.s@daniel.shahaf.name>


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 -----
>>=20
>>> 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
>>>=20
>>> Joe Schaefer wrote on Wed, Jan 04, 2012 at 09:52:39 -0800:
>>>> ----- Original Message -----
>>>>=20
>>>>> From: Dave Fisher <dave2wave@comcast.net>
>>>>> To: ooo-dev@incubator.apache.org
>>>>> Cc:=20
>>>>> Sent: Wednesday, January 4, 2012 12:40 PM
>>>>> Subject: Re: suggested CMS workflows for ooo-site=20
>>>>>=20
>>>>>=20
>>>>> On Jan 4, 2012, at 9:29 AM, Joe Schaefer wrote:
>>>>>=20
>>>>>>   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=20
>>>>>>=20
>>>>>>=20
>>>>>>   http://ci.apache.org/builders/ooo-site-site-staging
>>>>>=20
>>>>> I do do that, but tend to wait for the email anyway. If there is =
no=20
>>> reason to=20
>>>>> wait that will save time.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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
>>>=20
>>> Instead of:
>>>=20
>>> % cd production-wc
>>> % svn merge $URL/to/staging
>>>=20
>>> can you:
>>>=20
>>> % svnmucc -mm rm $URL/to/production cp $somerev $URL/to/staging=20
>>> $URL/to/production
>>=20
>> 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.
>>=20
>=20
> No we won't.  Just run 'svn log -qv' on the parent of the production =
tree.
>=20
>> 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.
>>=20
>> 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.

>=20
> FWIW, Subverison uses that.
>=20
> 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?

Regards,
Dave