meta-browser: Drop gatesgarth support?

[rakuco]

Per https://wiki.yoctoproject.org/wiki/Releases the gatesgarth branch is no longer supported. Does it make sense to remove it from LAYERSERIES_COMPAT for both meta-chromium and meta-firefox? Not sure how useful this is since dunfell is still supported and is older.

[msisov]

Yes, I think it does. At least, I no longer do test builds on gatesgarth.

[shr-project]

Not sure if it's worth removing, it's a bit pain to add it a back from distro layer and as long as someone is testing meta-browser with dunfell it's quite likely still compatible with gatesgarth as well.

It's still useful for people to be able to test their OE release upgrade in couple intermediate steps (e.g. when they will be upgrading between LTS from dunfell to kirkstone, it's a lot of changes in one step and if something goes wrong, it's very useful to have gatesgarth, hardknott and honister builds in between to "bisect" at least in 4 huge chunks :).

[rwmacleod]

I don't see a branch for gatesgarth or hardknott and while using master works, it would be better to have release specific branches even if it's just a merge from master. I don't think that's a significant overhead, is it? I expect that at some point, there will be incompatible changes that will require separate branches. What's the plan over the coming years for gatesgarth, hardknott, ... branches as we try to keep the latest version of chromium and firefox building on these older YP releases?

[kraj]

building chromium is not for faint hearted and folks want latest release of it while rest of system could be old. So best case is to support master on multiple releases as much as we can stretch. branch maintenance is added overhead. Someone will have to take it on.

[rwmacleod]

Using only the master branch continues to work well so there's no need for the other branches.
Gatesgarth is EOL so @rakuco can you close this issue?

[rakuco]

"gatesgarth" is still in LAYERSERIES_COMPAT, so I think the issue is still valid. @shr-project's point was that having all the intermediate releases between dunfell and kirkstone there helps migrating from one to the other; maybe we could formalize the decision and document it in layer.conf (and consequently have all those branches there until dunfell goes EOL in 2024 or its recipes can no longer build Chromium, whichever comes first).

[otavio]

I am ok in dropping it. If desired a branch can be made and we can add a change in README mentioning it is dead.

[msisov]

I don't have a strong opinion about that.

[shr-project]

What's the benefit of dropping it (other than few characters in LAYERSERIES_COMPAT variable)?

Creating identical branch if desired is still more work than keeping LAYERSERIES_COMPAT as it is and maybe just documenting in README that the gatesgarth, hardknott, honister releases are EOL and that meta-browser should be compatible with them, but nobody is testing new changes with these EOL releases anymore (or just documenting which combinations are regularly tested instead).

[kraj]

Lets just support whats not EOL at the moment, which is master, kirkstone and dunfell, and remove everything else. Or we will keep getting bug reports for the EOLed branches too. We can still accept fixes if someone is proposing them.

[kraj]

What's the benefit of dropping it (other than few characters in LAYERSERIES_COMPAT variable)?

Creating identical branch if desired is still more work than keeping LAYERSERIES_COMPAT as it is and maybe just documenting in README that the gatesgarth, hardknott, honister releases are EOL and that meta-browser should be compatible with them, but nobody is testing new changes with these EOL releases anymore (or just documenting which combinations are regularly tested instead).

if there are users sending support requests for these branches is one problem I can see, other than that there is no problem
secondly LAYERSERIES_COMPAT will be nudging users towards supported releases.

[rakuco]

gatesgarth support was finally dropped in #782 as part of the work on enabling Rust in Chromium.