git-based site and jekyll

[Christopher <ct...@apache.org>]

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 http://accumulo.apache.org
* Identical, automatic rendering of gh-pages branch at
http://apache.github.io/accumulo
* Changes to gh-pages in forks would render in fork's github.io 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:
https://drill.apache.org/
http://apache.github.io/drill/
http://ctubbsii.github.io/drill/ (example fork build)

Re: git-based site and jekyll

[William Slacum <ws...@gmail.com>]

I would like to request at least one frame and one scrolling marquee. Can
we blingee the Accumulo logo?

On Thursday, March 10, 2016, Josh Elser <jo...@gmail.com> wrote:

> * Some companies on http://ctubbsii.github.io/accumulo/people.html are
> goofed as are the timezones.
> * Some broken links on http://ctubbsii.github.io/accumulo/source.html.
> Coding practices are also messed up.
> * http://ctubbsii.github.io/accumulo/contrib.html contrib project entries
> are a little wacky.
> * http://ctubbsii.github.io/accumulo/screenshots.html is weird with the
> monitor screenshot (should be beneath the text?)
> * Just noticed that Other and Documentation both have a link to the
> papers/presentations. That might actually be how the site is now, just
> realized it's duplicative.
>
> Thanks again for doing this. It's great!
>
> Christopher wrote:
>
>> Actually, I now have it all working (as far as I can tell) with everything
>> pretty much the same as it looks with CMS today. After people have taken
>> the time to give it a glance, I'll push it to the ASF repo, and then push
>> the generated site to a separate branch. Then we can put in the INFRA
>> ticket to switch from svn to git.
>>
>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>  wrote:
>>
>> I'm working on converting our current site contents over to jekyll at
>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
>>> (view at http://ctubbsii.github.io/accumulo)
>>>
>>> Yes, it's terrible right now... it's in progress. :)
>>>
>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>  wrote:
>>>
>>> Lazy consensus is fine. If there are no objections, I don't want to hold
>>>> things up. I feel like I've adequately expressed my concerns. Silence
>>>> can and should be treated as acknowledgement for this, IMO.
>>>>
>>>> Christopher wrote:
>>>>
>>>>> Another reason we probably shouldn't worry about this: anybody can
>>>>>
>>>> create a
>>>>
>>>>> DNS name at their leisure which transparently redirects to
>>>>> accumulo.apache.org and serves its contents. This is perfectly
>>>>>
>>>> legitimate
>>>>
>>>>> for a number of reasons, including corporate proxies/mirrors,
>>>>> URL-shortening services, caching services, archiving services,
>>>>> vision-impaired accessibility services, foreign-language DNS mappings,
>>>>>
>>>> and
>>>>
>>>>> so-on.
>>>>>
>>>>> I think when it comes to trademarks and our website, our area of
>>>>> concern
>>>>> should mostly focus on when people misrepresent our trademark in the
>>>>>
>>>> course
>>>>
>>>>> of their mirroring/archiving. There's no risk of that for a mirror that
>>>>>
>>>> is
>>>>
>>>>> explicitly under our control, but I'm really leaning towards the
>>>>>
>>>> javascript
>>>>
>>>>> to detect and display a message about the canonical location just to
>>>>> mitigate any possibility for concern.
>>>>>
>>>>> If you still have concerns, I'd be happy to put it up for a formal vote
>>>>> from the PMC, or to get feedback from ASF trademarks folks before we
>>>>> proceed.
>>>>>
>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
>>>>>  wrote:
>>>>>
>>>>> Well, I think the difference is that archive.org (and others -- google
>>>>>> cached pages come to mind) are devoted/known for that specific
>>>>>> purpose.
>>>>>> The fact that Github ends up being a "de-facto" location for software
>>>>>> projects, I'm just nervous about the expecting good faith from the
>>>>>> denizens of the internet. Maybe I'm just worrying too much. If there's
>>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.
>>>>>>
>>>>>> Christopher wrote:
>>>>>>
>>>>>>> I can't imagine there's a trademark issue since it's really just
>>>>>>>
>>>>>> acting
>>>>
>>>>> as
>>>>>>
>>>>>>> a mirror. If there were trademark issues, I imagine sites like
>>>>>>> http://archive.org would be in big trouble. But, it certainly
>>>>>>>
>>>>>> couldn't
>>>>
>>>>> hurt
>>>>>>
>>>>>>> to find out.
>>>>>>>
>>>>>>> Another option to sabotage the GH-rendered site is to add some
>>>>>>>
>>>>>> javascript
>>>>
>>>>> which detects the location and displays an informative link back to
>>>>>>>
>>>>>> the
>>>>
>>>>> canonical location for the site. That should be simple enough to do.
>>>>>>>
>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
>>>>>>>
>>>>>>   wrote:
>>>>
>>>>> It's also probably worth mentioning that this concern only comes
>>>>>>>>
>>>>>>> about
>>>>
>>>>> for point #4 (or if we use the branch name gh-pages in point #1).
>>>>>>>>
>>>>>>>> Josh Elser wrote:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>> accumulo.apache.org
>>>>>>
>>>>>>> or similar).
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

Yeah, that menu scrolling has been a long-time irritation :)

You can adding some more padding-left if you want to increase the 
spacing (I think I put 5-10px).

Christopher wrote:
> I noticed that the arrow on the right of the drop-down menus looked a bit
> closer after Josh's last change, but I don't think it's a problem (it's not
> on my screen, anyway).
> (though, I think I prefer the anchors on the left for the sections)
>
> One annoying think about the anchor links is that linking directly to a
> section puts the section name underneath our top menu... that's kinda
> annoying, but not sure how to avoid it. Maybe make the menu auto-hide
> unless you're scrolled all the way to the top?
>
>
> On Tue, Mar 22, 2016 at 2:34 AM Christopher<ct...@apache.org>  wrote:
>
>> I think I updated all the existing pages covering that, but the whole site
>> could do with a cleanup and reorganization, along with additional howtos.
>>
>> On Mon, Mar 21, 2016, 22:17 Josh Elser<jo...@gmail.com>  wrote:
>>
>>> Moved the anchor links to the right side again :)
>>>
>>> In your post-commit hook, `mktemp` doesn't work on OSX with the
>>> `--tmpdir` option.
>>>
>>> Have you made a canonical "How to update the website" page yet?
>>>
>>> Christopher wrote:
>>>> I didn't see anything which indicated we had those in the past. Maybe it
>>>> was something CMS was doing special, but I figured out how to get the
>>>> section links present.
>>>>
>>>> On Sat, Mar 19, 2016 at 5:21 PM Christopher<ct...@apache.org>
>>> wrote:
>>>>> I don't think I ever noticed those before. There might be a kramdown
>>>>> option we can turn on.
>>>>>
>>>>> On Sat, Mar 19, 2016, 16:55 Josh Elser<jo...@gmail.com>   wrote:
>>>>>
>>>>>> One thing I just noticed is that the quick "anchor" links at the end
>>> of
>>>>>> each header (specifically on the release notes page) are missing.
>>>>>>
>>>>>> I liked those because it was easy to click the header to get a url and
>>>>>> use it to reference.
>>>>>>
>>>>>> The IDs are still there on each section, just the quick link to get
>>>>>> there is missing (so I have to look it up). Not sure if there is an
>>> easy
>>>>>> way to get this with Jekyll (or if it'd just be something we have to
>>> do
>>>>>> by hand).
>>>>>>
>>>>>> Christopher wrote:
>>>>>>> There's plenty of room for improvement to the new git/Jekyll site.
>>> For
>>>>>>> instance, we can start blogging there, so we have greater control
>>> over
>>>>>> the
>>>>>>> look and feel of our blog posts, and so any committer can blog
>>> without
>>>>>>> needing to request an extra account. At some point, I think it'd be
>>>>>> good to
>>>>>>> migrate our existing blogs over to this.
>>>>>>>
>>>>>>> Another thing we can do is put our release notes in an RSS feed, so
>>>>>> users
>>>>>>> subscribe to new release announcements/notes. I might put some
>>> thought
>>>>>> into
>>>>>>> that at a later point in time. For now, I'm just happy we're on git
>>> for
>>>>>>> everything except the dist.apache.org/release mirroring (for which
>>> I'm
>>>>>>> totally fine using git-svn).
>>>>>>>
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

I noticed that the arrow on the right of the drop-down menus looked a bit
closer after Josh's last change, but I don't think it's a problem (it's not
on my screen, anyway).
(though, I think I prefer the anchors on the left for the sections)

One annoying think about the anchor links is that linking directly to a
section puts the section name underneath our top menu... that's kinda
annoying, but not sure how to avoid it. Maybe make the menu auto-hide
unless you're scrolled all the way to the top?


On Tue, Mar 22, 2016 at 2:34 AM Christopher <ct...@apache.org> wrote:

> I think I updated all the existing pages covering that, but the whole site
> could do with a cleanup and reorganization, along with additional howtos.
>
> On Mon, Mar 21, 2016, 22:17 Josh Elser <jo...@gmail.com> wrote:
>
>> Moved the anchor links to the right side again :)
>>
>> In your post-commit hook, `mktemp` doesn't work on OSX with the
>> `--tmpdir` option.
>>
>> Have you made a canonical "How to update the website" page yet?
>>
>> Christopher wrote:
>> > I didn't see anything which indicated we had those in the past. Maybe it
>> > was something CMS was doing special, but I figured out how to get the
>> > section links present.
>> >
>> > On Sat, Mar 19, 2016 at 5:21 PM Christopher<ct...@apache.org>
>> wrote:
>> >
>> >> I don't think I ever noticed those before. There might be a kramdown
>> >> option we can turn on.
>> >>
>> >> On Sat, Mar 19, 2016, 16:55 Josh Elser<jo...@gmail.com>  wrote:
>> >>
>> >>> One thing I just noticed is that the quick "anchor" links at the end
>> of
>> >>> each header (specifically on the release notes page) are missing.
>> >>>
>> >>> I liked those because it was easy to click the header to get a url and
>> >>> use it to reference.
>> >>>
>> >>> The IDs are still there on each section, just the quick link to get
>> >>> there is missing (so I have to look it up). Not sure if there is an
>> easy
>> >>> way to get this with Jekyll (or if it'd just be something we have to
>> do
>> >>> by hand).
>> >>>
>> >>> Christopher wrote:
>> >>>> There's plenty of room for improvement to the new git/Jekyll site.
>> For
>> >>>> instance, we can start blogging there, so we have greater control
>> over
>> >>> the
>> >>>> look and feel of our blog posts, and so any committer can blog
>> without
>> >>>> needing to request an extra account. At some point, I think it'd be
>> >>> good to
>> >>>> migrate our existing blogs over to this.
>> >>>>
>> >>>> Another thing we can do is put our release notes in an RSS feed, so
>> >>> users
>> >>>> subscribe to new release announcements/notes. I might put some
>> thought
>> >>> into
>> >>>> that at a later point in time. For now, I'm just happy we're on git
>> for
>> >>>> everything except the dist.apache.org/release mirroring (for which
>> I'm
>> >>>> totally fine using git-svn).
>> >>>>
>> >
>>
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

I think I updated all the existing pages covering that, but the whole site
could do with a cleanup and reorganization, along with additional howtos.

On Mon, Mar 21, 2016, 22:17 Josh Elser <jo...@gmail.com> wrote:

> Moved the anchor links to the right side again :)
>
> In your post-commit hook, `mktemp` doesn't work on OSX with the
> `--tmpdir` option.
>
> Have you made a canonical "How to update the website" page yet?
>
> Christopher wrote:
> > I didn't see anything which indicated we had those in the past. Maybe it
> > was something CMS was doing special, but I figured out how to get the
> > section links present.
> >
> > On Sat, Mar 19, 2016 at 5:21 PM Christopher<ct...@apache.org>  wrote:
> >
> >> I don't think I ever noticed those before. There might be a kramdown
> >> option we can turn on.
> >>
> >> On Sat, Mar 19, 2016, 16:55 Josh Elser<jo...@gmail.com>  wrote:
> >>
> >>> One thing I just noticed is that the quick "anchor" links at the end of
> >>> each header (specifically on the release notes page) are missing.
> >>>
> >>> I liked those because it was easy to click the header to get a url and
> >>> use it to reference.
> >>>
> >>> The IDs are still there on each section, just the quick link to get
> >>> there is missing (so I have to look it up). Not sure if there is an
> easy
> >>> way to get this with Jekyll (or if it'd just be something we have to do
> >>> by hand).
> >>>
> >>> Christopher wrote:
> >>>> There's plenty of room for improvement to the new git/Jekyll site. For
> >>>> instance, we can start blogging there, so we have greater control over
> >>> the
> >>>> look and feel of our blog posts, and so any committer can blog without
> >>>> needing to request an extra account. At some point, I think it'd be
> >>> good to
> >>>> migrate our existing blogs over to this.
> >>>>
> >>>> Another thing we can do is put our release notes in an RSS feed, so
> >>> users
> >>>> subscribe to new release announcements/notes. I might put some thought
> >>> into
> >>>> that at a later point in time. For now, I'm just happy we're on git
> for
> >>>> everything except the dist.apache.org/release mirroring (for which
> I'm
> >>>> totally fine using git-svn).
> >>>>
> >
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

