The site was migrated to SvnSubPub but doesn't look good right now :P

http://struts.staging.apache.org/


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2012/12/16 Rene Gielen <[email protected]>:
>
> Am 16.12.12 14:21, schrieb Christian Grobmeier:
>> On Sun, Dec 16, 2012 at 12:41 PM, Rene Gielen <[email protected]> wrote:
>> [...]
>>> If I understand this right, we have two options to deal with our "main
>>> site", which is basically everything on s.a.o excluding the confluence
>>> exports:
>>> - move to CMS
>>> - maintain via svnpubsub
>>> The latter one, if I get this right, is basically the same as we had
>>> before with a changed transport - so instead of pushing the actual built
>>> HTML with ssh, we'd rather generate them into a svn-checkout and commit
>>> them.
>>
>> Thats also my understanding.
>>
>>> A CMS, on the other hand, is a ... CMS :) Sounds like live editing and
>>> such stuff. Do you have experience with the workflow improvements to
>>> expect, over using snvpubsub?
>>
>> The CMS is a bit ugly (forgive me cms devs, if you read that) but
>> works very well. As website maintainer, you would create a "working
>> space", do your changes and publish it. As it works on the back of svn
>> its like a svn creating a branch, changing and committing your text
>> and finally merging into trunk. It makes maintaining the website
>> pretty easy.
>>
>
> I just found the video tutorial, which gives a really good impression on
> how to enjoy the easy workflow bits
> http://s.apache.org/cms-tutorial
>
>> For example, you could look at the main Apache site.
>> https://cms.apache.org/www/wc/browse/grobmeier-rtuhJr/trunk/content/dev/cms.mdtext
>> Its written with Markdown. It easy to edit with the Chrome extension
>> (don't know currently where to download).
>>
>
> Markdown is a really nice option. Even though the site-plugin setup we
> use keeps away some boilerplate stuff, it's still HTML hacking we do in
> the source code files. MD is more concise and gives you room for
> consistent editing and styling as a separated concern, much like our
> confluence wiki.
>
> BUT - as I see it now, we would have to convert our whole site to MD
> right from the start if we wanted to use the CMS workflow now. Besides
> that others may have different opinions on MD driven websites, I don't
> see that we will be able to accomplish such a migration in time.
>
>> Ivan from the log4php team has made some Twig based templates for
>> Logging. Its now used on the mainsite logging.apache.org.
>> http://svn.apache.org/repos/asf/logging/site/cms/trunk/
>>
>> The content is maintained via the CMS. So you see, its possible to
>> make some kind of good design with it.
>> Here is another good link:
>> http://wiki.apache.org/logging/BuildingTheWebSite
>> for running the website locally (if you want some more geek stuff its
>> not necesary)#
>>
>
> What I really don't like about the local setup is that it requires Perl
> - we require Java and Maven so far, and I'd prefer that this stays to be
> the case. But given that you don't have to build the full site locally
> any more, one could argue that this downside is bearable.
>
>> That said, its kind of work to move it out from mvn to the CMS.
>>
>> My suggestion: move what we have now with the build we use now. Then
>> we can decide if walk the next step and use the CMS for our content.
>>
>
> +1 here - sounds like it would be the easiest possible migration to the
> maintained infrastructure for now, and we could keep the invested work
> in the Fluido based new site layout for launching a modernized Struts
> project site any time soon. Afterwards we might find the time and
> passion to move to a CMS based setu.
>
> - René
>
> --
> René Gielen
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to