On Mon, Jun 8, 2015 at 4:45 PM, Fabrice Desré <[email protected]> wrote:
> On 06/07/2015 11:32 PM, Gabriele Svelto wrote: > > On 08/06/2015 04:19, Greg Weng wrote: > >> BTW, I don't know why we looks like to have no standard working model > >> for "risky" patches. I mean, as Vivien mentioned, and what I've seen > >> in other OSS projects, to create a new branch for such radical changes > >> is a 100% rational action. > > > > +1 > > > > If we need to stabilize something we should branch it in due time. > > Similarly if one needs to land a large, complex patch-set the best > > option is also to branch and work on that until it's safe enough to > > merge back into master. Arguably one should avoid that entirely by > > splitting up work into smaller incremental steps if possible. > > The features for Spark were first developed on branches (including a > dedicated gecko repo). As far as I know, all the patches went through > the usual review process when merging to master/m-c happened. If > something went wrong there (like the camera button/lockscreen issue), > file a bug, etc. No need to stop the world for that, and please no > "hidden agenda" theory. > > Nightly builds should be stable enough to be fully usable (ie. no data > loss, no smoketest blocker, no broken updater). This has been the case > for firefox desktop & android for many years, and should be no different > for b2g. If you fear your changes may break nightlies, ask QA for a > smoketest of your build, and then blame QA if something goes wrong ;) > I do think we all agree that our master branch is not something that should be broken. My question is more: Is there any value from spark to ride master during those 2-3 weeks instead of branching and have a control over what's landed or not ? Spark patches can continue to land on master, like other patches. But nothing prevent to have a 'stable' branch where spark patches are landing as well. Not doing will expose spark to regressions, risky patches or not. > Fabrice > -- > Fabrice Desré > b2g team > Mozilla Corporation >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