Moved the anchor links to the right side again :)

In your post-commit hook, `mktemp` doesn't work on OSX with the 
`--tmpdir` option.

Have you made a canonical "How to update the website" page yet?

Christopher wrote:
> I didn't see anything which indicated we had those in the past. Maybe it
> was something CMS was doing special, but I figured out how to get the
> section links present.
>
> On Sat, Mar 19, 2016 at 5:21 PM Christopher<ct...@apache.org>  wrote:
>
>> I don't think I ever noticed those before. There might be a kramdown
>> option we can turn on.
>>
>> On Sat, Mar 19, 2016, 16:55 Josh Elser<jo...@gmail.com>  wrote:
>>
>>> One thing I just noticed is that the quick "anchor" links at the end of
>>> each header (specifically on the release notes page) are missing.
>>>
>>> I liked those because it was easy to click the header to get a url and
>>> use it to reference.
>>>
>>> The IDs are still there on each section, just the quick link to get
>>> there is missing (so I have to look it up). Not sure if there is an easy
>>> way to get this with Jekyll (or if it'd just be something we have to do
>>> by hand).
>>>
>>> Christopher wrote:
>>>> There's plenty of room for improvement to the new git/Jekyll site. For
>>>> instance, we can start blogging there, so we have greater control over
>>> the
>>>> look and feel of our blog posts, and so any committer can blog without
>>>> needing to request an extra account. At some point, I think it'd be
>>> good to
>>>> migrate our existing blogs over to this.
>>>>
>>>> Another thing we can do is put our release notes in an RSS feed, so
>>> users
>>>> subscribe to new release announcements/notes. I might put some thought
>>> into
>>>> that at a later point in time. For now, I'm just happy we're on git for
>>>> everything except the dist.apache.org/release mirroring (for which I'm
>>>> totally fine using git-svn).
>>>>
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

I didn't see anything which indicated we had those in the past. Maybe it
was something CMS was doing special, but I figured out how to get the
section links present.

On Sat, Mar 19, 2016 at 5:21 PM Christopher <ct...@apache.org> wrote:

> I don't think I ever noticed those before. There might be a kramdown
> option we can turn on.
>
> On Sat, Mar 19, 2016, 16:55 Josh Elser <jo...@gmail.com> wrote:
>
>> One thing I just noticed is that the quick "anchor" links at the end of
>> each header (specifically on the release notes page) are missing.
>>
>> I liked those because it was easy to click the header to get a url and
>> use it to reference.
>>
>> The IDs are still there on each section, just the quick link to get
>> there is missing (so I have to look it up). Not sure if there is an easy
>> way to get this with Jekyll (or if it'd just be something we have to do
>> by hand).
>>
>> Christopher wrote:
>> > There's plenty of room for improvement to the new git/Jekyll site. For
>> > instance, we can start blogging there, so we have greater control over
>> the
>> > look and feel of our blog posts, and so any committer can blog without
>> > needing to request an extra account. At some point, I think it'd be
>> good to
>> > migrate our existing blogs over to this.
>> >
>> > Another thing we can do is put our release notes in an RSS feed, so
>> users
>> > subscribe to new release announcements/notes. I might put some thought
>> into
>> > that at a later point in time. For now, I'm just happy we're on git for
>> > everything except the dist.apache.org/release mirroring (for which I'm
>> > totally fine using git-svn).
>> >
>>
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

I don't think I ever noticed those before. There might be a kramdown option
we can turn on.

On Sat, Mar 19, 2016, 16:55 Josh Elser <jo...@gmail.com> wrote:

> One thing I just noticed is that the quick "anchor" links at the end of
> each header (specifically on the release notes page) are missing.
>
> I liked those because it was easy to click the header to get a url and
> use it to reference.
>
> The IDs are still there on each section, just the quick link to get
> there is missing (so I have to look it up). Not sure if there is an easy
> way to get this with Jekyll (or if it'd just be something we have to do
> by hand).
>
> Christopher wrote:
> > There's plenty of room for improvement to the new git/Jekyll site. For
> > instance, we can start blogging there, so we have greater control over
> the
> > look and feel of our blog posts, and so any committer can blog without
> > needing to request an extra account. At some point, I think it'd be good
> to
> > migrate our existing blogs over to this.
> >
> > Another thing we can do is put our release notes in an RSS feed, so users
> > subscribe to new release announcements/notes. I might put some thought
> into
> > that at a later point in time. For now, I'm just happy we're on git for
> > everything except the dist.apache.org/release mirroring (for which I'm
> > totally fine using git-svn).
> >
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

One thing I just noticed is that the quick "anchor" links at the end of 
each header (specifically on the release notes page) are missing.

I liked those because it was easy to click the header to get a url and 
use it to reference.

The IDs are still there on each section, just the quick link to get 
there is missing (so I have to look it up). Not sure if there is an easy 
way to get this with Jekyll (or if it'd just be something we have to do 
by hand).

Christopher wrote:
> There's plenty of room for improvement to the new git/Jekyll site. For
> instance, we can start blogging there, so we have greater control over the
> look and feel of our blog posts, and so any committer can blog without
> needing to request an extra account. At some point, I think it'd be good to
> migrate our existing blogs over to this.
>
> Another thing we can do is put our release notes in an RSS feed, so users
> subscribe to new release announcements/notes. I might put some thought into
> that at a later point in time. For now, I'm just happy we're on git for
> everything except the dist.apache.org/release mirroring (for which I'm
> totally fine using git-svn).
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

There's plenty of room for improvement to the new git/Jekyll site. For
instance, we can start blogging there, so we have greater control over the
look and feel of our blog posts, and so any committer can blog without
needing to request an extra account. At some point, I think it'd be good to
migrate our existing blogs over to this.

Another thing we can do is put our release notes in an RSS feed, so users
subscribe to new release announcements/notes. I might put some thought into
that at a later point in time. For now, I'm just happy we're on git for
everything except the dist.apache.org/release mirroring (for which I'm
totally fine using git-svn).

On Tue, Mar 15, 2016 at 6:14 PM Christopher <ct...@apache.org> wrote:

> There seemed to be a slight hiccup with the switchover... it didn't work
> on the previous push, but it worked just fine now. I've added some small
> javascript/html to our template so it shows a link to our canonical site in
> a banner when you're seeing our site hosted in a mirror. The banner is
> hidden on our canonical site.
>
> On Mon, Mar 14, 2016 at 5:33 PM Christopher <ct...@apache.org> wrote:
>
>> With the completion of INFRA-11437
>> <https://issues.apache.org/jira/browse/INFRA-11437>, our site should now
>> be building out of git. They wanted the branch to be called "asf-site", so
>> I renamed the one called "accumulo.apache.org". Shortly, I will be
>> updating the docs on our site which provide instructions for updating.
>>
>> On Sun, Mar 13, 2016 at 12:25 AM Christopher <ct...@apache.org> wrote:
>>
>>> Well, if I wasn't a git aficionado before, I'm well on my way. Using
>>> some low-level git commands (making full use of StackOverflow[1]), I
>>> actually put together a git post-commit hook to automatically regenerate
>>> and update the accumulo.apache.org branch (assuming you have one
>>> checked out locally) whenever you edit the gh-pages branch.
>>>
>>> Feel free to check it out here[2]. I've gone ahead and checked it into
>>> the gh-pages repo in a "hidden" (from Jekyll) developer area.
>>>
>>> Basically, if you have a local branch (hopefully one that is up-to-date
>>> and tracking upstream accumulo git) called "accumulo.apache.org", and
>>> you're current working branch is "gh-pages", all you need to do is copy (or
>>> symlink) the file to .git/hooks/post-commit
>>>
>>> This is just one useful way to automate this. A pre-push hook might work
>>> just as well, which commits directly to the remote or something which
>>> doesn't require a local up-to-date tracking branch to be useful. Still, I'm
>>> pretty proud of it.
>>>
>>> Enjoy!
>>>
>>> [1]: http://stackoverflow.com/a/35963533/196405
>>> [2]:
>>> https://github.com/apache/accumulo/blob/gh-pages/_devtools/git-hooks/post-commit
>>>
>>>
>>> On Fri, Mar 11, 2016 at 1:12 PM Josh Elser <jo...@gmail.com> wrote:
>>>
>>>> +1
>>>>
>>>> Dylan Hutchison wrote:
>>>> > Sounds great Chris!
>>>> >
>>>> > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ct...@apache.org>
>>>> wrote:
>>>> >
>>>> >> So, if everybody's happy doing this, I'll go ahead and perform the
>>>> >> following steps:
>>>> >>
>>>> >> 1. Push gh-pages branch to our repo
>>>> >> 2. Perform a jekyll build on the branch and put it in a branch
>>>> called "
>>>> >> accumulo.apache.org"
>>>> >> 3. Push the accumulo.apache.org branch
>>>> >> 4. File INFRA ticket to switch our site to git using the
>>>> >> accumulo.apache.org
>>>> >> branch
>>>> >>
>>>> >>
>>>> >> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi<
>>>> billie.rinaldi@gmail.com>
>>>> >> wrote:
>>>> >>
>>>> >>> Wow, that's looking great.  Thanks, Christopher!
>>>> >>>
>>>> >>> Billie
>>>> >>>
>>>> >>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<ct...@apache.org>
>>>> >> wrote:
>>>> >>>> Thanks Josh! I fixed all the issues you saw, except the screenshots
>>>> >> one,
>>>> >>>> since that's currently just how our layout is (looks the same at
>>>> >>>> accumulo.apache.org).
>>>> >>>>
>>>> >>>> Most of the bugs you saw were existing bugs with either our HTML
>>>> or our
>>>> >>>> Markdown... but whatever CMS is doing is a bit more tolerant than
>>>> >>> Kramdown
>>>> >>>> is apparently.
>>>> >>>>
>>>> >>>> Biggest problem I saw was that people keep forgetting quotes around
>>>> >> HTML
>>>> >>>> attributes. Example, it should be<a href="location">, not<a
>>>> >>>> href=location>.
>>>> >>>>
>>>> >>>> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser<jo...@gmail.com>
>>>> >> wrote:
>>>> >>>>> * Some companies on
>>>> http://ctubbsii.github.io/accumulo/people.html
>>>> >> are
>>>> >>>>> goofed as are the timezones.
>>>> >>>>> * Some broken links on
>>>> >> http://ctubbsii.github.io/accumulo/source.html.
>>>> >>>>> Coding practices are also messed up.
>>>> >>>>> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
>>>> >>>>> entries are a little wacky.
>>>> >>>>> * http://ctubbsii.github.io/accumulo/screenshots.html is weird
>>>> with
>>>> >>> the
>>>> >>>>> monitor screenshot (should be beneath the text?)
>>>> >>>>> * Just noticed that Other and Documentation both have a link to
>>>> the
>>>> >>>>> papers/presentations. That might actually be how the site is now,
>>>> >> just
>>>> >>>>> realized it's duplicative.
>>>> >>>>>
>>>> >>>>> Thanks again for doing this. It's great!
>>>> >>>>>
>>>> >>>>> Christopher wrote:
>>>> >>>>>> Actually, I now have it all working (as far as I can tell) with
>>>> >>>>> everything
>>>> >>>>>> pretty much the same as it looks with CMS today. After people
>>>> have
>>>> >>>> taken
>>>> >>>>>> the time to give it a glance, I'll push it to the ASF repo, and
>>>> >> then
>>>> >>>> push
>>>> >>>>>> the generated site to a separate branch. Then we can put in the
>>>> >> INFRA
>>>> >>>>>> ticket to switch from svn to git.
>>>> >>>>>>
>>>> >>>>>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
>>>> >>>> wrote:
>>>> >>>>>>> I'm working on converting our current site contents over to
>>>> jekyll
>>>> >>> at
>>>> >>>>>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
>>>> >>>>>>> (view at http://ctubbsii.github.io/accumulo)
>>>> >>>>>>>
>>>> >>>>>>> Yes, it's terrible right now... it's in progress. :)
>>>> >>>>>>>
>>>> >>>>>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
>>>> >>>> wrote:
>>>> >>>>>>>> Lazy consensus is fine. If there are no objections, I don't
>>>> want
>>>> >> to
>>>> >>>>> hold
>>>> >>>>>>>> things up. I feel like I've adequately expressed my concerns.
>>>> >>> Silence
>>>> >>>>>>>> can and should be treated as acknowledgement for this, IMO.
>>>> >>>>>>>>
>>>> >>>>>>>> Christopher wrote:
>>>> >>>>>>>>> Another reason we probably shouldn't worry about this: anybody
>>>> >> can
>>>> >>>>>>>> create a
>>>> >>>>>>>>> DNS name at their leisure which transparently redirects to
>>>> >>>>>>>>> accumulo.apache.org and serves its contents. This is
>>>> perfectly
>>>> >>>>>>>> legitimate
>>>> >>>>>>>>> for a number of reasons, including corporate proxies/mirrors,
>>>> >>>>>>>>> URL-shortening services, caching services, archiving services,
>>>> >>>>>>>>> vision-impaired accessibility services, foreign-language DNS
>>>> >>>> mappings,
>>>> >>>>>>>> and
>>>> >>>>>>>>> so-on.
>>>> >>>>>>>>>
>>>> >>>>>>>>> I think when it comes to trademarks and our website, our area
>>>> of
>>>> >>>>> concern
>>>> >>>>>>>>> should mostly focus on when people misrepresent our trademark
>>>> in
>>>> >>> the
>>>> >>>>>>>> course
>>>> >>>>>>>>> of their mirroring/archiving. There's no risk of that for a
>>>> >> mirror
>>>> >>>>> that
>>>> >>>>>>>> is
>>>> >>>>>>>>> explicitly under our control, but I'm really leaning towards
>>>> the
>>>> >>>>>>>> javascript
>>>> >>>>>>>>> to detect and display a message about the canonical location
>>>> >> just
>>>> >>> to
>>>> >>>>>>>>> mitigate any possibility for concern.
>>>> >>>>>>>>>
>>>> >>>>>>>>> If you still have concerns, I'd be happy to put it up for a
>>>> >> formal
>>>> >>>>> vote
>>>> >>>>>>>>> from the PMC, or to get feedback from ASF trademarks folks
>>>> >> before
>>>> >>> we
>>>> >>>>>>>>> proceed.
>>>> >>>>>>>>>
>>>> >>>>>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<
>>>> josh.elser@gmail.com>
>>>> >>>>>   wrote:
>>>> >>>>>>>>>> Well, I think the difference is that archive.org (and others
>>>> >> --
>>>> >>>>> google
>>>> >>>>>>>>>> cached pages come to mind) are devoted/known for that
>>>> specific
>>>> >>>>> purpose.
>>>> >>>>>>>>>> The fact that Github ends up being a "de-facto" location for
>>>> >>>> software
>>>> >>>>>>>>>> projects, I'm just nervous about the expecting good faith
>>>> from
>>>> >>> the
>>>> >>>>>>>>>> denizens of the internet. Maybe I'm just worrying too much.
>>>> If
>>>> >>>>> there's
>>>> >>>>>>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's
>>>> fine
>>>> >>> by
>>>> >>>>> me.
>>>> >>>>>>>>>> Christopher wrote:
>>>> >>>>>>>>>>> I can't imagine there's a trademark issue since it's really
>>>> >> just
>>>> >>>>>>>> acting
>>>> >>>>>>>>>> as
>>>> >>>>>>>>>>> a mirror. If there were trademark issues, I imagine sites
>>>> like
>>>> >>>>>>>>>>> http://archive.org would be in big trouble. But, it
>>>> certainly
>>>> >>>>>>>> couldn't
>>>> >>>>>>>>>> hurt
>>>> >>>>>>>>>>> to find out.
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> Another option to sabotage the GH-rendered site is to add
>>>> some
>>>> >>>>>>>> javascript
>>>> >>>>>>>>>>> which detects the location and displays an informative link
>>>> >> back
>>>> >>>> to
>>>> >>>>>>>> the
>>>> >>>>>>>>>>> canonical location for the site. That should be simple
>>>> enough
>>>> >> to
>>>> >>>> do.
>>>> >>>>>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
>>>> >> josh.elser@gmail.com>
>>>> >>>>>>>>    wrote:
>>>> >>>>>>>>>>>> It's also probably worth mentioning that this concern only
>>>> >>> comes
>>>> >>>>>>>> about
>>>> >>>>>>>>>>>> for point #4 (or if we use the branch name gh-pages in
>>>> point
>>>> >>> #1).
>>>> >>>>>>>>>>>> Josh Elser wrote:
>>>> >>>>>>>>>>>>> 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
>>>> >>>>>>>>>> accumulo.apache.org
>>>> >>>>>>>>>>>>> or similar).
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> 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.
>>>> >
>>>>
>>>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

