Re: [DISCUSS] GitBox
One more thought on this: if we switched, I'd want to take the opportunity to move GitHub notifications to the notifications@ list. That allows people to subscribe directly to GitHub for customizing their notification settings, or to subscribe to the notifications@ list. It would help reduce redundant messages for those subscribing to dev@ On Mon, Jun 5, 2017 at 1:45 PM Christopherwrote: > (Note: CC'd Fluo dev list) > > Fluo recently switched to GitBox. I figured this experience might be > useful to mention if Accumulo decides to do it: > > Pitfalls: > > 1. commits and notifications didn't get forwarded to their respective > mailing lists properly at first; that was an incubator-specific issue that > wouldn't apply if Accumulo moved > > 2. the website repo stopped updating the website; I believe that has been > fixed (but haven't pushed a new website commit to test), and can probably > be avoided by mentioning the git-based website in the request to move to > GitBox (which I forgot to do) > > 3. I forgot to update the Jenkins builds for Fluo, so those were broken > for a few days; trivial to fix, and Fluo mostly relies on Travis CI instead > of Jenkins anyway > > 4. Since the URL changed, I had to update my ~/.gitconfig settings for the > credential.helper with a second credential line, and type in my password > once to save it in GNOME keyring daemon the first time I pushed a new > commit: > [credential] > helper = gnome-keyring > [credential "https://git-wip-us.apache.org/repos/asf/;] > username = ctubbsii > [credential "https://gitbox.apache.org/repos/asf/;] > username = ctubbsii > > 5. notifications may come from a different email address, so it may need > to be white-listed by the moderators the first time it sends to the list > > Several benefits (some surprising): > > 1. Can self-serve Travis CI configuration, because Travis CI grants > permissions based on whether you have write permission on the GitHub repo. > This was a very cool benefit. We can now clear caches, and set up builds > with more control (per-branch, pull requests, etc.) than before, without > submitting trivial INFRA tickets. > > 2. Can assign issues/PRs to individuals as well as use labels, milestones, > to make them more searchable; for Accumulo, this would only benefit PRs, > because we're not using GH issues. > > 3. Can close issues. > > 4. Only the host name changed in the URLs. GitBox is set up exactly like > git-wip, so that was very convenient. A simple find/replace was sufficient > to update docs and config files with the new host name without changing the > path to the repo on that host. > > 5. When pushing to the server, the git client receives and prints messages > about the pre-/post-push actions that the server is doing, like triggering > mailing list notifications. I found this to be pleasantly informative, and > possibly useful for debugging. > > 6. A private GitHub team is created in the Apache GitHub organization for > the Apache users who have registered their GitHub user name. This means > that the whole team can be @mentioned in GitHub by a team member, and team > members can more easily find their colleagues on GitHub (only works for > those who have opted-in with their GitHub user name). > > 7. This wouldn't apply to Accumulo, but Fluo was able to close a long-open > 1.0.0 milestone that we hadn't been able to close since moving the repo to > ASF. In general, this allows milestone management in GitHub (may not ever > matter for Accumulo). > > Unknowns: > > 1. One thing that's not known is how well the JIRA integration will > migrate. I imagine it works fine, but Fluo doesn't use JIRA, so I can't > speak to that. > > Overall: > > Overall, I think individual developer clones were easy to update, and it > didn't seem to inconvenience anybody too much. I emailed the list with a > one-liner to update the URL, and that seemed to be appreciated/helpful. > (git remote set-url > https://gitbox.apache.org/repos/asf/). This wouldn't be necessary > if INFRA made the old URL redirect to the new one, but such as it is, they > have not done so. > > The switch enables a lot more self-service, putting things more under the > control of the PMC/committers, so INFRA doesn't have to be involved for > various minor things. I think this is better for the foundation, because > less tedious issue-handling means INFRA can operate more efficiently, > possibly at lower cost to the foundation. > > I'm regularly seeing new small benefits (like the Travis CI one) that I > wasn't fully expecting. There has been no downside (other than the time I > spent chatting with INFRA to fix the mailing list notifications and website > rendering, which I didn't mind doing) after changing the hostname. > > If Accumulo moves to GitBox, we should specify in the request: > 1. list to use for PR/comment notifications > 2. list to use for commits > 3. git-based website > 4. JIRA integration (with "worklog" option)
Re: [DISCUSS] GitBox
(Note: CC'd Fluo dev list) Fluo recently switched to GitBox. I figured this experience might be useful to mention if Accumulo decides to do it: Pitfalls: 1. commits and notifications didn't get forwarded to their respective mailing lists properly at first; that was an incubator-specific issue that wouldn't apply if Accumulo moved 2. the website repo stopped updating the website; I believe that has been fixed (but haven't pushed a new website commit to test), and can probably be avoided by mentioning the git-based website in the request to move to GitBox (which I forgot to do) 3. I forgot to update the Jenkins builds for Fluo, so those were broken for a few days; trivial to fix, and Fluo mostly relies on Travis CI instead of Jenkins anyway 4. Since the URL changed, I had to update my ~/.gitconfig settings for the credential.helper with a second credential line, and type in my password once to save it in GNOME keyring daemon the first time I pushed a new commit: [credential] helper = gnome-keyring [credential "https://git-wip-us.apache.org/repos/asf/;] username = ctubbsii [credential "https://gitbox.apache.org/repos/asf/;] username = ctubbsii 5. notifications may come from a different email address, so it may need to be white-listed by the moderators the first time it sends to the list Several benefits (some surprising): 1. Can self-serve Travis CI configuration, because Travis CI grants permissions based on whether you have write permission on the GitHub repo. This was a very cool benefit. We can now clear caches, and set up builds with more control (per-branch, pull requests, etc.) than before, without submitting trivial INFRA tickets. 2. Can assign issues/PRs to individuals as well as use labels, milestones, to make them more searchable; for Accumulo, this would only benefit PRs, because we're not using GH issues. 3. Can close issues. 4. Only the host name changed in the URLs. GitBox is set up exactly like git-wip, so that was very convenient. A simple find/replace was sufficient to update docs and config files with the new host name without changing the path to the repo on that host. 5. When pushing to the server, the git client receives and prints messages about the pre-/post-push actions that the server is doing, like triggering mailing list notifications. I found this to be pleasantly informative, and possibly useful for debugging. 6. A private GitHub team is created in the Apache GitHub organization for the Apache users who have registered their GitHub user name. This means that the whole team can be @mentioned in GitHub by a team member, and team members can more easily find their colleagues on GitHub (only works for those who have opted-in with their GitHub user name). 7. This wouldn't apply to Accumulo, but Fluo was able to close a long-open 1.0.0 milestone that we hadn't been able to close since moving the repo to ASF. In general, this allows milestone management in GitHub (may not ever matter for Accumulo). Unknowns: 1. One thing that's not known is how well the JIRA integration will migrate. I imagine it works fine, but Fluo doesn't use JIRA, so I can't speak to that. Overall: Overall, I think individual developer clones were easy to update, and it didn't seem to inconvenience anybody too much. I emailed the list with a one-liner to update the URL, and that seemed to be appreciated/helpful. (git remote set-url https://gitbox.apache.org/repos/asf/). This wouldn't be necessary if INFRA made the old URL redirect to the new one, but such as it is, they have not done so. The switch enables a lot more self-service, putting things more under the control of the PMC/committers, so INFRA doesn't have to be involved for various minor things. I think this is better for the foundation, because less tedious issue-handling means INFRA can operate more efficiently, possibly at lower cost to the foundation. I'm regularly seeing new small benefits (like the Travis CI one) that I wasn't fully expecting. There has been no downside (other than the time I spent chatting with INFRA to fix the mailing list notifications and website rendering, which I didn't mind doing) after changing the hostname. If Accumulo moves to GitBox, we should specify in the request: 1. list to use for PR/comment notifications 2. list to use for commits 3. git-based website 4. JIRA integration (with "worklog" option) 5. list of repos to move (presumably, all accumulo*) On Fri, Jun 2, 2017 at 3:53 PM Mike Walchwrote: > I would like to revisit the discussion of moving to GitBox but table any > discussion of moving to GitHub issues as there is no consensus. > > I think it would be useful to move to GitBox for the ability to merge and > close pull requests. We currently have several old pull requests on the > Accumulo GitHub page: > > https://github.com/apache/accumulo/pulls > > Some are several years old. We should only keep open PRs that are being > reviewed/worked on.
[DISCUSS] GitBox
Hi all, it looks like https://gitbox.apache.org is up and running. >From what I understand, this provides bi-directional mirroring between GitHub repos and ASF repos, and would allow us to manage GitHub issues and PRs by adding labels and milestones to them. I think Fluo could really benefit from this, especially since we're already using GitHub for issue tracking, and we really need labels and milestones. I think we should put in a request to transition our repos over from the current git service. They have replied to me that they'll work requests on a first-come first-serve basis.