* Time for drm-ci-next?
@ 2024-03-14 20:31 Rob Clark
2024-03-15 9:28 ` Jani Nikula
0 siblings, 1 reply; 5+ messages in thread
From: Rob Clark @ 2024-03-14 20:31 UTC (permalink / raw
To: Helen Koike, Vignesh Raman, Dave Airlie, Daniel Vetter; +Cc: dri-devel
When we first merged drm/ci I was unsure if it would need it's own
-next branch. But after using it for a couple releases, a few times
I've found myself wanting to backmerge drm/ci changes without
necessarily backmerging all of drm-misc-next.
So, maybe it makes some sense to have a drm-ci-next branch that
driver-maintainers could back-merge as-needed?
Thoughts?
BR,
-R
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Time for drm-ci-next?
2024-03-14 20:31 Time for drm-ci-next? Rob Clark
@ 2024-03-15 9:28 ` Jani Nikula
2024-03-15 17:20 ` Rob Clark
0 siblings, 1 reply; 5+ messages in thread
From: Jani Nikula @ 2024-03-15 9:28 UTC (permalink / raw
To: Rob Clark, Helen Koike, Vignesh Raman, Dave Airlie, Daniel Vetter
Cc: dri-devel
On Thu, 14 Mar 2024, Rob Clark <robdclark@gmail.com> wrote:
> When we first merged drm/ci I was unsure if it would need it's own
> -next branch. But after using it for a couple releases, a few times
> I've found myself wanting to backmerge drm/ci changes without
> necessarily backmerging all of drm-misc-next.
>
> So, maybe it makes some sense to have a drm-ci-next branch that
> driver-maintainers could back-merge as-needed?
That's a crossmerge instead of a backmerge, and I feel that could get
messy. What if folks crossmerge drm-ci-next but it gets rejected for
drm-next? Or the baselines are different, and the crossmerge pulls in
way more stuff than it should?
IMO the route should be drm-ci-next -> pull request to drm-next ->
backmerge drm-next to drivers and drm-misc-next.
I'm not opposed to having drm-ci-next at all, mainly indifferent, but I
question the merge flows. And then the question becomes, does my
suggested merge flow complicate your original goal?
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Time for drm-ci-next?
2024-03-15 9:28 ` Jani Nikula
@ 2024-03-15 17:20 ` Rob Clark
2024-06-24 5:34 ` Vignesh Raman
0 siblings, 1 reply; 5+ messages in thread
From: Rob Clark @ 2024-03-15 17:20 UTC (permalink / raw
To: Jani Nikula
Cc: Helen Koike, Vignesh Raman, Dave Airlie, Daniel Vetter, dri-devel
On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Thu, 14 Mar 2024, Rob Clark <robdclark@gmail.com> wrote:
> > When we first merged drm/ci I was unsure if it would need it's own
> > -next branch. But after using it for a couple releases, a few times
> > I've found myself wanting to backmerge drm/ci changes without
> > necessarily backmerging all of drm-misc-next.
> >
> > So, maybe it makes some sense to have a drm-ci-next branch that
> > driver-maintainers could back-merge as-needed?
>
> That's a crossmerge instead of a backmerge, and I feel that could get
> messy. What if folks crossmerge drm-ci-next but it gets rejected for
> drm-next? Or the baselines are different, and the crossmerge pulls in
> way more stuff than it should?
Yeah, it would defeat the point a bit of drm-ci-next was on too new of
a baseline, the whole point is to be able to merge CI changes without
pulling in unrelated changes. So drm-ci-next would need to base on
something older, like the previous kernel release tag.
> IMO the route should be drm-ci-next -> pull request to drm-next ->
> backmerge drm-next to drivers and drm-misc-next.
>
> I'm not opposed to having drm-ci-next at all, mainly indifferent, but I
> question the merge flows. And then the question becomes, does my
> suggested merge flow complicate your original goal?
>
I guess we could avoid merging drm-ci-next until it had been merged
into drm-next?
Basically, I often find myself needing to merge CI patches on top of
msm-next in order to run CI, and then after a clean CI run, reset HEAD
back before the merge and force-push. Which isn't really how things
should work.
BR,
-R
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Time for drm-ci-next?
2024-03-15 17:20 ` Rob Clark
@ 2024-06-24 5:34 ` Vignesh Raman
2024-06-24 13:25 ` Helen Koike
0 siblings, 1 reply; 5+ messages in thread
From: Vignesh Raman @ 2024-06-24 5:34 UTC (permalink / raw
To: Rob Clark, Jani Nikula
Cc: Helen Koike, Dave Airlie, Daniel Vetter, dri-devel, Daniel Stone
Hi,
On 15/03/24 22:50, Rob Clark wrote:
> On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>>
>> On Thu, 14 Mar 2024, Rob Clark <robdclark@gmail.com> wrote:
>>> When we first merged drm/ci I was unsure if it would need it's own
>>> -next branch. But after using it for a couple releases, a few times
>>> I've found myself wanting to backmerge drm/ci changes without
>>> necessarily backmerging all of drm-misc-next.
>>>
>>> So, maybe it makes some sense to have a drm-ci-next branch that
>>> driver-maintainers could back-merge as-needed?
>>
>> That's a crossmerge instead of a backmerge, and I feel that could get
>> messy. What if folks crossmerge drm-ci-next but it gets rejected for
>> drm-next? Or the baselines are different, and the crossmerge pulls in
>> way more stuff than it should?
>
> Yeah, it would defeat the point a bit of drm-ci-next was on too new of
> a baseline, the whole point is to be able to merge CI changes without
> pulling in unrelated changes. So drm-ci-next would need to base on
> something older, like the previous kernel release tag.
>
>> IMO the route should be drm-ci-next -> pull request to drm-next ->
>> backmerge drm-next to drivers and drm-misc-next.
>>
>> I'm not opposed to having drm-ci-next at all, mainly indifferent, but I
>> question the merge flows. And then the question becomes, does my
>> suggested merge flow complicate your original goal?
>>
>
> I guess we could avoid merging drm-ci-next until it had been merged
> into drm-next?
>
> Basically, I often find myself needing to merge CI patches on top of
> msm-next in order to run CI, and then after a clean CI run, reset HEAD
> back before the merge and force-push. Which isn't really how things
> should work.
There are many CI patches merged recently to drm-misc-next.
With the GitLab 18.0 release, CI/CD pipeline configurations must
transition from using the deprecated CI_JOB_JWT to the new id_tokens
method, as the former will be removed.
Without the below commit kernel-build job pipelines fail in drm-ci,
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/cc806b74466672a9bbd4e9a04265d44eb506b686
We need to cherry pick only this commit to fix this issue.
So it would be beneficial to have a drm-ci-next branch.
Regards,
Vignesh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Time for drm-ci-next?
2024-06-24 5:34 ` Vignesh Raman
@ 2024-06-24 13:25 ` Helen Koike
0 siblings, 0 replies; 5+ messages in thread
From: Helen Koike @ 2024-06-24 13:25 UTC (permalink / raw
To: Vignesh Raman, Rob Clark, Jani Nikula
Cc: Dave Airlie, Daniel Vetter, dri-devel, Daniel Stone
On 24/06/2024 02:34, Vignesh Raman wrote:
> Hi,
>
> On 15/03/24 22:50, Rob Clark wrote:
>> On Fri, Mar 15, 2024 at 2:28 AM Jani Nikula
>> <jani.nikula@linux.intel.com> wrote:
>>>
>>> On Thu, 14 Mar 2024, Rob Clark <robdclark@gmail.com> wrote:
>>>> When we first merged drm/ci I was unsure if it would need it's own
>>>> -next branch. But after using it for a couple releases, a few times
>>>> I've found myself wanting to backmerge drm/ci changes without
>>>> necessarily backmerging all of drm-misc-next.
>>>>
>>>> So, maybe it makes some sense to have a drm-ci-next branch that
>>>> driver-maintainers could back-merge as-needed?
>>>
>>> That's a crossmerge instead of a backmerge, and I feel that could get
>>> messy. What if folks crossmerge drm-ci-next but it gets rejected for
>>> drm-next? Or the baselines are different, and the crossmerge pulls in
>>> way more stuff than it should?
>>
>> Yeah, it would defeat the point a bit of drm-ci-next was on too new of
>> a baseline, the whole point is to be able to merge CI changes without
>> pulling in unrelated changes. So drm-ci-next would need to base on
>> something older, like the previous kernel release tag.
>>
>>> IMO the route should be drm-ci-next -> pull request to drm-next ->
>>> backmerge drm-next to drivers and drm-misc-next.
>>>
>>> I'm not opposed to having drm-ci-next at all, mainly indifferent, but I
>>> question the merge flows. And then the question becomes, does my
>>> suggested merge flow complicate your original goal?
>>>
>>
>> I guess we could avoid merging drm-ci-next until it had been merged
>> into drm-next?
>>
>> Basically, I often find myself needing to merge CI patches on top of
>> msm-next in order to run CI, and then after a clean CI run, reset HEAD
>> back before the merge and force-push. Which isn't really how things
>> should work.
>
> There are many CI patches merged recently to drm-misc-next.
> With the GitLab 18.0 release, CI/CD pipeline configurations must
> transition from using the deprecated CI_JOB_JWT to the new id_tokens
> method, as the former will be removed.
>
> Without the below commit kernel-build job pipelines fail in drm-ci,
> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/cc806b74466672a9bbd4e9a04265d44eb506b686
>
> We need to cherry pick only this commit to fix this issue.
> So it would be beneficial to have a drm-ci-next branch.
>
> Regards,
> Vignesh
I don't mind using a drm-ci-next branch if it is created.
Thanks
Helen
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-06-24 13:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-14 20:31 Time for drm-ci-next? Rob Clark
2024-03-15 9:28 ` Jani Nikula
2024-03-15 17:20 ` Rob Clark
2024-06-24 5:34 ` Vignesh Raman
2024-06-24 13:25 ` Helen Koike
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.