Hacker News Reader

Comment by rtpg | Hacker News Reader

Is there any good faith read of this that people can lend credence to? The one I could maybe come up with (with their mention of stability) is "we want OSes derived from AOSP to be stable, instead of following main too closely". They mention third party devs working off of stable too... so maybe they're like "instead of dealing with outside contributors messing around with our 'wip' stuff, we'll sign up for integration work".

View on HN

Almost all device run on the initial android release (QPR0), and never shipped any of quarterly updates. Even less so using _main_ as a baseline so that point is moot.

With android 16 introducing "mid releases" (QPR2), they expect OEMs to start shipping those as well, QCOM already has a QPR2 BSP release, and Samsung is expected to release QPR2 based builds soon.

As far as contributions go, google usually wanted patches to apply to main, I don't think that ever changed. And even there now that AOSP development is fully closed, it's even easier as partners will likely just upload patches against internal main instead. Less integration work there as well.

There really isn't a good explanation as to why they want to do move code drop cadence, other than they can and want to avoid wasting time releasing QPR1/3 that no OEM ever shipped (expect Pixels that is)

Android's foundation has been mostly stable for years now, with fairly minor changes between releases. So I guess they just don't want to deal with too many versions to document and support, given that device vendors are generally awful.

Also for a long time they were doing yearly (or longer) release, afaiu it's only the past two years that they switched to quarterly (with the QPR release).

So the source code will be released in a kind of FreeBSD releases? These pieces work together, base things off them, don't mess with (or even see) any WIP stuff.

In other words, the result is still open, but the development process is not.

I don't work on Android, but I suspect it's a whole lot less work for both confidentiality and maintenance to not have to worry about daily/weekly OSS releases. That's probably worth more to the decisionmakers than the value of random contributions from people who aren't already inside the partner tent.

[edit] based on the other comments, I surmise that public pushes were already infrequent.

> the result is still open, but the development process is not.

Is the source code available at all times? This is a genuine question, I don't know right now.

Cost, I assume. It’s expensive to do releases, both in CI and release operations costs.

Maybe less fragmentation?

Sure. Development at Google is glacially slow because nobody does any work, and so they're only publishing releases bi-annually because there aren't enough substantive changes to make quarterly releases seem important. This will also allow the teams to move to biannual OKRs instead of quarterly, which lets ICs and line managers do half as much work while giving executives justification for why they need twice as much headcount.

When it comes to large bureaucracies, always assume laziness over malice or strategic competence.

Reply on news.ycombinator.com