Public patches but non-public development branch

Paul Menzel pmenzel at molgen.mpg.de
Tue Apr 5 14:16:20 UTC 2022


Dear Alex,


Am 05.04.22 um 16:13 schrieb Alex Deucher:
> On Tue, Apr 5, 2022 at 10:03 AM Paul Menzel <pmenzel at molgen.mpg.de> wrote:

>> Am 05.04.22 um 15:14 schrieb Alex Deucher:
>>> On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:
>>
>>>> Am 05.04.22 um 08:54 schrieb Christian König:
>>>>> Am 05.04.22 um 08:45 schrieb Paul Menzel:
>>>>
>>>>>> Am 04.04.22 um 23:42 schrieb Philip Yang:
>>>>>>> bo_adev is NULL for system memory mapping to GPU.
>>>>>>>
>>>>>>> Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)
>>>>>>
>>>>>> Sorry, where can I find that commit?
>>>>>
>>>>> Well that's expected, the development branch is not public.
>>>>
>>>> Well obviously, it was unexpected for me. How should I have known? Where
>>>> is that documented? If the patches are publicly posted to the mailing
>>>> list, why is that development branch not public?
>>>>
>>>> The current situation is really frustrating for non-AMD employees. How
>>>> can the current situation be improved?
>>>
>>> Our development branch
>>> (https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next)
>>> is available publicly.  There can be a day or so of lag depending on
>>> when it gets mirrored (e.g., over the weekend).
>>
>> Thank you for the clarification. As can be seen at hand, it still causes
>> confusion though.
>>
>>       commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
>>       Author:     Christian König <christian.koenig at amd.com>
>>       AuthorDate: Wed Mar 30 10:53:15 2022 +0200
>>       Commit:     Christian König <christian.koenig at amd.com>
>>       CommitDate: Fri Apr 1 11:05:51 2022 +0200
>>
>> Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.
>>
>> To avoid this friction in the future, is there an automated way to
>> mirror the branches? git hooks should allow that to be done on every
>> push for example.
> 
> It's a bit more complicated than that since we have various CI systems
> and IT security policies involved, but we can look into it.

That’d be awesome. Thank you!


Kind regards,

Paul


More information about the amd-gfx mailing list