metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <justinjl...@gmail.com>
Subject Re: [DISCUSS] Merging Solr feature branch (METRON-1416) into master
Date Fri, 22 Jun 2018 17:12:35 GMT
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 <ottobackwards@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 (justinjleet@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.miklavcic@gmail.com> wrote:
>
> > +1 let's do it.
> >
> > On Thu, Jun 21, 2018, 2:01 PM Nick Allen <nick@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 <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