Dear Hannes I assume the announcement on https://blog.chromium.org/2020/03/chrome-and-chrome-os-release-updates.html won't change what you started 2 days ago, right?
Regards, Frank On Tue, Mar 24, 2020 at 12:42 PM Hannes Payer <hpa...@chromium.org> wrote: > 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.0 becomes stable again <https://v8.dev/blog/v8-release-80> > > V8 8.1 is demoted to beta <https://v8.dev/blog/v8-release-81> > > 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 >> <https://groups.google.com/a/chromium.org/g/chromium-dev/c/Vn7uzglqLz0> 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: >> >> 1. >> >> Changing code behind a feature or command line flag. >> 2. >> >> 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. >> 3. >> >> 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: >> >> 1. >> >> 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… >> 2. >> >> 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. >> 3. >> >> 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-eng-rev...@google.com. These guidelines are also in this doc >> <https://docs.google.com/document/d/1dppYMaUK0A0PxzRZC647WsCAAK-8ccuH6l7rMAhdwL8/edit> >> 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 <k...@chromium.org> wrote: >> >>> Howdy folks, >>> >>> As you may have seen >>> <https://blog.chromium.org/2020/03/upcoming-chrome-releases.html>, >>> 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 <https://www.google.com/chrome/canary/> >>> 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: chromium-...@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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAAmRR%2Bwxh%3D2Vp%2BVVBn1CaDM4FXrBJPPstaJXsk6H1AGUKf29HA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > -- > v8-dev mailing list > v8-dev@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+unsubscr...@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 > <https://groups.google.com/d/msgid/v8-dev/4895d9b3-f8c4-41f0-b241-1e3b3be035ae%40chromium.org?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list v8-dev@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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAOcELL9PLsa9YhzzNCJ8LZPq%3DgRX1%2BjXhWYW%3DAuMUOa%2BAwyYuA%40mail.gmail.com.
