You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2017/11/11 15:56:30 UTC
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
Re: gitpubsub
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
>Bruno (or anyone), do you know if it would be possible to publish site changes for review out of Apache CI? (Something like the way we can set up to get built artifacts from branches of the codebase without actually releasing them.)
Might be worth checking with INFRA if we request it, or even in that IRC-like channel they use (always forget its name). It would be an interesting feature.
>Is it okay with respect to Apache policy to only import the current state of the site to Git (iow to leave behind that massive accumulation of Javadocs), or do we need to maintain a complete history on whatever infrastructure we use?
As far as I can tell, it varies from components. Some release the latest javadocs, others a few past releases, others one release only. It might be useful for other users to have previous releases, but when working on projects with older versions of a library, I normally rely on Eclipse + open implementation shortcut to look at the docs.
B
From: ajs6f <aj...@apache.org>
To: dev@jena.apache.org
Sent: Monday, 20 November 2017 2:48 AM
Subject: Re: gitpubsub
Bruno (or anyone), do you know if it would be possible to publish site changes for review out of Apache CI? (Something like the way we can set up to get built artifacts from branches of the codebase without actually releasing them.)
Is it okay with respect to Apache policy to only import the current state of the site to Git (iow to leave behind that massive accumulation of Javadocs), or do we need to maintain a complete history on whatever infrastructure we use?
ajs6f
> On Nov 17, 2017, at 3:30 AM, Bruno P. Kinoshita <br...@yahoo.com.br.INVALID> wrote:
>
>> 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 <an...@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
Re: gitpubsub
Posted by ajs6f <aj...@apache.org>.
Bruno (or anyone), do you know if it would be possible to publish site changes for review out of Apache CI? (Something like the way we can set up to get built artifacts from branches of the codebase without actually releasing them.)
Is it okay with respect to Apache policy to only import the current state of the site to Git (iow to leave behind that massive accumulation of Javadocs), or do we need to maintain a complete history on whatever infrastructure we use?
ajs6f
> On Nov 17, 2017, at 3:30 AM, Bruno P. Kinoshita <br...@yahoo.com.br.INVALID> wrote:
>
>> 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 <an...@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
Re: gitpubsub
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
>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 <an...@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