accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <md...@mdrob.com>
Subject Re: [DISCUSS] GitBox
Date Fri, 05 May 2017 21:05:18 GMT
>Requiring 2 accounts and unnecessary copy and pasting between
the sites are flaws in the process.
Of note, we don't require anybody to use GitHub.

On Fri, May 5, 2017, 3:15 PM Mike Miller <michaelpmiller@gmail.com> wrote:

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

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