>What changes if we go for gitpubsub?
Not much for end users. For developers, we would need to get used to whichever tool we choose for static site generator. >If I read that right, no CMS because CMS is svnpubsub only. Is it a "big >bang" switch to Jekyll? That isn't too scary but it is a step-change. Not much I think. Most of the Markdown can be easily ported with some regex/shell script. When I helped porting OpenNLP's site, I used Jena website as reference for parts of their new layout and general organization. If you open both sites opennlp.apache.org and jena.apache.org, you may find they are both very similar. And we don't have to necessarily use Jekyll. If the consensus is for another tool (e.g. Pelican, Hexo, JBake, etc) we just need to confirm with Apache Infra if they are able to run the same tool in their automation pipeline. >One thing we do benefit from currently is content fixes via CMS - we may have >to change that. I guess there is no jena.staging.a.o? It becomes local Jekyll >build? As far as I know, that is right. However, users can run something like `jekyll serve`. I like the current process, but if you have a great change, it is hard to get feedback without committing to SVN, having some draft in the staging area. With the gitpubsub + some static site generator. Or we can even share our own GitHub fork website. OpenNLP template has an issue with extra paths, so this is broken, but we can work to have Jena website working correctly, and send a pull request to opennlp's repo: https://kinow.github.io/opennlp-site/. So if we have a new repository like github.com/apache/jena-site, then I could fork it under github.com/kinow/jena-site, work in my own fork, prepare pull requests, and include a link like https://kinow.github.io/jena-site. I prefer this approach to having to `svn commit` to preview in the staging area. >A project can have more then one git repo so I guess we can choose whether to >use the main repo or not. Our site .svn is 2.2G (probably all those javadoc >changes). Or a separate repo git-include-submodule in the main one? Oh, very good point. OpenNLP has/had the same issue. Not sure if that was fixed. Their old docs are served here: http://opennlp.apache.org/docs/legacy.html I believe it's done here: https://github.com/apache/opennlp-site/blob/0303866c56689f602dc9258b32e1a64f59ea82e4/pom.xml#L204 Though not entirely sure how it works. I can join the Slack channel next week and check with them. The first version of the site included all the old javadocs, and was quite slow to check out and build. There was some service interruption during the Apache Infra automation set-up. But given OpenNLP just went through the process, it would be simpler, as we could just tell them to look at the job and instead of Maven/JBake, run jekyll or whatever tool we choose. I would be happy to volunteer and create ticket to create jena-site repository in GitHub. Then once we have the site being generated there and we have validated it, I can create the ticket for INFRA to set up the automation, and switch from svnpubsub to gitpubsub. Cheers Bruno ________________________________ From: Andy Seaborne <a...@apache.org> To: dev@jena.apache.org Sent: Sunday, 12 November 2017 4:56 AM Subject: gitpubsub On 09/11/17 20:51, Bruno P. Kinoshita wrote: ... > However, I'm +1 for moving our site to Git. What changes if we go for gitpubsub? All I know about it is the bullet point on https://www.apache.org/dev/project-site.html. If I read that right, no CMS because CMS is svnpubsub only. Is it a "big bang" switch to Jekyll? That isn't too scary but it is a step-change. One thing we do benefit from currently is content fixes via CMS - we may have to change that. I guess there is no jena.staging.a.o? It becomes local Jekyll build? A project can have more then one git repo so I guess we can choose whether to use the main repo or not. Our site .svn is 2.2G (probably all those javadoc changes). Or a separate repo git-include-submodule in the main one? Andy
