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