We need to figure out the versioning strategy for this that is not hopelessly confusing. Also, having too many fixes in master as described is a different problem, of not releasing off master often enough. What is to be done with master in this model?
On 16/11/29, 12:37, "Sergio Pena" <sergio.p...@cloudera.com> wrote: >Good, thanks Owen for volunteering. > >I see we have too many bugfixes, features, and improvements on the master >branch. > >A few questions: > >- How or what would be the process for cherry picking those fixes? How >will >you detect which ones are stable and which not? > >- What if others contributors want some patches to be added to the next >release? How can we prove they're stable enough to be included? > >- How can the community help on making this new branch stable? Should we >help on triaging, cherry-picking, testing, others ideas? > >I really agree we should be careful on doing the next feature release >stable. >Having hundred of new bugfixes and improvements on a branch makes >difficult >to validate its quality. > >- Sergio > > >On Tue, Nov 29, 2016 at 12:31 PM, Owen O'Malley <omal...@apache.org> >wrote: > >> Hi all, >> I'd like to volunteer as a Release Manager for making a stable >>feature >> release from branch 2. However, rather than starting with master, I'll >>use >> the 2.1 release and cherry pick fixes and features with a focus on a >>stable >> release and picking features that have been tested at scale. Testing a >>Hive >> release at scale is hard, time consuming, and resource intensive, but I >> think that having a stable release with some of the great features that >> we've put into Hive 2 will help drive adoption of the new branch. >> >> Thanks, >> Owen >>
