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