We got initial crash logs from Apple this morning -- it looks like the top crasher is a failure in DownloadSectionsOp when creating a dictionary with the downloaded info. Most likely something is coming up null in some corner case we're not catching, and it should be failing out before that gracefully.
-- brion
Looks like the only thing that can come up nil there is the last-modified date; everything else has a guard around it.
However it does seem like it'd be masking a bigger error -- failure to get data in the first place...
-- brion
On Fri, Aug 1, 2014 at 8:41 AM, Brion Vibber bvibber@wikimedia.org wrote:
We got initial crash logs from Apple this morning -- it looks like the top crasher is a failure in DownloadSectionsOp when creating a dictionary with the downloaded info. Most likely something is coming up null in some corner case we're not catching, and it should be failing out before that gracefully.
-- brion
Thanks for looking into the bugs, Brion. Where can I take a look at them? I poked around in iTunes Connect but couldn't find anything. I'd like to get a sense of the magnitude of bugs that we're dealing with.
Anyway, it's not a big deal if the last modified is null... or, at least, I'd rather choose last modified being null as opposed to having the app crash! So let's get that guard in place. We can worry about the larger issue of failing to get data once we've got the crashes smoothed over, somewhat.
Thanks, Dan
Manage apps -> select the app & current version -> 'Crash reports'
It doesn't seem to give an absolute number of crashes (really? wtf) but does give a percentage breakdown of the top crashers... however all of them in this initial report appear to be the same crash. :D
-- brion
On Fri, Aug 1, 2014 at 10:20 AM, Dan Garry dgarry@wikimedia.org wrote:
Thanks for looking into the bugs, Brion. Where can I take a look at them? I poked around in iTunes Connect but couldn't find anything. I'd like to get a sense of the magnitude of bugs that we're dealing with.
Anyway, it's not a big deal if the last modified is null... or, at least, I'd rather choose last modified being null as opposed to having the app crash! So let's get that guard in place. We can worry about the larger issue of failing to get data once we've got the crashes smoothed over, somewhat.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Dan, Tomasz is recommending that for our next push we do a small bug fix iteration from the first release branch, rather than landing all the stuff we've worked on in the last couple weeks right away.
Do we want to push both "small" and "large" updates to TestFlight or should we just send the "small" version?
-- brion
On Fri, Aug 1, 2014 at 10:20 AM, Dan Garry dgarry@wikimedia.org wrote:
Thanks for looking into the bugs, Brion. Where can I take a look at them? I poked around in iTunes Connect but couldn't find anything. I'd like to get a sense of the magnitude of bugs that we're dealing with.
Anyway, it's not a big deal if the last modified is null... or, at least, I'd rather choose last modified being null as opposed to having the app crash! So let's get that guard in place. We can worry about the larger issue of failing to get data once we've got the crashes smoothed over, somewhat.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
On Fri, Aug 1, 2014 at 10:57 AM, Brion Vibber bvibber@wikimedia.org wrote:
Dan, Tomasz is recommending that for our next push we do a small bug fix iteration from the first release branch, rather than landing all the stuff we've worked on in the last couple weeks right away.
We're discussing this on IRC right now if you would like to join Dan. No decision has been made. I want to make sure we have confidence in what we push out and that we don't introduce new issues.
Do we want to push both "small" and "large" updates to TestFlight or should we just send the "small" version?
--tomasz
Yep, if we do a more conservative release I'll want to back port at least the back-button fixes and that crash workaround. :) I'm investigating saved pages now...
-- brion
On Fri, Aug 1, 2014 at 11:11 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Aug 1, 2014 at 10:57 AM, Brion Vibber bvibber@wikimedia.org wrote:
Dan, Tomasz is recommending that for our next push we do a small bug fix iteration from the first release branch, rather than landing all the
stuff
we've worked on in the last couple weeks right away.
We're discussing this on IRC right now if you would like to join Dan. No decision has been made. I want to make sure we have confidence in what we push out and that we don't introduce new issues.
Do we want to push both "small" and "large" updates to TestFlight or
should
we just send the "small" version?
--tomasz
We should definitely make it as small as possible. Our goal here is just to fix the bugs, nothing more. That way we're less likely to introduce additional bugs. We can get the features out later. :-)
Dan
On 1 August 2014 11:34, Brion Vibber bvibber@wikimedia.org wrote:
Yep, if we do a more conservative release I'll want to back port at least the back-button fixes and that crash workaround. :) I'm investigating saved pages now...
-- brion
On Fri, Aug 1, 2014 at 11:11 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Aug 1, 2014 at 10:57 AM, Brion Vibber bvibber@wikimedia.org wrote:
Dan, Tomasz is recommending that for our next push we do a small bug fix iteration from the first release branch, rather than landing all the
stuff
we've worked on in the last couple weeks right away.
We're discussing this on IRC right now if you would like to join Dan. No decision has been made. I want to make sure we have confidence in what we push out and that we don't introduce new issues.
Do we want to push both "small" and "large" updates to TestFlight or
should
we just send the "small" version?
--tomasz
For reference: on IRC we decided to do the next release with all the bug fixes, but without the references. Since gerrit is being a ROYAL PAIN about cherry-picking to branches, we're accomplishing this by temporarily disabling the references code on master and branching there.
-- brion
On Fri, Aug 1, 2014 at 11:35 AM, Dan Garry dgarry@wikimedia.org wrote:
We should definitely make it as small as possible. Our goal here is just to fix the bugs, nothing more. That way we're less likely to introduce additional bugs. We can get the features out later. :-)
Dan
On 1 August 2014 11:34, Brion Vibber bvibber@wikimedia.org wrote:
Yep, if we do a more conservative release I'll want to back port at least the back-button fixes and that crash workaround. :) I'm investigating saved pages now...
-- brion
On Fri, Aug 1, 2014 at 11:11 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Aug 1, 2014 at 10:57 AM, Brion Vibber bvibber@wikimedia.org wrote:
Dan, Tomasz is recommending that for our next push we do a small bug
fix
iteration from the first release branch, rather than landing all the
stuff
we've worked on in the last couple weeks right away.
We're discussing this on IRC right now if you would like to join Dan. No decision has been made. I want to make sure we have confidence in what we push out and that we don't introduce new issues.
Do we want to push both "small" and "large" updates to TestFlight or
should
we just send the "small" version?
--tomasz
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Notably, this bug fix build also includes fixes for the counterintuitive back/forwards behaviour.
Dan
On 1 August 2014 12:45, Brion Vibber bvibber@wikimedia.org wrote:
For reference: on IRC we decided to do the next release with all the bug fixes, but without the references. Since gerrit is being a ROYAL PAIN about cherry-picking to branches, we're accomplishing this by temporarily disabling the references code on master and branching there.
-- brion
On Fri, Aug 1, 2014 at 11:35 AM, Dan Garry dgarry@wikimedia.org wrote:
We should definitely make it as small as possible. Our goal here is just to fix the bugs, nothing more. That way we're less likely to introduce additional bugs. We can get the features out later. :-)
Dan
On 1 August 2014 11:34, Brion Vibber bvibber@wikimedia.org wrote:
Yep, if we do a more conservative release I'll want to back port at least the back-button fixes and that crash workaround. :) I'm investigating saved pages now...
-- brion
On Fri, Aug 1, 2014 at 11:11 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Aug 1, 2014 at 10:57 AM, Brion Vibber bvibber@wikimedia.org wrote:
Dan, Tomasz is recommending that for our next push we do a small bug
fix
iteration from the first release branch, rather than landing all the
stuff
we've worked on in the last couple weeks right away.
We're discussing this on IRC right now if you would like to join Dan. No decision has been made. I want to make sure we have confidence in what we push out and that we don't introduce new issues.
Do we want to push both "small" and "large" updates to TestFlight or
should
we just send the "small" version?
--tomasz
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Ok, I've pushed 4.0.1 (built from "v4.0.1-rc-nonbroken" branch) to Apple, with a hold on release until we approve it. Most likely we won't get approval until Monday or Tuesday as I don't think they run reviews over the weekend.
In the meantime, Monte's pushing out the same version on TestFlight -- this has the new reference code *disabled* for now but all the bug fixes are in.
Please test away via TF and let us know if anything explodes, and if necessary I'll cut a new build and send that to Apple again. Wheeeee!
-- brion
On Fri, Aug 1, 2014 at 12:48 PM, Dan Garry dgarry@wikimedia.org wrote:
Notably, this bug fix build also includes fixes for the counterintuitive back/forwards behaviour.
Dan
On 1 August 2014 12:45, Brion Vibber bvibber@wikimedia.org wrote:
For reference: on IRC we decided to do the next release with all the bug fixes, but without the references. Since gerrit is being a ROYAL PAIN about cherry-picking to branches, we're accomplishing this by temporarily disabling the references code on master and branching there.
-- brion
On Fri, Aug 1, 2014 at 11:35 AM, Dan Garry dgarry@wikimedia.org wrote:
We should definitely make it as small as possible. Our goal here is just to fix the bugs, nothing more. That way we're less likely to introduce additional bugs. We can get the features out later. :-)
Dan
On 1 August 2014 11:34, Brion Vibber bvibber@wikimedia.org wrote:
Yep, if we do a more conservative release I'll want to back port at least the back-button fixes and that crash workaround. :) I'm investigating saved pages now...
-- brion
On Fri, Aug 1, 2014 at 11:11 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Fri, Aug 1, 2014 at 10:57 AM, Brion Vibber bvibber@wikimedia.org wrote:
Dan, Tomasz is recommending that for our next push we do a small bug
fix
iteration from the first release branch, rather than landing all the
stuff
we've worked on in the last couple weeks right away.
We're discussing this on IRC right now if you would like to join Dan. No decision has been made. I want to make sure we have confidence in what we push out and that we don't introduce new issues.
Do we want to push both "small" and "large" updates to TestFlight or
should
we just send the "small" version?
--tomasz
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation