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 ;)
Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
