Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dave2wave@comcast.net
 designates 76.96.30.24 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: <1325743045.26317.YahooMailNeo@web160902.mail.bf1.yahoo.com>
Date: Wed, 4 Jan 2012 22:37:39 -0800
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
 "ooo-dev@incubator.apache.org" <ooo-dev@incubator.apache.org>,
 "infrastructure@apache.org" <infrastructure@apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1D4B569-04B7-4E3F-947E-C6944656961D@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>
 <68E66C91-7FAC-4C6D-BEB2-BD59269190D8@comcast.net>
 <1325743045.26317.YahooMailNeo@web160902.mail.bf1.yahoo.com>
To: Joe Schaefer <joe_schaefer@yahoo.com>


On Jan 4, 2012, at 9:57 PM, Joe Schaefer wrote:

> ----- Original Message -----
>=20
>> 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
>>=20
>>=20
>> On Jan 4, 2012, at 5:00 PM, Daniel Shahaf wrote:
>>=20
>>> 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"=20
>> <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=20
>> the
>>>>>>>>    build status of sledgehammer commits instead of=20
>> waiting
>>>>>>>>    for svnmailer to figure out what to do with the=20
>> 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=20
>> there is no=20
>>>>> reason to=20
>>>>>>> wait that will save time.
>>>>>>=20
>>>>>> Buildbot performs the commit back as the final step in the=20
>> 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=20
>> effect.
>>>>>>=20
>>>>>> My experience is that the turnaround between sledgehammer=20
>> 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=20
>> 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=20
>> production tree.
>>>=20
>>>> There is an alternative approach that I am reluctant to mention but=20=

>> might
>>>> be the best solution for everyone: to use SSI as part of your=20
>> 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=20
>> 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. =20
>> You'd just
>>>> be altering individual files in content/ containing=20
>> (markdown-converted)
>>>> html fragments that the server would dynamically include into every=20=

>> page
>>>> based on the SSI calls in the Django templates.
>>=20
>> I can see your vision. Each file in templates and content get =
converted into=20
>> content in the staging and production repos either assembled via SSI =
or as=20
>> static "sledgehammer" content.
>=20
> 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.
>=20
> 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/*.
>=20
> 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