> To make life easier for those landing on b2g18, ensure that no patches miss > being uplifted, and to keep commit history more in sync between the branches, > I propose that *only* blocking-b2g:hd+ patches be manually landed on the > v1.1hd tree.
This makes total sense to me. I think we may also want to create an HD bugzilla status flag to further separate 1.1 and 1.1hd bug resolution. -Alex On Jun 4, 2013, at 7:53 AM, Ryan VanderMeulen <[email protected]> wrote: > Hi all, as most of you have probably seen by now, we now have a b2g18 v1.1hd > branch set up for the HD B2G port in development. The plan for this tree is > that it should exactly mirror b2g18 along with additional blocking-b2g:hd+ > patches landing on it. > > To make life easier for those landing on b2g18, ensure that no patches miss > being uplifted, and to keep commit history more in sync between the branches, > I propose that *only* blocking-b2g:hd+ patches be manually landed on the > v1.1hd tree. The v1.1hd repo will be kept in sync with b2g18 via regular > branch merges. While I recognize that this does invite the possibility of > merge conflicts eventually rising, I think this is worthwhile to try until we > find it to be unworkable. > > To be clear - when referring to b2g18 above, I am *ONLY* referring to the > hg-based Gecko repository (hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd), > I am NOT referring to the Git-based Gaia repository (v1.1.0hd branch). It is > my understanding that those uplifts will still need to be double-landed > (CCing jhford to confirm). > > Does this plan make sense for everyone? Ultimately, it should make life > easier for people on the Gecko side of things and IMO it reduces the chances > of mistakes being made. > > -Ryan _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
