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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> +1 >>> >>> Dylan Hutchison wrote: >>> > Sounds great Chris! >>> > >>> > On Fri, Mar 11, 2016 at 9:50 AM, Christopher<[email protected]> >>> 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< >>> [email protected]> >>> >> wrote: >>> >> >>> >>> Wow, that's looking great. Thanks, Christopher! >>> >>> >>> >>> Billie >>> >>> >>> >>> On Thu, Mar 10, 2016 at 10:38 PM, Christopher<[email protected]> >>> >> 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<[email protected]> >>> >> 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<[email protected]> >>> >>>> 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<[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. >>> > >>> >>
