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 <[email protected]> wrote: > +1 I like it all, Otto. You deserve a freakin' medal. > > > > > > On Wed, Aug 23, 2017 at 10:04 AM Otto Fowler <[email protected]> > 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 ([email protected]) > > 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
