[
https://issues.apache.org/jira/browse/HADOOP-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332035#comment-16332035
]
Elek, Marton commented on HADOOP-14163:
---------------------------------------
# Yes. It works exactly the same. I just attached the source, because the
generatted html files should be commited to a different branch according to
this proposal. But I uploaded them to here:
[https://github.com/elek/hadoop-site-proposal/tree/gh-pages]
# I found a very long comparison at here
[https://opensource.com/article/17/5/hugo-vs-jekyll] I used jekyll a few years
ago, so I am not so familiar with the latest version, but my biggest problem
was exactly the same what [~aw] is noted. It was difficult to maintain the
right version of ruby with the right version of gems when my blog is updated
only a few times per year (even if I used rvm). I think the two biggest
advantage of Hugo are:
## It is just a single binary for every platform, no dependencies. Very easy
to run even if the release manager is no familiar with ruby/python/npm any
other language/environment. Download and execute, nothing more.
## I also like how Hugo structures the content. Everything under the
content/release directory (eg. this file:
[https://raw.githubusercontent.com/elek/hadoop-site-proposal/master/content/release/2.8.1.md)]
could be handled in a different way not just as a news entry. This is a very
easy way to handle releases. The release script/release manager should generate
only a simple md file with a header, nothing more. More scriptable, easier to
maintain.
# Good question, I have never thought about it. I doesn't seems to be
supported (eg. [https://github.com/gohugoio/hugo/issues/1430)], but hopefully
it could be handled by an external tool. (Or during a pre-commit yetus check?)
> Refactor existing hadoop site to use more usable static website generator
> -------------------------------------------------------------------------
>
> Key: HADOOP-14163
> URL: https://issues.apache.org/jira/browse/HADOOP-14163
> Project: Hadoop Common
> Issue Type: Improvement
> Components: site
> Reporter: Elek, Marton
> Assignee: Elek, Marton
> Priority: Major
> Attachments: HADOOP-14163-001.zip, HADOOP-14163-002.zip,
> HADOOP-14163-003.zip, HADOOP-14163.004.patch, HADOOP-14163.005.patch,
> HADOOP-14163.006.patch, HADOOP-14163.007.patch, HADOOP-14163.008.tar.gz,
> hadoop-site.tar.gz, hadop-site-rendered.tar.gz
>
>
> From the dev mailing list:
> "Publishing can be attacked via a mix of scripting and revamping the darned
> website. Forrest is pretty bad compared to the newer static site generators
> out there (e.g. need to write XML instead of markdown, it's hard to review a
> staging site because of all the absolute links, hard to customize, did I
> mention XML?), and the look and feel of the site is from the 00s. We don't
> actually have that much site content, so it should be possible to migrate to
> a new system."
> This issue is find a solution to migrate the old site to a new modern static
> site generator using a more contemprary theme.
> Goals:
> * existing links should work (or at least redirected)
> * It should be easy to add more content required by a release automatically
> (most probably with creating separated markdown files)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
