accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: git-based site and jekyll
Date Fri, 11 Mar 2016 02:57:04 GMT
* 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<ctubbsii@apache.org>  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<josh.elser@gmail.com>  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<josh.elser@gmail.com>   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<josh.elser@gmail.com>
>>>   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.
>

Mime
View raw message