Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
References: <CAL5zq9b0t9gT=JH+Ata1BrpB=gT=-bJXReXpjmbCTrAm15FbTQ@mail.gmail.com>
 <590B5230.6030000@gmail.com> <CAL5zq9ZU7x7cGL2KQxPBzVnx_rtAtfqvVrrCkWw9PMhbmSperQ@mail.gmail.com>
 <590C9134.1070605@gmail.com> <CAL5zq9bL-qzBGUNojjVNpHh_CyJ6mX6t7XKkoQW_OP_7kq2WPQ@mail.gmail.com>
 <CAJRvFdo79LczcamVkg=Mxk=jK==kMVF+FRp+m5-qeiH4fk25aw@mail.gmail.com>
 <590CB1D3.9030008@gmail.com> <CAL4xCs=WQujWD952xDJhpNs2e0bKZt5yk_usm0emWFr71+AwXg@mail.gmail.com>
 <CALs6Wtu-1oaWWsjAS7V2tK6H-OeebV9RC_0D2jTPP9-bfKZzmQ@mail.gmail.com> <CAJRvFdpCbf9St+bVhwz--tz3BKMuMY5TQS3TcTXJ+7V5NVPVmg@mail.gmail.com>
In-Reply-To: <CAJRvFdpCbf9St+bVhwz--tz3BKMuMY5TQS3TcTXJ+7V5NVPVmg@mail.gmail.com>
From: Mike Drob <mdrob@mdrob.com>
Date: Fri, 05 May 2017 21:22:15 +0000
Message-ID: <CAJRvFdpO6M=e9YAT6-3jhB5TUDK3Ru2dKELW7W1nyJwgM1rFWw@mail.gmail.com>
Subject: Re: [DISCUSS] GitBox
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=94eb2c0654fc739bf3054ecd7c33
archived-at: Fri, 05 May 2017 21:22:32 -0000

--94eb2c0654fc739bf3054ecd7c33
Content-Type: text/plain; charset=UTF-8

In case this wasn't clear earlier, I'm currently against this move. It
sounds like change for the sake of change.

Sure, JIRA has some bloat but it is also very useful. Do GH issues support
bulk edit of version field to move out everything that doesn't make a
release deadline? The way to convince me is probably to look up our JIRA
downtime vs GH downtime for the past month or year.
Mike D

On Fri, May 5, 2017, 4:05 PM Mike Drob <mdrob@mdrob.com> wrote:

> >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 <michaelpmiller@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 <mwalch@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.elser@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<ctubbsii@apache.org>
>> wrote:
>> > > >
>> > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser<josh.elser@gmail.com>
>> > > wrote:
>> > > >>
>> > > >>>
>> > > >>> Christopher wrote:
>> > > >>>> On Thu, May 4, 2017 at 12:09 PM Josh Elser<josh.elser@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.
>> > > >>>>>>
>> > > >
>> > >
>> >
>>
>

--94eb2c0654fc739bf3054ecd7c33--