> * blocking-b2g:tef+ is for bugs that we've got agreement with partners about > needing as part of v1.0.0.0
This was my original understanding of this flag, it's not the information that I was told in the triaging sessions we've had the last couple of days. We have been marking many bugs as tef+ even when no partner was attending the meeting, which obviously means that we don't know if it's a partner requirement. So how should we be using this flag? If we are to only mark bugs as tef+ once we've gotten confirmed that it's a partner requirement, should we add some additional flag for things that we want to propose to partners as might needing to be a requirement. I.e. bugs that are passing our initial screening of nominations? > * status-b2g18 represents the fix status on the v1.* branches > > Now for landing. > > * v1.0.0.0 Landing > ** Gecko: mozilla-b2g18 > ** Gaia: master branch > ** Landing requirements: blocking-b2g:tef+ (representing agreement with > partners), and approval-gaia-master:+ or approval-mozilla-b2g18:+ I'm not sure that it makes sense to require both tef+ *and* an approval flag. So far we've not had the approval flag requirement and I think that has enabled us to get patches landed quickly. We do have a lot of regressions, but the types of regressions that I've seen hasn't been once that I think we would have caught by going through an approval step. Requiring this flag *does* have a cost in that it *will* delay the landing of patches. We do have close to 100 bugs to fix and 10 days to do it, so any slow down is putting a lot of risk in our ability to meet that goal. As a data point I'll note that we were able to keep an extremely high rate of bug fixing at the work week, and one of the reasons for this was that we were able to keep very short patch-review-land cycles. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
