V8 Development Guidelines During Chrome Release Pause & Release Update
Hannes Payer
Hi v8-dev,
Since the Chrome release is currently paused (see details below, posted on the Chromium-dev mailing list) V8 is going to follow the announced Chromium guidelines:
1) keep master stable and reliable
2) ensure that we can safely and easily merge fixes to V8 8.0 or 8.1
If you are working on a project and have questions please reach out to the owners to check if code can land in a given component.
Updated V8 release plan to stay in sync with the Chrome release:
V8 8.2 will be skipped
V8 8.3 is master
Thank you for your understanding,
Hannes, on behalf of the V8 team
On Thursday, March 19, 2020 at 8:24:06 PM UTC+1, John Abd-El-Malek wrote:
Hi everyone, on behalf of eng-review we wanted to provide some more guidance about what kind of changes should or shouldn’t land on trunk while Chrome is pausing releases and working to ensure stability for our users.The main objectives are:
1) Keep the trunk stable and reliable, so that once we restart releases we don’t end up with many bugs that delay trunk going to stable.
2) Ensure that we can merge fixes to M80 or M81 when needed.
If we had perfect test coverage 1) wouldn’t need to be stated. However we know that subtle bugs can creep in small or large changes. Ways to decrease the risk include:
Changing code behind a feature or command line flag.
If there’s cleanup work that you see as part of a change but isn’t required, file a bug and fix it when we’re out of this phase.
As always, all code needs automated test coverage. If you’re editing code (whether behind a flag or not) that didn’t have automated tests, now more than ever it’s important to add tests to ensure your CL doesn’t introduce any unintended behavioral change. Take advantage of the code coverage bots to verify this is the case.
For 2) the main concern is that refactoring changes make merges of fixes to the release branch hard or could break things in subtle ways that are hard to catch with tests. Ways to decrease the risk include:
Avoid refactoring changes that aren’t necessary for your team to execute in the near term. This includes things like refactorings for code health rotation, IPC conversions etc…
Consider if the code being refactored has been modified recently. Code with fewer recent modifications is unlikely to have recently added bugs that would require fixing and merging therefore changes in these areas are less likely to disturb critical merges.
Make your refactoring change behavior-free so that it’s easy for reviewers to confirm this. If there’s behavior changes needed, do them in a follow up which would be small and easy to review (see c) above).
Note that the above guidance does not mean you should stop working on feature work provided that the code you're introducing meets the guidelines above. Having said that, different teams may be assessing priorities and choosing to use this time to double down to test automation or other areas. Please check with your TL or manager.
We understand that these guidelines will affect some of your work; we are working towards loosening these requirements as we better understand the constraints we have in resuming releases. Expect further guidance around releases and our plans there in the near future.
If you have any feedback or questions, email us at chrome-e...@google.com. These guidelines are also in this doc if you want to share it or in case we provide more updates. If there are any major guidance changes we'll update this thread, but for minor clarifications the doc will be updated silently.
Thank you
John, on behalf of chome-eng-review
On Wed, Mar 18, 2020 at 5:23 PM Jason Kersey <ke...@chromium.org> wrote:--Howdy folks,
As you may have seen, we’ve currently paused the Chromium release schedule as we work to transition much of our testing and development to happen remotely. Our top objective is to keep trunk/master in a stable, reliable state.
This means in practice we will not be promoting new milestones to stable during this period and that the scheduled release of M81 will stay on hold pending our decision to resume releases.
For our upcoming releases, we’re currently evaluating what we will do for M82 which branched last week. We plan to release another Dev channel release of M82 this week to gather more stability data. For M83, we’ll continue shipping Canaries as planned, and pending the decision for M82, will begin shipping Dev channels again in the near future.
We’re hoping to provide an update in the next week around our future plans for resumption of releases.
What you can do to help
While our release schedule is paused, it’s critical that we keep the trunk/master in a stable, healthy state. This is where you can help:
Add the test coverage you’ve always wanted to, but haven’t had the time. Deflake your existing disabled tests would be great too! This helps avoid regressing the trunk, reduces our reliance on manual testing, and derisks our return to schedule.
Think some documentation is lacking? Please help work on improving it! Now is a great time to write that design doc or process doc you’ve been dreaming of.
In general, please avoid code changes that make merges hard (e.g. large refactors) or require a lot of branch bake time. The more of these we accrue, the harder it will be to get a stable branch and builds.
As much as possible, all behavioral changes should be behind (off-by-default) flags. That allows you to land new code, while delaying activating it until we're ready to resume releases.
Please use the Canary channel and file/investigate bugs. This is more helpful than ever to ensure trunk/master is healthy and releasable!
We know this may not answer all your questions, especially with regards to work that fundamentally causes a lot of churn. We haven't forgotten about these topics, but for the next few weeks we'd like people to focus on the work above where possible, and be extra cautious about changes that may be destabilizing. Thank you for your patience and understanding in these extraordinary times.
Jason, on behalf of Chromium Operations
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAmRR%2Bwxh%3D2Vp%2BVVBn1CaDM4FXrBJPPstaJXsk6H1AGUKf29HA%40mail.gmail.com.
Frank Tang
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAmRR%2Bwxh%3D2Vp%2BVVBn1CaDM4FXrBJPPstaJXsk6H1AGUKf29HA%40mail.gmail.com.
--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/4895d9b3-f8c4-41f0-b241-1e3b3be035ae%40chromium.org.
Hannes Payer
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAOcELL9PLsa9YhzzNCJ8LZPq%3DgRX1%2BjXhWYW%3DAuMUOa%2BAwyYuA%40mail.gmail.com.
| Hannes Payer | | V8 | | Google Germany GmbH | | Erika-Mann Str. 33, 80636 München |