There seemed to be a slight hiccup with the switchover... it didn't work on
the previous push, but it worked just fine now. I've added some small
javascript/html to our template so it shows a link to our canonical site in
a banner when you're seeing our site hosted in a mirror. The banner is
hidden on our canonical site.

On Mon, Mar 14, 2016 at 5:33 PM Christopher <ct...@apache.org> wrote:

> With the completion of INFRA-11437
> <https://issues.apache.org/jira/browse/INFRA-11437>, our site should now
> be building out of git. They wanted the branch to be called "asf-site", so
> I renamed the one called "accumulo.apache.org". Shortly, I will be
> updating the docs on our site which provide instructions for updating.
>
> On Sun, Mar 13, 2016 at 12:25 AM Christopher <ct...@apache.org> wrote:
>
>> Well, if I wasn't a git aficionado before, I'm well on my way. Using some
>> low-level git commands (making full use of StackOverflow[1]), I actually
>> put together a git post-commit hook to automatically regenerate and update
>> the accumulo.apache.org branch (assuming you have one checked out
>> locally) whenever you edit the gh-pages branch.
>>
>> Feel free to check it out here[2]. I've gone ahead and checked it into
>> the gh-pages repo in a "hidden" (from Jekyll) developer area.
>>
>> Basically, if you have a local branch (hopefully one that is up-to-date
>> and tracking upstream accumulo git) called "accumulo.apache.org", and
>> you're current working branch is "gh-pages", all you need to do is copy (or
>> symlink) the file to .git/hooks/post-commit
>>
>> This is just one useful way to automate this. A pre-push hook might work
>> just as well, which commits directly to the remote or something which
>> doesn't require a local up-to-date tracking branch to be useful. Still, I'm
>> pretty proud of it.
>>
>> Enjoy!
>>
>> [1]: http://stackoverflow.com/a/35963533/196405
>> [2]:
>> https://github.com/apache/accumulo/blob/gh-pages/_devtools/git-hooks/post-commit
>>
>>
>> On Fri, Mar 11, 2016 at 1:12 PM Josh Elser <jo...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Dylan Hutchison wrote:
>>> > Sounds great Chris!
>>> >
>>> > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ct...@apache.org>
>>> wrote:
>>> >
>>> >> So, if everybody's happy doing this, I'll go ahead and perform the
>>> >> following steps:
>>> >>
>>> >> 1. Push gh-pages branch to our repo
>>> >> 2. Perform a jekyll build on the branch and put it in a branch called
>>> "
>>> >> accumulo.apache.org"
>>> >> 3. Push the accumulo.apache.org branch
>>> >> 4. File INFRA ticket to switch our site to git using the
>>> >> accumulo.apache.org
>>> >> branch
>>> >>
>>> >>
>>> >> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi<
>>> billie.rinaldi@gmail.com>
>>> >> wrote:
>>> >>
>>> >>> Wow, that's looking great.  Thanks, Christopher!
>>> >>>
>>> >>> Billie
>>> >>>
>>> >>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<ct...@apache.org>
>>> >> wrote:
>>> >>>> Thanks Josh! I fixed all the issues you saw, except the screenshots
>>> >> one,
>>> >>>> since that's currently just how our layout is (looks the same at
>>> >>>> accumulo.apache.org).
>>> >>>>
>>> >>>> Most of the bugs you saw were existing bugs with either our HTML or
>>> our
>>> >>>> Markdown... but whatever CMS is doing is a bit more tolerant than
>>> >>> Kramdown
>>> >>>> is apparently.
>>> >>>>
>>> >>>> Biggest problem I saw was that people keep forgetting quotes around
>>> >> HTML
>>> >>>> attributes. Example, it should be<a href="location">, not<a
>>> >>>> href=location>.
>>> >>>>
>>> >>>> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser<jo...@gmail.com>
>>> >> wrote:
>>> >>>>> * Some companies on http://ctubbsii.github.io/accumulo/people.html
>>> >> are
>>> >>>>> goofed as are the timezones.
>>> >>>>> * Some broken links on
>>> >> http://ctubbsii.github.io/accumulo/source.html.
>>> >>>>> Coding practices are also messed up.
>>> >>>>> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
>>> >>>>> entries are a little wacky.
>>> >>>>> * http://ctubbsii.github.io/accumulo/screenshots.html is weird
>>> with
>>> >>> the
>>> >>>>> monitor screenshot (should be beneath the text?)
>>> >>>>> * Just noticed that Other and Documentation both have a link to the
>>> >>>>> papers/presentations. That might actually be how the site is now,
>>> >> just
>>> >>>>> realized it's duplicative.
>>> >>>>>
>>> >>>>> Thanks again for doing this. It's great!
>>> >>>>>
>>> >>>>> Christopher wrote:
>>> >>>>>> Actually, I now have it all working (as far as I can tell) with
>>> >>>>> everything
>>> >>>>>> pretty much the same as it looks with CMS today. After people have
>>> >>>> taken
>>> >>>>>> the time to give it a glance, I'll push it to the ASF repo, and
>>> >> then
>>> >>>> push
>>> >>>>>> the generated site to a separate branch. Then we can put in the
>>> >> INFRA
>>> >>>>>> ticket to switch from svn to git.
>>> >>>>>>
>>> >>>>>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
>>> >>>> wrote:
>>> >>>>>>> I'm working on converting our current site contents over to
>>> jekyll
>>> >>> at
>>> >>>>>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
>>> >>>>>>> (view at http://ctubbsii.github.io/accumulo)
>>> >>>>>>>
>>> >>>>>>> Yes, it's terrible right now... it's in progress. :)
>>> >>>>>>>
>>> >>>>>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
>>> >>>> wrote:
>>> >>>>>>>> Lazy consensus is fine. If there are no objections, I don't want
>>> >> to
>>> >>>>> hold
>>> >>>>>>>> things up. I feel like I've adequately expressed my concerns.
>>> >>> Silence
>>> >>>>>>>> can and should be treated as acknowledgement for this, IMO.
>>> >>>>>>>>
>>> >>>>>>>> Christopher wrote:
>>> >>>>>>>>> Another reason we probably shouldn't worry about this: anybody
>>> >> can
>>> >>>>>>>> create a
>>> >>>>>>>>> DNS name at their leisure which transparently redirects to
>>> >>>>>>>>> accumulo.apache.org and serves its contents. This is perfectly
>>> >>>>>>>> legitimate
>>> >>>>>>>>> for a number of reasons, including corporate proxies/mirrors,
>>> >>>>>>>>> URL-shortening services, caching services, archiving services,
>>> >>>>>>>>> vision-impaired accessibility services, foreign-language DNS
>>> >>>> mappings,
>>> >>>>>>>> and
>>> >>>>>>>>> so-on.
>>> >>>>>>>>>
>>> >>>>>>>>> I think when it comes to trademarks and our website, our area
>>> of
>>> >>>>> concern
>>> >>>>>>>>> should mostly focus on when people misrepresent our trademark
>>> in
>>> >>> the
>>> >>>>>>>> course
>>> >>>>>>>>> of their mirroring/archiving. There's no risk of that for a
>>> >> mirror
>>> >>>>> that
>>> >>>>>>>> is
>>> >>>>>>>>> explicitly under our control, but I'm really leaning towards
>>> the
>>> >>>>>>>> javascript
>>> >>>>>>>>> to detect and display a message about the canonical location
>>> >> just
>>> >>> to
>>> >>>>>>>>> mitigate any possibility for concern.
>>> >>>>>>>>>
>>> >>>>>>>>> If you still have concerns, I'd be happy to put it up for a
>>> >> formal
>>> >>>>> vote
>>> >>>>>>>>> from the PMC, or to get feedback from ASF trademarks folks
>>> >> before
>>> >>> we
>>> >>>>>>>>> proceed.
>>> >>>>>>>>>
>>> >>>>>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<josh.elser@gmail.com
>>> >
>>> >>>>>   wrote:
>>> >>>>>>>>>> Well, I think the difference is that archive.org (and others
>>> >> --
>>> >>>>> google
>>> >>>>>>>>>> cached pages come to mind) are devoted/known for that specific
>>> >>>>> purpose.
>>> >>>>>>>>>> The fact that Github ends up being a "de-facto" location for
>>> >>>> software
>>> >>>>>>>>>> projects, I'm just nervous about the expecting good faith from
>>> >>> the
>>> >>>>>>>>>> denizens of the internet. Maybe I'm just worrying too much. If
>>> >>>>> there's
>>> >>>>>>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's
>>> fine
>>> >>> by
>>> >>>>> me.
>>> >>>>>>>>>> Christopher wrote:
>>> >>>>>>>>>>> I can't imagine there's a trademark issue since it's really
>>> >> just
>>> >>>>>>>> acting
>>> >>>>>>>>>> as
>>> >>>>>>>>>>> a mirror. If there were trademark issues, I imagine sites
>>> like
>>> >>>>>>>>>>> http://archive.org would be in big trouble. But, it
>>> certainly
>>> >>>>>>>> couldn't
>>> >>>>>>>>>> hurt
>>> >>>>>>>>>>> to find out.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Another option to sabotage the GH-rendered site is to add
>>> some
>>> >>>>>>>> javascript
>>> >>>>>>>>>>> which detects the location and displays an informative link
>>> >> back
>>> >>>> to
>>> >>>>>>>> the
>>> >>>>>>>>>>> canonical location for the site. That should be simple enough
>>> >> to
>>> >>>> do.
>>> >>>>>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
>>> >> josh.elser@gmail.com>
>>> >>>>>>>>    wrote:
>>> >>>>>>>>>>>> It's also probably worth mentioning that this concern only
>>> >>> comes
>>> >>>>>>>> about
>>> >>>>>>>>>>>> for point #4 (or if we use the branch name gh-pages in point
>>> >>> #1).
>>> >>>>>>>>>>>> Josh Elser wrote:
>>> >>>>>>>>>>>>> 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
>>> >>>>>>>>>> accumulo.apache.org
>>> >>>>>>>>>>>>> or similar).
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> 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.
>>> >
>>>
>>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

