accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: git-based site and jekyll
Date Tue, 08 Mar 2016 18:32:01 GMT
+1 on moving to Jekyll

On Tue, Mar 8, 2016 at 12:46 PM, Josh Elser <> wrote:

> +1 as well. I would be extremely happy moving to Jekyll.
> The one concern I had was regarding automatic rendering of what would look
> like "the Apache Accumulo website" on Github (both apache/accumulo github
> account and other forks).
> Christopher had said that no one seemed to object in comdev@ when he
> talked about this a while back. I wanted to make sure everyone considered
> this (for example, Christopher's fork of Drill's repository now also looks
> like a canonical host of the Apache Drill project). I'm not actively
> stating that I think it's an issue at this point, only suggesting that we
> give it some thought and maybe ask someone who is more knowledgable (Shane
> from trademarks?) before moving forward. The worst case I envision is that
> we find some way to "gimp" the github-rendered site (redirect back to the
> canonical or similar).

I also I think it would be good to seek clarification on the trademark
issue.  The content of the website is ASF licensed and that gives lot of
freedom.   Howerver, the trademarks are a different animal.  Out of
curiosity, I was reading the following guidance on external entities using
Apache marks.  I don't have enough knowledge or experience to draw any
conclusions from reading the guidance, but found it interesting.

> Christopher wrote:
>> I got some information back from INFRA about how the git-based sites work.
>> It's just plain old static hosting of a git branch. So, whatever we'd put
>> in a specified branch would show up directly on the site, no rendering or
>> generation. This would completely bypass CMS and buildbot staging builds.
>> Was discussing this with elserj in IRC, and these ideas came out of that:
>> 1. Switch site to use git branch named "site" or "website" or similar.
>> 2. Use jekyll 3 to generate the static site contents in this git branch.
>> 3. Store the unrendered (markdown) jekyll stuff in a gh-pages branch.
>> 4. Possibly set up a post-commit hook on gh-pages branch to render locally
>> and commit the generated static site to the "site" branch.
>> This would have the following benefits:
>> * Canonical rendering of "site" branch at
>> * Identical, automatic rendering of gh-pages branch at
>> * Changes to gh-pages in forks would render in fork's for
>> preview/testing
>> * Jekyll can be run locally for preview for non-GitHub users wishing to
>> contribute updates to site
>> * Use of jekyll means we can still edit/use markdown to edit pages
>> * Can still include non-markdown content and raw html
>> Another project which seems to be doing this (or something close to it) is
>> Apache Drill:
>> (example fork build)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message