One aspect we should consider is git history - working on feature branch tends to produce a complicated git tree with many merges instead of the linear tree that we get by working on master directly.
On Tue, May 1, 2018 at 8:57 AM, Na Li <lina...@cloudera.com> wrote: > 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? > > > > >
