Re: Moving amber into separate repo?
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 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.
Re: Moving amber into separate repo?
Removing mainline drivers from the build system of Amber is a good idea. Marek On Fri, Sep 23, 2022, 06:33 Filip Gawin 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.
Re: Moving amber into separate repo?
> 2. repo is growing large. Amber kinda requires long history, modern > mesa not. This may be good spot to split if cleanup is required. mesa absolutely uses long history. there is nothing to clean up. those bytes of disk space are well worth it. (Neutral on the other points, I don't work on stuff suported in Amber)I thought here about traces in issues. (Sometimes traces are uploaded onto gitlab by users.) I'm guessing it should be possible to reedit really old closed issues and remove attachments.
Re: Moving amber into separate repo?
On September 24, 2022 04:04:48 "Filip Gawin" wrote: 2. repo is growing large. Amber kinda requires long history, modern mesa not. This may be good spot to split if cleanup is required. mesa absolutely uses long history. there is nothing to clean up. those bytes of disk space are well worth it. (Neutral on the other points, I don't work on stuff suported in Amber) I thought here about traces in issues. (Sometimes traces are uploaded onto gitlab by users.) I'm guessing it should be possible to reedit really old closed issues and remove attachments. If the fd.o admins are complaining about disk usage, we can take steps to reduce that but it's entirely irrelevant to the discussion of whether amber should get it's own repo. Pulling amber into a separate repo won't reduce disk usage. If anything, it'll slightly increase it but not by an amount that's likely to matter. Let's stay focused on actual reasons that might matter, like user confusion (if that's actually happening). --Jason
Re: Moving amber into separate repo?
Currently, amber branch only have * radeon * r200 * i915 * i965 * nouveau (the DRI driver for NV04-NV20) Indeed, I think i915 and i965 can also be removed from amber branch, because they have alternative i915g/ crocus alternatives in main branch, maybe in future, after all code that's not belongs to amber removed, we can even place amber under main branch's src/amber folder? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo
Re: Moving amber into separate repo?
Hi Filip!
Others have what explained why copying the repo (and everything around it) is
not a good idea, so I'll only reply to the other points.
On 2022-09-22 at 22:37 UTC+02:00, Filip Gawin 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".
Could you explain *where* you would like to do this? I don't see what *users*
would see where this would help.
> 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 think we should probably add a couple of lines in the meson.build on the
amber branch, like this:
if gallium_drivers.count() != 0 or vulkan_drivers.count() != 0
error("You shouldn't package Gallium or Vulkan drivers from the amber branch;
please only enable these in the standard Mesa package build.")
endif
Do you think that would be enough to resolve the distro packages maintainers'
confusion?