With the completion of INFRA-11437
<https://issues.apache.org/jira/browse/INFRA-11437>, our site should now be
building out of git. They wanted the branch to be called "asf-site", so I
renamed the one called "accumulo.apache.org". Shortly, I will be updating
the docs on our site which provide instructions for updating.

On Sun, Mar 13, 2016 at 12:25 AM Christopher <ct...@apache.org> wrote:

> Well, if I wasn't a git aficionado before, I'm well on my way. Using some
> low-level git commands (making full use of StackOverflow[1]), I actually
> put together a git post-commit hook to automatically regenerate and update
> the accumulo.apache.org branch (assuming you have one checked out
> locally) whenever you edit the gh-pages branch.
>
> Feel free to check it out here[2]. I've gone ahead and checked it into the
> gh-pages repo in a "hidden" (from Jekyll) developer area.
>
> Basically, if you have a local branch (hopefully one that is up-to-date
> and tracking upstream accumulo git) called "accumulo.apache.org", and
> you're current working branch is "gh-pages", all you need to do is copy (or
> symlink) the file to .git/hooks/post-commit
>
> This is just one useful way to automate this. A pre-push hook might work
> just as well, which commits directly to the remote or something which
> doesn't require a local up-to-date tracking branch to be useful. Still, I'm
> pretty proud of it.
>
> Enjoy!
>
> [1]: http://stackoverflow.com/a/35963533/196405
> [2]:
> https://github.com/apache/accumulo/blob/gh-pages/_devtools/git-hooks/post-commit
>
>
> On Fri, Mar 11, 2016 at 1:12 PM Josh Elser <jo...@gmail.com> wrote:
>
>> +1
>>
>> Dylan Hutchison wrote:
>> > Sounds great Chris!
>> >
>> > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ct...@apache.org>
>> wrote:
>> >
>> >> So, if everybody's happy doing this, I'll go ahead and perform the
>> >> following steps:
>> >>
>> >> 1. Push gh-pages branch to our repo
>> >> 2. Perform a jekyll build on the branch and put it in a branch called "
>> >> accumulo.apache.org"
>> >> 3. Push the accumulo.apache.org branch
>> >> 4. File INFRA ticket to switch our site to git using the
>> >> accumulo.apache.org
>> >> branch
>> >>
>> >>
>> >> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi<
>> billie.rinaldi@gmail.com>
>> >> wrote:
>> >>
>> >>> Wow, that's looking great.  Thanks, Christopher!
>> >>>
>> >>> Billie
>> >>>
>> >>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<ct...@apache.org>
>> >> wrote:
>> >>>> Thanks Josh! I fixed all the issues you saw, except the screenshots
>> >> one,
>> >>>> since that's currently just how our layout is (looks the same at
>> >>>> accumulo.apache.org).
>> >>>>
>> >>>> Most of the bugs you saw were existing bugs with either our HTML or
>> our
>> >>>> Markdown... but whatever CMS is doing is a bit more tolerant than
>> >>> Kramdown
>> >>>> is apparently.
>> >>>>
>> >>>> Biggest problem I saw was that people keep forgetting quotes around
>> >> HTML
>> >>>> attributes. Example, it should be<a href="location">, not<a
>> >>>> href=location>.
>> >>>>
>> >>>> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser<jo...@gmail.com>
>> >> wrote:
>> >>>>> * Some companies on http://ctubbsii.github.io/accumulo/people.html
>> >> are
>> >>>>> goofed as are the timezones.
>> >>>>> * Some broken links on
>> >> http://ctubbsii.github.io/accumulo/source.html.
>> >>>>> Coding practices are also messed up.
>> >>>>> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
>> >>>>> entries are a little wacky.
>> >>>>> * http://ctubbsii.github.io/accumulo/screenshots.html is weird with
>> >>> the
>> >>>>> monitor screenshot (should be beneath the text?)
>> >>>>> * Just noticed that Other and Documentation both have a link to the
>> >>>>> papers/presentations. That might actually be how the site is now,
>> >> just
>> >>>>> realized it's duplicative.
>> >>>>>
>> >>>>> Thanks again for doing this. It's great!
>> >>>>>
>> >>>>> Christopher wrote:
>> >>>>>> Actually, I now have it all working (as far as I can tell) with
>> >>>>> everything
>> >>>>>> pretty much the same as it looks with CMS today. After people have
>> >>>> taken
>> >>>>>> the time to give it a glance, I'll push it to the ASF repo, and
>> >> then
>> >>>> push
>> >>>>>> the generated site to a separate branch. Then we can put in the
>> >> INFRA
>> >>>>>> ticket to switch from svn to git.
>> >>>>>>
>> >>>>>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
>> >>>> wrote:
>> >>>>>>> I'm working on converting our current site contents over to jekyll
>> >>> at
>> >>>>>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
>> >>>>>>> (view at http://ctubbsii.github.io/accumulo)
>> >>>>>>>
>> >>>>>>> Yes, it's terrible right now... it's in progress. :)
>> >>>>>>>
>> >>>>>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
>> >>>> wrote:
>> >>>>>>>> Lazy consensus is fine. If there are no objections, I don't want
>> >> to
>> >>>>> hold
>> >>>>>>>> things up. I feel like I've adequately expressed my concerns.
>> >>> Silence
>> >>>>>>>> can and should be treated as acknowledgement for this, IMO.
>> >>>>>>>>
>> >>>>>>>> Christopher wrote:
>> >>>>>>>>> Another reason we probably shouldn't worry about this: anybody
>> >> can
>> >>>>>>>> create a
>> >>>>>>>>> DNS name at their leisure which transparently redirects to
>> >>>>>>>>> accumulo.apache.org and serves its contents. This is perfectly
>> >>>>>>>> legitimate
>> >>>>>>>>> for a number of reasons, including corporate proxies/mirrors,
>> >>>>>>>>> URL-shortening services, caching services, archiving services,
>> >>>>>>>>> vision-impaired accessibility services, foreign-language DNS
>> >>>> mappings,
>> >>>>>>>> and
>> >>>>>>>>> so-on.
>> >>>>>>>>>
>> >>>>>>>>> I think when it comes to trademarks and our website, our area of
>> >>>>> concern
>> >>>>>>>>> should mostly focus on when people misrepresent our trademark in
>> >>> the
>> >>>>>>>> course
>> >>>>>>>>> of their mirroring/archiving. There's no risk of that for a
>> >> mirror
>> >>>>> that
>> >>>>>>>> is
>> >>>>>>>>> explicitly under our control, but I'm really leaning towards the
>> >>>>>>>> javascript
>> >>>>>>>>> to detect and display a message about the canonical location
>> >> just
>> >>> to
>> >>>>>>>>> mitigate any possibility for concern.
>> >>>>>>>>>
>> >>>>>>>>> If you still have concerns, I'd be happy to put it up for a
>> >> formal
>> >>>>> vote
>> >>>>>>>>> from the PMC, or to get feedback from ASF trademarks folks
>> >> before
>> >>> we
>> >>>>>>>>> proceed.
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
>> >>>>>   wrote:
>> >>>>>>>>>> Well, I think the difference is that archive.org (and others
>> >> --
>> >>>>> google
>> >>>>>>>>>> cached pages come to mind) are devoted/known for that specific
>> >>>>> purpose.
>> >>>>>>>>>> The fact that Github ends up being a "de-facto" location for
>> >>>> software
>> >>>>>>>>>> projects, I'm just nervous about the expecting good faith from
>> >>> the
>> >>>>>>>>>> denizens of the internet. Maybe I'm just worrying too much. If
>> >>>>> there's
>> >>>>>>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine
>> >>> by
>> >>>>> me.
>> >>>>>>>>>> Christopher wrote:
>> >>>>>>>>>>> I can't imagine there's a trademark issue since it's really
>> >> just
>> >>>>>>>> acting
>> >>>>>>>>>> as
>> >>>>>>>>>>> a mirror. If there were trademark issues, I imagine sites like
>> >>>>>>>>>>> http://archive.org would be in big trouble. But, it certainly
>> >>>>>>>> couldn't
>> >>>>>>>>>> hurt
>> >>>>>>>>>>> to find out.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Another option to sabotage the GH-rendered site is to add some
>> >>>>>>>> javascript
>> >>>>>>>>>>> which detects the location and displays an informative link
>> >> back
>> >>>> to
>> >>>>>>>> the
>> >>>>>>>>>>> canonical location for the site. That should be simple enough
>> >> to
>> >>>> do.
>> >>>>>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
>> >> josh.elser@gmail.com>
>> >>>>>>>>    wrote:
>> >>>>>>>>>>>> It's also probably worth mentioning that this concern only
>> >>> comes
>> >>>>>>>> about
>> >>>>>>>>>>>> for point #4 (or if we use the branch name gh-pages in point
>> >>> #1).
>> >>>>>>>>>>>> Josh Elser wrote:
>> >>>>>>>>>>>>> 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
>> >>>>>>>>>> accumulo.apache.org
>> >>>>>>>>>>>>> or similar).
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> 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.
>> >
>>
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

Well, if I wasn't a git aficionado before, I'm well on my way. Using some
low-level git commands (making full use of StackOverflow[1]), I actually
put together a git post-commit hook to automatically regenerate and update
the accumulo.apache.org branch (assuming you have one checked out locally)
whenever you edit the gh-pages branch.

Feel free to check it out here[2]. I've gone ahead and checked it into the
gh-pages repo in a "hidden" (from Jekyll) developer area.

Basically, if you have a local branch (hopefully one that is up-to-date and
tracking upstream accumulo git) called "accumulo.apache.org", and you're
current working branch is "gh-pages", all you need to do is copy (or
symlink) the file to .git/hooks/post-commit

This is just one useful way to automate this. A pre-push hook might work
just as well, which commits directly to the remote or something which
doesn't require a local up-to-date tracking branch to be useful. Still, I'm
pretty proud of it.

Enjoy!

[1]: http://stackoverflow.com/a/35963533/196405
[2]:
https://github.com/apache/accumulo/blob/gh-pages/_devtools/git-hooks/post-commit


On Fri, Mar 11, 2016 at 1:12 PM Josh Elser <jo...@gmail.com> wrote:

