You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@adobe.com> on 2012/12/13 13:49:07 UTC
Felix Site
Hi all,
Earlier this year, Apache Infrastructure announced to switch off rsync support for Web Site management. On January, 1st, 2013, this will no actually happen.
We are a bit late in the game, so I started as follows:
* I created FELIX-3816 to track the migration
* I created INFRA-5648 to ask for staging creation
I will now export the existing Confluence content into SVN and start converting the pages. This will be an iterative process being mostly automatic. Since not everything can easily be converted, we will still have to cross check the pages and do some fine-tuning.
What does this change mean at the end ?
(1) We will get immediate site updates: Whenever we change one or more pages and publish, the change will almost immediately be seen on the web. There is no multi-hour delay and incertainty any longer
(2) As a markup language "markdown" has been chosen. See [1] for links to the respective documentation.
(3) We have more freedom in how we "build" our site. The initial look of the new site will be the same as the current site. But we may change this easily later on.
When switching I think we should start with a double site: The new site available directly through the URL at http://felix.apache.org and the old site still available at http://felix.apache.org/site. This has nice advantage, that links from the web still work and we can crosscheck the new pages against the old ones easily. Over time we will remove the old pages but add (static) redirects to still support the old URLs but redirected to the new pages.
I think the first steps (export, conversion) will be a task for the lonesome cowboy. Afterwards, any help is greatly appreciated.
Regards
Felix
[1] https://www.apache.org/dev/cms.html
[2] https://issues.apache.org/jira/browse/FELIX-3816
[3] https://issues.apache.org/jira/browse/INFRA-5648
Re: Felix Site
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
CMS has been configured for our site now. The current (new state) is available from http://felix.staging.apache.org.
I have added some information on how to manage the site now at http://felix.staging.apache.org/documentation.html.
Over time we should now go over the new pages fix them as needed and then remove the old pages and add a static redirect from the old URL to the new one (I will add some notes to the documentation.html page on the latter point).
Regards
Felix
Am 18.12.2012 um 18:03 schrieb Felix Meschberger:
> Hi Benedikt,
>
> Thanks for the link (I have been loosely following that thread).
>
> I have in fact converted the Confluence data to ASF CMS mdtext files.
>
> Everything is in the site/trunk/content directory:
>
> * ipojo, obr, and site are copies from the current
> felix.apache.org site (so the current site is currently
> preserved but I would consider it static for now)
> * The rest is converted Confluence content. This is up to
> editing now.
>
> In addition there is a site/tools folder which can be checked out to manually generate the site if needed.
>
> Finally, I have described how the CMS site currently works in the site/trunk/content/documentatio.mdtext file. You can view this file in your preferred editor or in an Markdown editor (such as Mou).
>
> I think going forward we should now crosscheck the new pages against the old pages. Once a page has been "finalized", the old page can be removed and we would add a redirect to the .htdocs file in the root such that we have a redirect for the old URLs to the new URLs.
>
> Yet, currently I am still waiting for Infra to setup the CMS staging area such that we have automatic builds of the site.
>
> Regards
> Felix
>
> Am 18.12.2012 um 11:20 schrieb Benedikt Ritter:
>
>> Hi Felix,
>>
>> commons is also in the process of migrating the website. They also have a
>> main site and several sub project sites. Maybe the discussion on commons ML
>> [1] can help you with the felix website.
>>
>> Regards,
>> Benedikt
>>
>> [1] http://markmail.org/message/amw6yrsgaqj2btug
>>
>>
>> 2012/12/13 Felix Meschberger <fm...@adobe.com>
>>
>>> Hi Marcel,
>>>
>>> Am 13.12.2012 um 15:36 schrieb Marcel Offermans:
>>>
>>>> Hey Felix,
>>>>
>>>> I did this a bit earlier in the year for the Apache ACE site, so I can
>>> definitely help out a bit.
>>>
>>> Cool. Thanks.
>>>
>>> Actually, since the Sling site is very similar in setup to the Felix site,
>>> I hope to be able to leverage the same tools that I used for the Sling site
>>> also for the Felix site.
>>>
>>> After that any help is highly appreciated.
>>>
>>>>>
>>>>> (1) We will get immediate site updates: Whenever we change one or more
>>> pages and publish, the change will almost immediately be seen on the web.
>>> There is no multi-hour delay and incertainty any longer
>>>>
>>>> Yes, this is a great advantage. Also, we can "stage" changes, and view
>>> them on a special staging site before we publish them. All in all this is
>>> one of the biggest advantages I've seen so far using the new approach.
>>>
>>> Yes.
>>>
>>>>>
>>>>> When switching I think we should start with a double site: The new site
>>> available directly through the URL at http://felix.apache.org and the old
>>> site still available at http://felix.apache.org/site. This has nice
>>> advantage, that links from the web still work and we can crosscheck the new
>>> pages against the old ones easily. Over time we will remove the old pages
>>> but add (static) redirects to still support the old URLs but redirected to
>>> the new pages.
>>>>
>>>> So you propose that we make the new and old sites 100% identical as a
>>> first step, and then replace the old site with a bunch of redirects, and
>>> then start discussing potential changes and improvements to our site
>>> (layout and content wise)?
>>>
>>> Yes, more or less: My idea is to have the old site still live while we
>>> also have the new site. We can work on improving and fixing the new site
>>> while at the same validating it against the old site.
>>>
>>> Regards
>>> Felix
>
Re: Felix Site
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Benedikt,
Thanks for the link (I have been loosely following that thread).
I have in fact converted the Confluence data to ASF CMS mdtext files.
Everything is in the site/trunk/content directory:
* ipojo, obr, and site are copies from the current
felix.apache.org site (so the current site is currently
preserved but I would consider it static for now)
* The rest is converted Confluence content. This is up to
editing now.
In addition there is a site/tools folder which can be checked out to manually generate the site if needed.
Finally, I have described how the CMS site currently works in the site/trunk/content/documentatio.mdtext file. You can view this file in your preferred editor or in an Markdown editor (such as Mou).
I think going forward we should now crosscheck the new pages against the old pages. Once a page has been "finalized", the old page can be removed and we would add a redirect to the .htdocs file in the root such that we have a redirect for the old URLs to the new URLs.
Yet, currently I am still waiting for Infra to setup the CMS staging area such that we have automatic builds of the site.
Regards
Felix
Am 18.12.2012 um 11:20 schrieb Benedikt Ritter:
> Hi Felix,
>
> commons is also in the process of migrating the website. They also have a
> main site and several sub project sites. Maybe the discussion on commons ML
> [1] can help you with the felix website.
>
> Regards,
> Benedikt
>
> [1] http://markmail.org/message/amw6yrsgaqj2btug
>
>
> 2012/12/13 Felix Meschberger <fm...@adobe.com>
>
>> Hi Marcel,
>>
>> Am 13.12.2012 um 15:36 schrieb Marcel Offermans:
>>
>>> Hey Felix,
>>>
>>> I did this a bit earlier in the year for the Apache ACE site, so I can
>> definitely help out a bit.
>>
>> Cool. Thanks.
>>
>> Actually, since the Sling site is very similar in setup to the Felix site,
>> I hope to be able to leverage the same tools that I used for the Sling site
>> also for the Felix site.
>>
>> After that any help is highly appreciated.
>>
>>>>
>>>> (1) We will get immediate site updates: Whenever we change one or more
>> pages and publish, the change will almost immediately be seen on the web.
>> There is no multi-hour delay and incertainty any longer
>>>
>>> Yes, this is a great advantage. Also, we can "stage" changes, and view
>> them on a special staging site before we publish them. All in all this is
>> one of the biggest advantages I've seen so far using the new approach.
>>
>> Yes.
>>
>>>>
>>>> When switching I think we should start with a double site: The new site
>> available directly through the URL at http://felix.apache.org and the old
>> site still available at http://felix.apache.org/site. This has nice
>> advantage, that links from the web still work and we can crosscheck the new
>> pages against the old ones easily. Over time we will remove the old pages
>> but add (static) redirects to still support the old URLs but redirected to
>> the new pages.
>>>
>>> So you propose that we make the new and old sites 100% identical as a
>> first step, and then replace the old site with a bunch of redirects, and
>> then start discussing potential changes and improvements to our site
>> (layout and content wise)?
>>
>> Yes, more or less: My idea is to have the old site still live while we
>> also have the new site. We can work on improving and fixing the new site
>> while at the same validating it against the old site.
>>
>> Regards
>> Felix
Re: Felix Site
Posted by Benedikt Ritter <be...@gmail.com>.
Hi Felix,
commons is also in the process of migrating the website. They also have a
main site and several sub project sites. Maybe the discussion on commons ML
[1] can help you with the felix website.
Regards,
Benedikt
[1] http://markmail.org/message/amw6yrsgaqj2btug
2012/12/13 Felix Meschberger <fm...@adobe.com>
> Hi Marcel,
>
> Am 13.12.2012 um 15:36 schrieb Marcel Offermans:
>
> > Hey Felix,
> >
> > I did this a bit earlier in the year for the Apache ACE site, so I can
> definitely help out a bit.
>
> Cool. Thanks.
>
> Actually, since the Sling site is very similar in setup to the Felix site,
> I hope to be able to leverage the same tools that I used for the Sling site
> also for the Felix site.
>
> After that any help is highly appreciated.
>
> >>
> >> (1) We will get immediate site updates: Whenever we change one or more
> pages and publish, the change will almost immediately be seen on the web.
> There is no multi-hour delay and incertainty any longer
> >
> > Yes, this is a great advantage. Also, we can "stage" changes, and view
> them on a special staging site before we publish them. All in all this is
> one of the biggest advantages I've seen so far using the new approach.
>
> Yes.
>
> >>
> >> When switching I think we should start with a double site: The new site
> available directly through the URL at http://felix.apache.org and the old
> site still available at http://felix.apache.org/site. This has nice
> advantage, that links from the web still work and we can crosscheck the new
> pages against the old ones easily. Over time we will remove the old pages
> but add (static) redirects to still support the old URLs but redirected to
> the new pages.
> >
> > So you propose that we make the new and old sites 100% identical as a
> first step, and then replace the old site with a bunch of redirects, and
> then start discussing potential changes and improvements to our site
> (layout and content wise)?
>
> Yes, more or less: My idea is to have the old site still live while we
> also have the new site. We can work on improving and fixing the new site
> while at the same validating it against the old site.
>
> Regards
> Felix
Re: Felix Site
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Marcel,
Am 13.12.2012 um 15:36 schrieb Marcel Offermans:
> Hey Felix,
>
> I did this a bit earlier in the year for the Apache ACE site, so I can definitely help out a bit.
Cool. Thanks.
Actually, since the Sling site is very similar in setup to the Felix site, I hope to be able to leverage the same tools that I used for the Sling site also for the Felix site.
After that any help is highly appreciated.
>>
>> (1) We will get immediate site updates: Whenever we change one or more pages and publish, the change will almost immediately be seen on the web. There is no multi-hour delay and incertainty any longer
>
> Yes, this is a great advantage. Also, we can "stage" changes, and view them on a special staging site before we publish them. All in all this is one of the biggest advantages I've seen so far using the new approach.
Yes.
>>
>> When switching I think we should start with a double site: The new site available directly through the URL at http://felix.apache.org and the old site still available at http://felix.apache.org/site. This has nice advantage, that links from the web still work and we can crosscheck the new pages against the old ones easily. Over time we will remove the old pages but add (static) redirects to still support the old URLs but redirected to the new pages.
>
> So you propose that we make the new and old sites 100% identical as a first step, and then replace the old site with a bunch of redirects, and then start discussing potential changes and improvements to our site (layout and content wise)?
Yes, more or less: My idea is to have the old site still live while we also have the new site. We can work on improving and fixing the new site while at the same validating it against the old site.
Regards
Felix
Re: Felix Site
Posted by Marcel Offermans <ma...@luminis.nl>.
Hey Felix,
I did this a bit earlier in the year for the Apache ACE site, so I can definitely help out a bit.
On Dec 13, 2012, at 13:49 , Felix Meschberger <fm...@adobe.com> wrote:
> Earlier this year, Apache Infrastructure announced to switch off rsync support for Web Site management. On January, 1st, 2013, this will no actually happen.
>
> We are a bit late in the game, so I started as follows:
>
> * I created FELIX-3816 to track the migration
> * I created INFRA-5648 to ask for staging creation
>
> I will now export the existing Confluence content into SVN and start converting the pages. This will be an iterative process being mostly automatic. Since not everything can easily be converted, we will still have to cross check the pages and do some fine-tuning.
>
> What does this change mean at the end ?
>
> (1) We will get immediate site updates: Whenever we change one or more pages and publish, the change will almost immediately be seen on the web. There is no multi-hour delay and incertainty any longer
Yes, this is a great advantage. Also, we can "stage" changes, and view them on a special staging site before we publish them. All in all this is one of the biggest advantages I've seen so far using the new approach.
> (2) As a markup language "markdown" has been chosen. See [1] for links to the respective documentation.
> (3) We have more freedom in how we "build" our site. The initial look of the new site will be the same as the current site. But we may change this easily later on.
>
> When switching I think we should start with a double site: The new site available directly through the URL at http://felix.apache.org and the old site still available at http://felix.apache.org/site. This has nice advantage, that links from the web still work and we can crosscheck the new pages against the old ones easily. Over time we will remove the old pages but add (static) redirects to still support the old URLs but redirected to the new pages.
So you propose that we make the new and old sites 100% identical as a first step, and then replace the old site with a bunch of redirects, and then start discussing potential changes and improvements to our site (layout and content wise)?
Greetings, Marcel