Evan, On Thu, Mar 16, 2017 at 9:13 PM Evan Hughes <[email protected]> wrote:
> Hey john, > > Still wantting to explore this venture? > > Yes - was waiting to free up some time to make this happen. I think that's going to start after next week. > Just wondering why the choice of jbake over something like middleman (my > perferred) , jekyll or hugo? > I've never heard of middleman before. It looks extremely powerful. I was introduced to jbake by one of the podlings I mentor - Tamaya. It actually satisfies a few needs that I wanted to make sure. First, obviously open source. Its extensible to some extent. When we get to porting pages like the podling status pages, I expect some customization required. In addition, jbake is heavily aligned to Apache (though not an ASF project) - its based on Groovy and Freemarker so it makes me feel like we're eating our own tooling. Its not tied to any specific format. I can mix pages of multiple formats together, at least from my local prototyping its very easy to get things working together. When I look at tools like jekyll or hugo, I can't say the same for those tools. > > ~ Evan > > On Thu, 19 Jan 2017 at 14:17 John D. Ament <[email protected]> wrote: > > > On Tue, Jan 17, 2017 at 10:52 PM Branko Čibej <[email protected]> wrote: > > > > > On 15.01.2017 15:47, John D. Ament wrote: > > > > So I want to put this out there as an idea I had been toying with. > > With > > > > our new logo we should launch a new incubator website. Something > more > > > > modern looking and easier to maintain. This is in part what I was > > trying > > > > to do with the git conversion, > > > > > > > > > Going slightly on a tangent, /me wonders what bearing the VCS has on > how > > > hard or easy it is to maintain the site content ... let alone how it > > looks. > > > > > > Looks like the world has graduated from the "Let's rewrite it in Java" > > > to the "Let's migrate it to Git" method of wasting time. :) > > > > > > Always acknowledging, of course, that your time is your own to waste > ... > > > as long as it does not cause everyone else to waste time changing their > > > tools and workflow. For what good reason, exactly? I must have missed > > > the well-argued rationale. > > > > > > > > > As a java guy, I'm completely taken aback by this! (just kidding) > > > > Basically, its my tendency to kill as many birds as possible with a > single > > stone. One of the advantages (though we can get this with svnpubsub as > > well) is the automatic building of website updates (over the staging > > area). Its my pet peeve that no one logs into CMS to perform the final > > commit of a website change. So eliminating it seems like the most > obvious > > step. > > > > Switching source control also gives us the gated feel of having the new > > website come up in parallel and doing a hard cut over when its ready. > The > > infra impact is minimal at that point. Granted, yes, it could just as > > easily be done with a new svn directory instead of a git repo. > > > > The proliferation of github also makes it a much lower barrier of entry > for > > people looking to make website changes. Outside committers doing a RTC > > workflow would have a good outlet, being able to edit files online and > > commit is also beneficial. It means you can just edit the file online, > fix > > it and the website is live. In a much simpler to use interface. The > goal > > of CMS, unfortunately not where CMS ever got to. > > > > It also in my opinion better aligns to the tools that podlings are using > > more and more. Looking at sites like http://status.apache.org/ you'll > see > > that git has become a lot more active than svn has (as of writing this, > 130 > > svn commits vs 927 git commits in the past 24 hours). > > > > So to summarize: > > > > - Automatic building of the website > > - Gated conversion to a new look and feel > > - Online editing of files > > - Better alignment to the tooling that podlings use > > > > John > > > > > > > > > > -- Brane > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
