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, 12 Jun 2017 16:17:27 GMT
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 <ctubbsii@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 <ctubbsii@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 <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