metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: [DISCUSS] METRON-777 and the road to perditi... er enlightenment
Date Wed, 23 Aug 2017 18:28:40 GMT
I propose that we go forward with our first feature branch without
guideline changes up-front.  We can use this as a learning experience out
of which guideline changes can be proposed.  I'd prefer to have a little
more flexibility on our first feature branch so we can determine how best
to push it through.




On Wed, Aug 23, 2017 at 2:18 PM Zeolla@GMail.com <zeolla@gmail.com> wrote:

> This is all great stuff.  As far as feature branch naming, I would suggest
> something like feature/$brief_explanation accompanied with a feature branch
> JIRA that explains the original intent of the branch and its
> goals/"complete" indicators.
>
> Along the lines of the FEATURE.md, I feel like at the very least we should
> update the dev guidelines
> <https://cwiki.apache.org/confluence/display/METRON/Development+Guidelines
> >,
> but doing more than that could potentially be warranted.
>
> +1
>
> Jon
>
> On Wed, Aug 23, 2017 at 12:38 PM Nick Allen <nick@nickallen.org> wrote:
>
> > +1 I like it all, Otto.  You deserve a freakin' medal.
> >
> >
> >
> >
> >
> > On Wed, Aug 23, 2017 at 10:04 AM Otto Fowler <ottobackwards@gmail.com>
> > wrote:
> >
> > > WRT : regression fixes, I would also like us to consider putting these
> > the
> > > initial 777 to feature branch PR as an option.
> > >
> > >
> > > On August 23, 2017 at 09:56:33, Otto Fowler (ottobackwards@gmail.com)
> > > wrote:
> > >
> > >
> > >
> > > A feature branch
> > >
> > > As discussed in the community meeting we are going to create a
> ‘feature’
> > > branch for METRON–777 and it’s associated PR’s. The purpose behind the
> > > feature branch is to more formally stage a large PR or set of PR’s to
> > allow
> > > for for better review participation ( of the pr and changes due to
> > feedback
> > > ) and more formal collaboration and testing.
> > >
> > > In order to accomplish this, there are several things that will have to
> > be
> > > done. I believe they are:
> > >
> > >    1. A new branch shall be made in the apache-git repo.
> > >    2. I will rebase my METRON–777 branch to that new branch and submit
> a
> > PR
> > >    to it in github, which we will land.
> > >    3. I will also follow the same procedure for METRON–942 with the
> > >    expectation of landing it.
> > >
> > > This will give us the full set of functionality as currently set of out
> > for
> > > extensions.
> > >
> > > Currently there are two other branches that I have to fix regressions
> or
> > > missing required functionality.
> > >
> > >    1. I will merge these into one ( they are related ).
> > >    2. I will then submit them are PR’s
> > >
> > > Hopefully we can get these into the branch, so that we can then test
> the
> > > whole end to end functionality, and have the ability to review and
> > discuss
> > > the design decisions made against a working system.
> > >
> > > To that end, after these PR sets land, I will make a video around using
> > the
> > > features.
> > >
> > > The end result of the feature branch and the effort will be a branch
> that
> > > has met all the criteria and and acceptance standards set out for it.
> > Will
> > > will have some community activity at that time as a means of
> introduction
> > > and demonstration.
> > > Questions:
> > >
> > >    - What should the naming convention for the branch be? feature-?
> > >    - Should there be a new FEATURE.md that has the equivalent of the PR
> > >    description? or should the README.md be modified ( to be changed
> back
> > >    before merge ) so that it is prominent?
> > >    - We need to set some criteria for ‘done’, and record that
> somewhere.
> > >    Should there be a feature branch jira? I think we need one for the
> > > eventual
> > >    merge anyways.
> > >    - other?
> > >
> > > Please provide any feedback or other questions so that we can proceed
> > > without much more delay.
> > > Refresher : What is METRON–777?
> > >
> > > METRON–777 one of two PR’s to implement the side loading of Metron
> > parsers
> > > ( METRON–258 ).
> > >
> > > In order to provide a working, testable build that meets our pr
> > > requirements, the functionality was only broken down into two PR’s:
> > >
> > >    -
> > >
> > >    [#530 METRON-777 Metron Extension System and Parser Extensions](
> > >    https://github.com/apache/metron/pull/530)
> > >    -
> > >
> > >    [#590 METRON-942 Rest api and configuration for Metron parser
> > > extensions]
> > >    (https://github.com/apache/metron/pull/580)
> > >
> > > METRON–777 provides the architecture support and changes and moves the
> > > current parsers over to the new architecture.
> > >
> > > METRON–942 provides the rest api to install a 3rd party parser
> extension,
> > > and a stellar command for reading extension configurations
> > >
> > > it should be noted that this set of features is still incomplete, as
> the
> > > metron-config ui should be changed to provide a ui front end for
> > extension
> > > management
> > >
> >
> --
>
> Jon
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message