Re: [DISCUSS] Whether to create separate 2.0 branch

[Aman Sinha <am...@gmail.com>]

Catching up on this thread since I was traveling and am currently in India
time zone.
Interesting suggestion about the C-T-R policy for a potential 2.0 branch.
I don't recall we have done this for any prior releases.
In the past, my experience with a separate feature branch (not on apache
but in a private repo) was that we still did the review-then-commit
since that's what everyone is accustomed to and most Drill developers tend
to want early feedback.  This depends on the folks working on the
specific features.

For the branching, it sounds like people are more inclined towards option
(a).   Parth does make a good case for 2.0 branch and it would be
inevitable at some point in future especially for the
compatibility-breaking functionality.   We would expect the feature
developers to indicate when
that time comes.

I believe at least partial support for Arrow is a 2.0 objective.  Hopefully
one of us can free up from other commitments and start working on it.

Aman

On Thu, Feb 28, 2019 at 9:56 AM Parth Chandra <pa...@apache.org> wrote:

> +1 for a 2.0 branch.
> Feature specific branches can be created off the 2.0 branch, and should
> ideally be merged periodically.
> I would also suggest that we adopt a C-T-R policy [1] for the 2.0 branch
> until it is at a stable point.
> Finally, I would assume that it is up to the feature developers to decide
> whether the feature will maintain backward compatibility or not. 2.0 is an
> opportunity to break backward compatibility so it would be quite acceptable
> for some major features to break compatibility.
> One major question backward compatibility for 2.0 would be Arrow. If we
> decide we want to have Arrow support, we would probably break backward
> compatibility in may ways. If we don't do Arrow support in 2.0, we'll
> probably never do it. We could, of course, do partial support. For
> reference see the Spark effort [2]
>
> [1] https://www.apache.org/foundation/glossary.html#CommitThenReview
> [2] https://jira.apache.org/jira/browse/SPARK-26413
>
>
> On Thu, Feb 28, 2019 at 9:26 AM Pritesh Maker <pm...@mapr.com> wrote:
>
> > I think option (a) is better in terms of maintaining branches. With
> option
> > (a) how do we handle a situation where one of these features breaks
> > backward compatibility or deprecates some functionality?
> >
> > Pritesh
> >
> > On Wed, Feb 27, 2019 at 4:23 PM Abhishek Girish <ag...@apache.org>
> > wrote:
> >
> > > My opinion would be option (a) as well. It's easier to maintain a
> single
> > > master branch. With a separate v2 branch, it's twice the effort to test
> > > common commits going in (either directly or via later via rebase).
> > >
> > > On Wed, Feb 27, 2019 at 12:40 PM Aman Sinha <am...@gmail.com>
> wrote:
> > >
> > > > My personal preference would be option (a)  as much as possible until
> > we
> > > > get to a situation where it is getting too unwieldy at which point we
> > > > re-evaluate.
> > > >
> > > > Aman
> > > >
> > > > On Wed, Feb 27, 2019 at 12:35 PM Aman Sinha <am...@gmail.com>
> > wrote:
> > > >
> > > > > Hi Drill devs,
> > > > > There are couple of ongoing projects - Resource Manager and the
> Drill
> > > > > Metastore - that are relatively large in scope.  Intermediate PRs
> > will
> > > be
> > > > > created for these (for example, there's one open for the metastore
> > [1].
> > > > > Another one for the RM [2].  These don't currently break existing
> > > > > functionality, so they have been opened against master branch.
> > > > >
> > > > > The question is, for future PRs,  would it make sense to create a
> > > > separate
> > > > > Drill 2.0 branch ?  There are pros and cons.  Separate branch would
> > > allow
> > > > > development on these features to proceed at a faster pace without
> > > > > disrupting others.  However, in Drill we typically have only
> created
> > a
> > > > > separate branch close to the release, not up-front.  It simplifies
> > > > testing
> > > > > and maintenance to have a unified master branch.
> > > > >
> > > > > Another option is feature specific branch.
> > > > >
> > > > > What do people think about the 3 options:
> > > > >  a)  Merge intermediate PRs into Apache master as long as they
> don't
> > > > break
> > > > > existing functionality.  In some cases, temporary config options
> may
> > be
> > > > > used to enable new functionality for unit testing.
> > > > >  b)  Create a Drill-2.0 branch which will be work-in-progress and
> be
> > > > > periodically sync-ed with master branch.  Code reviews will be done
> > > > against
> > > > > this branch.
> > > > > c)   Have a feature specific branch - e.g for RM, for Metastore
> etc.
> > > such
> > > > > that collaborators can do peer reviews and merge intermediate
> > commits.
> > > > > These branches will also need to be periodically sync-ed with the
> > > master
> > > > > branch.
> > > > >
> > > > > Please share your choice of one of these options and any additional
> > > > > thoughts.
> > > > >
> > > > > [1] https://github.com/apache/drill/pull/1646
> > > > > [2] https://github.com/apache/drill/pull/1652
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Whether to create separate 2.0 branch

