You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Joe Schaefer <jo...@yahoo.com> on 2012/01/04 17:28:07 UTC
suggested CMS workflows for ooo-site
Given that the size of ooo-site is around 9GB, there
are some unique challenges here in dealing with the CMS.
For the most part tho, the typical workflow of editing
a few pages on the site, committing them, and publishing
them can all be done reasonably effectively using the CMS
website.
OTOH, people who need to monkey with templates/** or lib/**
files will trigger full site builds and their changes may
materially impact every file on the site. While I've now
reduced the build time to around 4 minutes, the bottleneck
now remains squarely in the time it takes svn to commit back
those changes and to deal with merging those changes during
publication requests.
In those circumstances I strongly advise you to use the
publish.pl script on people.apache.org to review and if
ok publish your changes. This will eliminate the chances
that your browser times out a direct publish request to the
CMS site, which is a real hassle given that it takes ~15
minutes for a largeish publish request to be processed.
In the near future we will be upgrading svn to 1.7 on the CMS
server which will bring in better performance along with
full support for deletions via svn, but I don't expect the
performance changes to significantly alter the workflow I'm
recommending here.
And please for the sake of others who want to work on minor
changes to the site, don't make a sledgehammer type commit
without following up with an eventual publish request, because
publish requests are an all-or-nothing type deal. That means
a sledgehammer commit will cause unreasonable delays for people
who are trying to publish minor changes to the site, until
the person who did the sledgehammer commit follows thru and
publishes everything.
HTH
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Kay Schenk <ka...@gmail.com>
> To: ooo-dev@incubator.apache.org
> Cc:
> Sent: Wednesday, January 4, 2012 12:43 PM
> Subject: Re: suggested CMS workflows for ooo-site
>
> On Wed, Jan 4, 2012 at 8:46 AM, Dave Fisher <da...@comcast.net> wrote:
>
>>
>> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>>
>> > Given that the size of ooo-site is around 9GB, there
>> > are some unique challenges here in dealing with the CMS.
>> > For the most part tho, the typical workflow of editing
>> > a few pages on the site, committing them, and publishing
>> > them can all be done reasonably effectively using the CMS
>> > website.
>> >
>> > OTOH, people who need to monkey with templates/** or lib/**
>> > files will trigger full site builds and their changes may
>> > materially impact every file on the site. While I've now
>> > reduced the build time to around 4 minutes, the bottleneck
>> > now remains squarely in the time it takes svn to commit back
>> > those changes and to deal with merging those changes during
>> > publication requests.
>>
>> Thanks for your improvements.
>>
>> >
>> > In those circumstances I strongly advise you to use the
>> > publish.pl script on people.apache.org to review and if
>> > ok publish your changes. This will eliminate the chances
>> > that your browser times out a direct publish request to the
>> > CMS site, which is a real hassle given that it takes ~15
>> > minutes for a largeish publish request to be processed.
>>
>> I always use publish.pl when I use my sledgehammer ;-)
>>
>
> Well I haven't been using a sledgehammer at all, I think, but routinely use
> the following URL for publishing:
>
> https://cms.apache.org/openofficeorg/publish
>
> you need to login to use it, however. Just a web interface to publish.pl I
> think.
Yes, the publish.pl script uses the same url, but it's a bit faster
there because it's delivering raw JSON content versus templatized,
markdown-enabled HTML content. Normally the difference is negligible,
but with multimegabyte change-sets caused by slegehammer commits
the difference becomes suddenly appreciable.
>
>
>> I usually test my changes with local build_site.pl or build_file.pl.
>>
>> My observation is that the biggest bottleneck is more in the creation of
>> the email reports. Particularly after publish.pl returns.
FYI Dave the same advice applies here: once publish.pl completes succesfully,
the commit has been made and you don't need to wait for further confirmation
from svnmailer.
>>
>> >
>> > In the near future we will be upgrading svn to 1.7 on the CMS
>> > server which will bring in better performance along with
>> > full support for deletions via svn, but I don't expect the
>> > performance changes to significantly alter the workflow I'm
>> > recommending here.
>> >
>> > And please for the sake of others who want to work on minor
>> > changes to the site, don't make a sledgehammer type commit
>> > without following up with an eventual publish request, because
>> > publish requests are an all-or-nothing type deal. That means
>> > a sledgehammer commit will cause unreasonable delays for people
>> > who are trying to publish minor changes to the site, until
>> > the person who did the sledgehammer commit follows thru and
>> > publishes everything.
>>
>> I would recommend that larger template and skeleton changes with the whole
>> ooo-site are done locally and fully tested before committing to svn..
>>
>
> Probably a VERY good idea...but I'm just as happy to have a limited set of
> folks (Dave!), dealing with site-wide template changes. Despite the fact
> that I've looked over the templates and tried to figure them out,
> well...I'm not real confident about making changes to them. :/ Unless, in
> your *free* time, you might work up a nice tutorial on them. :)
Just documenting my remarks in this thread on the site somewhere would be
wise IMO. All I'm trying to point out is that a 9GB site requires more
cms usage documentation than the more typically sized <<100MB site we host.
HTH
>
>
>> Do you have any recommendations for comparing a locally built site with
>> current production in order to understand how big a sledgehammer is being
>> built?
>>
>> Regards,
>> Dave
>>
>> >
>> >
>> > HTH
>>
>>
>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "You will always be lucky if you know how to make friends
> with strange cats."
> -- *Colonial American
> proverb*
>
Re: suggested CMS workflows for ooo-site
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jan 4, 2012 at 8:46 AM, Dave Fisher <da...@comcast.net> wrote:
>
> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>
> > Given that the size of ooo-site is around 9GB, there
> > are some unique challenges here in dealing with the CMS.
> > For the most part tho, the typical workflow of editing
> > a few pages on the site, committing them, and publishing
> > them can all be done reasonably effectively using the CMS
> > website.
> >
> > OTOH, people who need to monkey with templates/** or lib/**
> > files will trigger full site builds and their changes may
> > materially impact every file on the site. While I've now
> > reduced the build time to around 4 minutes, the bottleneck
> > now remains squarely in the time it takes svn to commit back
> > those changes and to deal with merging those changes during
> > publication requests.
>
> Thanks for your improvements.
>
> >
> > In those circumstances I strongly advise you to use the
> > publish.pl script on people.apache.org to review and if
> > ok publish your changes. This will eliminate the chances
> > that your browser times out a direct publish request to the
> > CMS site, which is a real hassle given that it takes ~15
> > minutes for a largeish publish request to be processed.
>
> I always use publish.pl when I use my sledgehammer ;-)
>
Well I haven't been using a sledgehammer at all, I think, but routinely use
the following URL for publishing:
https://cms.apache.org/openofficeorg/publish
you need to login to use it, however. Just a web interface to publish.pl I
think.
> I usually test my changes with local build_site.pl or build_file.pl.
>
> My observation is that the biggest bottleneck is more in the creation of
> the email reports. Particularly after publish.pl returns.
>
> >
> > In the near future we will be upgrading svn to 1.7 on the CMS
> > server which will bring in better performance along with
> > full support for deletions via svn, but I don't expect the
> > performance changes to significantly alter the workflow I'm
> > recommending here.
> >
> > And please for the sake of others who want to work on minor
> > changes to the site, don't make a sledgehammer type commit
> > without following up with an eventual publish request, because
> > publish requests are an all-or-nothing type deal. That means
> > a sledgehammer commit will cause unreasonable delays for people
> > who are trying to publish minor changes to the site, until
> > the person who did the sledgehammer commit follows thru and
> > publishes everything.
>
> I would recommend that larger template and skeleton changes with the whole
> ooo-site are done locally and fully tested before committing to svn..
>
Probably a VERY good idea...but I'm just as happy to have a limited set of
folks (Dave!), dealing with site-wide template changes. Despite the fact
that I've looked over the templates and tried to figure them out,
well...I'm not real confident about making changes to them. :/ Unless, in
your *free* time, you might work up a nice tutorial on them. :)
> Do you have any recommendations for comparing a locally built site with
> current production in order to understand how big a sledgehammer is being
> built?
>
> Regards,
> Dave
>
> >
> >
> > HTH
>
>
--
----------------------------------------------------------------------------------------
MzK
"You will always be lucky if you know how to make friends
with strange cats."
-- *Colonial American
proverb*
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
FWIW I opened a thread on dev@svn about the time it takes
for svn to commit and merge large changesets. If there's
nothing more they can do to improve the situation, I have
a hunch that migrating the cms to a machine with SSD's running
l2arc cache for zfs will help a lot.
We have a machine lying around that would suit that purpose,
just haven't had the time to bring it up and migrate over to it.
Eventually tho I'll get the free tuits to make it happen.
----- Original Message -----
> From: Joe Schaefer <jo...@yahoo.com>
> To: "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>
> Cc:
> Sent: Wednesday, January 4, 2012 12:52 PM
> Subject: Re: suggested CMS workflows for ooo-site
>
> ----- Original Message -----
>
>> From: Dave Fisher <da...@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 huge volumes
> of data.
>
>>
>>>
>>> You may want to turn this thread into some basic cms
>>> usage documentation on the incubator/openofficeorg site.
>>
>> Yes. I think it is time to rework what is on the incubator site.
>>
>> See incubator/openofficeorg/website-local.mdtext.
>>
>> But not today. I'll let you know when and we can review it.
>
> Sounds like a plan.
>
>>
>> Regards,
>> Dave
>>
>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: Joe Schaefer <jo...@yahoo.com>
>>>> To: "ooo-dev@incubator.apache.org"
>> <oo...@incubator.apache.org>
>>>> Cc:
>>>> Sent: Wednesday, January 4, 2012 11:51 AM
>>>> Subject: Re: suggested CMS workflows for ooo-site
>>>>
>>>> You can always mimic exactly what the staging site
>>>> does with its builds, namely target the build to
>>>> a checkout of
>>>>
>>>> https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk
>>>>
>>>> When the build finishes you can just svn diff that
>>>> tree to see what you actually changed, but *please*
>>>> do not commit back those changes yourself. You
>>>> can nuke all your changes to that tree with svn revert -R
>>>> so it's handy for testing different types of sledgehammers.
>>>>
>>>>
>>>> HTH
>>>>
>>>>> ________________________________
>>>>> From: Dave Fisher <da...@comcast.net>
>>>>> To: ooo-dev@incubator.apache.org
>>>>> Sent: Wednesday, January 4, 2012 11:46 AM
>>>>> Subject: Re: suggested CMS workflows for ooo-site
>>>>>
>>>>>
>>>>> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>>>>>
>>>>>> Given that the size of ooo-site is around 9GB, there
>>>>>> are some unique challenges here in dealing with the CMS.
>>>>>> For the most part tho, the typical workflow of editing
>>>>>> a few pages on the site, committing them, and publishing
>>>>>> them can all be done reasonably effectively using the CMS
>>>>>> website.
>>>>>>
>>>>>> OTOH, people who need to monkey with templates/** or
> lib/**
>>>>>> files will trigger full site builds and their changes may
>>>>>> materially impact every file on the site. While I've
> now
>>>>>> reduced the build time to around 4 minutes, the bottleneck
>>>>>> now remains squarely in the time it takes svn to commit
> back
>>>>>> those changes and to deal with merging those changes
> during
>>>>>> publication requests.
>>>>>
>>>>> Thanks for your improvements.
>>>>>
>>>>>>
>>>>>> In those circumstances I strongly advise you to use the
>>>>>> publish.pl script on people.apache.org to review and if
>>>>>> ok publish your changes. This will eliminate the chances
>>>>>> that your browser times out a direct publish request to
> the
>>>>>> CMS site, which is a real hassle given that it takes ~15
>>>>>> minutes for a largeish publish request to be processed.
>>>>>
>>>>> I always use publish.pl when I use my sledgehammer ;-)
>>>>>
>>>>> I usually test my changes with local build_site.pl or
>> build_file.pl.
>>>>>
>>>>> My observation is that the biggest bottleneck is more in the
>> creation of the
>>>> email reports. Particularly after publish.pl returns.
>>>>>
>>>>>>
>>>>>> In the near future we will be upgrading svn to 1.7 on the
> CMS
>>>>>> server which will bring in better performance along with
>>>>>> full support for deletions via svn, but I don't expect
> the
>>>>>> performance changes to significantly alter the workflow
> I'm
>>>>>> recommending here.
>>>>>>
>>>>>> And please for the sake of others who want to work on
> minor
>>>>>> changes to the site, don't make a sledgehammer type
> commit
>>>>>> without following up with an eventual publish request,
> because
>>>>>> publish requests are an all-or-nothing type deal. That
> means
>>>>>> a sledgehammer commit will cause unreasonable delays for
> people
>>>>>> who are trying to publish minor changes to the site, until
>>>>>> the person who did the sledgehammer commit follows thru
> and
>>>>>> publishes everything.
>>>>>
>>>>> I would recommend that larger template and skeleton changes
> with
>> the whole
>>>> ooo-site are done locally and fully tested before committing to
> svn..
>>>>>
>>>>> Do you have any recommendations for comparing a locally built
> site
>> with
>>>> current production in order to understand how big a sledgehammer
> is
>> being built?
>>>>>
>>>>> Regards,
>>>>> Dave
>>>>>
>>>>>>
>>>>>>
>>>>>> HTH
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>
Re: suggested CMS workflows for ooo-site
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jan 4, 2012 at 9:45 PM, Dave Fisher <da...@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....@daniel.shahaf.name>
> >>> To: Joe Schaefer <jo...@yahoo.com>
> >>> Cc: "ooo-dev@incubator.apache.org" <oo...@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 <da...@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*
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
Staging and production will both do SSI if
you tell them to via a top-level .htaccess
file. Trafficserver does this right now
with the CMS.
----- Original Message -----
> From: Dave Fisher <da...@comcast.net>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: Daniel Shahaf <d....@daniel.shahaf.name>; "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>; "infrastructure@apache.org" <in...@apache.org>
> Sent: Thursday, January 5, 2012 1:37 AM
> Subject: Re: suggested CMS workflows for ooo-site
>
>
> On Jan 4, 2012, at 9:57 PM, Joe Schaefer wrote:
>
>> ----- Original Message -----
>>
>>> From: Dave Fisher <da...@comcast.net>
>>> To: Daniel Shahaf <d....@daniel.shahaf.name>
>>> Cc: Joe Schaefer <jo...@yahoo.com>;
> "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>;
> "infrastructure@apache.org" <in...@apache.org>
>>> 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 <d....@daniel.shahaf.name>
>>>>>> To: Joe Schaefer <jo...@yahoo.com>
>>>>>> Cc: "ooo-dev@incubator.apache.org"
>>> <oo...@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 <da...@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.
>>
>> 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?
>
> 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
>
Re: suggested CMS workflows for ooo-site
Posted by Dave Fisher <da...@comcast.net>.
On Jan 4, 2012, at 9:57 PM, Joe Schaefer wrote:
> ----- Original Message -----
>
>> From: Dave Fisher <da...@comcast.net>
>> To: Daniel Shahaf <d....@daniel.shahaf.name>
>> Cc: Joe Schaefer <jo...@yahoo.com>; "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>; "infrastructure@apache.org" <in...@apache.org>
>> 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 <d....@daniel.shahaf.name>
>>>>> To: Joe Schaefer <jo...@yahoo.com>
>>>>> Cc: "ooo-dev@incubator.apache.org"
>> <oo...@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 <da...@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.
>
> 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?
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
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Dave Fisher <da...@comcast.net>
> To: Daniel Shahaf <d....@daniel.shahaf.name>
> Cc: Joe Schaefer <jo...@yahoo.com>; "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>; "infrastructure@apache.org" <in...@apache.org>
> 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 <d....@daniel.shahaf.name>
>>>> To: Joe Schaefer <jo...@yahoo.com>
>>>> Cc: "ooo-dev@incubator.apache.org"
> <oo...@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 <da...@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.
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?
Re: suggested CMS workflows for ooo-site
Posted by Dave Fisher <da...@comcast.net>.
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....@daniel.shahaf.name>
>>> To: Joe Schaefer <jo...@yahoo.com>
>>> Cc: "ooo-dev@incubator.apache.org" <oo...@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 <da...@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?
Regards,
Dave
Re: suggested CMS workflows for ooo-site
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Joe Schaefer wrote on Wed, Jan 04, 2012 at 16:55:02 -0800:
> ----- Original Message -----
>
> > From: Daniel Shahaf <d....@daniel.shahaf.name>
> > To: Joe Schaefer <jo...@yahoo.com>
> > Cc: "ooo-dev@incubator.apache.org" <oo...@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 <da...@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.
FWIW, Subverison uses that.
http://subversion.apache.org/
http://svn.apache.org/repos/asf/subversion/site/publish/
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Daniel Shahaf <d....@daniel.shahaf.name>
> To: Joe Schaefer <jo...@yahoo.com>
> Cc: "ooo-dev@incubator.apache.org" <oo...@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 <da...@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.
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.
Re: suggested CMS workflows for ooo-site
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Joe Schaefer wrote on Wed, Jan 04, 2012 at 09:52:39 -0800:
> ----- Original Message -----
>
> > From: Dave Fisher <da...@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
> huge volumes
> of data.
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
----- Original Message -----
> From: Dave Fisher <da...@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 huge volumes
of data.
>
>>
>> You may want to turn this thread into some basic cms
>> usage documentation on the incubator/openofficeorg site.
>
> Yes. I think it is time to rework what is on the incubator site.
>
> See incubator/openofficeorg/website-local.mdtext.
>
> But not today. I'll let you know when and we can review it.
Sounds like a plan.
>
> Regards,
> Dave
>
>
>>
>>
>>
>> ----- Original Message -----
>>> From: Joe Schaefer <jo...@yahoo.com>
>>> To: "ooo-dev@incubator.apache.org"
> <oo...@incubator.apache.org>
>>> Cc:
>>> Sent: Wednesday, January 4, 2012 11:51 AM
>>> Subject: Re: suggested CMS workflows for ooo-site
>>>
>>> You can always mimic exactly what the staging site
>>> does with its builds, namely target the build to
>>> a checkout of
>>>
>>> https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk
>>>
>>> When the build finishes you can just svn diff that
>>> tree to see what you actually changed, but *please*
>>> do not commit back those changes yourself. You
>>> can nuke all your changes to that tree with svn revert -R
>>> so it's handy for testing different types of sledgehammers.
>>>
>>>
>>> HTH
>>>
>>>> ________________________________
>>>> From: Dave Fisher <da...@comcast.net>
>>>> To: ooo-dev@incubator.apache.org
>>>> Sent: Wednesday, January 4, 2012 11:46 AM
>>>> Subject: Re: suggested CMS workflows for ooo-site
>>>>
>>>>
>>>> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>>>>
>>>>> Given that the size of ooo-site is around 9GB, there
>>>>> are some unique challenges here in dealing with the CMS.
>>>>> For the most part tho, the typical workflow of editing
>>>>> a few pages on the site, committing them, and publishing
>>>>> them can all be done reasonably effectively using the CMS
>>>>> website.
>>>>>
>>>>> OTOH, people who need to monkey with templates/** or lib/**
>>>>> files will trigger full site builds and their changes may
>>>>> materially impact every file on the site. While I've now
>>>>> reduced the build time to around 4 minutes, the bottleneck
>>>>> now remains squarely in the time it takes svn to commit back
>>>>> those changes and to deal with merging those changes during
>>>>> publication requests.
>>>>
>>>> Thanks for your improvements.
>>>>
>>>>>
>>>>> In those circumstances I strongly advise you to use the
>>>>> publish.pl script on people.apache.org to review and if
>>>>> ok publish your changes. This will eliminate the chances
>>>>> that your browser times out a direct publish request to the
>>>>> CMS site, which is a real hassle given that it takes ~15
>>>>> minutes for a largeish publish request to be processed.
>>>>
>>>> I always use publish.pl when I use my sledgehammer ;-)
>>>>
>>>> I usually test my changes with local build_site.pl or
> build_file.pl.
>>>>
>>>> My observation is that the biggest bottleneck is more in the
> creation of the
>>> email reports. Particularly after publish.pl returns.
>>>>
>>>>>
>>>>> In the near future we will be upgrading svn to 1.7 on the CMS
>>>>> server which will bring in better performance along with
>>>>> full support for deletions via svn, but I don't expect the
>>>>> performance changes to significantly alter the workflow I'm
>>>>> recommending here.
>>>>>
>>>>> And please for the sake of others who want to work on minor
>>>>> changes to the site, don't make a sledgehammer type commit
>>>>> without following up with an eventual publish request, because
>>>>> publish requests are an all-or-nothing type deal. That means
>>>>> a sledgehammer commit will cause unreasonable delays for people
>>>>> who are trying to publish minor changes to the site, until
>>>>> the person who did the sledgehammer commit follows thru and
>>>>> publishes everything.
>>>>
>>>> I would recommend that larger template and skeleton changes with
> the whole
>>> ooo-site are done locally and fully tested before committing to svn..
>>>>
>>>> Do you have any recommendations for comparing a locally built site
> with
>>> current production in order to understand how big a sledgehammer is
> being built?
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>>
>>>>>
>>>>> HTH
>>>>
>>>>
>>>>
>>>>
>>>
>
Re: suggested CMS workflows for ooo-site
Posted by Dave Fisher <da...@comcast.net>.
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.
>
> You may want to turn this thread into some basic cms
> usage documentation on the incubator/openofficeorg site.
Yes. I think it is time to rework what is on the incubator site.
See incubator/openofficeorg/website-local.mdtext.
But not today. I'll let you know when and we can review it.
Regards,
Dave
>
>
>
> ----- Original Message -----
>> From: Joe Schaefer <jo...@yahoo.com>
>> To: "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>
>> Cc:
>> Sent: Wednesday, January 4, 2012 11:51 AM
>> Subject: Re: suggested CMS workflows for ooo-site
>>
>> You can always mimic exactly what the staging site
>> does with its builds, namely target the build to
>> a checkout of
>>
>> https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk
>>
>> When the build finishes you can just svn diff that
>> tree to see what you actually changed, but *please*
>> do not commit back those changes yourself. You
>> can nuke all your changes to that tree with svn revert -R
>> so it's handy for testing different types of sledgehammers.
>>
>>
>> HTH
>>
>>> ________________________________
>>> From: Dave Fisher <da...@comcast.net>
>>> To: ooo-dev@incubator.apache.org
>>> Sent: Wednesday, January 4, 2012 11:46 AM
>>> Subject: Re: suggested CMS workflows for ooo-site
>>>
>>>
>>> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>>>
>>>> Given that the size of ooo-site is around 9GB, there
>>>> are some unique challenges here in dealing with the CMS.
>>>> For the most part tho, the typical workflow of editing
>>>> a few pages on the site, committing them, and publishing
>>>> them can all be done reasonably effectively using the CMS
>>>> website.
>>>>
>>>> OTOH, people who need to monkey with templates/** or lib/**
>>>> files will trigger full site builds and their changes may
>>>> materially impact every file on the site. While I've now
>>>> reduced the build time to around 4 minutes, the bottleneck
>>>> now remains squarely in the time it takes svn to commit back
>>>> those changes and to deal with merging those changes during
>>>> publication requests.
>>>
>>> Thanks for your improvements.
>>>
>>>>
>>>> In those circumstances I strongly advise you to use the
>>>> publish.pl script on people.apache.org to review and if
>>>> ok publish your changes. This will eliminate the chances
>>>> that your browser times out a direct publish request to the
>>>> CMS site, which is a real hassle given that it takes ~15
>>>> minutes for a largeish publish request to be processed.
>>>
>>> I always use publish.pl when I use my sledgehammer ;-)
>>>
>>> I usually test my changes with local build_site.pl or build_file.pl.
>>>
>>> My observation is that the biggest bottleneck is more in the creation of the
>> email reports. Particularly after publish.pl returns.
>>>
>>>>
>>>> In the near future we will be upgrading svn to 1.7 on the CMS
>>>> server which will bring in better performance along with
>>>> full support for deletions via svn, but I don't expect the
>>>> performance changes to significantly alter the workflow I'm
>>>> recommending here.
>>>>
>>>> And please for the sake of others who want to work on minor
>>>> changes to the site, don't make a sledgehammer type commit
>>>> without following up with an eventual publish request, because
>>>> publish requests are an all-or-nothing type deal. That means
>>>> a sledgehammer commit will cause unreasonable delays for people
>>>> who are trying to publish minor changes to the site, until
>>>> the person who did the sledgehammer commit follows thru and
>>>> publishes everything.
>>>
>>> I would recommend that larger template and skeleton changes with the whole
>> ooo-site are done locally and fully tested before committing to svn..
>>>
>>> Do you have any recommendations for comparing a locally built site with
>> current production in order to understand how big a sledgehammer is being built?
>>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>>
>>>> HTH
>>>
>>>
>>>
>>>
>>
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
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
You may want to turn this thread into some basic cms
usage documentation on the incubator/openofficeorg site.
----- Original Message -----
> From: Joe Schaefer <jo...@yahoo.com>
> To: "ooo-dev@incubator.apache.org" <oo...@incubator.apache.org>
> Cc:
> Sent: Wednesday, January 4, 2012 11:51 AM
> Subject: Re: suggested CMS workflows for ooo-site
>
> You can always mimic exactly what the staging site
> does with its builds, namely target the build to
> a checkout of
>
> https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk
>
> When the build finishes you can just svn diff that
> tree to see what you actually changed, but *please*
> do not commit back those changes yourself. You
> can nuke all your changes to that tree with svn revert -R
> so it's handy for testing different types of sledgehammers.
>
>
> HTH
>
>> ________________________________
>> From: Dave Fisher <da...@comcast.net>
>> To: ooo-dev@incubator.apache.org
>> Sent: Wednesday, January 4, 2012 11:46 AM
>> Subject: Re: suggested CMS workflows for ooo-site
>>
>>
>> On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>>
>>> Given that the size of ooo-site is around 9GB, there
>>> are some unique challenges here in dealing with the CMS.
>>> For the most part tho, the typical workflow of editing
>>> a few pages on the site, committing them, and publishing
>>> them can all be done reasonably effectively using the CMS
>>> website.
>>>
>>> OTOH, people who need to monkey with templates/** or lib/**
>>> files will trigger full site builds and their changes may
>>> materially impact every file on the site. While I've now
>>> reduced the build time to around 4 minutes, the bottleneck
>>> now remains squarely in the time it takes svn to commit back
>>> those changes and to deal with merging those changes during
>>> publication requests.
>>
>> Thanks for your improvements.
>>
>>>
>>> In those circumstances I strongly advise you to use the
>>> publish.pl script on people.apache.org to review and if
>>> ok publish your changes. This will eliminate the chances
>>> that your browser times out a direct publish request to the
>>> CMS site, which is a real hassle given that it takes ~15
>>> minutes for a largeish publish request to be processed.
>>
>> I always use publish.pl when I use my sledgehammer ;-)
>>
>> I usually test my changes with local build_site.pl or build_file.pl.
>>
>> My observation is that the biggest bottleneck is more in the creation of the
> email reports. Particularly after publish.pl returns.
>>
>>>
>>> In the near future we will be upgrading svn to 1.7 on the CMS
>>> server which will bring in better performance along with
>>> full support for deletions via svn, but I don't expect the
>>> performance changes to significantly alter the workflow I'm
>>> recommending here.
>>>
>>> And please for the sake of others who want to work on minor
>>> changes to the site, don't make a sledgehammer type commit
>>> without following up with an eventual publish request, because
>>> publish requests are an all-or-nothing type deal. That means
>>> a sledgehammer commit will cause unreasonable delays for people
>>> who are trying to publish minor changes to the site, until
>>> the person who did the sledgehammer commit follows thru and
>>> publishes everything.
>>
>> I would recommend that larger template and skeleton changes with the whole
> ooo-site are done locally and fully tested before committing to svn..
>>
>> Do you have any recommendations for comparing a locally built site with
> current production in order to understand how big a sledgehammer is being built?
>>
>> Regards,
>> Dave
>>
>>>
>>>
>>> HTH
>>
>>
>>
>>
>
Re: suggested CMS workflows for ooo-site
Posted by Joe Schaefer <jo...@yahoo.com>.
You can always mimic exactly what the staging site
does with its builds, namely target the build to
a checkout of
https://svn.apache.org/repos/infra/websites/staging/ooo-site/trunk
When the build finishes you can just svn diff that
tree to see what you actually changed, but *please*
do not commit back those changes yourself. You
can nuke all your changes to that tree with svn revert -R
so it's handy for testing different types of sledgehammers.
HTH
>________________________________
> From: Dave Fisher <da...@comcast.net>
>To: ooo-dev@incubator.apache.org
>Sent: Wednesday, January 4, 2012 11:46 AM
>Subject: Re: suggested CMS workflows for ooo-site
>
>
>On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
>
>> Given that the size of ooo-site is around 9GB, there
>> are some unique challenges here in dealing with the CMS.
>> For the most part tho, the typical workflow of editing
>> a few pages on the site, committing them, and publishing
>> them can all be done reasonably effectively using the CMS
>> website.
>>
>> OTOH, people who need to monkey with templates/** or lib/**
>> files will trigger full site builds and their changes may
>> materially impact every file on the site. While I've now
>> reduced the build time to around 4 minutes, the bottleneck
>> now remains squarely in the time it takes svn to commit back
>> those changes and to deal with merging those changes during
>> publication requests.
>
>Thanks for your improvements.
>
>>
>> In those circumstances I strongly advise you to use the
>> publish.pl script on people.apache.org to review and if
>> ok publish your changes. This will eliminate the chances
>> that your browser times out a direct publish request to the
>> CMS site, which is a real hassle given that it takes ~15
>> minutes for a largeish publish request to be processed.
>
>I always use publish.pl when I use my sledgehammer ;-)
>
>I usually test my changes with local build_site.pl or build_file.pl.
>
>My observation is that the biggest bottleneck is more in the creation of the email reports. Particularly after publish.pl returns.
>
>>
>> In the near future we will be upgrading svn to 1.7 on the CMS
>> server which will bring in better performance along with
>> full support for deletions via svn, but I don't expect the
>> performance changes to significantly alter the workflow I'm
>> recommending here.
>>
>> And please for the sake of others who want to work on minor
>> changes to the site, don't make a sledgehammer type commit
>> without following up with an eventual publish request, because
>> publish requests are an all-or-nothing type deal. That means
>> a sledgehammer commit will cause unreasonable delays for people
>> who are trying to publish minor changes to the site, until
>> the person who did the sledgehammer commit follows thru and
>> publishes everything.
>
>I would recommend that larger template and skeleton changes with the whole ooo-site are done locally and fully tested before committing to svn..
>
>Do you have any recommendations for comparing a locally built site with current production in order to understand how big a sledgehammer is being built?
>
>Regards,
>Dave
>
>>
>>
>> HTH
>
>
>
>
Re: suggested CMS workflows for ooo-site
Posted by Dave Fisher <da...@comcast.net>.
On Jan 4, 2012, at 8:28 AM, Joe Schaefer wrote:
> Given that the size of ooo-site is around 9GB, there
> are some unique challenges here in dealing with the CMS.
> For the most part tho, the typical workflow of editing
> a few pages on the site, committing them, and publishing
> them can all be done reasonably effectively using the CMS
> website.
>
> OTOH, people who need to monkey with templates/** or lib/**
> files will trigger full site builds and their changes may
> materially impact every file on the site. While I've now
> reduced the build time to around 4 minutes, the bottleneck
> now remains squarely in the time it takes svn to commit back
> those changes and to deal with merging those changes during
> publication requests.
Thanks for your improvements.
>
> In those circumstances I strongly advise you to use the
> publish.pl script on people.apache.org to review and if
> ok publish your changes. This will eliminate the chances
> that your browser times out a direct publish request to the
> CMS site, which is a real hassle given that it takes ~15
> minutes for a largeish publish request to be processed.
I always use publish.pl when I use my sledgehammer ;-)
I usually test my changes with local build_site.pl or build_file.pl.
My observation is that the biggest bottleneck is more in the creation of the email reports. Particularly after publish.pl returns.
>
> In the near future we will be upgrading svn to 1.7 on the CMS
> server which will bring in better performance along with
> full support for deletions via svn, but I don't expect the
> performance changes to significantly alter the workflow I'm
> recommending here.
>
> And please for the sake of others who want to work on minor
> changes to the site, don't make a sledgehammer type commit
> without following up with an eventual publish request, because
> publish requests are an all-or-nothing type deal. That means
> a sledgehammer commit will cause unreasonable delays for people
> who are trying to publish minor changes to the site, until
> the person who did the sledgehammer commit follows thru and
> publishes everything.
I would recommend that larger template and skeleton changes with the whole ooo-site are done locally and fully tested before committing to svn..
Do you have any recommendations for comparing a locally built site with current production in order to understand how big a sledgehammer is being built?
Regards,
Dave
>
>
> HTH