> +1
>
> Dylan Hutchison wrote:
> > Sounds great Chris!
> >
> > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ct...@apache.org>
> wrote:
> >
> >> So, if everybody's happy doing this, I'll go ahead and perform the
> >> following steps:
> >>
> >> 1. Push gh-pages branch to our repo
> >> 2. Perform a jekyll build on the branch and put it in a branch called "
> >> accumulo.apache.org"
> >> 3. Push the accumulo.apache.org branch
> >> 4. File INFRA ticket to switch our site to git using the
> >> accumulo.apache.org
> >> branch
> >>
> >>
> >> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi<
> billie.rinaldi@gmail.com>
> >> wrote:
> >>
> >>> Wow, that's looking great.  Thanks, Christopher!
> >>>
> >>> Billie
> >>>
> >>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<ct...@apache.org>
> >> wrote:
> >>>> Thanks Josh! I fixed all the issues you saw, except the screenshots
> >> one,
> >>>> since that's currently just how our layout is (looks the same at
> >>>> accumulo.apache.org).
> >>>>
> >>>> Most of the bugs you saw were existing bugs with either our HTML or
> our
> >>>> Markdown... but whatever CMS is doing is a bit more tolerant than
> >>> Kramdown
> >>>> is apparently.
> >>>>
> >>>> Biggest problem I saw was that people keep forgetting quotes around
> >> HTML
> >>>> attributes. Example, it should be<a href="location">, not<a
> >>>> href=location>.
> >>>>
> >>>> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser<jo...@gmail.com>
> >> wrote:
> >>>>> * Some companies on http://ctubbsii.github.io/accumulo/people.html
> >> are
> >>>>> goofed as are the timezones.
> >>>>> * Some broken links on
> >> http://ctubbsii.github.io/accumulo/source.html.
> >>>>> Coding practices are also messed up.
> >>>>> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> >>>>> entries are a little wacky.
> >>>>> * http://ctubbsii.github.io/accumulo/screenshots.html is weird with
> >>> the
> >>>>> monitor screenshot (should be beneath the text?)
> >>>>> * Just noticed that Other and Documentation both have a link to the
> >>>>> papers/presentations. That might actually be how the site is now,
> >> just
> >>>>> realized it's duplicative.
> >>>>>
> >>>>> Thanks again for doing this. It's great!
> >>>>>
> >>>>> Christopher wrote:
> >>>>>> Actually, I now have it all working (as far as I can tell) with
> >>>>> everything
> >>>>>> pretty much the same as it looks with CMS today. After people have
> >>>> taken
> >>>>>> the time to give it a glance, I'll push it to the ASF repo, and
> >> then
> >>>> push
> >>>>>> the generated site to a separate branch. Then we can put in the
> >> INFRA
> >>>>>> ticket to switch from svn to git.
> >>>>>>
> >>>>>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
> >>>> wrote:
> >>>>>>> I'm working on converting our current site contents over to jekyll
> >>> at
> >>>>>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
> >>>>>>> (view at http://ctubbsii.github.io/accumulo)
> >>>>>>>
> >>>>>>> Yes, it's terrible right now... it's in progress. :)
> >>>>>>>
> >>>>>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
> >>>> wrote:
> >>>>>>>> Lazy consensus is fine. If there are no objections, I don't want
> >> to
> >>>>> hold
> >>>>>>>> things up. I feel like I've adequately expressed my concerns.
> >>> Silence
> >>>>>>>> can and should be treated as acknowledgement for this, IMO.
> >>>>>>>>
> >>>>>>>> Christopher wrote:
> >>>>>>>>> Another reason we probably shouldn't worry about this: anybody
> >> can
> >>>>>>>> create a
> >>>>>>>>> DNS name at their leisure which transparently redirects to
> >>>>>>>>> accumulo.apache.org and serves its contents. This is perfectly
> >>>>>>>> legitimate
> >>>>>>>>> for a number of reasons, including corporate proxies/mirrors,
> >>>>>>>>> URL-shortening services, caching services, archiving services,
> >>>>>>>>> vision-impaired accessibility services, foreign-language DNS
> >>>> mappings,
> >>>>>>>> and
> >>>>>>>>> so-on.
> >>>>>>>>>
> >>>>>>>>> I think when it comes to trademarks and our website, our area of
> >>>>> concern
> >>>>>>>>> should mostly focus on when people misrepresent our trademark in
> >>> the
> >>>>>>>> course
> >>>>>>>>> of their mirroring/archiving. There's no risk of that for a
> >> mirror
> >>>>> that
> >>>>>>>> is
> >>>>>>>>> explicitly under our control, but I'm really leaning towards the
> >>>>>>>> javascript
> >>>>>>>>> to detect and display a message about the canonical location
> >> just
> >>> to
> >>>>>>>>> mitigate any possibility for concern.
> >>>>>>>>>
> >>>>>>>>> If you still have concerns, I'd be happy to put it up for a
> >> formal
> >>>>> vote
> >>>>>>>>> from the PMC, or to get feedback from ASF trademarks folks
> >> before
> >>> we
> >>>>>>>>> proceed.
> >>>>>>>>>
> >>>>>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
> >>>>>   wrote:
> >>>>>>>>>> Well, I think the difference is that archive.org (and others
> >> --
> >>>>> google
> >>>>>>>>>> cached pages come to mind) are devoted/known for that specific
> >>>>> purpose.
> >>>>>>>>>> The fact that Github ends up being a "de-facto" location for
> >>>> software
> >>>>>>>>>> projects, I'm just nervous about the expecting good faith from
> >>> the
> >>>>>>>>>> denizens of the internet. Maybe I'm just worrying too much. If
> >>>>> there's
> >>>>>>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine
> >>> by
> >>>>> me.
> >>>>>>>>>> Christopher wrote:
> >>>>>>>>>>> I can't imagine there's a trademark issue since it's really
> >> just
> >>>>>>>> acting
> >>>>>>>>>> as
> >>>>>>>>>>> a mirror. If there were trademark issues, I imagine sites like
> >>>>>>>>>>> http://archive.org would be in big trouble. But, it certainly
> >>>>>>>> couldn't
> >>>>>>>>>> hurt
> >>>>>>>>>>> to find out.
> >>>>>>>>>>>
> >>>>>>>>>>> Another option to sabotage the GH-rendered site is to add some
> >>>>>>>> javascript
> >>>>>>>>>>> which detects the location and displays an informative link
> >> back
> >>>> to
> >>>>>>>> the
> >>>>>>>>>>> canonical location for the site. That should be simple enough
> >> to
> >>>> do.
> >>>>>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
> >> josh.elser@gmail.com>
> >>>>>>>>    wrote:
> >>>>>>>>>>>> It's also probably worth mentioning that this concern only
> >>> comes
> >>>>>>>> about
> >>>>>>>>>>>> for point #4 (or if we use the branch name gh-pages in point
> >>> #1).
> >>>>>>>>>>>> Josh Elser wrote:
> >>>>>>>>>>>>> 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
> >>>>>>>>>> accumulo.apache.org
> >>>>>>>>>>>>> or similar).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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.
> >
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

+1

Dylan Hutchison wrote:
> Sounds great Chris!
>
> On Fri, Mar 11, 2016 at 9:50 AM, Christopher<ct...@apache.org>  wrote:
>
>> So, if everybody's happy doing this, I'll go ahead and perform the
>> following steps:
>>
>> 1. Push gh-pages branch to our repo
>> 2. Perform a jekyll build on the branch and put it in a branch called "
>> accumulo.apache.org"
>> 3. Push the accumulo.apache.org branch
>> 4. File INFRA ticket to switch our site to git using the
>> accumulo.apache.org
>> branch
>>
>>
>> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi<bi...@gmail.com>
>> wrote:
>>
>>> Wow, that's looking great.  Thanks, Christopher!
>>>
>>> Billie
>>>
>>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<ct...@apache.org>
>> wrote:
>>>> Thanks Josh! I fixed all the issues you saw, except the screenshots
>> one,
>>>> since that's currently just how our layout is (looks the same at
>>>> accumulo.apache.org).
>>>>
>>>> Most of the bugs you saw were existing bugs with either our HTML or our
>>>> Markdown... but whatever CMS is doing is a bit more tolerant than
>>> Kramdown
>>>> is apparently.
>>>>
>>>> Biggest problem I saw was that people keep forgetting quotes around
>> HTML
>>>> attributes. Example, it should be<a href="location">, not<a
>>>> href=location>.
>>>>
>>>> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser<jo...@gmail.com>
>> wrote:
>>>>> * Some companies on http://ctubbsii.github.io/accumulo/people.html
>> are
>>>>> goofed as are the timezones.
>>>>> * Some broken links on
>> http://ctubbsii.github.io/accumulo/source.html.
>>>>> Coding practices are also messed up.
>>>>> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
>>>>> entries are a little wacky.
>>>>> * http://ctubbsii.github.io/accumulo/screenshots.html is weird with
>>> the
>>>>> monitor screenshot (should be beneath the text?)
>>>>> * Just noticed that Other and Documentation both have a link to the
>>>>> papers/presentations. That might actually be how the site is now,
>> just
>>>>> realized it's duplicative.
>>>>>
>>>>> Thanks again for doing this. It's great!
>>>>>
>>>>> Christopher wrote:
>>>>>> Actually, I now have it all working (as far as I can tell) with
>>>>> everything
>>>>>> pretty much the same as it looks with CMS today. After people have
>>>> taken
>>>>>> the time to give it a glance, I'll push it to the ASF repo, and
>> then
>>>> push
>>>>>> the generated site to a separate branch. Then we can put in the
>> INFRA
>>>>>> ticket to switch from svn to git.
>>>>>>
>>>>>> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
>>>> wrote:
>>>>>>> I'm working on converting our current site contents over to jekyll
>>> at
>>>>>>> https://github.com/ctubbsii/accumulo/tree/gh-pages
>>>>>>> (view at http://ctubbsii.github.io/accumulo)
>>>>>>>
>>>>>>> Yes, it's terrible right now... it's in progress. :)
>>>>>>>
>>>>>>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
>>>> wrote:
>>>>>>>> Lazy consensus is fine. If there are no objections, I don't want
>> to
>>>>> hold
>>>>>>>> things up. I feel like I've adequately expressed my concerns.
>>> Silence
>>>>>>>> can and should be treated as acknowledgement for this, IMO.
>>>>>>>>
>>>>>>>> Christopher wrote:
>>>>>>>>> Another reason we probably shouldn't worry about this: anybody
>> can
>>>>>>>> create a
>>>>>>>>> DNS name at their leisure which transparently redirects to
>>>>>>>>> accumulo.apache.org and serves its contents. This is perfectly
>>>>>>>> legitimate
>>>>>>>>> for a number of reasons, including corporate proxies/mirrors,
>>>>>>>>> URL-shortening services, caching services, archiving services,
>>>>>>>>> vision-impaired accessibility services, foreign-language DNS
>>>> mappings,
>>>>>>>> and
>>>>>>>>> so-on.
>>>>>>>>>
>>>>>>>>> I think when it comes to trademarks and our website, our area of
>>>>> concern
>>>>>>>>> should mostly focus on when people misrepresent our trademark in
>>> the
>>>>>>>> course
>>>>>>>>> of their mirroring/archiving. There's no risk of that for a
>> mirror
>>>>> that
>>>>>>>> is
>>>>>>>>> explicitly under our control, but I'm really leaning towards the
>>>>>>>> javascript
>>>>>>>>> to detect and display a message about the canonical location
>> just
>>> to
>>>>>>>>> mitigate any possibility for concern.
>>>>>>>>>
>>>>>>>>> If you still have concerns, I'd be happy to put it up for a
>> formal
>>>>> vote
>>>>>>>>> from the PMC, or to get feedback from ASF trademarks folks
>> before
>>> we
>>>>>>>>> proceed.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
>>>>>   wrote:
>>>>>>>>>> Well, I think the difference is that archive.org (and others
>> --
>>>>> google
>>>>>>>>>> cached pages come to mind) are devoted/known for that specific
>>>>> purpose.
>>>>>>>>>> The fact that Github ends up being a "de-facto" location for
>>>> software
>>>>>>>>>> projects, I'm just nervous about the expecting good faith from
>>> the
>>>>>>>>>> denizens of the internet. Maybe I'm just worrying too much. If
>>>>> there's
>>>>>>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine
>>> by
>>>>> me.
>>>>>>>>>> Christopher wrote:
>>>>>>>>>>> I can't imagine there's a trademark issue since it's really
>> just
>>>>>>>> acting
>>>>>>>>>> as
>>>>>>>>>>> a mirror. If there were trademark issues, I imagine sites like
>>>>>>>>>>> http://archive.org would be in big trouble. But, it certainly
>>>>>>>> couldn't
>>>>>>>>>> hurt
>>>>>>>>>>> to find out.
>>>>>>>>>>>
>>>>>>>>>>> Another option to sabotage the GH-rendered site is to add some
>>>>>>>> javascript
>>>>>>>>>>> which detects the location and displays an informative link
>> back
>>>> to
>>>>>>>> the
>>>>>>>>>>> canonical location for the site. That should be simple enough
>> to
>>>> do.
>>>>>>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
>> josh.elser@gmail.com>
>>>>>>>>    wrote:
>>>>>>>>>>>> It's also probably worth mentioning that this concern only
>>> comes
>>>>>>>> about
>>>>>>>>>>>> for point #4 (or if we use the branch name gh-pages in point
>>> #1).
>>>>>>>>>>>> Josh Elser wrote:
>>>>>>>>>>>>> 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
>>>>>>>>>> accumulo.apache.org
>>>>>>>>>>>>> or similar).
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.
>

Re: git-based site and jekyll

[Dylan Hutchison <dh...@cs.washington.edu>]

Sounds great Chris!

On Fri, Mar 11, 2016 at 9:50 AM, Christopher <ct...@apache.org> wrote:

