Re: [ANN] Media Summit September 16th: Final Agenda (v7)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Wed, 18 Sep 2024 11:30:20 +0200
Sebastian Fricke <sebastian.fricke@xxxxxxxxxxxxx> escreveu:

> Hey Hans & Mauro,
> 
> On 18.09.2024 09:24, Mauro Carvalho Chehab wrote:
> >Em Tue, 17 Sep 2024 14:52:19 +0200
> >Hans Verkuil <hverkuil@xxxxxxxxx> escreveu:
> >  
> >> Hi Sebastian,
> >>
> >> 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.

> 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:). 

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 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,
Mauro




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux