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. > > > > 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. > [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 have the same doubt. As discussed during the summit, Hans and I had some > > > > > discussions yesterday, to address a few details. For both of us the process > > > > > sounds well defined. > > > > > > > > I know that we scraped a lot of topics in the meeting at the media > > > > summit and I am not sure about the scope you discussed with Ricardo > > > > yesterday. So, we don't have to meet if you feel like we covered > > > > everything, just wanted to use the opportunity as long as we are all in > > > > the same place. > > > > > > I guess we covered everything that are needed for now. If required, > > > further discussions may happen later via e-mail and/or virtual meetings. -- Regards, Laurent Pinchart