> So, if everybody's happy doing this, I'll go ahead and perform the
> following steps:
>
> 1. Push gh-pages branch to our repo
> 2. Perform a jekyll build on the branch and put it in a branch called "
> accumulo.apache.org"
> 3. Push the accumulo.apache.org branch
> 4. File INFRA ticket to switch our site to git using the
> accumulo.apache.org
> branch
>
>
> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi <bi...@gmail.com>
> wrote:
>
> > Wow, that's looking great.  Thanks, Christopher!
> >
> > Billie
> >
> > On Thu, Mar 10, 2016 at 10:38 PM, Christopher <ct...@apache.org>
> wrote:
> >
> > > Thanks Josh! I fixed all the issues you saw, except the screenshots
> one,
> > > since that's currently just how our layout is (looks the same at
> > > accumulo.apache.org).
> > >
> > > Most of the bugs you saw were existing bugs with either our HTML or our
> > > Markdown... but whatever CMS is doing is a bit more tolerant than
> > Kramdown
> > > is apparently.
> > >
> > > Biggest problem I saw was that people keep forgetting quotes around
> HTML
> > > attributes. Example, it should be <a href="location">, not <a
> > > href=location>.
> > >
> > > On Thu, Mar 10, 2016 at 9:57 PM Josh Elser <jo...@gmail.com>
> wrote:
> > >
> > > > * Some companies on http://ctubbsii.github.io/accumulo/people.html
> are
> > > > goofed as are the timezones.
> > > > * Some broken links on
> http://ctubbsii.github.io/accumulo/source.html.
> > > > Coding practices are also messed up.
> > > > * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> > > > entries are a little wacky.
> > > > * http://ctubbsii.github.io/accumulo/screenshots.html is weird with
> > the
> > > > monitor screenshot (should be beneath the text?)
> > > > * Just noticed that Other and Documentation both have a link to the
> > > > papers/presentations. That might actually be how the site is now,
> just
> > > > realized it's duplicative.
> > > >
> > > > Thanks again for doing this. It's great!
> > > >
> > > > Christopher wrote:
> > > > > Actually, I now have it all working (as far as I can tell) with
> > > > everything
> > > > > pretty much the same as it looks with CMS today. After people have
> > > taken
> > > > > the time to give it a glance, I'll push it to the ASF repo, and
> then
> > > push
> > > > > the generated site to a separate branch. Then we can put in the
> INFRA
> > > > > ticket to switch from svn to git.
> > > > >
> > > > > On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
> > > wrote:
> > > > >
> > > > >> I'm working on converting our current site contents over to jekyll
> > at
> > > > >> https://github.com/ctubbsii/accumulo/tree/gh-pages
> > > > >> (view at http://ctubbsii.github.io/accumulo)
> > > > >>
> > > > >> Yes, it's terrible right now... it's in progress. :)
> > > > >>
> > > > >> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
> > > wrote:
> > > > >>
> > > > >>> Lazy consensus is fine. If there are no objections, I don't want
> to
> > > > hold
> > > > >>> things up. I feel like I've adequately expressed my concerns.
> > Silence
> > > > >>> can and should be treated as acknowledgement for this, IMO.
> > > > >>>
> > > > >>> Christopher wrote:
> > > > >>>> Another reason we probably shouldn't worry about this: anybody
> can
> > > > >>> create a
> > > > >>>> DNS name at their leisure which transparently redirects to
> > > > >>>> accumulo.apache.org and serves its contents. This is perfectly
> > > > >>> legitimate
> > > > >>>> for a number of reasons, including corporate proxies/mirrors,
> > > > >>>> URL-shortening services, caching services, archiving services,
> > > > >>>> vision-impaired accessibility services, foreign-language DNS
> > > mappings,
> > > > >>> and
> > > > >>>> so-on.
> > > > >>>>
> > > > >>>> I think when it comes to trademarks and our website, our area of
> > > > concern
> > > > >>>> should mostly focus on when people misrepresent our trademark in
> > the
> > > > >>> course
> > > > >>>> of their mirroring/archiving. There's no risk of that for a
> mirror
> > > > that
> > > > >>> is
> > > > >>>> explicitly under our control, but I'm really leaning towards the
> > > > >>> javascript
> > > > >>>> to detect and display a message about the canonical location
> just
> > to
> > > > >>>> mitigate any possibility for concern.
> > > > >>>>
> > > > >>>> If you still have concerns, I'd be happy to put it up for a
> formal
> > > > vote
> > > > >>>> from the PMC, or to get feedback from ASF trademarks folks
> before
> > we
> > > > >>>> proceed.
> > > > >>>>
> > > > >>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
> > > >  wrote:
> > > > >>>>
> > > > >>>>> Well, I think the difference is that archive.org (and others
> --
> > > > google
> > > > >>>>> cached pages come to mind) are devoted/known for that specific
> > > > purpose.
> > > > >>>>> The fact that Github ends up being a "de-facto" location for
> > > software
> > > > >>>>> projects, I'm just nervous about the expecting good faith from
> > the
> > > > >>>>> denizens of the internet. Maybe I'm just worrying too much. If
> > > > there's
> > > > >>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine
> > by
> > > > me.
> > > > >>>>>
> > > > >>>>> Christopher wrote:
> > > > >>>>>> I can't imagine there's a trademark issue since it's really
> just
> > > > >>> acting
> > > > >>>>> as
> > > > >>>>>> a mirror. If there were trademark issues, I imagine sites like
> > > > >>>>>> http://archive.org would be in big trouble. But, it certainly
> > > > >>> couldn't
> > > > >>>>> hurt
> > > > >>>>>> to find out.
> > > > >>>>>>
> > > > >>>>>> Another option to sabotage the GH-rendered site is to add some
> > > > >>> javascript
> > > > >>>>>> which detects the location and displays an informative link
> back
> > > to
> > > > >>> the
> > > > >>>>>> canonical location for the site. That should be simple enough
> to
> > > do.
> > > > >>>>>>
> > > > >>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<
> josh.elser@gmail.com>
> > > > >>>   wrote:
> > > > >>>>>>> It's also probably worth mentioning that this concern only
> > comes
> > > > >>> about
> > > > >>>>>>> for point #4 (or if we use the branch name gh-pages in point
> > #1).
> > > > >>>>>>>
> > > > >>>>>>> Josh Elser wrote:
> > > > >>>>>>>> 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
> > > > >>>>> accumulo.apache.org
> > > > >>>>>>>> or similar).
> > > > >>>>>>>>
> > > > >>>>>>>> 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.
> > > > >
> > > >
> > >
> >
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

So, if everybody's happy doing this, I'll go ahead and perform the
following steps:

1. Push gh-pages branch to our repo
2. Perform a jekyll build on the branch and put it in a branch called "
accumulo.apache.org"
3. Push the accumulo.apache.org branch
4. File INFRA ticket to switch our site to git using the accumulo.apache.org
branch


On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi <bi...@gmail.com>
wrote:

> Wow, that's looking great.  Thanks, Christopher!
>
> Billie
>
> On Thu, Mar 10, 2016 at 10:38 PM, Christopher <ct...@apache.org> wrote:
>
> > Thanks Josh! I fixed all the issues you saw, except the screenshots one,
> > since that's currently just how our layout is (looks the same at
> > accumulo.apache.org).
> >
> > Most of the bugs you saw were existing bugs with either our HTML or our
> > Markdown... but whatever CMS is doing is a bit more tolerant than
> Kramdown
> > is apparently.
> >
> > Biggest problem I saw was that people keep forgetting quotes around HTML
> > attributes. Example, it should be <a href="location">, not <a
> > href=location>.
> >
> > On Thu, Mar 10, 2016 at 9:57 PM Josh Elser <jo...@gmail.com> wrote:
> >
> > > * Some companies on http://ctubbsii.github.io/accumulo/people.html are
> > > goofed as are the timezones.
> > > * Some broken links on http://ctubbsii.github.io/accumulo/source.html.
> > > Coding practices are also messed up.
> > > * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> > > entries are a little wacky.
> > > * http://ctubbsii.github.io/accumulo/screenshots.html is weird with
> the
> > > monitor screenshot (should be beneath the text?)
> > > * Just noticed that Other and Documentation both have a link to the
> > > papers/presentations. That might actually be how the site is now, just
> > > realized it's duplicative.
> > >
> > > Thanks again for doing this. It's great!
> > >
> > > Christopher wrote:
> > > > Actually, I now have it all working (as far as I can tell) with
> > > everything
> > > > pretty much the same as it looks with CMS today. After people have
> > taken
> > > > the time to give it a glance, I'll push it to the ASF repo, and then
> > push
> > > > the generated site to a separate branch. Then we can put in the INFRA
> > > > ticket to switch from svn to git.
> > > >
> > > > On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
> > wrote:
> > > >
> > > >> I'm working on converting our current site contents over to jekyll
> at
> > > >> https://github.com/ctubbsii/accumulo/tree/gh-pages
> > > >> (view at http://ctubbsii.github.io/accumulo)
> > > >>
> > > >> Yes, it's terrible right now... it's in progress. :)
> > > >>
> > > >> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
> > wrote:
> > > >>
> > > >>> Lazy consensus is fine. If there are no objections, I don't want to
> > > hold
> > > >>> things up. I feel like I've adequately expressed my concerns.
> Silence
> > > >>> can and should be treated as acknowledgement for this, IMO.
> > > >>>
> > > >>> Christopher wrote:
> > > >>>> Another reason we probably shouldn't worry about this: anybody can
> > > >>> create a
> > > >>>> DNS name at their leisure which transparently redirects to
> > > >>>> accumulo.apache.org and serves its contents. This is perfectly
> > > >>> legitimate
> > > >>>> for a number of reasons, including corporate proxies/mirrors,
> > > >>>> URL-shortening services, caching services, archiving services,
> > > >>>> vision-impaired accessibility services, foreign-language DNS
> > mappings,
> > > >>> and
> > > >>>> so-on.
> > > >>>>
> > > >>>> I think when it comes to trademarks and our website, our area of
> > > concern
> > > >>>> should mostly focus on when people misrepresent our trademark in
> the
> > > >>> course
> > > >>>> of their mirroring/archiving. There's no risk of that for a mirror
> > > that
> > > >>> is
> > > >>>> explicitly under our control, but I'm really leaning towards the
> > > >>> javascript
> > > >>>> to detect and display a message about the canonical location just
> to
> > > >>>> mitigate any possibility for concern.
> > > >>>>
> > > >>>> If you still have concerns, I'd be happy to put it up for a formal
> > > vote
> > > >>>> from the PMC, or to get feedback from ASF trademarks folks before
> we
> > > >>>> proceed.
> > > >>>>
> > > >>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
> > >  wrote:
> > > >>>>
> > > >>>>> Well, I think the difference is that archive.org (and others --
> > > google
> > > >>>>> cached pages come to mind) are devoted/known for that specific
> > > purpose.
> > > >>>>> The fact that Github ends up being a "de-facto" location for
> > software
> > > >>>>> projects, I'm just nervous about the expecting good faith from
> the
> > > >>>>> denizens of the internet. Maybe I'm just worrying too much. If
> > > there's
> > > >>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine
> by
> > > me.
> > > >>>>>
> > > >>>>> Christopher wrote:
> > > >>>>>> I can't imagine there's a trademark issue since it's really just
> > > >>> acting
> > > >>>>> as
> > > >>>>>> a mirror. If there were trademark issues, I imagine sites like
> > > >>>>>> http://archive.org would be in big trouble. But, it certainly
> > > >>> couldn't
> > > >>>>> hurt
> > > >>>>>> to find out.
> > > >>>>>>
> > > >>>>>> Another option to sabotage the GH-rendered site is to add some
> > > >>> javascript
> > > >>>>>> which detects the location and displays an informative link back
> > to
> > > >>> the
> > > >>>>>> canonical location for the site. That should be simple enough to
> > do.
> > > >>>>>>
> > > >>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
> > > >>>   wrote:
> > > >>>>>>> It's also probably worth mentioning that this concern only
> comes
> > > >>> about
> > > >>>>>>> for point #4 (or if we use the branch name gh-pages in point
> #1).
> > > >>>>>>>
> > > >>>>>>> Josh Elser wrote:
> > > >>>>>>>> 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
> > > >>>>> accumulo.apache.org
> > > >>>>>>>> or similar).
> > > >>>>>>>>
> > > >>>>>>>> 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.
> > > >
> > >
> >
>

Re: git-based site and jekyll

[Billie Rinaldi <bi...@gmail.com>]

Wow, that's looking great.  Thanks, Christopher!

Billie

On Thu, Mar 10, 2016 at 10:38 PM, Christopher <ct...@apache.org> wrote:

