>Requiring 2 accounts and unnecessary copy and pasting between the sites are flaws in the process. Of note, we don't require anybody to use GitHub.
On Fri, May 5, 2017, 3:15 PM Mike Miller <michaelpmil...@gmail.com> wrote: > I think there are many benefits already mentioned that would make it worth > the switch. I would add frames to the list of annoyances in JIRA. > > > I think having relevant project tracking information shared across two > separate systems is a recipe for disaster. > > This sounds like our current setup... GitHub + JIRA no? If we had an easy > to migrate open issues than JIRA just becomes an archive. Might be a good > chance to clean up old tickets too. > > > 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 would argue this as a reason to switch - more convenience for new > developers should be a priority over propagating the habits of current > developers. > > > without a specific hole in our current process, this just seems likely to > create confusion about how to use it. > > I agree, there would be confusion at first and an adjustment period (like > any change would require). I would also agree there aren't holes in the > current process but this change wouldn't fill a hole, it would fix flaws in > the process. Requiring 2 accounts and unnecessary copy and pasting between > the sites are flaws in the process. > > Does GitHub issues have custom filters? If not, then that is one thing we > would lose. But these may not be needed if it just works better. > > On Fri, May 5, 2017 at 1:34 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. > > > >>>>>> > > > > > > > > > >
