accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <>
Subject Re: [DISCUSS] Switch to GitHub issues after trial
Date Fri, 16 Feb 2018 01:51:56 GMT
The move from SVN to GIT had a clear plan for what happens to the old code,
and a migration strategy for moving commits over.

I think we're having trouble communicating here, but I'm really coming at
this from the perspective of "what if this is fabulously successful" - I
don't want to be seen as the curmudgeon impeding community because this is
how things were back in my day or whatever.

Let's say we do a trial. Let's say that everybody loves it, everybody
becomes 2x more productive, we get 3x more new contributors, whatever. All
good things!

Some of the concerns brought up would be answerable with a trial. How do we
do a release? What does aggregating issues fixed in a particular version
look like? Sure, I'm fine with people not knowing now, and giving a
concrete answer as to how a trial would help them figure this out.

A trial would also answer how we handle security issues - JIRA can make
certain issues only visible to PMC. Is there a GH issues equivalent?
Probably. Do I want to discover that there isn't a way to do this in three
years when somebody privately reports one? Absolutely not. This should
actually be answerable before the trial, but is something that should be
tested during. I assume there's a workable solution, but we need to know
what it is.

Some issues are not answerable with a trial, however. What happens to our
old issues? Do we close them as Won't Fix? Do we migrate them? Do we lock
JIRA and leave the archives up as a historical reference? If there is some
aspect of a trial that would answer this, then I'm all ears.

Again, I'm not trying to fight growth here. I'm assuming that switching
will be a given once the trial gets off the ground. I know that those
advocating for it already like GH Issues, otherwise they wouldn't be
proposing this change. My questions are all of the nature, "after we
switch, what do we do with [current process X]?"


On Thu, Feb 15, 2018 at 7:26 PM, Mike Walch <> wrote:

> I want step back a little. I don't view this as just changing our issue
> tracker. I want to move to GitHub issues as I see a lot of benefit in using
> one tool to manage issues, view/browse code, and review pull requests.  One
> tool makes contributing to open source so much easier.  I think it will
> become the norm over time. This doesn't mean projects need to be locked
> into GitHub. Gitlab provides the same thing. I understand there are
> switching costs so I am on board with a trial. However, I think the
> benefits are worth the switch. You can fight this trend but I think it's
> like fighting the move from Subversion to Git.
> On Thu, Feb 15, 2018 at 7:04 PM, Josh Elser <> wrote:
> > On 2/15/18 6:18 PM, Christopher wrote:
> >
> >> On Thu, Feb 15, 2018 at 5:08 PM Josh Elser <> wrote:
> >>
> >> On 2/15/18 4:56 PM, Christopher wrote:
> >>>
> >>>> On Thu, Feb 15, 2018 at 4:55 PM Josh Elser <>
> >>>>
> >>>> On 2/15/18 4:17 PM, Mike Drob wrote:
> >>>>>
> >>>>>> What do we do if the trial is wildly successful? Is there a
> migration
> >>>>>>>>
> >>>>>>> plan
> >>>>>>>
> >>>>>>>> for our currently open issues? We have almost 1000 of
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> As Keith said in the other thread, we don't need to
have all the
> >>>>>>>
> >>>>>> answers up
> >>>>>
> >>>>>> front.
> >>>>>>>
> >>>>>>> You're right, we don't need to have all of the answers up
> >>>>>> This is one that I'd like to have some thought put into though.
> >>>>>>
> >>>>>> There's lots of things that are fine to handle as we approach
> but
> >>>>>>
> >>>>> this
> >>>>>
> >>>>>> one seems like it will lead to us having split issue trackers
> >>>>>>
> >>>>> for_years_
> >>>
> >>>> down the road.
> >>>>>>
> >>>>>>
> >>>>> This is a good point I hadn't yet considered.
> >>>>>
> >>>>> There's not only the migration question that eventually needs to
> >>>>> answered, but an immediate question of how will we determine when
> >>>>> can
> >>>>> release a version of Accumulo? Are there conventions/features on
> GH
> >>>>> issues side that will provide some logical analog to the fixVersion
> of
> >>>>> JIRA?
> >>>>>
> >>>>>
> >>>> These are all great questions... that could be answered with a
> trial...
> >>>>
> >>>>
> >>> Shall I assume then that you are volunteering to handle all issue
> >>> management across the disparate systems for all releases?
> >>>
> >>> A trial is a good idea to determine _if we like the system_ and want to
> >>> migrate to it. It's not a substitute for determining if the system is
> >>> _viable_.
> >>>
> >>>
> >> I'm of a different opinion: I already know I like GitHub issues and want
> >> to
> >> migrate to it. What I don't know is if it is viable for Accumulo's
> needs.
> >>
> >
> >
> > Glad you like GH issues, but that isn't not what is being discussed here.
> > The matter at hand is figuring out the logistics of *how* do we move to a
> > different issue tracker in a manner that doesn't derail the project
> > management of a fully-distributed team.
> >
> > I'm worried because I feel like there are valid concerns being brought up
> > here without acknowledgement of the impact of those who only participate
> > with Accumulo digitally.
> >

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