Thanks for this email Stefan, some great points in there. I want to preface this by saying I think we’ve done some incredible work and I’m stoked with what we’ve accomplished this year with iOS.
Now… I’m going to propose one more thing: ui-review. I don’t know how to turn this flag option on in bugzilla, but I think we should. In the past few weeks I’ve seen and filed a number of trivial and non-trivial UI regressions. Some of these regressions have been fixed, but then introduced new ones. As we approach a public release, catching and addressing these things before they ship becomes more and more important. While I sincerely appreciate the care and detail the fine folk building this app put into each patch, I don’t want the engineering team to bear the full responsibility of watching each and every pixel for correctness. My team and I are more than happy to do that (and in fact, want to!) so please don’t ever feel like you’re causing us grief or trouble if you ask us to look at something before it lands. So, tldr: If you’ve got yourself a PR which in any way touches the design (pixels, animations, language, colors, etc) please ui-review? someone from UX – typically darrin or tecgirl for iOS… both is fine. We will do our best to take a look in a timely manner, and accept the pings and pokes you may send if you’ve got something urgent. This will help us feel confident that we are releasing a quality experience, and will let the design team sleep better at night knowing our dear little pixels are safe and sound. Thanks all! Darrin –– Darrin Henein ∙ Design Lead, Firefox Mobile ∙ Mozilla > On Jul 13, 2015, at 2:15 PM, Stefan Arentz <[email protected]> wrote: > > Getting to our most recent test build was a bit of a rough ride. > > I would like to suggest three things: > > 1) We get back to a regular schedule of doing a build every week. At > predictable times so that we all know when it will happen. Additional, Steph > suggested that we do builds for both Aurora and TestFlight on Thursday, but > then only make the Aurora one available immediately and wait till Monday for > the Testflight one. That gives us a little buffer to react to things that > absolutely need to be fixed for our external testers. Ideally there is > nothing and we can just push the 'Publish' button on Monday. And they still > go out on weekly intervals. Specific dates/times can go into the team > calendar so that it is very clear when what happens. > > 2) Run automated tests. We need to get back to a situation where all of our > tests are run on Nightly builds and on each and every PR branch. We currently > run about 140 (!) unit tests but I am not so sure that includes the UI tests. > Which is most likely where we catch regressions. If the UI tests currently > don't work on Xcode Server then we need to fix that. If they are simply > disabled then we need to turn them back on. > > 3) Because we are very close to a release, try not to introduce new > functionality or refactor big chunks of code. We should be extremely careful > with patches that substantially change the internal workings of the app at > this point. If you do need to do that, be sure that we have UI/Unit tests > that cover all the parts that your patch touches. Either directly or > indirectly. If we don't have tests then they need to be written. > > S. > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
