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