On Wed, Feb 18, 2015, at 10:55 AM, [email protected] wrote: > i agree with julien here. the answer is not more process but pride of > ownership. i've worked with people in the past that no matter what made > sure the components they've touched/owned are as free of bugs as > possible. it has its own challenges -- no question there -- but over > time, it pays for itself.
One area where process interacts is complications from branching and uplifts. Small/trivial fixes made on trunk that aren't uplifted may complicate and/or increase the risk for more important fixes subsequently made on trunk that do need to be uplifted. Small/trivial fixes that do get uplifted still have the hassle cost of providing an uplift request comment and for the effort required for evaluating the request by the approvals team. Things are generally improving on this front. v2.2 approvals have come quickly and with little hassle, for example. But it arguably would have been easier and encouraged papercut fixes even more if we didn't have a 1.5 month time period where v2.2 exists and uplift is granted freely but you still have to manually request it. A process where module owners were allowed to approve patches in their component unless experience proved they were no good at it, or the component was high-risk/high-impact on other components could have been even better. Andrew _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
