Also i dont follow how we remove On Saturday, March 4, 2017, Edward Capriolo <edlinuxg...@gmail.com> wrote:
> > > On Fri, Mar 3, 2017 at 8:46 PM, Thejas Nair <thejas.n...@gmail.com > <javascript:_e(%7B%7D,'cvml','thejas.n...@gmail.com');>> wrote: > >> +1 >> There are some features that are incomplete and what I would not recommend >> for any real production use.The 'legacy authorization mode' is a great >> example of that - >> https://cwiki.apache.org/confluence/display/Hive/Hive+Defaul >> t+Authorization+-+Legacy+Mode >> . It is inherently insecure mode that nobody should be using. >> >> There is also potential to cleanup of the thrift api. However, there are >> many users of this api, we would need to go the deprecation then remove >> after couple of releases route or so for that. >> >> I am sure there are many other candidates. We will have to evaluate each >> of >> those features on the risk/benefit of keeping them and arriving at a >> decision. >> >> Also, +1 on getting a 2.2 release out before we branch. >> >> >> >> On Fri, Mar 3, 2017 at 1:50 PM, Ashutosh Chauhan <hashut...@apache.org >> <javascript:_e(%7B%7D,'cvml','hashut...@apache.org');>> >> wrote: >> >> > Hi all, >> > >> > Hive project has come a long way. With wide-spread adoption also comes >> > expectations. Expectation of being backward compatible and not breaking >> > things. However that doesn't come free of cost and results in lot of >> legacy >> > code which can't be refactored without fear of breaking things. As a >> result >> > project has accumulated lot of debt over time. At the same time there >> are >> > also lot of features which have seen little uptake. We may want to drop >> > some of those. >> > >> > In order to move forward and shed that debt we may need a major version >> > release which allows us to make backward incompatible changes and drop >> > rarely used features. At the same time there are lots of users which are >> > consuming currently released 2.1 , 2.2 branches and expect them to stay >> on >> > it for some time. So, I propose that we create branch-2 from current tip >> > and do future 2.x releases from that branch and keep it backward >> > compatible. This will allow devs to land breaking changes on master and >> > pave way to release hive 3.0 in future. >> > >> > Ofcourse, each specific incompatible change and feature drop even on >> > master need to be evaluated on its own merit on corresponding jira. This >> > email is just a solicitation of feedback for creating branch-2 and >> allowing >> > breaking changes in master. Thoughts? >> > >> > Thanks, >> > Ashutosh >> > >> > > One of the challenges of the developers conducting the risk-benefit > analysis are that the developers are mostly focused on new features, but > there are deployments of hive that are 5+ years old and people that rely on > the features are not on the mailing list. > > For example I developed and use this frequently: > > https://community.hortonworks.com/articles/8861/apache-hive- > groovy-udf-examples.html > > My career went away from hive for a while. I was quite surprised to find > out the cli->beeline it was more or less decided not to port it. I learned > of this the first time I was forced to work in a hive server only > environment and it did not work. > > Now I have to go and spend time adding this back so I don't have to work > around it not being there. > > What we should do continue/doing is making code that is modular we need to > break hard dependencies like ThriftSerde or OrcSerde being "native" and > having to be linked to the metastore move them out into proper submodules. > There is too much code that only works for one implementation of a serde > etc. > > > I would like a timeline to understand this. It sounds as if master is not releasable currently, so already broken in a way. We make a branch and aggreasively break it more? Im not following what makes this branching policy makes adding features faster or how it helps shed debt faster. -- Sorry this was sent from mobile. Will do less grammar and spell check than usual.
