metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master
Date Thu, 21 Jun 2018 21:01:05 GMT
+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 <justinjleet@gmail.com> 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
> <https://issues.apache.org/jira/browse/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 <https://issues.apache.org/jira/browse/METRON-1629> -
>    There is an active PR #1072 <https://github.com/apache/metron/pull/1072
> >
>    - METRON-1609 <https://issues.apache.org/jira/browse/METRON-1609> -
>    There is an active PR #1056 <https://github.com/apache/metron/pull/1056
> >
>    - METRON-1602 <https://issues.apache.org/jira/browse/METRON-1602> -
> Full
>    dev can run with Solr without this, it would simply be more convenient.
>    - METRON-1632 <https://issues.apache.org/jira/browse/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
>

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