Moving amber into separate repo?

[Rob Clark]

On Fri, Sep 23, 2022 at 3:33 AM Filip Gawin <filip at gawin.net> wrote:
>
> Hi, recently I've seen case of user been using Amber when hardware was supported by mainline mesa. This gave me a couple of thoughts.
>
> 1) Users don't correlate "Amber" with "Legacy" and probably it's gonna be best to always also print "Legacy" together with "Mesa".
> 2) Not sure if problem of choosing best driver is on mesa's or distro maintainer's side, but it became more complicated for maintainers.
>
> I'm thinking that moving Amber into separate repo may make this situation more clear. (Disabling duplicated drivers or only allowing glsl_to_tgsi codepath may futher help.)
>
> Some more reasoning from gitlab:
>
> web based tools provided by gitlab are quite useful, unfortunately they work best with main branch.
> repo is growing large. Amber kinda requires long history, modern mesa not. This may be good spot to split if cleanup is required.
> imho having amber's issues in this repo, won't create new contributors. Due to lack of kernel driver (on commercial level) or documentation for these gpus, so you need to be both mesa and kernel developer. (Any contribution is gonna require deep knowledge about hardware, domain and time consuming effort.)
> for normal users (not software developers) amber is kinda "hidden under the carpet". Communities like vogons may be interested in having simpler access to kinda documentation for these ancient gpus.
>

not sure we need a different repo, but I would recommend
disabling/removing drivers (gallium and vk) in the amber branch which
are maintained in the main branch

BR,
-R

>
> Thanks for all insights, Filip.