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 <justinjl...@gmail.com> 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 <ottobackwa...@gmail.com> > 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 <https://github.com/apache/metron/pull/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 <n...@nickallen.org> 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 <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 >> > > > >> > > >> > >> >>