[hanu mapr <ha...@gmail.com>]

Hello,

+1 for 2.0 branch. I totally agree with Parth that for the fast progress of
a feature (like RM) which can break the backward compatibility of an
existing functionality, maintaining a separate branch is better.

Thanks,
-Hanu



On Mon, Mar 4, 2019 at 11:44 AM Parth Chandra <pa...@apache.org> wrote:

> The wisdom of the ancients says that if you want fast progress while a new
> code base is in development, CTR is the way to go. Once the code is out in
> a release, stability becomes important and you want to review before
> committing it.
>
> With CTR you are allowed to -
>   Not worry about style.
>   Not worry about clean implementation.
>   You don't even have to make sure the code compiles.
>   Have non committers work alongside committers without having to wait.
>
> While it is up to each group of developers to have a common policy to which
> they will adhere, as a project we can relax the rules and make sure that
> those who want to move fast are able to do so without process getting in
> the way.
>
> Either way, we should go ahead with the new branch and evolve the commit
> policy as works starts/continues on 2.0
>
>
>
> On Sun, Mar 3, 2019 at 9:18 PM Sorabh Hamirwasia <sh...@mapr.com>
> wrote:
>
> > Hi,
> > +1 for 2.0 branch. From RM perspective since we will be adding support
> for
> > more richer configuration to support multiple queues, the existing
> > functionality will be deprecated. This will result in breaking backward
> > compatibility hence 2.0 branch will be preferred. I think it will be
> > confusing and also extra work to keep support for both existing and new
> > queues support for RM.
> > However I would still prefer the commit process in 2.0 branch to be same
> as
> > that in master branch. Review and approved by a committer before check in
> > and all tests should pass. If we follow these steps then during
> integration
> > of the entire feature into master branch, review of 1 big fat PR will not
> > be required.
> >
> > Thanks,
> > Sorabh
> >
> > On Sun, Mar 3, 2019 at 7:35 PM Aman Sinha <am...@gmail.com> wrote:
> >
> > > Catching up on this thread since I was traveling and am currently in
> > India
> > > time zone.
> > > Interesting suggestion about the C-T-R policy for a potential 2.0
> branch.
> > > I don't recall we have done this for any prior releases.
> > > In the past, my experience with a separate feature branch (not on
> apache
> > > but in a private repo) was that we still did the review-then-commit
> > > since that's what everyone is accustomed to and most Drill developers
> > tend
> > > to want early feedback.  This depends on the folks working on the
> > > specific features.
> > >
> > > For the branching, it sounds like people are more inclined towards
> option
> > > (a).   Parth does make a good case for 2.0 branch and it would be
> > > inevitable at some point in future especially for the
> > > compatibility-breaking functionality.   We would expect the feature
> > > developers to indicate when
> > > that time comes.
> > >
> > > I believe at least partial support for Arrow is a 2.0 objective.
> > Hopefully
> > > one of us can free up from other commitments and start working on it.
> > >
> > > Aman
> > >
> > > On Thu, Feb 28, 2019 at 9:56 AM Parth Chandra <pa...@apache.org>
> wrote:
> > >
> > > > +1 for a 2.0 branch.
> > > > Feature specific branches can be created off the 2.0 branch, and
> should
> > > > ideally be merged periodically.
> > > > I would also suggest that we adopt a C-T-R policy [1] for the 2.0
> > branch
> > > > until it is at a stable point.
> > > > Finally, I would assume that it is up to the feature developers to
> > decide
> > > > whether the feature will maintain backward compatibility or not. 2.0
> is
> > > an
> > > > opportunity to break backward compatibility so it would be quite
> > > acceptable
> > > > for some major features to break compatibility.
> > > > One major question backward compatibility for 2.0 would be Arrow. If
> we
> > > > decide we want to have Arrow support, we would probably break
> backward
> > > > compatibility in may ways. If we don't do Arrow support in 2.0, we'll
> > > > probably never do it. We could, of course, do partial support. For
> > > > reference see the Spark effort [2]
> > > >
> > > > [1] https://www.apache.org/foundation/glossary.html#CommitThenReview
> > > > [2] https://jira.apache.org/jira/browse/SPARK-26413
> > > >
> > > >
> > > > On Thu, Feb 28, 2019 at 9:26 AM Pritesh Maker <pm...@mapr.com>
> wrote:
> > > >
> > > > > I think option (a) is better in terms of maintaining branches. With
> > > > option
> > > > > (a) how do we handle a situation where one of these features breaks
> > > > > backward compatibility or deprecates some functionality?
> > > > >
> > > > > Pritesh
> > > > >
> > > > > On Wed, Feb 27, 2019 at 4:23 PM Abhishek Girish <
> agirish@apache.org>
> > > > > wrote:
> > > > >
> > > > > > My opinion would be option (a) as well. It's easier to maintain a
> > > > single
> > > > > > master branch. With a separate v2 branch, it's twice the effort
> to
> > > test
> > > > > > common commits going in (either directly or via later via
> rebase).
> > > > > >
> > > > > > On Wed, Feb 27, 2019 at 12:40 PM Aman Sinha <amansinha@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > My personal preference would be option (a)  as much as possible
> > > until
> > > > > we
> > > > > > > get to a situation where it is getting too unwieldy at which
> > point
> > > we
> > > > > > > re-evaluate.
> > > > > > >
> > > > > > > Aman
> > > > > > >
> > > > > > > On Wed, Feb 27, 2019 at 12:35 PM Aman Sinha <
> amansinha@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > Hi Drill devs,
> > > > > > > > There are couple of ongoing projects - Resource Manager and
> the
> > > > Drill
> > > > > > > > Metastore - that are relatively large in scope.  Intermediate
> > PRs
> > > > > will
> > > > > > be
> > > > > > > > created for these (for example, there's one open for the
> > > metastore
> > > > > [1].
> > > > > > > > Another one for the RM [2].  These don't currently break
> > existing
> > > > > > > > functionality, so they have been opened against master
> branch.
> > > > > > > >
> > > > > > > > The question is, for future PRs,  would it make sense to
> > create a
> > > > > > > separate
> > > > > > > > Drill 2.0 branch ?  There are pros and cons.  Separate branch
> > > would
> > > > > > allow
> > > > > > > > development on these features to proceed at a faster pace
> > without
> > > > > > > > disrupting others.  However, in Drill we typically have only
> > > > created
> > > > > a
> > > > > > > > separate branch close to the release, not up-front.  It
> > > simplifies
> > > > > > > testing
> > > > > > > > and maintenance to have a unified master branch.
> > > > > > > >
> > > > > > > > Another option is feature specific branch.
> > > > > > > >
> > > > > > > > What do people think about the 3 options:
> > > > > > > >  a)  Merge intermediate PRs into Apache master as long as
> they
> > > > don't
> > > > > > > break
> > > > > > > > existing functionality.  In some cases, temporary config
> > options
> > > > may
> > > > > be
> > > > > > > > used to enable new functionality for unit testing.
> > > > > > > >  b)  Create a Drill-2.0 branch which will be work-in-progress
> > and
> > > > be
> > > > > > > > periodically sync-ed with master branch.  Code reviews will
> be
> > > done
> > > > > > > against
> > > > > > > > this branch.
> > > > > > > > c)   Have a feature specific branch - e.g for RM, for
> Metastore
> > > > etc.
> > > > > > such
> > > > > > > > that collaborators can do peer reviews and merge intermediate
> > > > > commits.
> > > > > > > > These branches will also need to be periodically sync-ed with
> > the
> > > > > > master
> > > > > > > > branch.
> > > > > > > >
> > > > > > > > Please share your choice of one of these options and any
> > > additional
> > > > > > > > thoughts.
> > > > > > > >
> > > > > > > > [1] https://github.com/apache/drill/pull/1646
> > > > > > > > [2] https://github.com/apache/drill/pull/1652
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Whether to create separate 2.0 branch

