On Wed, Sep 10, 2014 at 1:46 PM, Michal Mocny <mmo...@chromium.org> wrote:
> Question is, do you consider the fact that bugs are introduced & discovered > (possibly with pain) a sign that the system is broken, or a sign that the > system is working? > Given when they are discovered (right before release), I consider it a sign of that the system is broken. This delayed the release of 3.6.1 a fair bit, which I personally consider a bad thing. > > I sense that Andrew worries that if work has to land on a feature branch of > this feature branch, it won't get eyeballs. > > I sense that Joe worries that if we land everything/anything in Android-4.0 > it will become unstable, as mistakes are prone to happen (see i.e. recent > issue with black background). > > Personally, I prefer eyeballs and instability to delayed discovery and a > sense of stability, especially for a feature branch like Android-4.0. > 1. It's not a feature branch. This is a branch for the eventual release of 4.0.x. I introduced the many webviews code in a feature branch before it landed. 2. It's up to the person who is introducing the feature to get us interested in the feature branch. > There are workarounds for demos (i.e. create your own branch off of a > known working version), but its not as easy to solve the eyeball problem. > > Actually, it makes the eyeball problem worse. We want MORE eyeballs on 4.0.x, and that works by actually demoing stuff that people can reproduce with that branch. We want to show something that we're planning to release soon, not demoware. Also, it make us accountable to our users, which is important to some of us. > -Michal > > On Wed, Sep 10, 2014 at 3:50 PM, Joe Bowser <bows...@gmail.com> wrote: > > > I think this needs to be thought through more, and I'm extremely wary > when > > you say this is a single commit, especially based on the last couple of > > months and how long it took 3.6 to go through. Given that we have people > > travelling halfway across the planet who intend to show people their work > > in less than two weeks, I would definitely like it if you were to put > this > > in your own branch for testing. > > > > On Wed, Sep 10, 2014 at 12:41 PM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > > > I don't think there'd be much value in that. It'll be a single commit > > > that almost entirely just deletes lines. > > > > > > What do you think about the never auto-pausing on backgrounding? or > > > about auto-pausing when intent sending? > > > > > > On Wed, Sep 10, 2014 at 12:32 PM, Joe Bowser <bows...@gmail.com> > wrote: > > > > Can you put this on its own branch before it lands in 4.0.x? That'd > be > > > > awesome! > > > > > > > > On Tue, Sep 9, 2014 at 5:32 PM, Andrew Grieve <agri...@chromium.org> > > > wrote: > > > >> > > > >> For cordova-android 4.0, I'd like to go as far as just deleting the > > > >> "KeepRunning" <preference>. > > > >> > > > >> Apps get a "pause" event when they are backgrounded, and they can do > > > >> any pause-type logic there (e.g. unlisten to accelerometer events or > > > >> pausing audio). > > > >> > > > >> Any strong objections? > > > >> > > > >> On Tue, Sep 9, 2014 at 4:27 PM, Andrew Grieve <agri...@chromium.org > > > > > >> wrote: > > > >> > Commit description: If multitasking is turned on > (keepRunning=true), > > > >> > then temporarily disable it when starting a new activity that > > returns > > > >> > a result - such as camera. > > > >> > > > > >> > > > > >> > > > > > > > https://github.com/apache/cordova-android/commit/26adfb634651196106fb5b66f15eecb535a06d82 > > > >> > > > > >> > Bryce / anyone - clues as to *why* we'd want to disable JS timers > > when > > > >> > firing off an intent? > > > > > > > > > > > > > >
