Hi Gene, We'd like to avoid taking change on mozilla-b2g18 that isn't a partner requirement (new features, perf requirements, etc.) or a critical usability/security issue for a couple of reasons. The first is that the risk of uplifting large amount of non-critical code change imposes is typically greater than the one-time risk of backporting when uplifting. The second is that we're trying to limit code change in general so that update size is minimal for v1.x.
We can still evaluate these sorts of changes on a case by case basis though, so don't think this is a hard and fast rule. We just need to be confident that it's riskier to not take the patch than it is to take it (a pretty high bar). -Alex On Jan 31, 2013, at 10:13 PM, Gene Lian <[email protected]> wrote: > Just one quick question about when to use the approval-mozilla-b2g18 tag. > > I understand we usually use this tag to uplift patches for solving critical > bugs or regressions in the b2g18 branch. However, supposing we're having some > *big changes* regarding code refactoring, file renaming or any other changes > that touch lots of lines, which would add difficulties for uplifting patches > in the future since the code bases have gotten diverse, may we ask > approval-mozilla-b2g18 under this circumstance? Or that's exactly one of the > potential drawback we have to afford when it comes to branching? > > Thanks, > Gene > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
