Re: Feature Branch Process

2018-07-30 Thread Michael Miklavcic
Hey Nick, thanks for starting this thread. Some thought of mine from recent
work in feature branches for Solr and the Pcap query panel:

   1. As a general rule, feature branches should be started for code
   changes that are not able to be delivered in 1-2 PR's of no more than 1-2k
   lines, but as usual a developer/contributor can make the case for
   exceptions. There should also be a DISCUSS to kick it off with a breakdown
   of what the feature branch will deliver. Your recent DISCUSS around the
   profiler is a good example.
   
https://lists.apache.org/thread.html/da81c1227ffda3a47eb2e5bb4d0b162dd6d36006241c4ba4b659587b@%3Cdev.metron.apache.org%3E
   2. I think the feature branch should include a parent Epic/Jira that
   describes the end state with accompanying Jiras delivered along the way.
  1. This is not a static list, but rather something that evolves as
  the feature is fleshed out.
  2. Any individual PR's with follow-on work per the comments on that
  PR should be added as a task to the final feature branch epic.
The point is
  that all PR's can be committed prior to every check list item,
but there is
  always a final accounting and balancing of the books. All PR's should
  continue to have accountability and roll up into the final
deliverable and
  the feature branch should not be merged into master until either a) all
  items have been addressed or b) a case has been made for making
those items
  follow-on work in master after the merge.

Best,
Mike


On Mon, Jul 2, 2018 at 12:08 PM Nick Allen  wrote:

> Maintaining a feature branch (FB) comes with its own overhead.  The longer
> we take to merge back into the main line, the harder it becomes.  I think
> we could have merged the Solr work sooner and avoided some of that
> overhead.  It might help to answer these questions in the Developer
> Guidelines.
>
> (Q) When should a feature branch be started?
>
> (Q) When is a feature branch finished?  When is it ready to be merged into
> master?
>
>
>
>
>
>
>
> On 2018/07/02 17:56:46, Nick Allen  wrote:
> > We recently merged our first feature branch back into master; the
> enhanced>
> > support for Solr.  How did the feature branch "process" go from start to>
> > finish?  What were some of the pain points?  What can we learn from the>
> > experience?>
> >
>


Re: Feature Branch Process

2018-07-02 Thread Nick Allen
Maintaining a feature branch (FB) comes with its own overhead.  The longer
we take to merge back into the main line, the harder it becomes.  I think
we could have merged the Solr work sooner and avoided some of that
overhead.  It might help to answer these questions in the Developer
Guidelines.

(Q) When should a feature branch be started?

(Q) When is a feature branch finished?  When is it ready to be merged into
master?







On 2018/07/02 17:56:46, Nick Allen  wrote:
> We recently merged our first feature branch back into master; the
enhanced>
> support for Solr.  How did the feature branch "process" go from start to>
> finish?  What were some of the pain points?  What can we learn from the>
> experience?>
>