Steve, I am OK for ABAC to be on feature branch if you make sure 1) pull latest master to your feature branch 2) Let us review your changes with all unit tests pass.
Thanks, Lina On Tue, May 1, 2018 at 10:48 AM, Stephen Moist <mo...@cloudera.com> wrote: > I’m fine with putting everything into a feature branch for now. Right > now, the initial ABAC patch is a working solution. It’s not the final > solution that we plan to deliver. We could keep iterating on SENTRY-2201 < > https://issues.apache.org/jira/browse/SENTRY-2201> and adding more code > to a single patch and merge it back into master. I don’t think anyone in > the community is going to want to review a 10mb patch. So, I think going > forward, we will submit patches to an abac feature branch. We plan to keep > iterating and expanding on the code base. We want to always have a end to > end working solution at all time that our QA team can test. Once the > Sentry community feels that abac is stable, we can merge it into master. > This way it 1) doesn’t impact Sentry 2.1 2) We don’t ship an incomplete > feature in 2.1 3)We can keep moving forward with development. > > With that said, I expect then the Sentry community (and more specifically > Committers) to stay on top of the changes we’re making to this feature > branch. I don’t want everyone to ignore it for a few months and then start > re-reveiwing with it as we merge it back into master when we get to the end. > > Does this sound good to the community? > > > On Apr 30, 2018, at 6:35 PM, Alexander Kolbasov <ak...@cloudera.com> > wrote: > > > > Stephen, > > > > a lot depends on your plans in terms of breaking functionality. For > > example, one of the reasons Sentry HA was developed on a feature branch > was > > because it was a serious change in architecture and in broke > functionality > > for a while. I think some of the merge problems which Sergio referred to > > were caused by poor planning and communication - I think we are in much > > better shape now. > > > > One thing I would be concerned (in case you do your development in master > > branch) is that we end up shipping a release with half-baked feature > where > > there is a bunch of things that are there for the future but not really > > used. If you think this isn't a really a problem, developing on master is > > fine since it will automatically handle any potential conflicts with > > fine-grained privileges changes. > > > > Alex > > > > On Thu, Apr 26, 2018 at 9:08 AM, Stephen Moist <mo...@cloudera.com> > wrote: > > > >> Hey all, what does the current roadmap and release schedule look like > for > >> FGP and ABAC? I’ve been told that FGP is going out in the next release, > >> ABAC is more slated for the summer. How do we want to handle > simultaneous > >> development of these features? For ABAC, our dev process is more agile. > >> So while we have a working version of ABAC right now in review, it’s not > >> the final solution. We plan to iterate, improve, fix and add features > to > >> it over the next few months. I had talked with Kalyan and Sergio > offline > >> once, they don’t like large patches and recommended not using a feature > >> branch. I don’t see an issue with continuing to develop ABAC and FGP at > >> the same time and committing both to master. We’ll add a switch in > ABAC to > >> turn the feature off for now through the next release. What does the > >> community think about supporting development of two different features > at > >> once? > >
