Thank you, Justin.  Great job on the merge 

26.06.2018, 14:20, "Justin Leet" <justinjl...@gmail.com>:
> 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 <ottobackwa...@gmail.com> 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 <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
>>>>  > > >
>>>>  > >
>>>>  >

------------------- 
Thank you,

James Sirota
PMC- Apache Metron
jsirota AT apache DOT org

Reply via email to