Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

2018-06-27 Thread James Sirota 
Thank you, Justin.  Great job on the merge 

26.06.2018, 14:20, "Justin Leet" :
> The Solr feature branch is in now in master. Note that there is no
> METRON-1416 commit in the logs because all subtasks are committed under
> their own JIRA and are in the history to maintain attribution.
>
> On Tue, Jun 26, 2018 at 1:26 PM Otto Fowler  wrote:
>
>>  +1
>>
>>  On June 26, 2018 at 11:43:39, Justin Leet (justinjl...@gmail.com) wrote:
>>
>>  The PR has two +1's at this point (and I'm implicitly +1). In the interest
>>  of full disclosure, both are from people who made contributions of varying
>>  degrees to the branch.
>>
>>  Are there any objections to merging the feature branch into master at this
>>  point?
>>
>>  On Fri, Jun 22, 2018 at 1:12 PM Justin Leet  wrote:
>>
>>>  That's more or less why I didn't flesh out testing. Might be worth
>>>  spinning up full dev and the site-book to smoke test, but the branch should
>>>  be in a good state. I figured if we get a couple +1's on the PR, it's
>>>  essentially voting anyway, but this is pretty new in terms of process.
>>>
>>>  On Fri, Jun 22, 2018 at 12:53 PM Otto Fowler 
>>>  wrote:
>>>
  If all the PR’s are on master->feature branch. Why do we need testing?
  this is almost a vote situation.

  On June 22, 2018 at 12:01:11, Justin Leet (justinjl...@gmail.com) wrote:

  The (formerly) active PRs are now merged in and closed.

  We don't seem to have defined way to merge a feature branch into master
  (unless I missed it), so I went ahead and opened a PR against the parent
  ticket. Please see #1076 .

  I haven't fleshed out testing and so on for the PR description, although
  if
  we'd like it compiled from the various child PRs against the branch, I
  can
  certainly do so.

  Justin

  On Thu, Jun 21, 2018 at 6:46 PM Michael Miklavcic <
  michael.miklav...@gmail.com> wrote:

  > +1 let's do it.
  >
  > On Thu, Jun 21, 2018, 2:01 PM Nick Allen  wrote:
  >
  > > +1 I think we should merge ASAP and kill the feature branch. I think
  the
  > > work has well surpassed the level required to get it into master.
  > >
  > > On Thu, Jun 21, 2018 at 1:20 PM, Justin Leet 
  > > wrote:
  > >
  > > > Hi All,
  > > >
  > > > The Solr branch (/feature/METRON-1416-upgrade-solr
  > > > <
  > https://github.com/apache/metron/tree/feature/METRON-1416-upgrade-solr
  > > >),
  > > > has been progressing for a while now. I'd like to open up
  discussion
  > > > around what it takes to get it into master.
  > > >
  > > > The JIRA for tracking this feature branch is METRON-1416
  > > > .
  > > >
  > > > As shown in the JIRA, the majority of tasks are complete, with a
  few
  > > > outstanding issues. Of these, I believe these are the main ones of
  > > interest
  > > > to this discussion.
  > > >
  > > > - METRON-1629 
  -
  > > > There is an active PR #1072 <
  > > https://github.com/apache/metron/pull/1072
  > > > >
  > > > - METRON-1609 
  -
  > > > There is an active PR #1056 <
  > > https://github.com/apache/metron/pull/1056
  > > > >
  > > > - METRON-1602 
  -
  > > > Full
  > > > dev can run with Solr without this, it would simply be more
  > > convenient.
  > > > - METRON-1632 
  -
  > > > Causes a metaalert specific issue where UI filtering on
  > > > source.type:metaalert fails. More detail is on the Jira.
  > > > - Two validation tickets. It's been run up on multinode, and manual
  > > > testing has happened (and I'm will be seen a bit more on the final
  > PR
  > > by
  > > > various reviewers), so I'm inclined to just leave these open until
  > > we're
  > > > good to go. Let me know if we want to handle this differently.
  > > >
  > > > I'm of the opinion both of the active PRs need to be merged before
  we
  > > merge
  > > > this into master, especially the documentation one. The other two
  > > tickets
  > > > can be done in the future; one can be worked around and one is a
  > > metaalert
  > > > specific issue that primarily effects the alerts UI.
  > > >
  > > > As the branch has grown and diverged from master, it's gotten
  > > increasingly
  > > > unwieldy to maintain (and I think it's worth a follow-on discussion
  > about
  > > > how we manage refactorings that happen in these sorts of
  branches). I
  > > know
  > > > there's been at least a couple merges from master that have been

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

