You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Daniel Pono Takamori <po...@apache.org> on 2017/11/09 18:22:17 UTC
Re: Gitbox?
Gitbox would indeed allow you to have the Github tools available to
committers. It treats Github as the canonical source (we also keep a
copy on Gitbox), which allows the PRs and issues to be a bit more
convenient (there are still some things we can't support due to the
Github's coarse permission structure).
We require all committers to use Github's 2FA [0] so once you have a
taken a vote in the project, file a ticket on the INFRA JIRA [1] and
then your committers can run through the Gitbox syncing [2] to matchup
ASF IDs and Github IDs.
Let us know if you have any other questions.
[0] - https://help.github.com/articles/providing-your-2fa-authentication-code/
[1] - https://issues.apache.org/jira/browse/INFRA
[2] - https://gitbox.apache.org/setup/
On Thu, Nov 9, 2017 at 10:50 AM, <aj...@apache.org> wrote:
> Hi, I'm a committer for Jena. Recently, we had some discussion about our
> source management and there was some uncertainty about how we can arrange
> the relationship between Github and Apache git.
>
> Currently, commits go against Apache git, and Github picks them up and
> mirrors them, which is a bit annoying in that it's not possible to use the
> Github PR review machinery transparently. This is not a big deal, but is it
> in fact possible to do that? In other words, is it possible to (e.g.) merge
> PRs at Github and have Apache git pick up the change?
>
> I went to https://gitbox.apache.org/setup/ and linked my accounts, but that
> didn't seem to do anything...
>
> Thanks for any info!
>
> --
>
> ajs6f
Re: Gitbox?
Posted by aj...@apache.org.
Daniel--
We have begun to discuss this on dev@jena, and one question that immediately came up is how this plays with JIRA
integration. Currently we have a system in which any mention of any extant JIRA ticket in a Github PR starts copying the
comments in that PR over to that JIRA ticket, which is useful. Can we assume that the same integration will work the
same way if we go to "Github as canonical"?
Are there any further integrations available after choosing "Github as canonical", e.g. create-JIRA-ticket-on-PR or the
like?
Thanks for info!
ajs6f
Daniel Pono Takamori wrote on 11/9/17 1:22 PM:
> Gitbox would indeed allow you to have the Github tools available to
> committers. It treats Github as the canonical source (we also keep a
> copy on Gitbox), which allows the PRs and issues to be a bit more
> convenient (there are still some things we can't support due to the
> Github's coarse permission structure).
> We require all committers to use Github's 2FA [0] so once you have a
> taken a vote in the project, file a ticket on the INFRA JIRA [1] and
> then your committers can run through the Gitbox syncing [2] to matchup
> ASF IDs and Github IDs.
> Let us know if you have any other questions.
>
> [0] - https://help.github.com/articles/providing-your-2fa-authentication-code/
> [1] - https://issues.apache.org/jira/browse/INFRA
> [2] - https://gitbox.apache.org/setup/
>
> On Thu, Nov 9, 2017 at 10:50 AM, <aj...@apache.org> wrote:
>> Hi, I'm a committer for Jena. Recently, we had some discussion about our
>> source management and there was some uncertainty about how we can arrange
>> the relationship between Github and Apache git.
>>
>> Currently, commits go against Apache git, and Github picks them up and
>> mirrors them, which is a bit annoying in that it's not possible to use the
>> Github PR review machinery transparently. This is not a big deal, but is it
>> in fact possible to do that? In other words, is it possible to (e.g.) merge
>> PRs at Github and have Apache git pick up the change?
>>
>> I went to https://gitbox.apache.org/setup/ and linked my accounts, but that
>> didn't seem to do anything...
>>
>> Thanks for any info!
>>
>> --
>>
>> ajs6f
Re: Gitbox?
Posted by Andy Seaborne <an...@apache.org>.
On 12/11/17 17:48, ajs6f@apache.org wrote:
> First question, what is a [DISCUSS]? :) I assume you are talking about a
> dev@ thread with that label to discuss this possibility, but is there
> more to it than that?
That's what it is - they are a preparation for a [VOTE], both as notice
it's going to happen and getting the [VOTE} intention clear. Having the
[VOTE] turn into a discussion is unhelpful - eg early votes may be
invalidated by clarification/changes.
Andy
Re: Gitbox?
Posted by aj...@apache.org.
Yes, I'm on this!
First question, what is a [DISCUSS]? :) I assume you are talking about a dev@ thread with that label to discuss this
possibility, but is there more to it than that?
As I understand it now, "it" is changing from our current setup, in which we act against Apache git and the results are
mirrored to Github, to the opposite direction, in which we act against Github and the results are mirrored to Apache
git. As far as PR machinery goes, an advantage that I see is that we will be able to use the complete excellent web UI
at Github. Right now, we can comment, review, etc, but when it comes time to merge, it occurs via CLI. It's true that
that isn't the end of the world, but is both clunky (as Andy notes) and error-prone (I had a annoying problem with it on
a recent PR). We would also get accurate results from Github's visualization tools, which isn't a major thing, but could
be nice.
My understanding is that such a change will have no effect at all on our current JIRA integration, but I will get that
confirmed (or disproved!) by INFRA. Going to Github issues would be a different choice, and I am not arguing for that
now. (Trying to split as much off of this as possible to keep the decision simpler!)
Bruno-- if it's not obvious, I am intentionally splitting off the question of where we maintain our site, which is a
really good thing to discuss, but think it is orthogonal.
ajs6f
Andy Seaborne wrote on 11/11/17 10:41 AM:
>
>
> On 09/11/17 18:24, ajs6f@apache.org wrote:
>> Great, thanks!
>>
>> So folks, is there interest in pursuing this rearrangement of our source management? I would certainly vote for it.
>
> Great - do you want to take this on and see us through the process?
>
> We'll need a [DISCUSS] I expect to make sure we all know what the VOTE is really about. I'm not clear what "it" is exactly.
>
> I'm all linked up - 2FA etc, and it can see which repo I have access to.
>
>
> I use JIRA search and git history more and more to understand what users are asking about and to trace down bugs.
>
> How does gitbox interact with JIRA? Do we get a nice set of JIRA comment (obvious existing bug - JIRA isn't markdown so
> `` and {{}} mess up.
>
> I guess discussion is on GH issues, not JIRA tickets, which is a change but fine by me.
>
>
> The "git pull github pull/XXX/head --no-ff ; git push" is clunky but not the end of the world.
>
> (Unrelated wish - delete of the local branch - is that "git fetch --prune"?).
>
>> it's not possible to use the Github PR review machinery transparently
>
> This confused me - we use GH PR review at the monent. Could you expand the point?
>
>
> So I guess I want to know what changes in the workflows for submission (nothing presumably but what about JIRA? Auto
> create-JIRA-on-PR would be fancy) and for acceptance
>
> I'm expecting changes if we go "gitbox" and that's fine, I'm not arguing for the status quo. It's not easy to reverse so
> I want to know what it is.
>
> Andy
>
> https://github.com/apache/jena/blob/master/CONTRIBUTING.md
>
>>
>> ajs6f
>>
>> Daniel Pono Takamori wrote on 11/9/17 1:22 PM:
>>> Gitbox would indeed allow you to have the Github tools available to
>>> committers. It treats Github as the canonical source (we also keep a
>>> copy on Gitbox), which allows the PRs and issues to be a bit more
>>> convenient (there are still some things we can't support due to the
>>> Github's coarse permission structure).
>>> We require all committers to use Github's 2FA [0] so once you have a
>>> taken a vote in the project, file a ticket on the INFRA JIRA [1] and
>>> then your committers can run through the Gitbox syncing [2] to matchup
>>> ASF IDs and Github IDs.
>>> Let us know if you have any other questions.
>>>
>>> [0] - https://help.github.com/articles/providing-your-2fa-authentication-code/
>>> [1] - https://issues.apache.org/jira/browse/INFRA
>>> [2] - https://gitbox.apache.org/setup/
>>>
>>> On Thu, Nov 9, 2017 at 10:50 AM, <aj...@apache.org> wrote:
>>>> Hi, I'm a committer for Jena. Recently, we had some discussion about our
>>>> source management and there was some uncertainty about how we can arrange
>>>> the relationship between Github and Apache git.
>>>>
>>>> Currently, commits go against Apache git, and Github picks them up and
>>>> mirrors them, which is a bit annoying in that it's not possible to use the
>>>> Github PR review machinery transparently. This is not a big deal, but is it
>>>> in fact possible to do that? In other words, is it possible to (e.g.) merge
>>>> PRs at Github and have Apache git pick up the change?
>>>>
>>>> I went to https://gitbox.apache.org/setup/ and linked my accounts, but that
>>>> didn't seem to do anything...
>>>>
>>>> Thanks for any info!
>>>>
>>>> --
>>>>
>>>> ajs6f
Re: Gitbox?
Posted by Andy Seaborne <an...@apache.org>.
On 09/11/17 18:24, ajs6f@apache.org wrote:
> Great, thanks!
>
> So folks, is there interest in pursuing this rearrangement of our source
> management? I would certainly vote for it.
Great - do you want to take this on and see us through the process?
We'll need a [DISCUSS] I expect to make sure we all know what the VOTE
is really about. I'm not clear what "it" is exactly.
I'm all linked up - 2FA etc, and it can see which repo I have access to.
I use JIRA search and git history more and more to understand what users
are asking about and to trace down bugs.
How does gitbox interact with JIRA? Do we get a nice set of JIRA
comment (obvious existing bug - JIRA isn't markdown so `` and {{}} mess up.
I guess discussion is on GH issues, not JIRA tickets, which is a change
but fine by me.
The "git pull github pull/XXX/head --no-ff ; git push" is clunky but not
the end of the world.
(Unrelated wish - delete of the local branch - is that "git fetch
--prune"?).
> it's not possible to use the Github PR review machinery transparently
This confused me - we use GH PR review at the monent. Could you expand
the point?
So I guess I want to know what changes in the workflows for submission
(nothing presumably but what about JIRA? Auto create-JIRA-on-PR would be
fancy) and for acceptance
I'm expecting changes if we go "gitbox" and that's fine, I'm not arguing
for the status quo. It's not easy to reverse so I want to know what it is.
Andy
https://github.com/apache/jena/blob/master/CONTRIBUTING.md
>
> ajs6f
>
> Daniel Pono Takamori wrote on 11/9/17 1:22 PM:
>> Gitbox would indeed allow you to have the Github tools available to
>> committers. It treats Github as the canonical source (we also keep a
>> copy on Gitbox), which allows the PRs and issues to be a bit more
>> convenient (there are still some things we can't support due to the
>> Github's coarse permission structure).
>> We require all committers to use Github's 2FA [0] so once you have a
>> taken a vote in the project, file a ticket on the INFRA JIRA [1] and
>> then your committers can run through the Gitbox syncing [2] to matchup
>> ASF IDs and Github IDs.
>> Let us know if you have any other questions.
>>
>> [0] -
>> https://help.github.com/articles/providing-your-2fa-authentication-code/
>> [1] - https://issues.apache.org/jira/browse/INFRA
>> [2] - https://gitbox.apache.org/setup/
>>
>> On Thu, Nov 9, 2017 at 10:50 AM, <aj...@apache.org> wrote:
>>> Hi, I'm a committer for Jena. Recently, we had some discussion about our
>>> source management and there was some uncertainty about how we can
>>> arrange
>>> the relationship between Github and Apache git.
>>>
>>> Currently, commits go against Apache git, and Github picks them up and
>>> mirrors them, which is a bit annoying in that it's not possible to
>>> use the
>>> Github PR review machinery transparently. This is not a big deal, but
>>> is it
>>> in fact possible to do that? In other words, is it possible to (e.g.)
>>> merge
>>> PRs at Github and have Apache git pick up the change?
>>>
>>> I went to https://gitbox.apache.org/setup/ and linked my accounts,
>>> but that
>>> didn't seem to do anything...
>>>
>>> Thanks for any info!
>>>
>>> --
>>>
>>> ajs6f
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
gitpubsub
Posted by Andy Seaborne <an...@apache.org>.
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: Gitbox?
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
I'm OK with git at ASF or GitHub + gitbox (-:
However, I'm +1 for moving our site to Git.
From: "ajs6f@apache.org" <aj...@apache.org>
To: Daniel Pono Takamori <po...@apache.org>; dev@jena.apache.org
Sent: Friday, 10 November 2017 7:24 AM
Subject: Re: Gitbox?
Great, thanks!
So folks, is there interest in pursuing this rearrangement of our source management? I would certainly vote for it.
ajs6f
Daniel Pono Takamori wrote on 11/9/17 1:22 PM:
> Gitbox would indeed allow you to have the Github tools available to
> committers. It treats Github as the canonical source (we also keep a
> copy on Gitbox), which allows the PRs and issues to be a bit more
> convenient (there are still some things we can't support due to the
> Github's coarse permission structure).
> We require all committers to use Github's 2FA [0] so once you have a
> taken a vote in the project, file a ticket on the INFRA JIRA [1] and
> then your committers can run through the Gitbox syncing [2] to matchup
> ASF IDs and Github IDs.
> Let us know if you have any other questions.
>
> [0] - https://help.github.com/articles/providing-your-2fa-authentication-code/
> [1] - https://issues.apache.org/jira/browse/INFRA
> [2] - https://gitbox.apache.org/setup/
>
> On Thu, Nov 9, 2017 at 10:50 AM, <aj...@apache.org> wrote:
>> Hi, I'm a committer for Jena. Recently, we had some discussion about our
>> source management and there was some uncertainty about how we can arrange
>> the relationship between Github and Apache git.
>>
>> Currently, commits go against Apache git, and Github picks them up and
>> mirrors them, which is a bit annoying in that it's not possible to use the
>> Github PR review machinery transparently. This is not a big deal, but is it
>> in fact possible to do that? In other words, is it possible to (e.g.) merge
>> PRs at Github and have Apache git pick up the change?
>>
>> I went to https://gitbox.apache.org/setup/ and linked my accounts, but that
>> didn't seem to do anything...
>>
>> Thanks for any info!
>>
>> --
>>
>> ajs6f
Re: Gitbox?
Posted by aj...@apache.org.
Great, thanks!
So folks, is there interest in pursuing this rearrangement of our source management? I would certainly vote for it.
ajs6f
Daniel Pono Takamori wrote on 11/9/17 1:22 PM:
> Gitbox would indeed allow you to have the Github tools available to
> committers. It treats Github as the canonical source (we also keep a
> copy on Gitbox), which allows the PRs and issues to be a bit more
> convenient (there are still some things we can't support due to the
> Github's coarse permission structure).
> We require all committers to use Github's 2FA [0] so once you have a
> taken a vote in the project, file a ticket on the INFRA JIRA [1] and
> then your committers can run through the Gitbox syncing [2] to matchup
> ASF IDs and Github IDs.
> Let us know if you have any other questions.
>
> [0] - https://help.github.com/articles/providing-your-2fa-authentication-code/
> [1] - https://issues.apache.org/jira/browse/INFRA
> [2] - https://gitbox.apache.org/setup/
>
> On Thu, Nov 9, 2017 at 10:50 AM, <aj...@apache.org> wrote:
>> Hi, I'm a committer for Jena. Recently, we had some discussion about our
>> source management and there was some uncertainty about how we can arrange
>> the relationship between Github and Apache git.
>>
>> Currently, commits go against Apache git, and Github picks them up and
>> mirrors them, which is a bit annoying in that it's not possible to use the
>> Github PR review machinery transparently. This is not a big deal, but is it
>> in fact possible to do that? In other words, is it possible to (e.g.) merge
>> PRs at Github and have Apache git pick up the change?
>>
>> I went to https://gitbox.apache.org/setup/ and linked my accounts, but that
>> didn't seem to do anything...
>>
>> Thanks for any info!
>>
>> --
>>
>> ajs6f