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 > > >