2018-06-26 Thread Justin Leet 
The Solr feature branch is in now in master.  Note that there is no
METRON-1416 commit in the logs because all subtasks are committed under
their own JIRA and are in the history to maintain attribution.

On Tue, Jun 26, 2018 at 1:26 PM Otto Fowler  wrote:

> +1
>
>
> On June 26, 2018 at 11:43:39, Justin Leet (justinjl...@gmail.com) wrote:
>
> The PR has two +1's at this point (and I'm implicitly +1). In the interest
> of full disclosure, both are from people who made contributions of varying
> degrees to the branch.
>
> Are there any objections to merging the feature branch into master at this
> point?
>
> On Fri, Jun 22, 2018 at 1:12 PM Justin Leet  wrote:
>
>> That's more or less why I didn't flesh out testing.  Might be worth
>> spinning up full dev and the site-book to smoke test, but the branch should
>> be in a good state.  I figured if we get a couple +1's on the PR, it's
>> essentially voting anyway, but this is pretty new in terms of process.
>>
>>
>>
>> On Fri, Jun 22, 2018 at 12:53 PM Otto Fowler 
>> wrote:
>>
>>> If all the PR’s are on master->feature branch.  Why do we need testing?
>>> this is almost a vote situation.
>>>
>>>
>>>
>>>
>>> On June 22, 2018 at 12:01:11, Justin Leet (justinjl...@gmail.com) wrote:
>>>
>>> The (formerly) active PRs are now merged in and closed.
>>>
>>> We don't seem to have defined way to merge a feature branch into master
>>> (unless I missed it), so I went ahead and opened a PR against the parent
>>> ticket. Please see #1076 .
>>>
>>> I haven't fleshed out testing and so on for the PR description, although
>>> if
>>> we'd like it compiled from the various child PRs against the branch, I
>>> can
>>> certainly do so.
>>>
>>> Justin
>>>
>>> On Thu, Jun 21, 2018 at 6:46 PM Michael Miklavcic <
>>> michael.miklav...@gmail.com> wrote:
>>>
>>> > +1 let's do it.
>>> >
>>> > On Thu, Jun 21, 2018, 2:01 PM Nick Allen  wrote:
>>> >
>>> > > +1 I think we should merge ASAP and kill the feature branch. I think
>>> the
>>> > > work has well surpassed the level required to get it into master.
>>> > >
>>> > > On Thu, Jun 21, 2018 at 1:20 PM, Justin Leet 
>>> > > wrote:
>>> > >
>>> > > > Hi All,
>>> > > >
>>> > > > The Solr branch (/feature/METRON-1416-upgrade-solr
>>> > > > <
>>> > https://github.com/apache/metron/tree/feature/METRON-1416-upgrade-solr
>>> > > >),
>>> > > > has been progressing for a while now. I'd like to open up
>>> discussion
>>> > > > around what it takes to get it into master.
>>> > > >
>>> > > > The JIRA for tracking this feature branch is METRON-1416
>>> > > > .
>>> > > >
>>> > > > As shown in the JIRA, the majority of tasks are complete, with a
>>> few
>>> > > > outstanding issues. Of these, I believe these are the main ones of
>>> > > interest
>>> > > > to this discussion.
>>> > > >
>>> > > > - METRON-1629 
>>> -
>>> > > > There is an active PR #1072 <
>>> > > https://github.com/apache/metron/pull/1072
>>> > > > >
>>> > > > - METRON-1609 
>>> -
>>> > > > There is an active PR #1056 <
>>> > > https://github.com/apache/metron/pull/1056
>>> > > > >
>>> > > > - METRON-1602 
>>> -
>>> > > > Full
>>> > > > dev can run with Solr without this, it would simply be more
>>> > > convenient.
>>> > > > - METRON-1632 
>>> -
>>> > > > Causes a metaalert specific issue where UI filtering on
>>> > > > source.type:metaalert fails. More detail is on the Jira.
>>> > > > - Two validation tickets. It's been run up on multinode, and manual
>>> > > > testing has happened (and I'm will be seen a bit more on the final
>>> > PR
>>> > > by
>>> > > > various reviewers), so I'm inclined to just leave these open until
>>> > > we're
>>> > > > good to go. Let me know if we want to handle this differently.
>>> > > >
>>> > > > I'm of the opinion both of the active PRs need to be merged before
>>> we
>>> > > merge
>>> > > > this into master, especially the documentation one. The other two
>>> > > tickets
>>> > > > can be done in the future; one can be worked around and one is a
>>> > > metaalert
>>> > > > specific issue that primarily effects the alerts UI.
>>> > > >
>>> > > > As the branch has grown and diverged from master, it's gotten
>>> > > increasingly
>>> > > > unwieldy to maintain (and I think it's worth a follow-on discussion
>>> > about
>>> > > > how we manage refactorings that happen in these sorts of
>>> branches). I
>>> > > know
>>> > > > there's been at least a couple merges from master that have been
>>> > > > nontrivially difficult and required careful testing, particularly
>>> > around
>>> > > > the DAO layer, to avoid regressions in both code and tests.
>>> > > >
>>> > > > The feature set is pretty complete. The UI works, barring the
>>> > metaalert
>>> > > > issue. Much of the

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