[Parth Chandra <pa...@apache.org>]

The wisdom of the ancients says that if you want fast progress while a new
code base is in development, CTR is the way to go. Once the code is out in
a release, stability becomes important and you want to review before
committing it.

With CTR you are allowed to -
  Not worry about style.
  Not worry about clean implementation.
  You don't even have to make sure the code compiles.
  Have non committers work alongside committers without having to wait.

While it is up to each group of developers to have a common policy to which
they will adhere, as a project we can relax the rules and make sure that
those who want to move fast are able to do so without process getting in
the way.

Either way, we should go ahead with the new branch and evolve the commit
policy as works starts/continues on 2.0



On Sun, Mar 3, 2019 at 9:18 PM Sorabh Hamirwasia <sh...@mapr.com>
wrote:

> Hi,
> +1 for 2.0 branch. From RM perspective since we will be adding support for
> more richer configuration to support multiple queues, the existing
> functionality will be deprecated. This will result in breaking backward
> compatibility hence 2.0 branch will be preferred. I think it will be
> confusing and also extra work to keep support for both existing and new
> queues support for RM.
> However I would still prefer the commit process in 2.0 branch to be same as
> that in master branch. Review and approved by a committer before check in
> and all tests should pass. If we follow these steps then during integration
> of the entire feature into master branch, review of 1 big fat PR will not
> be required.
>
> Thanks,
> Sorabh
>
> On Sun, Mar 3, 2019 at 7:35 PM Aman Sinha <am...@gmail.com> wrote:
>
> > Catching up on this thread since I was traveling and am currently in
> India
> > time zone.
> > Interesting suggestion about the C-T-R policy for a potential 2.0 branch.
> > I don't recall we have done this for any prior releases.
> > In the past, my experience with a separate feature branch (not on apache
> > but in a private repo) was that we still did the review-then-commit
> > since that's what everyone is accustomed to and most Drill developers
> tend
> > to want early feedback.  This depends on the folks working on the
> > specific features.
> >
> > For the branching, it sounds like people are more inclined towards option
> > (a).   Parth does make a good case for 2.0 branch and it would be
> > inevitable at some point in future especially for the
> > compatibility-breaking functionality.   We would expect the feature
> > developers to indicate when
> > that time comes.
> >
> > I believe at least partial support for Arrow is a 2.0 objective.
> Hopefully
> > one of us can free up from other commitments and start working on it.
> >
> > Aman
> >
> > On Thu, Feb 28, 2019 at 9:56 AM Parth Chandra <pa...@apache.org> wrote:
> >
> > > +1 for a 2.0 branch.
> > > Feature specific branches can be created off the 2.0 branch, and should
> > > ideally be merged periodically.
> > > I would also suggest that we adopt a C-T-R policy [1] for the 2.0
> branch
> > > until it is at a stable point.
> > > Finally, I would assume that it is up to the feature developers to
> decide
> > > whether the feature will maintain backward compatibility or not. 2.0 is
> > an
> > > opportunity to break backward compatibility so it would be quite
> > acceptable
> > > for some major features to break compatibility.
> > > One major question backward compatibility for 2.0 would be Arrow. If we
> > > decide we want to have Arrow support, we would probably break backward
> > > compatibility in may ways. If we don't do Arrow support in 2.0, we'll
> > > probably never do it. We could, of course, do partial support. For
> > > reference see the Spark effort [2]
> > >
> > > [1] https://www.apache.org/foundation/glossary.html#CommitThenReview
> > > [2] https://jira.apache.org/jira/browse/SPARK-26413
> > >
> > >
> > > On Thu, Feb 28, 2019 at 9:26 AM Pritesh Maker <pm...@mapr.com> wrote:
> > >
> > > > I think option (a) is better in terms of maintaining branches. With
> > > option
> > > > (a) how do we handle a situation where one of these features breaks
> > > > backward compatibility or deprecates some functionality?
> > > >
> > > > Pritesh
> > > >
> > > > On Wed, Feb 27, 2019 at 4:23 PM Abhishek Girish <ag...@apache.org>
> > > > wrote:
> > > >
> > > > > My opinion would be option (a) as well. It's easier to maintain a
> > > single
> > > > > master branch. With a separate v2 branch, it's twice the effort to
> > test
> > > > > common commits going in (either directly or via later via rebase).
> > > > >
> > > > > On Wed, Feb 27, 2019 at 12:40 PM Aman Sinha <am...@gmail.com>
> > > wrote:
> > > > >
> > > > > > My personal preference would be option (a)  as much as possible
> > until
> > > > we
> > > > > > get to a situation where it is getting too unwieldy at which
> point
> > we
> > > > > > re-evaluate.
> > > > > >
> > > > > > Aman
> > > > > >
> > > > > > On Wed, Feb 27, 2019 at 12:35 PM Aman Sinha <amansinha@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Hi Drill devs,
> > > > > > > There are couple of ongoing projects - Resource Manager and the
> > > Drill
> > > > > > > Metastore - that are relatively large in scope.  Intermediate
> PRs
> > > > will
> > > > > be
> > > > > > > created for these (for example, there's one open for the
> > metastore
> > > > [1].
> > > > > > > Another one for the RM [2].  These don't currently break
> existing
> > > > > > > functionality, so they have been opened against master branch.
> > > > > > >
> > > > > > > The question is, for future PRs,  would it make sense to
> create a
> > > > > > separate
> > > > > > > Drill 2.0 branch ?  There are pros and cons.  Separate branch
> > would
> > > > > allow
> > > > > > > development on these features to proceed at a faster pace
> without
> > > > > > > disrupting others.  However, in Drill we typically have only
> > > created
> > > > a
> > > > > > > separate branch close to the release, not up-front.  It
> > simplifies
> > > > > > testing
> > > > > > > and maintenance to have a unified master branch.
> > > > > > >
> > > > > > > Another option is feature specific branch.
> > > > > > >
> > > > > > > What do people think about the 3 options:
> > > > > > >  a)  Merge intermediate PRs into Apache master as long as they
> > > don't
> > > > > > break
> > > > > > > existing functionality.  In some cases, temporary config
> options
> > > may
> > > > be
> > > > > > > used to enable new functionality for unit testing.
> > > > > > >  b)  Create a Drill-2.0 branch which will be work-in-progress
> and
> > > be
> > > > > > > periodically sync-ed with master branch.  Code reviews will be
> > done
> > > > > > against
> > > > > > > this branch.
> > > > > > > c)   Have a feature specific branch - e.g for RM, for Metastore
> > > etc.
> > > > > such
> > > > > > > that collaborators can do peer reviews and merge intermediate
> > > > commits.
> > > > > > > These branches will also need to be periodically sync-ed with
> the
> > > > > master
> > > > > > > branch.
> > > > > > >
> > > > > > > Please share your choice of one of these options and any
> > additional
> > > > > > > thoughts.
> > > > > > >
> > > > > > > [1] https://github.com/apache/drill/pull/1646
> > > > > > > [2] https://github.com/apache/drill/pull/1652
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Whether to create separate 2.0 branch

