[DISCUSS] GitBox

[Christopher <ct...@apache.org>]

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.

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.

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

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 <ct...@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 <ct...@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 <mw...@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 <mj...@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 <ct...@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 <mw...@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 <jo...@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<ct...@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.
>>> > > > > >>>>>>
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

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 <ct...@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 <mw...@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 <mj...@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 <ct...@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 <mw...@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 <jo...@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<ct...@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.
>> > > > > >>>>>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

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 <ct...@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 <mw...@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 <mj...@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 <ct...@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 <mw...@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 <jo...@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<ct...@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.
>> > > > > >>>>>>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

(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 <mw...@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 <mj...@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 <ct...@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 <mw...@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 <jo...@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<ct...@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.
> > > > > >>>>>>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

(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 <mw...@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 <mj...@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 <ct...@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 <mw...@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 <jo...@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<ct...@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.
> > > > > >>>>>>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] GitBox

[Mike Walch <mw...@apache.org>]

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 <mj...@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 <ct...@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 <mw...@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 <jo...@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<ct...@apache.org>
> > wrote:
> > > > >
> > > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser<jo...@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.
> > > > >>>>>>
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] GitBox

[Michael Wall <mj...@gmail.com>]

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

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

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

Re: [DISCUSS] GitBox

[Mike Drob <md...@mdrob.com>]

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 <md...@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 <mi...@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 <mw...@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 <jo...@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<ct...@apache.org>
>> wrote:
>> > > >
>> > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser<jo...@gmail.com>
>> > > wrote:
>> > > >>
>> > > >>>
>> > > >>> Christopher wrote:
>> > > >>>> On Thu, May 4, 2017 at 12:09 PM Josh Elser<jo...@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.
>> > > >>>>>>
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] GitBox

[Mike Drob <md...@mdrob.com>]

>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 <mi...@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 <mw...@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 <jo...@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<ct...@apache.org>
> wrote:
> > > >
> > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser<jo...@gmail.com>
> > > wrote:
> > > >>
> > > >>>
> > > >>> Christopher wrote:
> > > >>>> On Thu, May 4, 2017 at 12:09 PM Josh Elser<jo...@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.
> > > >>>>>>
> > > >
> > >
> >
>

Re: [DISCUSS] GitBox

[Josh Elser <jo...@gmail.com>]

Mike Miller 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.

No, GH is only supplementary. JIRA is the "source system" for tracking 
Accumulo as a project. But, this isn't a discussion about switching to 
Github issues, as Christopher clarified earlier. That's a whole other 
can of worms I definitely don't want to open.

If a transition to Gitbox is paving the way to move to issues, that's a 
different issue. I'd have more concerns WRT how we do project mgmt in 
that case.

>> >  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.

As a gray-beard, I don't really have much other ability than to just 
disagree with you on this point.

>> >  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.

... what flaws? All I've seen so far are UX complaints. Have I failed to 
grasp something? What copy-pasting are you referring to?

Re: [DISCUSS] GitBox

[Mike Miller <mi...@gmail.com>]

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

Re: [DISCUSS] GitBox

[Mike Walch <mw...@apache.org>]

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

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

On Fri, May 5, 2017 at 1:09 PM Josh Elser <jo...@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.
>
>
I agree with your point about confusion, and about our current workflow
working well for us as is. But, I'm always looking for opportunities to
improve. The way I saw it was that these features wouldn't be changing our
workflow, but adding to it, providing us with the opportunity to experiment
and discover new things which could benefit our workflow. (But also, I just
wanted to query PRs.)

I don't want to force our workflow to change. That's why I didn't suggest
any changes to it, such as using GH issues or any specific labeling scheme.
I don't have data on what would work yet. I actually spend a lot of time
reinforcing our existing workflow by triage'ing JIRA issues daily and,
recently, reminding people to close JIRA issues when PR work is done. So,
I'm certainly not interested in arbitrarily disrupting the workflow which
works. But, I don't want us to stagnate and cut ourselves off from
opportunities to evolve our workflow organically, either.

Like I said, I'm fine with waiting until GitBox matures a bit. I don't
query PRs often enough for that to be a sticking point, and obviously,
there isn't consensus yet on whether the opportunity to experiment with
these features outweighs the disruption of the URL change.

Personally, I'd prefer INFRA just automatically move *all* git projects to
GitBox, so everybody automatically benefits, and nobody is negatively
impacted at all (assuming URL redirects are put in place to keep things
working seamlessly). But, I don't think they're going to do that. (I asked,
but no response from infra yet about its plans.)

Re: [DISCUSS] GitBox

[Josh Elser <jo...@gmail.com>]

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

Re: [DISCUSS] GitBox

[Mike Drob <md...@apache.org>]

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 <ct...@apache.org> wrote:

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

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

On Fri, May 5, 2017 at 10:50 AM Josh Elser <jo...@gmail.com> wrote:

>
>
> Christopher wrote:
> > On Thu, May 4, 2017 at 12:09 PM Josh Elser<jo...@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.
> >>>
> >
>

Re: [DISCUSS] GitBox

[Josh Elser <jo...@gmail.com>]

Christopher wrote:
> On Thu, May 4, 2017 at 12:09 PM Josh Elser<jo...@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.

>>> 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.
>>>
>

Re: [DISCUSS] GitBox

[Christopher <ct...@apache.org>]

On Thu, May 4, 2017 at 12:09 PM Josh Elser <jo...@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).



> 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.

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.

I think using GitBox would also allow us to close PRs without adding a
dummy commit.

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.

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.



>
> > 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.
> >
>

Re: [DISCUSS] GitBox

[Josh Elser <jo...@gmail.com>]

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.

What problems do we have as a project which labels and milestones would 
solve? Otherwise, this just seems like change for change's sake.

> 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.
>