2018-06-26 Thread Otto Fowler 
+1


On June 26, 2018 at 11:43:39, Justin Leet (justinjl...@gmail.com) wrote:

The PR has two +1's at this point (and I'm implicitly +1). In the interest
of full disclosure, both are from people who made contributions of varying
degrees to the branch.

Are there any objections to merging the feature branch into master at this
point?

On Fri, Jun 22, 2018 at 1:12 PM Justin Leet  wrote:

> That's more or less why I didn't flesh out testing.  Might be worth
> spinning up full dev and the site-book to smoke test, but the branch should
> be in a good state.  I figured if we get a couple +1's on the PR, it's
> essentially voting anyway, but this is pretty new in terms of process.
>
>
>
> On Fri, Jun 22, 2018 at 12:53 PM Otto Fowler 
> wrote:
>
>> If all the PR’s are on master->feature branch.  Why do we need testing?
>> this is almost a vote situation.
>>
>>
>>
>>
>> On June 22, 2018 at 12:01:11, Justin Leet (justinjl...@gmail.com) wrote:
>>
>> The (formerly) active PRs are now merged in and closed.
>>
>> We don't seem to have defined way to merge a feature branch into master
>> (unless I missed it), so I went ahead and opened a PR against the parent
>> ticket. Please see #1076 .
>>
>> I haven't fleshed out testing and so on for the PR description, although
>> if
>> we'd like it compiled from the various child PRs against the branch, I can
>> certainly do so.
>>
>> Justin
>>
>> On Thu, Jun 21, 2018 at 6:46 PM Michael Miklavcic <
>> michael.miklav...@gmail.com> wrote:
>>
>> > +1 let's do it.
>> >
>> > On Thu, Jun 21, 2018, 2:01 PM Nick Allen  wrote:
>> >
>> > > +1 I think we should merge ASAP and kill the feature branch. I think
>> the
>> > > work has well surpassed the level required to get it into master.
>> > >
>> > > On Thu, Jun 21, 2018 at 1:20 PM, Justin Leet 
>> > > wrote:
>> > >
>> > > > Hi All,
>> > > >
>> > > > The Solr branch (/feature/METRON-1416-upgrade-solr
>> > > > <
>> > https://github.com/apache/metron/tree/feature/METRON-1416-upgrade-solr
>> > > >),
>> > > > has been progressing for a while now. I'd like to open up discussion
>> > > > around what it takes to get it into master.
>> > > >
>> > > > The JIRA for tracking this feature branch is METRON-1416
>> > > > .
>> > > >
>> > > > As shown in the JIRA, the majority of tasks are complete, with a few
>> > > > outstanding issues. Of these, I believe these are the main ones of
>> > > interest
>> > > > to this discussion.
>> > > >
>> > > > - METRON-1629  -
>> > > > There is an active PR #1072 <
>> > > https://github.com/apache/metron/pull/1072
>> > > > >
>> > > > - METRON-1609  -
>> > > > There is an active PR #1056 <
>> > > https://github.com/apache/metron/pull/1056
>> > > > >
>> > > > - METRON-1602  -
>> > > > Full
>> > > > dev can run with Solr without this, it would simply be more
>> > > convenient.
>> > > > - METRON-1632  -
>> > > > Causes a metaalert specific issue where UI filtering on
>> > > > source.type:metaalert fails. More detail is on the Jira.
>> > > > - Two validation tickets. It's been run up on multinode, and manual
>> > > > testing has happened (and I'm will be seen a bit more on the final
>> > PR
>> > > by
>> > > > various reviewers), so I'm inclined to just leave these open until
>> > > we're
>> > > > good to go. Let me know if we want to handle this differently.
>> > > >
>> > > > I'm of the opinion both of the active PRs need to be merged before
>> we
>> > > merge
>> > > > this into master, especially the documentation one. The other two
>> > > tickets
>> > > > can be done in the future; one can be worked around and one is a
>> > > metaalert
>> > > > specific issue that primarily effects the alerts UI.
>> > > >
>> > > > As the branch has grown and diverged from master, it's gotten
>> > > increasingly
>> > > > unwieldy to maintain (and I think it's worth a follow-on discussion
>> > about
>> > > > how we manage refactorings that happen in these sorts of branches).
>> I
>> > > know
>> > > > there's been at least a couple merges from master that have been
>> > > > nontrivially difficult and required careful testing, particularly
>> > around
>> > > > the DAO layer, to avoid regressions in both code and tests.
>> > > >
>> > > > The feature set is pretty complete. The UI works, barring the
>> > metaalert
>> > > > issue. Much of the backend has been refactored and seen improved
>> test
>> > > > coverage benefiting both Solr and Elasticsearch. The main difference
>> > > > between ES and Solr is the lack of the equivalent visualizations to
>> > > > Kibana. I don't believe the feature branch needs to wait for this,
>> as
>> > > it's
>> > > > pretty standalone work that can be added as usage and demand
>> dictates.
>> > > >
>> > > > I'm of the

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