> Thanks Josh! I fixed all the issues you saw, except the screenshots one,
> since that's currently just how our layout is (looks the same at
> accumulo.apache.org).
>
> Most of the bugs you saw were existing bugs with either our HTML or our
> Markdown... but whatever CMS is doing is a bit more tolerant than Kramdown
> is apparently.
>
> Biggest problem I saw was that people keep forgetting quotes around HTML
> attributes. Example, it should be <a href="location">, not <a
> href=location>.
>
> On Thu, Mar 10, 2016 at 9:57 PM Josh Elser <jo...@gmail.com> wrote:
>
> > * Some companies on http://ctubbsii.github.io/accumulo/people.html are
> > goofed as are the timezones.
> > * Some broken links on http://ctubbsii.github.io/accumulo/source.html.
> > Coding practices are also messed up.
> > * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> > entries are a little wacky.
> > * http://ctubbsii.github.io/accumulo/screenshots.html is weird with the
> > monitor screenshot (should be beneath the text?)
> > * Just noticed that Other and Documentation both have a link to the
> > papers/presentations. That might actually be how the site is now, just
> > realized it's duplicative.
> >
> > Thanks again for doing this. It's great!
> >
> > Christopher wrote:
> > > Actually, I now have it all working (as far as I can tell) with
> > everything
> > > pretty much the same as it looks with CMS today. After people have
> taken
> > > the time to give it a glance, I'll push it to the ASF repo, and then
> push
> > > the generated site to a separate branch. Then we can put in the INFRA
> > > ticket to switch from svn to git.
> > >
> > > On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>
> wrote:
> > >
> > >> I'm working on converting our current site contents over to jekyll at
> > >> https://github.com/ctubbsii/accumulo/tree/gh-pages
> > >> (view at http://ctubbsii.github.io/accumulo)
> > >>
> > >> Yes, it's terrible right now... it's in progress. :)
> > >>
> > >> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>
> wrote:
> > >>
> > >>> Lazy consensus is fine. If there are no objections, I don't want to
> > hold
> > >>> things up. I feel like I've adequately expressed my concerns. Silence
> > >>> can and should be treated as acknowledgement for this, IMO.
> > >>>
> > >>> Christopher wrote:
> > >>>> Another reason we probably shouldn't worry about this: anybody can
> > >>> create a
> > >>>> DNS name at their leisure which transparently redirects to
> > >>>> accumulo.apache.org and serves its contents. This is perfectly
> > >>> legitimate
> > >>>> for a number of reasons, including corporate proxies/mirrors,
> > >>>> URL-shortening services, caching services, archiving services,
> > >>>> vision-impaired accessibility services, foreign-language DNS
> mappings,
> > >>> and
> > >>>> so-on.
> > >>>>
> > >>>> I think when it comes to trademarks and our website, our area of
> > concern
> > >>>> should mostly focus on when people misrepresent our trademark in the
> > >>> course
> > >>>> of their mirroring/archiving. There's no risk of that for a mirror
> > that
> > >>> is
> > >>>> explicitly under our control, but I'm really leaning towards the
> > >>> javascript
> > >>>> to detect and display a message about the canonical location just to
> > >>>> mitigate any possibility for concern.
> > >>>>
> > >>>> If you still have concerns, I'd be happy to put it up for a formal
> > vote
> > >>>> from the PMC, or to get feedback from ASF trademarks folks before we
> > >>>> proceed.
> > >>>>
> > >>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
> >  wrote:
> > >>>>
> > >>>>> Well, I think the difference is that archive.org (and others --
> > google
> > >>>>> cached pages come to mind) are devoted/known for that specific
> > purpose.
> > >>>>> The fact that Github ends up being a "de-facto" location for
> software
> > >>>>> projects, I'm just nervous about the expecting good faith from the
> > >>>>> denizens of the internet. Maybe I'm just worrying too much. If
> > there's
> > >>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine by
> > me.
> > >>>>>
> > >>>>> Christopher wrote:
> > >>>>>> I can't imagine there's a trademark issue since it's really just
> > >>> acting
> > >>>>> as
> > >>>>>> a mirror. If there were trademark issues, I imagine sites like
> > >>>>>> http://archive.org would be in big trouble. But, it certainly
> > >>> couldn't
> > >>>>> hurt
> > >>>>>> to find out.
> > >>>>>>
> > >>>>>> Another option to sabotage the GH-rendered site is to add some
> > >>> javascript
> > >>>>>> which detects the location and displays an informative link back
> to
> > >>> the
> > >>>>>> canonical location for the site. That should be simple enough to
> do.
> > >>>>>>
> > >>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
> > >>>   wrote:
> > >>>>>>> It's also probably worth mentioning that this concern only comes
> > >>> about
> > >>>>>>> for point #4 (or if we use the branch name gh-pages in point #1).
> > >>>>>>>
> > >>>>>>> Josh Elser wrote:
> > >>>>>>>> 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
> > >>>>> accumulo.apache.org
> > >>>>>>>> or similar).
> > >>>>>>>>
> > >>>>>>>> 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.
> > >
> >
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

Thanks Josh! I fixed all the issues you saw, except the screenshots one,
since that's currently just how our layout is (looks the same at
accumulo.apache.org).

Most of the bugs you saw were existing bugs with either our HTML or our
Markdown... but whatever CMS is doing is a bit more tolerant than Kramdown
is apparently.

Biggest problem I saw was that people keep forgetting quotes around HTML
attributes. Example, it should be <a href="location">, not <a
href=location>.

On Thu, Mar 10, 2016 at 9:57 PM Josh Elser <jo...@gmail.com> wrote:

> * Some companies on http://ctubbsii.github.io/accumulo/people.html are
> goofed as are the timezones.
> * Some broken links on http://ctubbsii.github.io/accumulo/source.html.
> Coding practices are also messed up.
> * http://ctubbsii.github.io/accumulo/contrib.html contrib project
> entries are a little wacky.
> * http://ctubbsii.github.io/accumulo/screenshots.html is weird with the
> monitor screenshot (should be beneath the text?)
> * Just noticed that Other and Documentation both have a link to the
> papers/presentations. That might actually be how the site is now, just
> realized it's duplicative.
>
> Thanks again for doing this. It's great!
>
> Christopher wrote:
> > Actually, I now have it all working (as far as I can tell) with
> everything
> > pretty much the same as it looks with CMS today. After people have taken
> > the time to give it a glance, I'll push it to the ASF repo, and then push
> > the generated site to a separate branch. Then we can put in the INFRA
> > ticket to switch from svn to git.
> >
> > On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>  wrote:
> >
> >> I'm working on converting our current site contents over to jekyll at
> >> https://github.com/ctubbsii/accumulo/tree/gh-pages
> >> (view at http://ctubbsii.github.io/accumulo)
> >>
> >> Yes, it's terrible right now... it's in progress. :)
> >>
> >> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>  wrote:
> >>
> >>> Lazy consensus is fine. If there are no objections, I don't want to
> hold
> >>> things up. I feel like I've adequately expressed my concerns. Silence
> >>> can and should be treated as acknowledgement for this, IMO.
> >>>
> >>> Christopher wrote:
> >>>> Another reason we probably shouldn't worry about this: anybody can
> >>> create a
> >>>> DNS name at their leisure which transparently redirects to
> >>>> accumulo.apache.org and serves its contents. This is perfectly
> >>> legitimate
> >>>> for a number of reasons, including corporate proxies/mirrors,
> >>>> URL-shortening services, caching services, archiving services,
> >>>> vision-impaired accessibility services, foreign-language DNS mappings,
> >>> and
> >>>> so-on.
> >>>>
> >>>> I think when it comes to trademarks and our website, our area of
> concern
> >>>> should mostly focus on when people misrepresent our trademark in the
> >>> course
> >>>> of their mirroring/archiving. There's no risk of that for a mirror
> that
> >>> is
> >>>> explicitly under our control, but I'm really leaning towards the
> >>> javascript
> >>>> to detect and display a message about the canonical location just to
> >>>> mitigate any possibility for concern.
> >>>>
> >>>> If you still have concerns, I'd be happy to put it up for a formal
> vote
> >>>> from the PMC, or to get feedback from ASF trademarks folks before we
> >>>> proceed.
> >>>>
> >>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>
>  wrote:
> >>>>
> >>>>> Well, I think the difference is that archive.org (and others --
> google
> >>>>> cached pages come to mind) are devoted/known for that specific
> purpose.
> >>>>> The fact that Github ends up being a "de-facto" location for software
> >>>>> projects, I'm just nervous about the expecting good faith from the
> >>>>> denizens of the internet. Maybe I'm just worrying too much. If
> there's
> >>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine by
> me.
> >>>>>
> >>>>> Christopher wrote:
> >>>>>> I can't imagine there's a trademark issue since it's really just
> >>> acting
> >>>>> as
> >>>>>> a mirror. If there were trademark issues, I imagine sites like
> >>>>>> http://archive.org would be in big trouble. But, it certainly
> >>> couldn't
> >>>>> hurt
> >>>>>> to find out.
> >>>>>>
> >>>>>> Another option to sabotage the GH-rendered site is to add some
> >>> javascript
> >>>>>> which detects the location and displays an informative link back to
> >>> the
> >>>>>> canonical location for the site. That should be simple enough to do.
> >>>>>>
> >>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
> >>>   wrote:
> >>>>>>> It's also probably worth mentioning that this concern only comes
> >>> about
> >>>>>>> for point #4 (or if we use the branch name gh-pages in point #1).
> >>>>>>>
> >>>>>>> Josh Elser wrote:
> >>>>>>>> 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
> >>>>> accumulo.apache.org
> >>>>>>>> or similar).
> >>>>>>>>
> >>>>>>>> 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.
> >
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

* Some companies on http://ctubbsii.github.io/accumulo/people.html are 
goofed as are the timezones.
* Some broken links on http://ctubbsii.github.io/accumulo/source.html. 
Coding practices are also messed up.
* http://ctubbsii.github.io/accumulo/contrib.html contrib project 
entries are a little wacky.
* http://ctubbsii.github.io/accumulo/screenshots.html is weird with the 
monitor screenshot (should be beneath the text?)
* Just noticed that Other and Documentation both have a link to the 
papers/presentations. That might actually be how the site is now, just 
realized it's duplicative.

Thanks again for doing this. It's great!

Christopher wrote:
> Actually, I now have it all working (as far as I can tell) with everything
> pretty much the same as it looks with CMS today. After people have taken
> the time to give it a glance, I'll push it to the ASF repo, and then push
> the generated site to a separate branch. Then we can put in the INFRA
> ticket to switch from svn to git.
>
> On Thu, Mar 10, 2016 at 6:42 PM Christopher<ct...@apache.org>  wrote:
>
>> I'm working on converting our current site contents over to jekyll at
>> https://github.com/ctubbsii/accumulo/tree/gh-pages
>> (view at http://ctubbsii.github.io/accumulo)
>>
>> Yes, it's terrible right now... it's in progress. :)
>>
>> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<jo...@gmail.com>  wrote:
>>
>>> Lazy consensus is fine. If there are no objections, I don't want to hold
>>> things up. I feel like I've adequately expressed my concerns. Silence
>>> can and should be treated as acknowledgement for this, IMO.
>>>
>>> Christopher wrote:
>>>> Another reason we probably shouldn't worry about this: anybody can
>>> create a
>>>> DNS name at their leisure which transparently redirects to
>>>> accumulo.apache.org and serves its contents. This is perfectly
>>> legitimate
>>>> for a number of reasons, including corporate proxies/mirrors,
>>>> URL-shortening services, caching services, archiving services,
>>>> vision-impaired accessibility services, foreign-language DNS mappings,
>>> and
>>>> so-on.
>>>>
>>>> I think when it comes to trademarks and our website, our area of concern
>>>> should mostly focus on when people misrepresent our trademark in the
>>> course
>>>> of their mirroring/archiving. There's no risk of that for a mirror that
>>> is
>>>> explicitly under our control, but I'm really leaning towards the
>>> javascript
>>>> to detect and display a message about the canonical location just to
>>>> mitigate any possibility for concern.
>>>>
>>>> If you still have concerns, I'd be happy to put it up for a formal vote
>>>> from the PMC, or to get feedback from ASF trademarks folks before we
>>>> proceed.
>>>>
>>>> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>   wrote:
>>>>
>>>>> Well, I think the difference is that archive.org (and others -- google
>>>>> cached pages come to mind) are devoted/known for that specific purpose.
>>>>> The fact that Github ends up being a "de-facto" location for software
>>>>> projects, I'm just nervous about the expecting good faith from the
>>>>> denizens of the internet. Maybe I'm just worrying too much. If there's
>>>>> sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.
>>>>>
>>>>> Christopher wrote:
>>>>>> I can't imagine there's a trademark issue since it's really just
>>> acting
>>>>> as
>>>>>> a mirror. If there were trademark issues, I imagine sites like
>>>>>> http://archive.org would be in big trouble. But, it certainly
>>> couldn't
>>>>> hurt
>>>>>> to find out.
>>>>>>
>>>>>> Another option to sabotage the GH-rendered site is to add some
>>> javascript
>>>>>> which detects the location and displays an informative link back to
>>> the
>>>>>> canonical location for the site. That should be simple enough to do.
>>>>>>
>>>>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
>>>   wrote:
>>>>>>> It's also probably worth mentioning that this concern only comes
>>> about
>>>>>>> for point #4 (or if we use the branch name gh-pages in point #1).
>>>>>>>
>>>>>>> Josh Elser wrote:
>>>>>>>> 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
>>>>> accumulo.apache.org
>>>>>>>> or similar).
>>>>>>>>
>>>>>>>> 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.
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

Actually, I now have it all working (as far as I can tell) with everything
pretty much the same as it looks with CMS today. After people have taken
the time to give it a glance, I'll push it to the ASF repo, and then push
the generated site to a separate branch. Then we can put in the INFRA
ticket to switch from svn to git.

On Thu, Mar 10, 2016 at 6:42 PM Christopher <ct...@apache.org> wrote:

