<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - REQUEST: Skia Raster default for the initial release" href="https://bugs.documentfoundation.org/show_bug.cgi?id=133848#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - REQUEST: Skia Raster default for the initial release" href="https://bugs.documentfoundation.org/show_bug.cgi?id=133848">bug 133848</a> from <a class="email" href="mailto:telesto@surfxs.nl" title="Telesto <telesto@surfxs.nl>"> Telesto</a> <pre>(In reply to Luboš Luňák from <a href="show_bug.cgi?id=133848#c3">comment #3</a>) > I disagree. Later patchlevel releases are meant to be more stable than early > x.y.0, so if this really would be a problem, later "more stable" releases > would regress. IMO 7.0.0 is the right release to enable this, to catch these > problems as early as possible with early adopters, before more serious > adopters update to 7.0.2 or so. True, that is the other point of view.. OTOH, the majority of these type of issue appear around 7.0.5 as everybody steps in.. >From (my) QA perspective. Splitting is more ideal IMHO. 7.0 will cause already an increase in reports without Skia Vulkan. So a delay would be welcome.. even if it is 7.0.1.. Based on the release principle 7.0 is the way to go. There are of course a few step ahead B2 RC1/RC2/RC3.. so it's still possibility to evaluate.. However the release principle is only an ideal.. I only wanted to note that there are other considerations also (like QA capacity). But not sure what the general QA opinion is; I would prefer some delay. Even at the cost of (know) regress later on. Downside of course is that 'the early adapters' will run Raster all the time, even after an update with Skia Vulkan enabled by default (caused by profile setting)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>