Moving amber into separate repo?

[Marek Olšák]

Git stores all commits. Removing files at the top of main doesn't make the
repository smaller. It actually makes it bigger. Forking the repository
would also double the size on the server.

Marek

On Fri, Sep 23, 2022, 06:33 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:
>
>
>    1. web based tools provided by gitlab are quite useful, unfortunately
>    they work best with main branch.
>    2. repo is growing large. Amber kinda requires long history, modern
>    mesa not. This may be good spot to split if cleanup is required.
>    3. 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.)
>    4. 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.
>
>
> Thanks for all insights, Filip.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20220924/f6b4ffcf/attachment.htm>