Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Committing bug and test fixes to branches

Copy link to this message
Re: Committing bug and test fixes to branches
I think we should have a volunteer on deck as RM for the next major release
at any given time, and so this person would/should be concerned about the
state of trunk. Good idea.

As for me asking for a "soft freeze" on 0.98, I thank you for your
indulgence and it will be a thing of the past after the 0.98.0 release.
On Fri, Jan 3, 2014 at 3:09 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> We currently have 4 branches (0.94, 0.96, 0.98, and trunk).
> For bug and test fixes, do we really need the release managers to agree to
> every single check-in.
> Andy
>  currently wants to stabilize the tests in 0.98 so looking at every
> change there makes sense and was specifically requested by him.
> What about 0.94, 0.96, and trunk. I do not feel like I need to be pinged
> for every bug/test fix for 0.94.
> I
>  would propose that committers use good judgment and commit small
> changes to fix bugs and tests to any branch without a nod from the RMs,
> unless specifically request as with 0.98. If we can't trust a committer
> with that, (s)he should not be a committer.
> For larger fixes and any new feature the RMs should be pinged of course.
> Related to this, it seems we're a little loose with trunk as in "It's OK
> it's just trunk". Trunk will become a release eventually and IMHO we should
> aim for keeping trunk in a releasable state as much as this is possible.
> If we had done that before 0.96, Stack would not have had to face the
> superhuman task of getting 0.96 back to a releasable state.
> Does trunk need a release manager?
> Comments?
> -- Lars

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)