On Sun, Aug 5, 2012 at 1:25 PM, Adrian Cole <[email protected]> wrote:
> Hi, team.
>
> Andrew B and I have been trying to stabilize trunk, which has been
> difficult due to the number of one-off fixes only made in the 0.7 branch.
> Doing a fix only in a release branch may seem quick-to-value, but it puts a
> burden on future committers. For example, we are wasting a lot of time
> looking through literally >1year old issues trying to figure out what's
> merged vs what isn't.
>
> Can we agree to not put any change that affects trunk on a release branch
> before it works on trunk?
>
+1 We should definitely be doing this.
I just ran the following to find JIRAs that are in branch 0.7, but not in
trunk:
$ comm -23 <(grep WHIRR whirr-0.7/CHANGES.txt | awk '{print substr($1, 1,
length($1) -1)}' | sort) <(grep WHIRR whirr-trunk/CHANGES.txt | awk '{print
substr($1, 1, length($1) -1)}' | sort)
WHIRR-391
WHIRR-517
WHIRR-391 (Write a YARN (Hadoop MR2) service for Whirr) is an anomaly in
CHANGES.txt since YARN is definitely in trunk.
WHIRR-517 (Add a retry loop around apt-get and yum commands to overcome
transient errors) is missing, but I think is now fixed by WHIRR-528.
Thanks to you and Andrew for working to stabilize trunk!
Cheers,
Tom
>
> -A
>
