Did not intend that last message to go to Fluo list. Fluo list removed from recipients.
On Mon, Jun 12, 2017 at 12:16 PM Christopher <ctubb...@apache.org> wrote: > 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 Christopher <ctubb...@apache.org> wrote: > >> (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 <apache-remote> >> https://gitbox.apache.org/repos/asf/<repo>). 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 Walch <mwa...@apache.org> wrote: >> >>> 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. However, PRs can only be closed by the person that >>> created it or by pushing an empty commit that closes them. With GitBox, >>> committers could close them on GitHub. >>> >>> GitBox would also be useful for the Accumulo-website Github page now. For >>> 2.0, each documentation page has an "Edit this page" link. See the page >>> below for an example: >>> >>> https://accumulo.apache.org/docs/unreleased/getting-started/design >>> >>> This will hopefully lead to more PRs from users as the "Edit this page" >>> link directs you to GitHub where can you to edit the markdown and submit >>> a >>> pull request without leaving GitHub. When 2.0 gets released, it would >>> nice >>> to be able to merge/close these PRs too. >>> >>> On Thu, May 11, 2017 at 8:41 AM Michael Wall <mjw...@gmail.com> wrote: >>> >>> > Late to this thread, but wanted to offer my 2 cents. Having done >>> several >>> > releases, the search and bulk edit features of Jira were really key. >>> > Moving all those issues is really the worst part of doing a release, >>> > because you have to open each one and try to understand enough about >>> it to >>> > make a decision. Some tickets are assigned to 1.7, 1.8 and 2.0, some >>> are >>> > 1.8 and 2.0, some were only 1.8. You have to bulk edit each distinct >>> > combination. I am unsure what the GH would be except to edit them 1 by >>> 1. >>> > Although if we cleaned up old issues it wouldn't be as big a deal. >>> > >>> > I would be willing to try it out better GH integration. I love the PR >>> > review. >>> > >>> > Mike >>> > >>> > On Fri, May 5, 2017 at 7:54 PM Christopher <ctubb...@apache.org> >>> wrote: >>> > >>> > > I agree with Mike here, but to be clear, that's not what I was >>> proposing. >>> > > :) >>> > > >>> > > On Fri, May 5, 2017 at 1:35 PM Mike Walch <mwa...@apache.org> wrote: >>> > > >>> > > > I prefer GithHub issues over JIRA. Apache JIRA is slow, has a >>> bloated >>> > UI, >>> > > > and it's annoying that it doesn't remember my session and I have to >>> > > > re-login daily. I think new developers (esp those unfamiliar with >>> > Apache) >>> > > > are more likely to report/work on issues if they were on GitHub as >>> most >>> > > > non-Apache projects use GitHub and Apache JIRA requires an extra >>> > account. >>> > > > I understand two issue trackers can be pain (esp for the person >>> > creating >>> > > > release notes) but I would rather encourage more issue reporting >>> and >>> > > > contributions then speed up the process of creating release notes. >>> We >>> > > could >>> > > > also move over the remaining open JIRA issues if GH issues became >>> more >>> > > > heavily used. >>> > > > >>> > > > On Fri, May 5, 2017 at 1:09 PM Josh Elser <josh.el...@gmail.com> >>> > wrote: >>> > > > >>> > > > > (just making sure my point is clear and that Mike's is another >>> unique >>> > > > > point that I hadn't actually considered..) >>> > > > > >>> > > > > I meant confusion about what information would be encapsulated in >>> > JIRA >>> > > > > and what information would be encapsulated in GH metadata. >>> > > > > >>> > > > > e.g. we missed issue $x in the 2.x.x. release notes because it >>> had >>> > the >>> > > > > "releasenotes" GH label and not a "releasenotes" JIRA label (or >>> vice >>> > > > > versa). I think a similar issue would come up with "fixVersion" >>> and >>> > > > > "milestone". >>> > > > > >>> > > > > Our use of JIRA is pretty well hashed out, and I think it works >>> well >>> > > for >>> > > > > us. To my earlier point, without a specific hole in our current >>> > > process, >>> > > > > this just seems likely to create confusion about how to use it. >>> The >>> > > > > points you referenced to me don't seem virulent enough to >>> justify the >>> > > > > switch. >>> > > > > >>> > > > > Mike Drob wrote: >>> > > > > > Changing the repo URL seems fairly disruptive to me, fwiw. >>> Would >>> > need >>> > > > to >>> > > > > > send notice to the dev list with instructions how to update >>> your >>> > git >>> > > > > > remotes probably. >>> > > > > > >>> > > > > > On Fri, May 5, 2017, 10:30 AM Christopher<ctubb...@apache.org> >>> > > wrote: >>> > > > > > >>> > > > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser< >>> josh.el...@gmail.com> >>> > > > > wrote: >>> > > > > >> >>> > > > > >>> >>> > > > > >>> Christopher wrote: >>> > > > > >>>> On Thu, May 4, 2017 at 12:09 PM Josh Elser< >>> josh.el...@gmail.com >>> > > >>> > > > > >> wrote: >>> > > > > >>>>> Christopher wrote: >>> > > > > >>>>>> 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. >>> > > > > >>>>>> >>> > > > > >>>>>> Personally, I think this would be helpful, especially as >>> we >>> > use >>> > > > > >> GitHub >>> > > > > >>>>> more >>> > > > > >>>>>> and more for pull requests / code reviews. >>> > > > > >>>>> Github's review interface is my favored method of code >>> review, >>> > > but >>> > > > it >>> > > > > >>>>> seems like you're also suggesting that we adopt GH issues >>> (or >>> > is >>> > > > that >>> > > > > >>>>> just some passing comment about Gitbox functionality?). I >>> think >>> > > our >>> > > > > >>>>> current process of JIRA and Github works just fine. >>> > > > > >>>>> >>> > > > > >>>>> >>> > > > > >>>> Agreed, it does work fine. I'm not suggesting we adopt GH >>> > issues. >>> > > > But, >>> > > > > >> if >>> > > > > >>>> we ever did, this would be a prerequisite to using GH issues >>> > > > > >> effectively. >>> > > > > >>>> I personally prefer GH issues over JIRA, but if I were to >>> > propose >>> > > > > that, >>> > > > > >>> it >>> > > > > >>>> would be after we've adjusted to this switch, and I would >>> > suggest >>> > > we >>> > > > > do >>> > > > > >>> it >>> > > > > >>>> gradually and organically... similar to how we transitioned >>> from >>> > > RB >>> > > > to >>> > > > > >> GH >>> > > > > >>>> for reviews. Technically, we still have RB, but we just >>> don't >>> > use >>> > > it >>> > > > > >>>> because GH is better. >>> > > > > >>>> >>> > > > > >>>> In any case, I'm not proposing we start using GH issues, or >>> even >>> > > > make >>> > > > > >> it >>> > > > > >>> an >>> > > > > >>>> option, right now. For now, I'm just thinking it would >>> benefit >>> > > > > >> management >>> > > > > >>>> of PRs (among the other, lesser, benefits I list). >>> > > > > >>> Ok, migrating to GH issues was just a data point for now. >>> > > > > >>> >>> > > > > >>>>> What problems do we have as a project which labels and >>> > milestones >>> > > > > >> would >>> > > > > >>>>> solve? Otherwise, this just seems like change for change's >>> > sake. >>> > > > > >>>>> >>> > > > > >>>>> >>> > > > > >>>> I think not being able to add labels and milestones is >>> itself a >>> > > > > >> problem. >>> > > > > >>> It >>> > > > > >>>> makes organizing/tracking/searching PRs harder. Certainly, >>> it's >>> > > much >>> > > > > >>> harder >>> > > > > >>>> to navigate to the corresponding JIRA issue (if one was >>> > > mentioned), >>> > > > > and >>> > > > > >>>> view that information there, rather than simply see it on >>> the PR >>> > > > > >> itself. >>> > > > > >>> I don't agree with the assessment that it's much harder to >>> open >>> > the >>> > > > > JIRA >>> > > > > >>> issue in another browser tab, but perhaps that's just me. I >>> think >>> > > > > having >>> > > > > >>> relevant project tracking information shared across two >>> separate >>> > > > > systems >>> > > > > >>> is a recipe for disaster. >>> > > > > >>> >>> > > > > >>>> In addition to label and milestone, it also lets us use >>> > > "assignees", >>> > > > > >>> which >>> > > > > >>>> I think is useful to track committers who are working on >>> merging >>> > > the >>> > > > > >> PR, >>> > > > > >>>> and "projects", which I don't think is very useful. >>> > > > > >>> IMO, someone saying "I'm working on merging this" is >>> sufficient. >>> > > > > >>> >>> > > > > >>>> I think using GitBox would also allow us to close PRs >>> without >>> > > > adding a >>> > > > > >>>> dummy commit. >>> > > > > >>> Might be nice, but doing a dummy commit or asking the author >>> to >>> > > close >>> > > > > it >>> > > > > >>> is not onerous. >>> > > > > >>> >>> > > > > >>>> It would also allow us to push directly to GH and >>> optionally do >>> > > > merges >>> > > > > >>> and >>> > > > > >>>> edits from the GitHub UI, which lowers the bar for >>> committers to >>> > > > make >>> > > > > >>> small >>> > > > > >>>> changes or merge changes. Being able to push directly to GH >>> also >>> > > > gives >>> > > > > >>> more >>> > > > > >>>> options to people who might have a good GH connection, but a >>> > poor >>> > > > ASF >>> > > > > >>>> connection. >>> > > > > >>> That would be nice -- GH does have some nice push-button >>> > > integrations >>> > > > > >> here. >>> > > > > >>>> It also puts us in a good position to self-service Travis >>> CI and >>> > > > other >>> > > > > >> GH >>> > > > > >>>> apps, as GitBox service matures and INFRA provides more >>> > > self-service >>> > > > > >>>> features. >>> > > > > >>> Thanks for listing these points. >>> > > > > >>> >>> > > > > >>> I don't see this as having sufficient value to disrupt our >>> > existing >>> > > > > >>> workflow. The points you raised are primarily convenience >>> issues, >>> > > not >>> > > > > >>> flaws in our JIRA workflow. Given the overall "low" activity >>> on >>> > the >>> > > > > >>> project, I don't see a point in disrupting what has been >>> working >>> > > for >>> > > > us >>> > > > > >>> and what the gray-beards are used to doing. >>> > > > > >>> >>> > > > > >>> >>> > > > > >> I guess I just don't see it as much of a disruption. There's >>> the >>> > > > > switching >>> > > > > >> cost, which is pretty small**, but after that, there's not >>> really >>> > > any >>> > > > > >> downside. We wouldn't lose anything, but would gain some >>> things. >>> > > > However >>> > > > > >> small they might be, they can add up. >>> > > > > >> >>> > > > > >> In any case, I'm also fine waiting for now... to see how >>> GitBox >>> > > > matures. >>> > > > > >> This is actually far more important for Fluo (which uses GH >>> > issues) >>> > > > than >>> > > > > >> for Accumulo. I opened a similar discussion on the Fluo dev >>> list, >>> > > and >>> > > > if >>> > > > > >> Fluo switches to GitBox, we can provide feedback here to how >>> it >>> > all >>> > > > > worked >>> > > > > >> out, if we want to revisit this later. >>> > > > > >> >>> > > > > >> **Just a change in URL for the repo for anybody not actively >>> > > involved >>> > > > in >>> > > > > >> working with INFRA to make the switch happen. >>> > > > > >> >>> > > > > >> >>> > > > > >>>>>> If we want to use this, we can put in requests to INFRA to >>> > move >>> > > > our >>> > > > > >>> repos >>> > > > > >>>>>> over to this service rather than the current git service. >>> > > > > >>>>>> >>> > > > > >>>>>> INFRA has responded to my question saying they'll support >>> use >>> > of >>> > > > > this >>> > > > > >>> on >>> > > > > >>>>> a >>> > > > > >>>>>> first-come first-serve basis. I think it might be worth >>> it. >>> > Some >>> > > > of >>> > > > > >> the >>> > > > > >>>>>> transition might be self service (GitBox allows PMCs to >>> set up >>> > > > their >>> > > > > >>> own >>> > > > > >>>>>> repos), but at the very least, we'd have to request INFRA >>> to >>> > add >>> > > > our >>> > > > > >>> PMC >>> > > > > >>>>> to >>> > > > > >>>>>> the list of participating projects and have them remove >>> the >>> > old >>> > > > one >>> > > > > >>> once >>> > > > > >>>>>> the transition is complete. >>> > > > > >>>>>> >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> >>
