On Mon, Sep 09, 2024 at 07:34:04AM GMT, Rob Clark wrote: > On Mon, Sep 9, 2024 at 2:54 AM Dmitry Baryshkov > <dmitry.barysh...@linaro.org> wrote: > > > > On Mon, 9 Sept 2024 at 10:50, Maxime Ripard <mrip...@redhat.com> wrote: > > > > > > Hi, > > > > > > On Tue, Jul 09, 2024 at 01:27:51AM GMT, Dmitry Baryshkov wrote: > > > > On Mon, 8 Jul 2024 at 21:38, Rob Clark <robdcl...@gmail.com> wrote: > > > > > > > > > > On Mon, Jul 8, 2024 at 1:52 AM Daniel Vetter <daniel.vet...@ffwll.ch> > > > > > wrote: > > > > > > > > > > > > On Fri, Jul 05, 2024 at 12:31:36PM -0700, Rob Clark wrote: > > > > > > > On Fri, Jul 5, 2024 at 3:36 AM Daniel Vetter > > > > > > > <daniel.vet...@ffwll.ch> wrote: > > > > > > > > > > > > > > > > On Thu, Jul 04, 2024 at 08:40:26AM -0700, Rob Clark wrote: > > > > > > > > > On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter > > > > > > > > > <daniel.vet...@ffwll.ch> wrote: > > > > > > > > > > > > > > > > > > > > On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote: > > > > > > > > > > > On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter > > > > > > > > > > > <dan...@ffwll.ch> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter > > > > > > > > > > > > > <dan...@ffwll.ch> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry > > > > > > > > > > > > > > Baryshkov wrote: > > > > > > > > > > > > > > > On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel > > > > > > > > > > > > > > > Vetter wrote: > > > > > > > > > > > > > > > > On Mon, Jun 24, 2024 at 10:25:25AM -0300, Helen > > > > > > > > > > > > > > > > Koike wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 24/06/2024 02:34, Vignesh Raman wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 15/03/24 22:50, Rob Clark wrote: > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This sounds more like you want an integration > > > > > > > > > > > > > > > > tree like drm-tip. Get msm > > > > > > > > > > > > > > > > branches integrated there, done. Backmerges > > > > > > > > > > > > > > > > just for integration testing > > > > > > > > > > > > > > > > are not a good idea indeed. > > > > > > > > > > > > > > > > > > > > > > > > > > But AFAIU this doesn't help for pre-merge testing, > > > > > > > > > > > > > ie. prior to a > > > > > > > > > > > > > patch landing in msm-next > > > > > > > > > > > > > > > > > > > > > > > > > > My idea was to have a drm-ci-next managed similar to > > > > > > > > > > > > > drm-misc-next, if > > > > > > > > > > > > > we have needed drm/ci patches we could push them to > > > > > > > > > > > > > drm-ci-next, and > > > > > > > > > > > > > then merge that into the driver tree (along with a PR > > > > > > > > > > > > > from drm-ci-next > > > > > > > > > > > > > to Dave). > > > > > > > > > > > > > > > > > > > > > > > > I guess I'm confused about what kind of pre-merge > > > > > > > > > > > > testing we're talking > > > > > > > > > > > > about then ... Or maybe this just doesn't work too well > > > > > > > > > > > > with the linux > > > > > > > > > > > > kernel. The model is that you have some pile of trees, > > > > > > > > > > > > they're split up, > > > > > > > > > > > > and testing of all the trees together is done in > > > > > > > > > > > > integration trees like > > > > > > > > > > > > linux-next or drm-tip. > > > > > > > > > > > > > > > > > > > > > > pre-merge: for msm we've been collecting up patches from > > > > > > > > > > > list into a > > > > > > > > > > > fast-forward MR which triggers CI before merging to > > > > > > > > > > > msm-next/msm-fixes > > > > > > > > > > > > > > > > > > > > > > Ideally drm-misc and other trees would do similar, we'd > > > > > > > > > > > catch more > > > > > > > > > > > regressions that way. For example, in msm-next the > > > > > > > > > > > nodebugfs build is > > > > > > > > > > > currently broken, because we merged drm-misc-next at a > > > > > > > > > > > time when > > > > > > > > > > > komeda was broken: > > > > > > > > > > > > > > > > > > > > > > https://gitlab.freedesktop.org/drm/msm/-/jobs/60575681#L9520 > > > > > > > > > > > > > > > > > > > > > > If drm-misc was using pre-merge CI this would have been > > > > > > > > > > > caught and the > > > > > > > > > > > offending patch dropped. > > > > > > > > > > > > > > > > > > > > That sounds more like we should push on the drm-misc > > > > > > > > > > pre-merge CI boulder > > > > > > > > > > to move it uphill, than add even more trees to make it even > > > > > > > > > > harder to get > > > > > > > > > > there long term ... > > > > > > > > > > > > > > > > > > > > Short term it helps locally to have finer trees, but only > > > > > > > > > > short term and > > > > > > > > > > only very locally. > > > > > > > > > > > > > > > > > > The path to have fewer trees (ideally only one for all of > > > > > > > > > drm) is to > > > > > > > > > use gitlab MRs to land everything :-) > > > > > > > > > > > > > > > > > > drm-ci-next is only a stop-gap.. but one that we need. The > > > > > > > > > ${branchname}-external-fixes trick covers _most_ cases where > > > > > > > > > we need > > > > > > > > > unrelated patches (ie. to fix random ToT breakage outside of > > > > > > > > > drm or in > > > > > > > > > core drm), but it doesn't help when the needed changes are yml > > > > > > > > > (because gitlab processes all the yml before merging the > > > > > > > > > -external-fixes branch). This is where we need drm-ci-next, > > > > > > > > > otherwise > > > > > > > > > we are having to create a separate MR which cherry-picks > > > > > > > > > drm/ci > > > > > > > > > patches for doing the CI. This is a rather broken process. > > > > > > > > > > > > > > > > So what I don't get is ... if we CI drm-misc, how does that not > > > > > > > > help > > > > > > > > improve the situation here? Step one would be post-merge (i.e. > > > > > > > > just enable > > > > > > > > CI in the repo), then get MRs going. > > > > > > > > > > > > > > I guess post-merge is better than nothing.. but pre-merge is > > > > > > > better. > > > > > > > > > > > > > > post-merge can work if you have a "sheriff" system where someone > > > > > > > (perhaps on a rotation) is actively monitoring results and > > > > > > > "revert and > > > > > > > ask questions later" when something breaks. Pre-merge ensures the > > > > > > > interested party is involved in the process ;-) > > > > > > > > > > > > So ... make that happen? And it doesn't have to be for all of > > > > > > drm-misc, > > > > > > mesa after all switched over to MR also on a bit a driver/area > > > > > > basis. So > > > > > > agreeing among all drm-ci folks to use gitlab MR in drm-misc for > > > > > > pre-merge > > > > > > testing shouldn't be that hard to make happen. And unlike a separate > > > > > > branch it's not some kind of detour with a good chance to get stuck > > > > > > in a > > > > > > local optimum. > > > > > > > > > > Tree vs branch doesn't really have much in the way of distinction, > > > > > modulo gitlab permissions. In that it doesn't do much good if drm/ci > > > > > patches are landing on a different branch. > > > > > > > > > > I guess what you are suggesting is that we have a single tree/branch > > > > > that drm/ci + drm/msm + (plus whoever else wants to get in on the > > > > > drm/ci, so probably at least vkms) lands patches into via gitlab MRs? > > > > > > > > This again brings a separate CI-enabled tree. I think it has been > > > > suggested to start with enabling DRM CI for drm-misc branches. Then we > > > > can possibly start landing MRs with CI testing (probably starting with > > > > vkms). > > > > > > It's something we've discussed with Sima for a while, but enabling CI on > > > drm-misc at some point will make sense so we could just as well start > > > now. > > > > > > The biggest unknown at the moment to start doing so is how we could keep > > > drm-tip and the rerere repo with MR. > > > > Let's do a slow start and begin with post-merge testing. At least this > > gives us an idea of how stable it is (and what does it take to keep it > > green). Maybe we can perform post-merge testing for both drm-misc and > > drm-tip. > > The one thing is that currently the runtime for igt is quite long > (~1hr) because you can't really parallelize kms tests. So maybe > nightly scheduled runs would be a better idea.
SGTM. So, the question would be, who can set it up? -- With best wishes Dmitry
