[HN Gopher] Speeding up Chrome's release cycle
___________________________________________________________________
Speeding up Chrome's release cycle
Author : twapi
Score : 63 points
Date : 2021-03-04 18:08 UTC (4 hours ago)
(HTM) web link (blog.chromium.org)
(TXT) w3m dump (blog.chromium.org)
| baggy_trough wrote:
| Extended support release = 8 weeks? lol
| hartator wrote:
| I rather them to slow down and address the performance issues.
| war1025 wrote:
| Release cadence and performance issues are orthogonal.
|
| Frequent releases just mean you get updates as they become
| available. That doesn't mean they can't take on longer-term
| issues that need several release cycles to complete.
| lukifer wrote:
| Have they given any follow-up to the https://chromeisbad.com
| fiasco?
| jasonvorhe wrote:
| Has there ever been a deeper investigation into this that
| goes beyond "I did a thing on my computer and something
| changed somehow"?
| coldtea wrote:
| Well, if by "fiasco" we mean "a random person wrote some
| random observations about his computer and chrome on some
| random website" then, probably they don't really need to
| follow up on it...
| vinger wrote:
| I think it's important and may explain a lot. The fact that
| they started looking into this is a good sign.
|
| I've always wondered what the slowdown with having chrome
| or not was and this could explain it.
| smoldesu wrote:
| Looks like a MacOS issue to me. I used Chrome for years on my
| x201 with i3, it idled only a few degrees above room temp
| with Chrome open.
| jeffbee wrote:
| Chrome project has a pretty robust system of continuous
| benchmarking where regressions are automatically detected and
| filed as bugs, and the causing CLs are automatically found by
| bisection. For example, a recent regression:
|
| https://bugs.chromium.org/p/chromium/issues/detail?id=117656...
|
| What, in your expert opinion, is missing from this regime?
| dvfjsdhgfv wrote:
| Thank you, but this is not necessary. If you ever asked for
| feedback (but you haven't) and based your actions on it (which
| you won't), you would make the release cycle much slower, you
| would inform the user about the upgrade, you would tell them
| which options are going to disappear and what will be broken, and
| you would give them the option to at least delay the upgrade. You
| also would ask their permission to run the Software Reporter
| tool, and it wouldn't report its findings to you.
| vxNsr wrote:
| But you don't understand google engineers know best, they know
| what's good for you my sweet summer child, you're just a
| toddler who needs to be cradled and kept from ever being able
| to make decisions.
| nickhalfasleep wrote:
| This is an arms race to keep control of their browser market
| share.
| jdxcode wrote:
| Every time that Chrome updates I have to give it macOS permission
| to access my location (if I want my location available to any web
| page at least).
|
| Is there a way to make this permanent anyone is aware of?
| heisenbit wrote:
| Even if they managed to make releasing easier for themselves and
| can keep the pure release overhead the same this can impact
| development. These shorter release cycles can make it harder to
| make larger changes and can add overhead for breaking and
| coordinating changes across releases.
| exac wrote:
| Just because the release cycle is faster, doesn't mean that
| features spend less time in alpha/beta channels. Evergreen
| browsers release features behind flags, and those features can
| sit sometimes for years before they're turned on by default in
| the public release channel.
| londons_explore wrote:
| This seems like it might be some middle management trying to make
| a big 'impactful' change that won't really change anything...
|
| Changing from a 6 week release cycle to a 4+8 week release cycle
| seems to be exactly that - in reality, nothing will really
| change.
| minikites wrote:
| Google wants to own the entire web just like Microsoft did when
| they shipped IE6, but somehow the people who were mad when
| Microsoft did it actually love that Google is doing it.
| duhi88 wrote:
| Now if Safari would only do the same...
| alphabettsy wrote:
| For me, Safari is much better with resources and generally
| faster. If longer release cycles is what maintains that I'm
| fine with it.
| bemused wrote:
| so Chrome 94 will be released on 09/21 and Firefox 94 on 10/05 ..
| what a coincidence, seems like 'my version number is bigger then
| yours' is still a thing in 2021 ;)
|
| anyways, I like having these aligned - one number less to keep
| track of
| zerocrates wrote:
| I don't know that I'm ready for these to be in triple digits.
| capableweb wrote:
| Maybe we'll see versioning ala Ubuntu in the future, "Firefox
| 21.03.04" for todays release. Append more digits if you start
| doing more than one per day.
| kubanczyk wrote:
| And... Fail when you reach 256 releases per day, or the
| year 2256.
| caslon wrote:
| Google: Making it even less likely there's anything other than
| Blink that implements the most recent HTML* spec since 2013.
| Chris_Newton wrote:
| I wish the evergreen browsers would ease back on the pace of
| releases. Most sites and apps can't use bleeding edge features in
| production anyway for a variety of reasons. One of those reasons
| is low quality of implementation, for example if a feature is
| supported in theory but the rendering looks awful in one or more
| major browsers when it's used in practice. Another is
| inconsistent implementation across browsers that need to be
| supported. Both of these areas have suffered noticeably in the
| modern era of rolling updates and the dubious concept of "living
| standards". With the increasing significance of the web as an
| application platform and not just a medium for content delivery,
| developers need stability and clear specifications or the quality
| and longevity of their own products will inevitably suffer.
| yjftsjthsd-h wrote:
| I mean, Firefox ESR works pretty well.
| Chris_Newton wrote:
| But developers need to support the browsers their audience
| choose to use, and as sad as it is, Firefox simply doesn't
| have the market share today that it once did. Even if my
| amazing new web app runs perfectly in Firefox ESR, that isn't
| going to help me if Chrome pushes out an update that breaks
| something for half my users.
| cma wrote:
| Performance has gotten really bad recently, I don't know if it is
| GPU drivers or Chrome's fault, but it has gotten very stuttery.
| butz wrote:
| It might be fault of websites too, they are constantly adding
| new features and "improving UX".
| agumonkey wrote:
| * { filter: none !important;
| transition: none !important; }
|
| newest css reset addition
| AshleysBrain wrote:
| I always thought that for a project this size, a 6 week release
| cycle was already super aggressive. We came from pretty much
| annual releases back in the IE days, so it made a huge difference
| to go to rapid releases. Does trimming another 2 weeks off really
| make a big difference to how quickly features arrive? I feel kind
| of sceptical that it's a meaningful difference. I would also
| guess a risk is that with less time on the pre-stable channels
| for testing, there might actually be more bugs and issues as a
| result. I'd be interested to hear the arguments in favour, which
| the blog post doesn't seem to go in to any real detail about.
| SkyPuncher wrote:
| In a sprint cycle, you really need to consider timing of both
| one and two sprints if you want to try to maintain stable
| sprints. If a bug comes in just after the start of a sprint, it
| may be until the end of the next sprint that it ships.
|
| In this case, 2 weeks cuts a month off your "2orst" case
| delivery timeframe.
| cle wrote:
| I believe it's a mistake to assume that this change is solely
| to deliver features to users faster. There are all kinds of
| other things in Chrome other than end-user features.
|
| One important thing would be security updates.
|
| Chrome also has mechanisms that feed back into core Google
| businesses, so this also might improve Google's ability to
| iterate on those faster, gather feedback and make business
| decisions faster, etc.
|
| Personally I want to avoid Google's "core business" as much as
| possible, so if that's a major reason for this change then it's
| even more motivation to stay off of Chrome.
|
| (This is all speculation, since Google doesn't really have any
| credibility to me anymore, so I won't believe any official
| reasons they have for doing this.)
| dralley wrote:
| If your goal is faster security updates you need bugfix
| releases, not faster major releases.
| deadmutex wrote:
| > I would also guess a risk is that with less time on the pre-
| stable channels for testing, there might actually be more bugs
| and issues as a result
|
| Is it also possible that a shorter window would allow less
| number of features being in flux in each release? Perhaps that
| actually leads to easier bug triaging, etc.
|
| Disclaimer: Work at Google, but not on Chrome.
| dralley wrote:
| Why not just do bugfix releases? Much less risk...
| lkbm wrote:
| That's not the issue.
|
| If you release two changes at once and a bug appears, you
| look at those two changes.
|
| If you release ten changes at once and a bug appears, you
| have ten things to look into.
|
| In either case, you do a bugfix release, but finding the
| source of the bug is much easier if you do smaller
| releases.
| mrighele wrote:
| On the other side, if you release the software more
| often, there is an higher probability for a bug to end up
| in the hands of the users instead of being found
| internally. Given that most people won't ever report a
| bug, do like firefox and give to willing people a
| nightly/developer/preview edition and to regular people
| something released less often.
| Chris_Newton wrote:
| IMHO, this isn't a compelling argument. For a large
| application like a browser, even releasing every few
| weeks, surely there will not be two or ten changes since
| the last release but probably hundreds. If a bug makes it
| into a new release and none of the developers sees the
| report and immediately realises where it probably came
| from, won't they look for a more systematic method to
| identify when it started happening than manually
| examining every change since the last release?
| jsnell wrote:
| The latency is higher than that, but just hidden by pipelining.
| It seems that this should reduce latency from commit to prod by
| 3 weeks (from about 13w to 10w).
| 0xDEEPFAC wrote:
| Great, just what we need... more updates, downloads, and EULA
| changes.
|
| I am tired of updating everything, and it often leads to
| rushed/less performant software because - hey we'll fix it soon
| anyway as long as we meet the deadline right? Or, even worse,
| like Microsoft openly using customers as beta testers.
|
| Also, anyone notice these days how we used to be excited about
| buying or getting an "upgrade" and now we get pestered about
| "updates"... interesting semantic difference..
| remus wrote:
| Maybe it's just me but I can't remember the last time I had to
| think about a chrome update/download/EULA change. Personally I
| think that's great, they aren't things I want to spend my time
| on so if they're automated than all the better imo.
| 0xDEEPFAC wrote:
| Just because they don't make it explicit doesn't mean its not
| changing. I could be wrong though.
| antisthenes wrote:
| Why aren't browsers feature-complete?
|
| I know someone has to justify employing those people, but
| honestly, where is the browser that just works by default for the
| 99.9% of simple use cases and isn't a resource hog?
|
| We don't need a separate sandboxed OS eating 4GB of RAM just to
| display 5KB of text (and 2MB of javascript). Maybe focus on that,
| if any Googlers are reading.
| kibwen wrote:
| _> Why aren 't browsers feature-complete?_
|
| Because other browsers keep adding features, and then web sites
| start using those features. Any browser that stops adding
| features eventually finds itself unable to display certain
| sites, and loses users to browsers that can display those
| sites.
|
| Which is to say (channeling Zawinski's Law), any browser that
| fails to add features will eventually be replaced by a browser
| that does.
| jakub_g wrote:
| Google's strategical view is to make web browser as capable as
| the native apps on mobile (mostly to counterbalance the iOS
| native apps' walled garden). It's called Project Fugu.
|
| I don't expect them to stop shipping any time soon.
|
| (Meanwhile Firefox's agenda is to push web forward but keep the
| balance; and Apple's agenda is to keep browser fast with
| minimal bloat, and lately privacy as an anti-Google selling
| point; and evolve the browser in other aspects just to not
| become the next IE and avoid lawsuits for blocking other
| rendering engines on iOS).
|
| Up to you to choose your preferred one.
___________________________________________________________________
(page generated 2021-03-04 23:02 UTC)