Thanks for clarifying the branch quality issue. So, maybe I could compare our master to Debian 'testing', and customized branches as 'unstable(s)'.
And for the camera button issue, I don't think it's an technical problem, so I don't even know whether it deserves a bug for the very late involving problem (or, how to mark it as "RESOLVED FIXED"; by guarantee things would not happen again?) Anyway, I raised that because I feel the current situation is we're landing some risky patches (according to its size and changes; unless, and hopefully, they're fully tested on the branch already) and asking others to be slower. I just worry if this is an acceptable working model for FFOS, that any features can ask others to do as less as possible on master, if they got the permission from decision teams. If so, we may need to start some fiercely competitions to get the permission for our own plans as well. And those whom can't get it can only slow the pace until the one get landed. I really hope things like this are only exceptions, but from the past, and not limited to this kind of exceptions, we have too much exceptions that may bring from partners or ourselves' schedules. 2015-06-08 22:45 GMT+08:00 Fabrice Desré <[email protected]>: > 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-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > -- <http://about.me/snowmantw>Greg Weng http://about.me/snowmantw *Understand y f = f [ y f ] ; lose last remaining non-major friend* * -- Anonymous*
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
