Does anyone else have any comments? I would like to get the ball rolling on this, maybe this weekend.
On August 23, 2017 at 14:28:57, Nick Allen (n...@nickallen.org) wrote: 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 zeo...@gmail.com <zeo...@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 <n...@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 <ottobackwa...@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 (ottobackwa...@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 >
