<div dir="ltr">On Thu, Nov 26, 2015 at 7:59 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From the earlier thread about aurora uplifts on firefox-dev (I'm crossposting to m.d.platform, please follow-up on fx-dev because that's where the original thread was.):<br>
<br>
On 22/11/2015 15:41, L. David Baron wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is a significant part of the instability on aurora related to things<br>
that land on aurora, rather than things that are unstable on nightly<br>
and then are uplifted to aurora every 6 weeks?<br>
<br>
I think if we're worried about crashes on aurora, we should be<br>
putting more resources into quickly filing and quickly fixing (or<br>
backing out) crash regressions on both nightly and aurora.  My<br>
understanding is that we spend most of our topcrash-chasing<br>
resources on stages later in the release train.<br>
[...]<br>
Letting low quality hang around on nightly and aurora for extended<br>
periods of time just improves the chances that some of it will get<br>
through to release.  If we want to address issues of quality on<br>
those channels, I'd rather use a project management process that<br>
looks more like sheriffing than one that looks like approvals.<br>
</blockquote>
<br>
On 23/11/2015 14:33, Robert Kaiser wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I fully agree, but we don't have the resources. My job is release quality (including stability), so I concentrate first on what is on or near release, and only as time allows take a look at Dev Edition and Nightly - which due to frequent fires on beta is very rare.<br>
In addition, we recently lost the only developer that was focused on looking at crashes (dmajor) with no replacement in sight. He looked at and found a number of issues on Nightly pretty fast, esp. as he knew what things mean when looking at code. I'm convinced we'll need someone like that again - plus additional people to look at data and identify issues.<br>
</blockquote>
<br>
What's the best way forward from this? It sounds to me like there are a number of things we could do (not necessarily exclusive):<br>
- "a project management process that looks more like sheriffing than one that looks like approvals" -- dbaron, can you expand on that? What do you have in mind?<br></blockquote><div><br></div><div>One change that we're making that may be related is to redefine the process around the merge. Currently all code merges from m-c -> m-a and m-a -> m-b automatically on set days. Instead, we are working on clear quality criteria that need to be met before code can move to the next branch. This means that you have to prove that work is ready rather than just getting the green light because you managed to land on time. This is not fully flushed out and is being worked on by relman, RyanVM, and our SV teams to start.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- increase our focus on automated testing. I've heard suggestions that we should hire people to just write more tests, or force more landings to come with tests.<br></blockquote><div><br></div><div>I think the first step is understanding where our testing is deficient. For this the plan is to integrate code coverage into our process to identify areas of the codebase that are not well covered and identify when new code is being introduced without suitable automated testing. We'll start with C++ but plan to incorporate JS when it's ready as well. (See Gijs' other thread.)<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- increase our use of static analysis / linting / automated scanning of things. I posted something else for the JS side of this. On the compiled code side of things, Sylvestre, do you know if any of the tools we're currently using are being run on checkins / every day to detect *newly introduced* problems specifically, and to file bugs on them (which we should be able to automate with the bugzilla API, I think)? Is there anything we can ramp up / improve there?<br></blockquote><div><br></div><div>There is nothing currently running on checkin but running on review is the plan. Sylvestre is hiring a contractor to help with the existing backlog of issues identified by static analysis and to determine a set of rules that can be used in day-to-day use. The plan is to integrate static analysis and linting as automatic reviews in MozReview.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- increase the manual testing we do of things that happen on Nightly. Ryan, can you comment on this? It seems we have the possibility to get extra QE attention for "new" projects we land on Nightly. Are there (other) people focused on quality/smoketesting things on nightly?<br></blockquote><div><br></div><div>Ryan's team is focused on Firefox features on Nightly. Note that platform work that is unrelated to Firefox features is currently out of scope and something that we have to figure out how to cover. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- I notice from bugmail that we have days when new volunteers help verify fixed bugs, but this mostly happens when those bugs are on the release/beta channel at that point. How stretched are we for capacity to do that on Nightly instead? Mike, how easy would it be to adapt the tool we have for triage to give people bugs to verify? Same question for things like filing topcrashers and getting regression ranges / STR for them... Robert, are there simple instructions for how to examine and file topcrashes on MDN/wikimo? If not, would you be able to write some?<br></blockquote><div><br></div><div>At least part of this likely falls on Ryan's team. I like the idea of getting more people involved here. We need to figure out how to do that effectively. (I think mhoye likely has ideas.)<br><br></div><div>We also have a new hire joining the relman team at the beginning of Jan who will focus on Nightly quality. This is a technical role and the expectation is that this person will contribute tools to help manage the release including stability tooling.<br><br></div><div>As chofmann wrote, one of the biggest changes that we need to make is to change the mindset about quality on prerelease channels and the quality that we'll accept before shipping to release. We need to address issues earlier and ship better code. We ship known regressions - some user visible - in every release. Some of these bugs are simply not prioritized for fixing. Others are in Bugzilla but not identified early enough. Our process should be one where we iteratively improve instead of stabilizing every single cycle. This takes tools, process, and cultural changes, that latter IMO being the hardest to make.<br></div><div><br></div><div>Lawrence<br></div></div></div></div>