Re: Branch (and team?) for mesa updates

[Maxim Cournoyer]

Hi John,

John Kehayias <john.kehayias@protonmail.com> writes:

> Hi Maxim,
>
> On Sun, Jul 30, 2023 at 09:50 PM, Maxim Cournoyer wrote:
>
>> Hi John,
>>
>> John Kehayias <john.kehayias@protonmail.com> writes:
>>
>> [...]
>>
>>> I'll open a branch merge request issue later today as per new
>>> procedure for QA. Though I believe that only builds 2 branches, which
>>> is occupied at the moment. Or can someone set a separate build job
>>> specifically for mesa-updates, especially if we think it is a good
>>> idea to have this going forward?
>>
>> Do you already have admin access to Cuirass?  We can issue client certs
>> for team members needing to create branches on it or restart builds
>> there, etc.
>>
>
> I do not have access. The mesa-updates branch remains (and still an
> active job I think, just nothing pushed since the merge). I plan on
> making use of it as soon as 23.2 is out, along with a handful of
> pending patches I've seen that will make sense here.

I'll email you your TLS client cert that you can install into your
favorite browser.

> I haven't used Cuirass before but if a hand would be helpful I'm happy
> to lend it (let me know if there is someone I should contact directly
> or message me off list).

It's unfortunately kind of necessary to baby sit the builds and restart
those that failed due to bugs in our CI infrastructure such as #54447
("cuirass: missing derivation error").  The more hands, the better.

>>>> Do we want a "Mesa team" or something a bit larger? Not sure what
>>>> exactly, since "graphics" is perhaps too broad. Happy to help
>>>> spearhead the Mesa front for Guix (the very package that got me first
>>>> involved in the patching process).

>>>
>>> This is still a good question I think, of how we want to have a
>>> team(s) to handle things like xorg, wayland, mesa, and related
>>> packages. They are a bit all over the place in terms of scope and what
>>> they touch. For now I'd like to go ahead with a regular mesa-updates
>>> branch since that sees regular releases and is pretty self-contained
>>> currently.
>>
>> It seems a 'desktop' team could make sense, covering some of the things
>> listed here that makes sense / are already well separated in modules in
>> Guix to avoid being added to two teams:
>> <https://www.freedesktop.org/wiki/Software/>.
>
> The problem I'm thinking of for a "desktop" team is setting the
> correct scope of package files to make use of e.g. auto cc-ing on
> patch submissions. Though at least (gnu packages gl) looks pretty
> reasonable to start for maybe a graphics team? Maybe with vulkan?

Yeah, it's not super focused, but I think it may be best to start to
broad and refine later to have more teams coverage.

> I'm still not sure but I should probably propose something concrete
> with at least myself for gl since those patches generally will go to
> the mesa-updates branch for convenient building.

A "graphics" or "desktop" team which would include freedesktop and the
gl modules sounds good to me.

-- 
Thanks,
Maxim