On Thu, Sep 26, 2024 at 01:06:15PM +0200, Mauro Carvalho Chehab wrote: > Em Thu, 26 Sep 2024 13:30:02 +0300 > Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu: > > > On Thu, Sep 26, 2024 at 12:38:15AM +0200, Mauro Carvalho Chehab wrote: > > > Em Wed, 25 Sep 2024 22:56:53 +0300 > > > Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu: > > > > > > > Hi Mauro, > > > > > > > > On Wed, Sep 18, 2024 at 01:23:23PM +0200, Mauro Carvalho Chehab wrote: > > > > > Em Wed, 18 Sep 2024 11:30:20 +0200 Sebastian Fricke escreveu: > > > > > > On 18.09.2024 09:24, Mauro Carvalho Chehab wrote: > > > > > > > Em Tue, 17 Sep 2024 14:52:19 +0200 Hans Verkuil escreveu: > > > > > > >> On 9/17/24 11:17 AM, Sebastian Fricke wrote: > > > > > > >> > Greetings, > > > > > > >> > > > > > > > >> > I remember that we wanted to still define a couple of processes for the > > > > > > >> > multi-committer model for which we hadn't have the time on the media > > > > > > >> > summit. Just would like to gather who would be interested to meet for > > > > > > >> > that, where we meet (probably LPC venue) and when (Laurent just told me > > > > > > >> > that Friday is probably a good slot for that). > > > > > > >> > > > > > > >> Can you refresh my memory which processes need more work? > > > > > > > > > > > > Well I basically remember that we had a bunch of topics in our meetings > > > > > > that we wanted to skip in order to talk about them here. > > > > > > We looked at the documentation from DRM and wanted to think about > > > > > > equivalent policies for media. > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/committer/committer-drm-misc.html#where-do-i-apply-my-patch > > > > > > > > > > Thanks for the pointer. Yeah, examples from other trees can be helpful when > > > > > improving media developers profile and writing the committers agreement, > > > > > even when they have a message that it is just the opposite of what we > > > > > we want, like this (from DRM-misc ruleset): > > > > > > > > > > "Since even a broken driver is more useful than no driver minimal > > > > > review standards are a lot lower." > > > > > > > > > > In this particular case, for instance, as discussed at media summit, we'd > > > > > like to have high quality standards for stuff under drivers/media. After > > > > > all, we do use drivers/media/staging for low quality drivers. > > > > > > > > > > It it worth mentioning that committers shall not merge low quality drivers > > > > > nor patches for staging. If ever needed, those should be done via PRs or > > > > > be explicitly authorized by maintainers. > > > > > > > > Do you mean new drivers only, or also patches for existing staging/ > > > > drivers ? > > > > > > New drivers only. Patches for drivers already at staging can go via > > > committers tree. > > > > I think those could still be pushed directly, but I'm fine with a pull > > request for the time being. If the concern is that you'd like to have a > > look at the driver first, in the long run I'd rather ping you for a > > review and then push once you give an ack. We should move away from > > reviews at pull request time, they don't scale. > > There aren't many new stage drivers, so this doesn't need to scale. The comment about scaling was about reviews at PR time, not about drivers/staging/. > Also, we prefer drivers going directly to drivers/media, so staging > should be used only on unusual cases. No disagreement there, and I think that accepting new drivers in staging is something worth discussing when it happens. Nobody said drivers should be sneaked in there. > Subsystem maintainers should > give a final word if a driver should be merged there or directly on > drivers/media. > > > > > > > Also there were topics like how to handle backports. > > > > > > > > > > We don't handle backports on media tree. This is up to stable maintainers. > > > > > Basically, we follow stable rules to the letter: > > > > > > > > > > Documentation/process/stable-kernel-rules.rst > > > > > > > > > > E. g. patches that require backports shall have the proper meta-tags > > > > > (specially cc: stable and fixes:). > > > > > > > > Sebastian may have meant backmerges. > > > > > > > > > Also, we're not implementing multi-committers for fixes, just for next. > > > > > > > > > > So, fixes shall follow the normal flow: they should be sent via PR. > > > > > > > > I see there's a fixes branch in the media-committers tree, does that > > > > mean you have agreed with Hans and Ricardo that fixes will go through > > > > pull requests but be pushed there for visibility ? If so, thanks for > > > > that, I think it will improve the experience. > > > > > > Hans and I are planning to push fixes at the media-committers tree, as it > > > allows CI to run those, but the goal here is not about visibility - it is > > > just to ensure that CI will execute tests on the merged patches. > > > > That's also a useful goal of course. If we can kill two birds with one > > stone, that's a good outcome. > > > > > For committers and developers, the fixes workflow remains the same: > > > PRs for committers and patches for developers. > > > > > > - > > > > > > See, the main repository is hosted at linuxtv.org. We intend to avoid > > > as much as possible rebases at the media tree at linuxtv.org, on both > > > fixes and next branches. > > > > > > The media-committers tree at fdo is focused on executing patches at CI > > > and should only be used by committers. All other developers should base > > > their work at the repository stored at linuxtv.org[1]. > > > > That I don't like. We want people working on the media subsystem to test > > the very latest code, and to base their work on the tree that their > > patches will land in. Otherwise there will be conflicts, and the risk of > > conflict will increase as we pick up pace with the new workflow and > > merge patches faster. > > This is unavoidable: in the beginning committers may (and will) make > mistakes, as this is a different workflow. As we keep adding more committers, > more mistakes may happen, specially for the newbies. > > So, we need to protect the tree where patches land in (media at > linuxtv.org) from potential issues that might happen at the shared tree. > > Besides that, conflicts are unavoidable on a multi-committers tree. > > > > [1] We are planning to have a "media" repository there, replacing the > > > current "media-stage" tree. > > > > > > See, the media-committers repository at fdo can be rebased. This might > > > happen, for instance, if we don't agree with some merge there during > > > our merge review or if other committers disagree with merges. On such > > > case, the not-accepted patches will be dropped via rebase and the patches > > > will need to be reviewed the normal way. > > > > Things that haven't reached a consensus should not be merged in the > > first place, and in the rare cases where it happens, a revert is fine. > > Rebases should be kept for situations where no other option is possible. > > I guess we agree to disagree. I certainly disagree, yes. I won't comment further, I think you know my position well enough, and I'm certain the majority of the community is also against rebases. -- Regards, Laurent Pinchart
