accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: [DISCUSS] GitBox
Date Fri, 05 May 2017 17:09:39 GMT
(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 

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 

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<>  wrote:
>> On Fri, May 5, 2017 at 10:50 AM Josh Elser<>  wrote:
>>> Christopher wrote:
>>>> On Thu, May 4, 2017 at 12:09 PM Josh Elser<>
>> wrote:
>>>>> Christopher wrote:
>>>>>> Hi all, it looks like 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
>>> on
>>>>> a
>>>>>> first-come first-serve basis. I think it might be worth it. Some
>> 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
>>> PMC
>>>>> to
>>>>>> the list of participating projects and have them remove the old one
>>> once
>>>>>> the transition is complete.

View raw message