> I'm working on converting our current site contents over to jekyll at
> https://github.com/ctubbsii/accumulo/tree/gh-pages
> (view at http://ctubbsii.github.io/accumulo)
>
> Yes, it's terrible right now... it's in progress. :)
>
> On Tue, Mar 8, 2016 at 4:21 PM Josh Elser <jo...@gmail.com> wrote:
>
>> Lazy consensus is fine. If there are no objections, I don't want to hold
>> things up. I feel like I've adequately expressed my concerns. Silence
>> can and should be treated as acknowledgement for this, IMO.
>>
>> Christopher wrote:
>> > Another reason we probably shouldn't worry about this: anybody can
>> create a
>> > DNS name at their leisure which transparently redirects to
>> > accumulo.apache.org and serves its contents. This is perfectly
>> legitimate
>> > for a number of reasons, including corporate proxies/mirrors,
>> > URL-shortening services, caching services, archiving services,
>> > vision-impaired accessibility services, foreign-language DNS mappings,
>> and
>> > so-on.
>> >
>> > I think when it comes to trademarks and our website, our area of concern
>> > should mostly focus on when people misrepresent our trademark in the
>> course
>> > of their mirroring/archiving. There's no risk of that for a mirror that
>> is
>> > explicitly under our control, but I'm really leaning towards the
>> javascript
>> > to detect and display a message about the canonical location just to
>> > mitigate any possibility for concern.
>> >
>> > If you still have concerns, I'd be happy to put it up for a formal vote
>> > from the PMC, or to get feedback from ASF trademarks folks before we
>> > proceed.
>> >
>> > On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>  wrote:
>> >
>> >> Well, I think the difference is that archive.org (and others -- google
>> >> cached pages come to mind) are devoted/known for that specific purpose.
>> >> The fact that Github ends up being a "de-facto" location for software
>> >> projects, I'm just nervous about the expecting good faith from the
>> >> denizens of the internet. Maybe I'm just worrying too much. If there's
>> >> sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.
>> >>
>> >> Christopher wrote:
>> >>> I can't imagine there's a trademark issue since it's really just
>> acting
>> >> as
>> >>> a mirror. If there were trademark issues, I imagine sites like
>> >>> http://archive.org would be in big trouble. But, it certainly
>> couldn't
>> >> hurt
>> >>> to find out.
>> >>>
>> >>> Another option to sabotage the GH-rendered site is to add some
>> javascript
>> >>> which detects the location and displays an informative link back to
>> the
>> >>> canonical location for the site. That should be simple enough to do.
>> >>>
>> >>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
>>  wrote:
>> >>>
>> >>>> It's also probably worth mentioning that this concern only comes
>> about
>> >>>> for point #4 (or if we use the branch name gh-pages in point #1).
>> >>>>
>> >>>> Josh Elser wrote:
>> >>>>> 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
>> >> accumulo.apache.org
>> >>>>> or similar).
>> >>>>>
>> >>>>> 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.
>> >
>>
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

I'm working on converting our current site contents over to jekyll at
https://github.com/ctubbsii/accumulo/tree/gh-pages
(view at http://ctubbsii.github.io/accumulo)

Yes, it's terrible right now... it's in progress. :)

On Tue, Mar 8, 2016 at 4:21 PM Josh Elser <jo...@gmail.com> wrote:

> Lazy consensus is fine. If there are no objections, I don't want to hold
> things up. I feel like I've adequately expressed my concerns. Silence
> can and should be treated as acknowledgement for this, IMO.
>
> Christopher wrote:
> > Another reason we probably shouldn't worry about this: anybody can
> create a
> > DNS name at their leisure which transparently redirects to
> > accumulo.apache.org and serves its contents. This is perfectly
> legitimate
> > for a number of reasons, including corporate proxies/mirrors,
> > URL-shortening services, caching services, archiving services,
> > vision-impaired accessibility services, foreign-language DNS mappings,
> and
> > so-on.
> >
> > I think when it comes to trademarks and our website, our area of concern
> > should mostly focus on when people misrepresent our trademark in the
> course
> > of their mirroring/archiving. There's no risk of that for a mirror that
> is
> > explicitly under our control, but I'm really leaning towards the
> javascript
> > to detect and display a message about the canonical location just to
> > mitigate any possibility for concern.
> >
> > If you still have concerns, I'd be happy to put it up for a formal vote
> > from the PMC, or to get feedback from ASF trademarks folks before we
> > proceed.
> >
> > On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>  wrote:
> >
> >> Well, I think the difference is that archive.org (and others -- google
> >> cached pages come to mind) are devoted/known for that specific purpose.
> >> The fact that Github ends up being a "de-facto" location for software
> >> projects, I'm just nervous about the expecting good faith from the
> >> denizens of the internet. Maybe I'm just worrying too much. If there's
> >> sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.
> >>
> >> Christopher wrote:
> >>> I can't imagine there's a trademark issue since it's really just acting
> >> as
> >>> a mirror. If there were trademark issues, I imagine sites like
> >>> http://archive.org would be in big trouble. But, it certainly couldn't
> >> hurt
> >>> to find out.
> >>>
> >>> Another option to sabotage the GH-rendered site is to add some
> javascript
> >>> which detects the location and displays an informative link back to the
> >>> canonical location for the site. That should be simple enough to do.
> >>>
> >>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>
>  wrote:
> >>>
> >>>> It's also probably worth mentioning that this concern only comes about
> >>>> for point #4 (or if we use the branch name gh-pages in point #1).
> >>>>
> >>>> Josh Elser wrote:
> >>>>> 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
> >> accumulo.apache.org
> >>>>> or similar).
> >>>>>
> >>>>> 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.
> >
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

Lazy consensus is fine. If there are no objections, I don't want to hold 
things up. I feel like I've adequately expressed my concerns. Silence 
can and should be treated as acknowledgement for this, IMO.

Christopher wrote:
> Another reason we probably shouldn't worry about this: anybody can create a
> DNS name at their leisure which transparently redirects to
> accumulo.apache.org and serves its contents. This is perfectly legitimate
> for a number of reasons, including corporate proxies/mirrors,
> URL-shortening services, caching services, archiving services,
> vision-impaired accessibility services, foreign-language DNS mappings, and
> so-on.
>
> I think when it comes to trademarks and our website, our area of concern
> should mostly focus on when people misrepresent our trademark in the course
> of their mirroring/archiving. There's no risk of that for a mirror that is
> explicitly under our control, but I'm really leaning towards the javascript
> to detect and display a message about the canonical location just to
> mitigate any possibility for concern.
>
> If you still have concerns, I'd be happy to put it up for a formal vote
> from the PMC, or to get feedback from ASF trademarks folks before we
> proceed.
>
> On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<jo...@gmail.com>  wrote:
>
>> Well, I think the difference is that archive.org (and others -- google
>> cached pages come to mind) are devoted/known for that specific purpose.
>> The fact that Github ends up being a "de-facto" location for software
>> projects, I'm just nervous about the expecting good faith from the
>> denizens of the internet. Maybe I'm just worrying too much. If there's
>> sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.
>>
>> Christopher wrote:
>>> I can't imagine there's a trademark issue since it's really just acting
>> as
>>> a mirror. If there were trademark issues, I imagine sites like
>>> http://archive.org would be in big trouble. But, it certainly couldn't
>> hurt
>>> to find out.
>>>
>>> Another option to sabotage the GH-rendered site is to add some javascript
>>> which detects the location and displays an informative link back to the
>>> canonical location for the site. That should be simple enough to do.
>>>
>>> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>   wrote:
>>>
>>>> It's also probably worth mentioning that this concern only comes about
>>>> for point #4 (or if we use the branch name gh-pages in point #1).
>>>>
>>>> Josh Elser wrote:
>>>>> 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
>> accumulo.apache.org
>>>>> or similar).
>>>>>
>>>>> 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.
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

Another reason we probably shouldn't worry about this: anybody can create a
DNS name at their leisure which transparently redirects to
accumulo.apache.org and serves its contents. This is perfectly legitimate
for a number of reasons, including corporate proxies/mirrors,
URL-shortening services, caching services, archiving services,
vision-impaired accessibility services, foreign-language DNS mappings, and
so-on.

I think when it comes to trademarks and our website, our area of concern
should mostly focus on when people misrepresent our trademark in the course
of their mirroring/archiving. There's no risk of that for a mirror that is
explicitly under our control, but I'm really leaning towards the javascript
to detect and display a message about the canonical location just to
mitigate any possibility for concern.

If you still have concerns, I'd be happy to put it up for a formal vote
from the PMC, or to get feedback from ASF trademarks folks before we
proceed.

On Tue, Mar 8, 2016 at 3:22 PM Josh Elser <jo...@gmail.com> wrote:

> Well, I think the difference is that archive.org (and others -- google
> cached pages come to mind) are devoted/known for that specific purpose.
> The fact that Github ends up being a "de-facto" location for software
> projects, I'm just nervous about the expecting good faith from the
> denizens of the internet. Maybe I'm just worrying too much. If there's
> sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.
>
> Christopher wrote:
> > I can't imagine there's a trademark issue since it's really just acting
> as
> > a mirror. If there were trademark issues, I imagine sites like
> > http://archive.org would be in big trouble. But, it certainly couldn't
> hurt
> > to find out.
> >
> > Another option to sabotage the GH-rendered site is to add some javascript
> > which detects the location and displays an informative link back to the
> > canonical location for the site. That should be simple enough to do.
> >
> > On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>  wrote:
> >
> >> It's also probably worth mentioning that this concern only comes about
> >> for point #4 (or if we use the branch name gh-pages in point #1).
> >>
> >> Josh Elser wrote:
> >>> 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
> accumulo.apache.org
> >>> or similar).
> >>>
> >>> 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.
> >
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

Well, I think the difference is that archive.org (and others -- google 
cached pages come to mind) are devoted/known for that specific purpose. 
The fact that Github ends up being a "de-facto" location for software 
projects, I'm just nervous about the expecting good faith from the 
denizens of the internet. Maybe I'm just worrying too much. If there's 
sufficient "it'll be ok" opinion coming from the PMC, it's fine by me.

Christopher wrote:
> I can't imagine there's a trademark issue since it's really just acting as
> a mirror. If there were trademark issues, I imagine sites like
> http://archive.org would be in big trouble. But, it certainly couldn't hurt
> to find out.
>
> Another option to sabotage the GH-rendered site is to add some javascript
> which detects the location and displays an informative link back to the
> canonical location for the site. That should be simple enough to do.
>
> On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<jo...@gmail.com>  wrote:
>
>> It's also probably worth mentioning that this concern only comes about
>> for point #4 (or if we use the branch name gh-pages in point #1).
>>
>> Josh Elser wrote:
>>> 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 accumulo.apache.org
>>> or similar).
>>>
>>> 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.
>

Re: git-based site and jekyll

[Christopher <ct...@apache.org>]

I can't imagine there's a trademark issue since it's really just acting as
a mirror. If there were trademark issues, I imagine sites like
http://archive.org would be in big trouble. But, it certainly couldn't hurt
to find out.

Another option to sabotage the GH-rendered site is to add some javascript
which detects the location and displays an informative link back to the
canonical location for the site. That should be simple enough to do.

On Tue, Mar 8, 2016 at 1:36 PM Josh Elser <jo...@gmail.com> wrote:

> It's also probably worth mentioning that this concern only comes about
> for point #4 (or if we use the branch name gh-pages in point #1).
>
> Josh Elser wrote:
> > 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 accumulo.apache.org
> > or similar).
> >
> > 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.
>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

It's also probably worth mentioning that this concern only comes about 
for point #4 (or if we use the branch name gh-pages in point #1).

Josh Elser wrote:
> 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 accumulo.apache.org
> or similar).
>
> 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.

Re: git-based site and jekyll

[Keith Turner <ke...@deenlo.com>]

+1 on moving to Jekyll

On Tue, Mar 8, 2016 at 12:46 PM, Josh Elser <jo...@gmail.com> 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 accumulo.apache.org 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.

http://www.apache.org/foundation/marks/
http://www.apache.org/foundation/marks/domains.html



>
>
> 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 http://accumulo.apache.org
>> * Identical, automatic rendering of gh-pages branch at
>> http://apache.github.io/accumulo
>> * Changes to gh-pages in forks would render in fork's github.io 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:
>> https://drill.apache.org/
>> http://apache.github.io/drill/
>> http://ctubbsii.github.io/drill/ (example fork build)
>>
>>

Re: git-based site and jekyll

[Josh Elser <jo...@gmail.com>]

+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 accumulo.apache.org 
or similar).

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 http://accumulo.apache.org
> * Identical, automatic rendering of gh-pages branch at
> http://apache.github.io/accumulo
> * Changes to gh-pages in forks would render in fork's github.io 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:
> https://drill.apache.org/
> http://apache.github.io/drill/
> http://ctubbsii.github.io/drill/ (example fork build)
>

Re: git-based site and jekyll

[Sean Busbey <bu...@cloudera.com>]

+1 sounds great!

On Mon, Mar 7, 2016 at 5:09 PM, Christopher <ct...@apache.org> 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 http://accumulo.apache.org
> * Identical, automatic rendering of gh-pages branch at
> http://apache.github.io/accumulo
> * Changes to gh-pages in forks would render in fork's github.io 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:
> https://drill.apache.org/
> http://apache.github.io/drill/
> http://ctubbsii.github.io/drill/ (example fork build)
>



-- 
busbey