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. > > >