2018-06-26 Thread Justin Leet 
The PR has two +1's at this point (and I'm implicitly +1). In the interest
of full disclosure, both are from people who made contributions of varying
degrees to the branch.

Are there any objections to merging the feature branch into master at this
point?

On Fri, Jun 22, 2018 at 1:12 PM Justin Leet  wrote:

> That's more or less why I didn't flesh out testing.  Might be worth
> spinning up full dev and the site-book to smoke test, but the branch should
> be in a good state.  I figured if we get a couple +1's on the PR, it's
> essentially voting anyway, but this is pretty new in terms of process.
>
>
>
> On Fri, Jun 22, 2018 at 12:53 PM Otto Fowler 
> wrote:
>
>> If all the PR’s are on master->feature branch.  Why do we need testing?
>> this is almost a vote situation.
>>
>>
>>
>>
>> On June 22, 2018 at 12:01:11, Justin Leet (justinjl...@gmail.com) wrote:
>>
>> The (formerly) active PRs are now merged in and closed.
>>
>> We don't seem to have defined way to merge a feature branch into master
>> (unless I missed it), so I went ahead and opened a PR against the parent
>> ticket. Please see #1076 .
>>
>> I haven't fleshed out testing and so on for the PR description, although
>> if
>> we'd like it compiled from the various child PRs against the branch, I
>> can
>> certainly do so.
>>
>> Justin
>>
>> On Thu, Jun 21, 2018 at 6:46 PM Michael Miklavcic <
>> michael.miklav...@gmail.com> wrote:
>>
>> > +1 let's do it.
>> >
>> > On Thu, Jun 21, 2018, 2:01 PM Nick Allen  wrote:
>> >
>> > > +1 I think we should merge ASAP and kill the feature branch. I think
>> the
>> > > work has well surpassed the level required to get it into master.
>> > >
>> > > On Thu, Jun 21, 2018 at 1:20 PM, Justin Leet 
>> > > wrote:
>> > >
>> > > > Hi All,
>> > > >
>> > > > The Solr branch (/feature/METRON-1416-upgrade-solr
>> > > > <
>> > https://github.com/apache/metron/tree/feature/METRON-1416-upgrade-solr
>> > > >),
>> > > > has been progressing for a while now. I'd like to open up
>> discussion
>> > > > around what it takes to get it into master.
>> > > >
>> > > > The JIRA for tracking this feature branch is METRON-1416
>> > > > .
>> > > >
>> > > > As shown in the JIRA, the majority of tasks are complete, with a
>> few
>> > > > outstanding issues. Of these, I believe these are the main ones of
>> > > interest
>> > > > to this discussion.
>> > > >
>> > > > - METRON-1629 
>> -
>> > > > There is an active PR #1072 <
>> > > https://github.com/apache/metron/pull/1072
>> > > > >
>> > > > - METRON-1609 
>> -
>> > > > There is an active PR #1056 <
>> > > https://github.com/apache/metron/pull/1056
>> > > > >
>> > > > - METRON-1602 
>> -
>> > > > Full
>> > > > dev can run with Solr without this, it would simply be more
>> > > convenient.
>> > > > - METRON-1632 
>> -
>> > > > Causes a metaalert specific issue where UI filtering on
>> > > > source.type:metaalert fails. More detail is on the Jira.
>> > > > - Two validation tickets. It's been run up on multinode, and manual
>> > > > testing has happened (and I'm will be seen a bit more on the final
>> > PR
>> > > by
>> > > > various reviewers), so I'm inclined to just leave these open until
>> > > we're
>> > > > good to go. Let me know if we want to handle this differently.
>> > > >
>> > > > I'm of the opinion both of the active PRs need to be merged before
>> we
>> > > merge
>> > > > this into master, especially the documentation one. The other two
>> > > tickets
>> > > > can be done in the future; one can be worked around and one is a
>> > > metaalert
>> > > > specific issue that primarily effects the alerts UI.
>> > > >
>> > > > As the branch has grown and diverged from master, it's gotten
>> > > increasingly
>> > > > unwieldy to maintain (and I think it's worth a follow-on discussion
>> > about
>> > > > how we manage refactorings that happen in these sorts of branches).
>> I
>> > > know
>> > > > there's been at least a couple merges from master that have been
>> > > > nontrivially difficult and required careful testing, particularly
>> > around
>> > > > the DAO layer, to avoid regressions in both code and tests.
>> > > >
>> > > > The feature set is pretty complete. The UI works, barring the
>> > metaalert
>> > > > issue. Much of the backend has been refactored and seen improved
>> test
>> > > > coverage benefiting both Solr and Elasticsearch. The main
>> difference
>> > > > between ES and Solr is the lack of the equivalent visualizations to
>> > > > Kibana. I don't believe the feature branch needs to wait for this,
>> as
>> > > it's
>> > > > pretty standalone work that can be added as usage and demand
>> dictates.
>> > > >
>> > > > I'm of the opinion that the benefits of getting the branch into
>>

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

