+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 <justinjl...@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 >
