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 ? > > 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. > > > 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