2018-06-22 Thread Justin Leet 
The (formerly) active PRs are now merged in and closed.

We don't seem to have defined way to merge a feature branch into master
(unless I missed it), so I went ahead and opened a PR against the parent
ticket. Please see #1076 .

I haven't fleshed out testing and so on for the PR description, although if
we'd like it compiled from the various child PRs against the branch, I can
certainly do so.

Justin

On Thu, Jun 21, 2018 at 6:46 PM Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> +1 let's do it.
>
> On Thu, Jun 21, 2018, 2:01 PM Nick Allen  wrote:
>
> > +1 I think we should merge ASAP and kill the feature branch.  I think the
> > work has well surpassed the level required to get it into master.
> >
> > On Thu, Jun 21, 2018 at 1:20 PM, Justin Leet 
> > wrote:
> >
> > > Hi All,
> > >
> > > The Solr branch (/feature/METRON-1416-upgrade-solr
> > > <
> https://github.com/apache/metron/tree/feature/METRON-1416-upgrade-solr
> > >),
> > > has been progressing for a while now.  I'd like to open up discussion
> > > around what it takes to get it into master.
> > >
> > > The JIRA for tracking this feature branch is METRON-1416
> > > .
> > >
> > > As shown in the JIRA, the majority of tasks are complete, with a few
> > > outstanding issues. Of these, I believe these are the main ones of
> > interest
> > > to this discussion.
> > >
> > >- METRON-1629  -
> > >There is an active PR #1072 <
> > https://github.com/apache/metron/pull/1072
> > > >
> > >- METRON-1609  -
> > >There is an active PR #1056 <
> > https://github.com/apache/metron/pull/1056
> > > >
> > >- METRON-1602  -
> > > Full
> > >dev can run with Solr without this, it would simply be more
> > convenient.
> > >- METRON-1632  -
> > >Causes a metaalert specific issue where UI filtering on
> > >source.type:metaalert fails. More detail is on the Jira.
> > >- Two validation tickets.  It's been run up on multinode, and manual
> > >testing has happened (and I'm will be seen a bit more on the final
> PR
> > by
> > >various reviewers), so I'm inclined to just leave these open until
> > we're
> > >good to go.  Let me know if we want to handle this differently.
> > >
> > > I'm of the opinion both of the active PRs need to be merged before we
> > merge
> > > this into master, especially the documentation one.  The other two
> > tickets
> > > can be done in the future; one can be worked around and one is a
> > metaalert
> > > specific issue that primarily effects the alerts UI.
> > >
> > > As the branch has grown and diverged from master, it's gotten
> > increasingly
> > > unwieldy to maintain (and I think it's worth a follow-on discussion
> about
> > > how we manage refactorings that happen in these sorts of branches).  I
> > know
> > > there's been at least a couple merges from master that have been
> > > nontrivially difficult and required careful testing, particularly
> around
> > > the DAO layer, to avoid regressions in both code and tests.
> > >
> > > The feature set is pretty complete.  The UI works, barring the
> metaalert
> > > issue.  Much of the backend has been refactored and seen improved test
> > > coverage benefiting both Solr and Elasticsearch.  The main difference
> > > between ES and Solr is the lack of the equivalent visualizations to
> > > Kibana.  I don't believe the feature branch needs to wait for this, as
> > it's
> > > pretty standalone work that can be added as usage and demand dictates.
> > >
> > > I'm of the opinion that the benefits of getting the branch into master
> > > outweighs the issues still present, especially in terms of making
> > > refactoring and features available and easing the dev burden.  The
> > > remaining tickets are Solr specific, and ES functions as it does in
> > master.
> > >
> > > Are there any must-haves before we bring this branch back?  Are there
> any
> > > other concerns we have before a final PR is opened (pending completion
> of
> > > active PRs and any other must-haves)?
> > >
> > > Justin
> > >
> >
>

Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master