[Sorabh Hamirwasia <sh...@mapr.com>]

Hi,
+1 for 2.0 branch. From RM perspective since we will be adding support for
more richer configuration to support multiple queues, the existing
functionality will be deprecated. This will result in breaking backward
compatibility hence 2.0 branch will be preferred. I think it will be
confusing and also extra work to keep support for both existing and new
queues support for RM.
However I would still prefer the commit process in 2.0 branch to be same as
that in master branch. Review and approved by a committer before check in
and all tests should pass. If we follow these steps then during integration
of the entire feature into master branch, review of 1 big fat PR will not
be required.

Thanks,
Sorabh

On Sun, Mar 3, 2019 at 7:35 PM Aman Sinha <am...@gmail.com> wrote:

> Catching up on this thread since I was traveling and am currently in India
> time zone.
> Interesting suggestion about the C-T-R policy for a potential 2.0 branch.
> I don't recall we have done this for any prior releases.
> In the past, my experience with a separate feature branch (not on apache
> but in a private repo) was that we still did the review-then-commit
> since that's what everyone is accustomed to and most Drill developers tend
> to want early feedback.  This depends on the folks working on the
> specific features.
>
> For the branching, it sounds like people are more inclined towards option
> (a).   Parth does make a good case for 2.0 branch and it would be
> inevitable at some point in future especially for the
> compatibility-breaking functionality.   We would expect the feature
> developers to indicate when
> that time comes.
>
> I believe at least partial support for Arrow is a 2.0 objective.  Hopefully
> one of us can free up from other commitments and start working on it.
>
> Aman
>
> On Thu, Feb 28, 2019 at 9:56 AM Parth Chandra <pa...@apache.org> wrote:
>
> > +1 for a 2.0 branch.
> > Feature specific branches can be created off the 2.0 branch, and should
> > ideally be merged periodically.
> > I would also suggest that we adopt a C-T-R policy [1] for the 2.0 branch
> > until it is at a stable point.
> > Finally, I would assume that it is up to the feature developers to decide
> > whether the feature will maintain backward compatibility or not. 2.0 is
> an
> > opportunity to break backward compatibility so it would be quite
> acceptable
> > for some major features to break compatibility.
> > One major question backward compatibility for 2.0 would be Arrow. If we
> > decide we want to have Arrow support, we would probably break backward
> > compatibility in may ways. If we don't do Arrow support in 2.0, we'll
> > probably never do it. We could, of course, do partial support. For
> > reference see the Spark effort [2]
> >
> > [1] https://www.apache.org/foundation/glossary.html#CommitThenReview
> > [2] https://jira.apache.org/jira/browse/SPARK-26413
> >
> >
> > On Thu, Feb 28, 2019 at 9:26 AM Pritesh Maker <pm...@mapr.com> wrote:
> >
> > > I think option (a) is better in terms of maintaining branches. With
> > option
> > > (a) how do we handle a situation where one of these features breaks
> > > backward compatibility or deprecates some functionality?
> > >
> > > Pritesh
> > >
> > > On Wed, Feb 27, 2019 at 4:23 PM Abhishek Girish <ag...@apache.org>
> > > wrote:
> > >
> > > > My opinion would be option (a) as well. It's easier to maintain a
> > single
> > > > master branch. With a separate v2 branch, it's twice the effort to
> test
> > > > common commits going in (either directly or via later via rebase).
> > > >
> > > > On Wed, Feb 27, 2019 at 12:40 PM Aman Sinha <am...@gmail.com>
> > wrote:
> > > >
> > > > > My personal preference would be option (a)  as much as possible
> until
> > > we
> > > > > get to a situation where it is getting too unwieldy at which point
> we
> > > > > re-evaluate.
> > > > >
> > > > > Aman
> > > > >
> > > > > On Wed, Feb 27, 2019 at 12:35 PM Aman Sinha <am...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hi Drill devs,
> > > > > > There are couple of ongoing projects - Resource Manager and the
> > Drill
> > > > > > Metastore - that are relatively large in scope.  Intermediate PRs
> > > will
> > > > be
> > > > > > created for these (for example, there's one open for the
> metastore
> > > [1].
> > > > > > Another one for the RM [2].  These don't currently break existing
> > > > > > functionality, so they have been opened against master branch.
> > > > > >
> > > > > > The question is, for future PRs,  would it make sense to create a
> > > > > separate
> > > > > > Drill 2.0 branch ?  There are pros and cons.  Separate branch
> would
> > > > allow
> > > > > > development on these features to proceed at a faster pace without
> > > > > > disrupting others.  However, in Drill we typically have only
> > created
> > > a
> > > > > > separate branch close to the release, not up-front.  It
> simplifies
> > > > > testing
> > > > > > and maintenance to have a unified master branch.
> > > > > >
> > > > > > Another option is feature specific branch.
> > > > > >
> > > > > > What do people think about the 3 options:
> > > > > >  a)  Merge intermediate PRs into Apache master as long as they
> > don't
> > > > > break
> > > > > > existing functionality.  In some cases, temporary config options
> > may
> > > be
> > > > > > used to enable new functionality for unit testing.
> > > > > >  b)  Create a Drill-2.0 branch which will be work-in-progress and
> > be
> > > > > > periodically sync-ed with master branch.  Code reviews will be
> done
> > > > > against
> > > > > > this branch.
> > > > > > c)   Have a feature specific branch - e.g for RM, for Metastore
> > etc.
> > > > such
> > > > > > that collaborators can do peer reviews and merge intermediate
> > > commits.
> > > > > > These branches will also need to be periodically sync-ed with the
> > > > master
> > > > > > branch.
> > > > > >
> > > > > > Please share your choice of one of these options and any
> additional
> > > > > > thoughts.
> > > > > >
> > > > > > [1] https://github.com/apache/drill/pull/1646
> > > > > > [2] https://github.com/apache/drill/pull/1652
> > > > > >
> > > > >
> > > >
> > >
> >
>