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 <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 >
