metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Allen <n...@nickallen.org>
Subject Re: Feature Branch: Extension System for Metron and Metron Parsers
Date Wed, 30 Aug 2017 14:25:49 GMT
Yes, I think you still need +1s.  The same PR rules apply to the feature
branch PRs.

The only difference being that as a reviewer/committer I won't expect the
same level of quality, documentation, etc to get my +1 for a PR that is
destined for a feature branch.  And of course, each reviewer/committer is
free to set the expectations they have for handing out a +1, in all cases.

At least, that is how I have been thinking about this process.  I am open
to alternatives though.





On Wed, Aug 30, 2017 at 9:59 AM Otto Fowler <ottobackwards@gmail.com> wrote:

> So the question is: Can I commit the PR or do I need some +1’s to rubber
> stamp it?
>
>
> On August 29, 2017 at 10:01:13, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
> And finally : https://github.com/apache/metron/pull/720
>
>
>
> On August 28, 2017 at 10:24:43, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
>
> https://github.com/apache/metron/tree/feature/METRON-1136-extensions-parsers
>
>
> On August 27, 2017 at 12:39:15, Otto Fowler (ottobackwards@gmail.com)
> wrote:
>
> To start in creation the feature branch I have done the following:
>
> 1. I have created a new confluence area to track feature branches :
> https://cwiki.apache.org/confluence/display/METRON/Feature+Branches
> 2. I have created a new set of confluence pages for this feature branch:
> https://cwiki.apache.org/confluence/display/METRON/Metron+Extension+System+and+Parser+Extensions#
> 3. I have created a jira for this feature branch :
> https://issues.apache.org/jira/browse/METRON-1136
>
> The idea is that we want to document the feature branch effort and concept
> ( wiki ) and track the work in jira.
>
> There is redundancy and gaps between the wiki and the PR’s, but that is
> unavoidable for an effort that has been going on so long.
>
> I plan on adding more to the wiki, but also would encourage others that
> have been involved in the review to do so as well ( or anyone interested
> etc ).  Also any comments
> on this approach for Feature Branches are welcome.
>
> As Nick said, we are not necessarily creating a process for all future
> branches.
>
> I think this is enough structure to start the branch off at least.
>
>
>
>
>

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