logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: Moving from svn up to mvn site-deploy
Date Fri, 23 Dec 2011 21:04:23 GMT
On Fri, Dec 23, 2011 at 9:51 PM, Stefan Bodewig <bodewig@apache.org> wrote:
> On 2011-12-23, Christian Grobmeier wrote:
>> On Thu, Dec 22, 2011 at 6:41 PM, Stefan Bodewig <bodewig@apache.org> wrote:
>>> On 2011-12-21, Christian Grobmeier wrote:
>>> svnpubsub would solve that and even make the infra crew happy or at
>>> least happier than with a "files on people.apache.org" solution.
>> hm besides the code: http://bit.ly/uJs5mQ
>> I could not find any docs. But I heard of it... is it still preferred,
>> because of the ASF CMS?
> While looking for information I can link to I stumbled over
> <http://www.apache.org/dev/project-site.html#svnpubsub>
> This kind of voids your idea of using site-deploy.  Or you'd have to
> deploy to a local directory that is a svn copy and commit that (kind of
> what you do now but without updating people.apache.org).

Not only mine. Even for Commons.
I will ask infra if there are additional docs and if this is still true.
If it is true, we need to consider this for whole logging.

Thanks for digging it out and the explaination below.

Have a nice x-mas!

> Ant uses svnpubsub.  Just think of it as automating the manual update
> we've been doing so far - and without the delay between commit and
> "visible on the live site".  All we'd have to do was opening a JIRA
> ticket with infra and point them to the svn directory to publish.
> <http://www.apache.org/dev/cms.html#svnpubsub> doesn't say much more
> than that either (but the page as such explains infra's rationale for
> builing the CMS and how they want to manage sites in the future).  One
> important point against site-deploy and any other technology that
> requires to sync files from people.apache.org is the big amount of data
> to scan and sync as the ASF grows.  This isn't related to desaster
> recovery at all.
> Stefan


View raw message