2018-06-21 Thread Casey Stella 
I think that we should merge now, but I’m perhaps biased since I did one of
the hard merges. I think that since the major outstanding bug is being
worked and we are otherwise feature complete, the feature branch did its
job and we are ready to merge.
On Thu, Jun 21, 2018 at 10:21 Justin Leet  wrote:

> Hi All,
>
> The Solr branch (/feature/METRON-1416-upgrade-solr
> ),
> has been progressing for a while now.  I'd like to open up discussion
> around what it takes to get it into master.
>
> The JIRA for tracking this feature branch is METRON-1416
> .
>
> As shown in the JIRA, the majority of tasks are complete, with a few
> outstanding issues. Of these, I believe these are the main ones of interest
> to this discussion.
>
>- METRON-1629  -
>There is an active PR #1072  >
>- METRON-1609  -
>There is an active PR #1056  >
>- METRON-1602  -
> Full
>dev can run with Solr without this, it would simply be more convenient.
>- METRON-1632  -
>Causes a metaalert specific issue where UI filtering on
>source.type:metaalert fails. More detail is on the Jira.
>- Two validation tickets.  It's been run up on multinode, and manual
>testing has happened (and I'm will be seen a bit more on the final PR by
>various reviewers), so I'm inclined to just leave these open until we're
>good to go.  Let me know if we want to handle this differently.
>
> I'm of the opinion both of the active PRs need to be merged before we merge
> this into master, especially the documentation one.  The other two tickets
> can be done in the future; one can be worked around and one is a metaalert
> specific issue that primarily effects the alerts UI.
>
> As the branch has grown and diverged from master, it's gotten increasingly
> unwieldy to maintain (and I think it's worth a follow-on discussion about
> how we manage refactorings that happen in these sorts of branches).  I know
> there's been at least a couple merges from master that have been
> nontrivially difficult and required careful testing, particularly around
> the DAO layer, to avoid regressions in both code and tests.
>
> The feature set is pretty complete.  The UI works, barring the metaalert
> issue.  Much of the backend has been refactored and seen improved test
> coverage benefiting both Solr and Elasticsearch.  The main difference
> between ES and Solr is the lack of the equivalent visualizations to
> Kibana.  I don't believe the feature branch needs to wait for this, as it's
> pretty standalone work that can be added as usage and demand dictates.
>
> I'm of the opinion that the benefits of getting the branch into master
> outweighs the issues still present, especially in terms of making
> refactoring and features available and easing the dev burden.  The
> remaining tickets are Solr specific, and ES functions as it does in master.
>
> Are there any must-haves before we bring this branch back?  Are there any
> other concerns we have before a final PR is opened (pending completion of
> active PRs and any other must-haves)?
>
> Justin
>