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 <[email protected]> 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<[email protected]> 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<[email protected]> > 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. > > >
