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.pena@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 <omalley@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
>>