accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] GitBox
Date Mon, 05 Jun 2017 17:45:04 GMT
(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 <mwalch@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 <mjwall@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 <ctubbsii@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 <mwalch@apache.org> wrote:
> > >
> > > > I prefer GithHub issues over JIRA. Apache JIRA is slow, has a bloated
> > UI,
> > > > and it's annoying that it doesn't remember my session and I have to
> > > > re-login daily. I think new developers (esp those unfamiliar with
> > Apache)
> > > > are more likely to report/work on issues if they were on GitHub as
> most
> > > > non-Apache projects use GitHub and Apache JIRA requires an extra
> > account.
> > > > I understand two issue trackers can be pain (esp for the person
> > creating
> > > > release notes) but I would rather encourage more issue reporting and
> > > > contributions then speed up the process of creating release notes. We
> > > could
> > > > also move over the remaining open JIRA issues if GH issues became
> more
> > > > heavily used.
> > > >
> > > > On Fri, May 5, 2017 at 1:09 PM Josh Elser <josh.elser@gmail.com>
> > wrote:
> > > >
> > > > > (just making sure my point is clear and that Mike's is another
> unique
> > > > > point that I hadn't actually considered..)
> > > > >
> > > > > I meant confusion about what information would be encapsulated in
> > JIRA
> > > > > and what information would be encapsulated in GH metadata.
> > > > >
> > > > > e.g. we missed issue $x in the 2.x.x. release notes because it had
> > the
> > > > > "releasenotes" GH label and not a "releasenotes" JIRA label (or
> vice
> > > > > versa). I think a similar issue would come up with "fixVersion" and
> > > > > "milestone".
> > > > >
> > > > > Our use of JIRA is pretty well hashed out, and I think it works
> well
> > > for
> > > > > us. To my earlier point, without a specific hole in our current
> > > process,
> > > > > this just seems likely to create confusion about how to use it. The
> > > > > points you referenced to me don't seem virulent enough to justify
> the
> > > > > switch.
> > > > >
> > > > > Mike Drob wrote:
> > > > > > Changing the repo URL seems fairly disruptive to me, fwiw. Would
> > need
> > > > to
> > > > > > send notice to the dev list with instructions how to update
your
> > git
> > > > > > remotes probably.
> > > > > >
> > > > > > On Fri, May 5, 2017, 10:30 AM Christopher<ctubbsii@apache.org>
> > > wrote:
> > > > > >
> > > > > >> On Fri, May 5, 2017 at 10:50 AM Josh Elser<josh.elser@gmail.com
> >
> > > > > wrote:
> > > > > >>
> > > > > >>>
> > > > > >>> Christopher wrote:
> > > > > >>>> On Thu, May 4, 2017 at 12:09 PM Josh Elser<
> josh.elser@gmail.com
> > >
> > > > > >> wrote:
> > > > > >>>>> Christopher wrote:
> > > > > >>>>>> Hi all, it looks like https://gitbox.apache.org
is up and
> > > > running.
> > > > > >>>>>>
> > > > > >>>>>>    From what I understand, this provides
bi-directional
> > > mirroring
> > > > > >>> between
> > > > > >>>>>> GitHub repos and ASF repos, and would allow
us to manage
> > GitHub
> > > > > >> issues
> > > > > >>>>> and
> > > > > >>>>>> PRs by adding labels and milestones to them.
> > > > > >>>>>>
> > > > > >>>>>> Personally, I think this would be helpful,
especially as we
> > use
> > > > > >> GitHub
> > > > > >>>>> more
> > > > > >>>>>> and more for pull requests / code reviews.
> > > > > >>>>> Github's review interface is my favored method
of code
> review,
> > > but
> > > > it
> > > > > >>>>> seems like you're also suggesting that we adopt
GH issues (or
> > is
> > > > that
> > > > > >>>>> just some passing comment about Gitbox functionality?).
I
> think
> > > our
> > > > > >>>>> current process of JIRA and Github works just
fine.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>> Agreed, it does work fine. I'm not suggesting we
adopt GH
> > issues.
> > > > But,
> > > > > >> if
> > > > > >>>> we ever did, this would be a prerequisite to using
GH issues
> > > > > >> effectively.
> > > > > >>>> I personally prefer GH issues over JIRA, but if
I were to
> > propose
> > > > > that,
> > > > > >>> it
> > > > > >>>> would be after we've adjusted to this switch, and
I would
> > suggest
> > > we
> > > > > do
> > > > > >>> it
> > > > > >>>> gradually and organically... similar to how we transitioned
> from
> > > RB
> > > > to
> > > > > >> GH
> > > > > >>>> for reviews. Technically, we still have RB, but
we just don't
> > use
> > > it
> > > > > >>>> because GH is better.
> > > > > >>>>
> > > > > >>>> In any case, I'm not proposing we start using GH
issues, or
> even
> > > > make
> > > > > >> it
> > > > > >>> an
> > > > > >>>> option, right now. For now, I'm just thinking it
would benefit
> > > > > >> management
> > > > > >>>> of PRs (among the other, lesser, benefits I list).
> > > > > >>> Ok, migrating to GH issues was just a data point for
now.
> > > > > >>>
> > > > > >>>>> What problems do we have as a project which
labels and
> > milestones
> > > > > >> would
> > > > > >>>>> solve? Otherwise, this just seems like change
for change's
> > sake.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>> I think not being able to add labels and milestones
is itself
> a
> > > > > >> problem.
> > > > > >>> It
> > > > > >>>> makes organizing/tracking/searching PRs harder.
Certainly,
> it's
> > > much
> > > > > >>> harder
> > > > > >>>> to navigate to the corresponding JIRA issue (if
one was
> > > mentioned),
> > > > > and
> > > > > >>>> view that information there, rather than simply
see it on the
> PR
> > > > > >> itself.
> > > > > >>> I don't agree with the assessment that it's much harder
to open
> > the
> > > > > JIRA
> > > > > >>> issue in another browser tab, but perhaps that's just
me. I
> think
> > > > > having
> > > > > >>> relevant project tracking information shared across
two
> separate
> > > > > systems
> > > > > >>> is a recipe for disaster.
> > > > > >>>
> > > > > >>>> In addition to label and milestone, it also lets
us use
> > > "assignees",
> > > > > >>> which
> > > > > >>>> I think is useful to track committers who are working
on
> merging
> > > the
> > > > > >> PR,
> > > > > >>>> and "projects", which I don't think is very useful.
> > > > > >>> IMO, someone saying "I'm working on merging this" is
> sufficient.
> > > > > >>>
> > > > > >>>> I think using GitBox would also allow us to close
PRs without
> > > > adding a
> > > > > >>>> dummy commit.
> > > > > >>> Might be nice, but doing a dummy commit or asking the
author to
> > > close
> > > > > it
> > > > > >>> is not onerous.
> > > > > >>>
> > > > > >>>> It would also allow us to push directly to GH and
optionally
> do
> > > > merges
> > > > > >>> and
> > > > > >>>> edits from the GitHub UI, which lowers the bar for
committers
> to
> > > > make
> > > > > >>> small
> > > > > >>>> changes or merge changes. Being able to push directly
to GH
> also
> > > > gives
> > > > > >>> more
> > > > > >>>> options to people who might have a good GH connection,
but a
> > poor
> > > > ASF
> > > > > >>>> connection.
> > > > > >>> That would be nice -- GH does have some nice push-button
> > > integrations
> > > > > >> here.
> > > > > >>>> It also puts us in a good position to self-service
Travis CI
> and
> > > > other
> > > > > >> GH
> > > > > >>>> apps, as GitBox service matures and INFRA provides
more
> > > self-service
> > > > > >>>> features.
> > > > > >>> Thanks for listing these points.
> > > > > >>>
> > > > > >>> I don't see this as having sufficient value to disrupt
our
> > existing
> > > > > >>> workflow. The points you raised are primarily convenience
> issues,
> > > not
> > > > > >>> flaws in our JIRA workflow. Given the overall "low"
activity on
> > the
> > > > > >>> project, I don't see a point in disrupting what has
been
> working
> > > for
> > > > us
> > > > > >>> and what the gray-beards are used to doing.
> > > > > >>>
> > > > > >>>
> > > > > >> I guess I just don't see it as much of a disruption. There's
the
> > > > > switching
> > > > > >> cost, which is pretty small**, but after that, there's not
> really
> > > any
> > > > > >> downside. We wouldn't lose anything, but would gain some
things.
> > > > However
> > > > > >> small they might be, they can add up.
> > > > > >>
> > > > > >> In any case, I'm also fine waiting for now... to see how
GitBox
> > > > matures.
> > > > > >> This is actually far more important for Fluo (which uses
GH
> > issues)
> > > > than
> > > > > >> for Accumulo. I opened a similar discussion on the Fluo
dev
> list,
> > > and
> > > > if
> > > > > >> Fluo switches to GitBox, we can provide feedback here to
how it
> > all
> > > > > worked
> > > > > >> out, if we want to revisit this later.
> > > > > >>
> > > > > >> **Just a change in URL for the repo for anybody not actively
> > > involved
> > > > in
> > > > > >> working with INFRA to make the switch happen.
> > > > > >>
> > > > > >>
> > > > > >>>>>> If we want to use this, we can put in requests
to INFRA to
> > move
> > > > our
> > > > > >>> repos
> > > > > >>>>>> over to this service rather than the current
git service.
> > > > > >>>>>>
> > > > > >>>>>> INFRA has responded to my question saying
they'll support
> use
> > of
> > > > > this
> > > > > >>> on
> > > > > >>>>> a
> > > > > >>>>>> first-come first-serve basis. I think it
might be worth it.
> > Some
> > > > of
> > > > > >> the
> > > > > >>>>>> transition might be self service (GitBox
allows PMCs to set
> up
> > > > their
> > > > > >>> own
> > > > > >>>>>> repos), but at the very least, we'd have
to request INFRA to
> > add
> > > > our
> > > > > >>> PMC
> > > > > >>>>> to
> > > > > >>>>>> the list of participating projects and have
them remove the
> > old
> > > > one
> > > > > >>> once
> > > > > >>>>>> the transition is complete.
> > > > > >>>>>>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message