My major concern is having master branch in an inconsistent state where
some parts are there but some parts are not. I guess as long as new changes
do not break any existing functionality, working on master branch should be
ok, but otherwise I would be worried.


On Mon, Mar 26, 2018 at 3:13 PM, Sergio Pena <sergio.p...@cloudera.com>
wrote:

> The plan I prefer is to commit patches on the master branch and not a
> feature branch. This is to avoid the issues we had with Sentry HA and syncs
> with master. I've worked in a feature branch in the past, and we had
> several merge commits on the feature branch just to keep it in sync with
> master. Some people then like to merge the feature branch into master as a
> one single commit which I don't like to have.
>
> Being finer grained privileges and owner privileges the only important
> feature that will be available in Sentry 2.1, I think it makes sense to
> continue with that path unless there are other features planned for 2.1 and
> we cannot guarantee to have FGP ready by 2.1?
>
> On Mon, Mar 26, 2018 at 4:28 PM, Alexander Kolbasov <ak...@cloudera.com>
> wrote:
>
> > There is one thing I'd like to clarify. What is the plan for all the work
> > around introducing fine-grained permissions managed by Sentry - do you
> > intend to do the work in a feature branch and merge the whole thing when
> it
> > is ready - similar to the way Sentry HA was done or you intend to
> directly
> > work in master instead? I think this warrants an explicit discussion.
> >
> > - Alex
> >
>

Reply via email to