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

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

[Hans Verkuil]

Hi all,

Here is my seventh and final version of the agenda for the media summit. As always,
all times (except lunch time) are guesstimates!

The media summit will be held on Monday September 16th. Avnet Silica has very
kindly offered to host this summit at their Vienna office, which is about 35
minutes by public transport from the Open Source Summit Europe venue
(https://events.linuxfoundation.org/open-source-summit-europe/OSSE).

Avnet Silica Office Location:

Schönbrunner Str. 297/307, 1120 Vienna, Austria

https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu

Refreshments are available during the day.

Lunch is held at Schönbrunner Stöckl (https://www.schoenbrunnerstoeckl.com/), close
to the Avnet Silica office. The lunch is sponsored by Ideas on Board and Cisco Systems
Norway.

Regarding the face mask policy: we will follow the same guidance that the
Linux Foundation gives for the EOSS conference:

https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety


In-Person Attendees:

Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera AG)
Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel Maintainer)
Steve Cho <stevecho@chromium.org> (Google)
Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
Martin Hecht <martin.hecht@avnet.eu> (Avnet)
Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
Ricardo Ribalda <ribalda@chromium.org> (Google)
Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
Sean Young <sean@mess.org>
Jerry W Hu <jerry.w.hu@intel.com> (Intel)

Remote Attendees (using MS Teams):

Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
Rishikesh Donadkar <r-donadkar@ti.com> (TI)
Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
Tomasz Figa <tfiga@chromium.org> (Google)
Hidenori Kobayashi <hidenorik@chromium.org> (Google)
Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
Devarsh Thakkar <devarsht@ti.com> (TI)

All remote participants listed above should have received an invite with connection details.
If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.

If any information above is incorrect, or if I missed someone, then please let me know.

We have 18 confirmed in-person participants, so we're full.
If you want to join remotely, then contact me and I'll add you to that list.

Draft agenda:

8:45-9:15: Get settled :-)

9:15-9:25: Hans: Quick introduction

9:25-11:00: Ricardo: multi-committer model using gitlab

11:00-11:15: break

11:15-12:15: Jacopo: Multi-context support in V4L2

12:15-13:30: Lunch at Schönbrunner Stöckl

13:30-14:00: Tomasz: Current state of videobuf2, its limitations and the paths forward.

14:00-14:45: Laurent: subdevs, state, and usage of the media controller device to submit requests.

14:45-15:00: break

15:00-15:30: Sean: new tooling for infrared:

- What it is and what it can do (love to hear any feedback of course)
- Where it should be hosted? (I hope gitlab fdo, who do I ask)
- What needs to be in place for a release?
- This tool replaces ir-ctl and ir-keytable. How we phase them out?

15:30-16:00: Daniel: Rust in the media subsystem

16:00-16:15: break

16:15-16:30: Hans: UVC maintenance

16:30-17:00: Steve Cho:

- V4L2 testing on Chromium using virtual video decode driver (visl)
- V4L2 video decoding testing with KernelCI

17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
See here for more info:
https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/

17:30-18:00: Any other topics and feedback on what can be improved next media summit.

Hope to see you all on Monday!

Regards,

	Hans

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

[Sakari Ailus]

Hi Hans,

On Wed, Sep 11, 2024 at 11:03:26AM +0200, Hans Verkuil wrote:
> 17:30-18:00: Any other topics and feedback on what can be improved next media summit.

Perhaps this could be a good occasion to discuss the upcoming sub-device
configuration models and the common raw camera model in particular. This is
closely related to the metadata set and in fact the main reason why the
latter isn't in upstream yet.

-- 
Kind regards,

Sakari Ailus

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

[Hans Verkuil]

+linux-media

Sorry, I'd removed that in my previous reply, but some people may not 
have access to their company email while on the road, but are subscribed 
to linux-media with their private email.

So read the instructions below on where to find the Avnet office, and 
use WienMobil app to determine the route to the office, since Google 
Maps still thinks the U4 U-Bahn can get there, which isn't true due to 
flooding.

Regards,

	Hans

On 9/16/24 1:03 AM, Hecht, Martin (Avnet Silica) wrote:
> Hi all,
> 
> please apologize the late update.
> 
> When you arrive at Schoenbrunner Strasse 297 please use the vehicle entry to enter the area und walk through the tunnel to pass the first building. Turn to right and walk until you see the entrance of the building in the second row of that area labelled with "Grunbergstrasse 15 - Stiege 1" above a glass door. This is the correct entry and you will see a white plate showing the names "Avnet" and "EBV".
> Please take the lift and go up to meet us in the Avnet office at Level 4.
> 
> If you need further assistance, please don't hesitate to send me an email or call me on my mobile phone +491728906019.
> 
> BR Martin
> 
> 
> ________________________________________
> Von: Hans Verkuil <hverkuil@xs4all.nl>
> Gesendet: Sonntag, 15. September 2024 17:10
> An: Sakari Ailus; Daniel Almeida; Mauro Carvalho Chehab; Sebastian Fricke; Hecht, Martin (Avnet Silica); Tommaso Merciai; Jacopo Mondi; Benjamin Mugnier; Laurent Pinchart; Ricardo Ribalda; Michael Tretter; Alain Volmat; Sean Young; Steve Cho; Tomasz Figa; Hidenori Kobayashi; Hu, Jerry W; Suresh Vankadara; Devarsh Thakkar; r-donadkar@ti.com; Dave Stevenson; Mehdi Djait; Nicolas Dufresne; Salahaldeen Altous
> Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda (v7)
> 
> Hi all,
> 
> The large amount of rain in Vienna affected the public transport, in
> particular the U4 U-Bahn is partially closed, including the station
> closest to the Avnet office. I noticed that Google Maps still doesn't
> take that into account when calculating the route to take. Instead I
> advice to use the WienMobil app, that is kept up to date.
> 
> For me it means 15-20 minutes extra travel time.
> 
> Another problem is that I couldn't find the entrance to the Avnet office
> when I went there on Saturday (scouting the place!). Schönbrunner Str.
> 297 is easy enough to find, but I couldn't find Avnet mentioned on the
> list of companies at either entrance.
> 
> Martin Hecht will try to figure that out, so hopefully he can give an
> update later today.
> 
> Regards,
> 
>          Hans
> 
> On 9/11/24 11:03 AM, Hans Verkuil wrote:
>> Hi all,
>>
>> Here is my seventh and final version of the agenda for the media summit. As always,
>> all times (except lunch time) are guesstimates!
>>
>> The media summit will be held on Monday September 16th. Avnet Silica has very
>> kindly offered to host this summit at their Vienna office, which is about 35
>> minutes by public transport from the Open Source Summit Europe venue
>> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>>
>> Avnet Silica Office Location:
>>
>> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>>
>> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>>
>> Refreshments are available during the day.
>>
>> Lunch is held at Schönbrunner Stöckl (https://www.schoenbrunnerstoeckl.com/), close
>> to the Avnet Silica office. The lunch is sponsored by Ideas on Board and Cisco Systems
>> Norway.
>>
>> Regarding the face mask policy: we will follow the same guidance that the
>> Linux Foundation gives for the EOSS conference:
>>
>> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>>
>>
>> In-Person Attendees:
>>
>> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera AG)
>> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel Maintainer)
>> Steve Cho <stevecho@chromium.org> (Google)
>> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>> Ricardo Ribalda <ribalda@chromium.org> (Google)
>> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>> Sean Young <sean@mess.org>
>> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>>
>> Remote Attendees (using MS Teams):
>>
>> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>> Tomasz Figa <tfiga@chromium.org> (Google)
>> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>> Devarsh Thakkar <devarsht@ti.com> (TI)
>>
>> All remote participants listed above should have received an invite with connection details.
>> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>>
>> If any information above is incorrect, or if I missed someone, then please let me know.
>>
>> We have 18 confirmed in-person participants, so we're full.
>> If you want to join remotely, then contact me and I'll add you to that list.
>>
>> Draft agenda:
>>
>> 8:45-9:15: Get settled :-)
>>
>> 9:15-9:25: Hans: Quick introduction
>>
>> 9:25-11:00: Ricardo: multi-committer model using gitlab
>>
>> 11:00-11:15: break
>>
>> 11:15-12:15: Jacopo: Multi-context support in V4L2
>>
>> 12:15-13:30: Lunch at Schönbrunner Stöckl
>>
>> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and the paths forward.
>>
>> 14:00-14:45: Laurent: subdevs, state, and usage of the media controller device to submit requests.
>>
>> 14:45-15:00: break
>>
>> 15:00-15:30: Sean: new tooling for infrared:
>>
>> - What it is and what it can do (love to hear any feedback of course)
>> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>> - What needs to be in place for a release?
>> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>>
>> 15:30-16:00: Daniel: Rust in the media subsystem
>>
>> 16:00-16:15: break
>>
>> 16:15-16:30: Hans: UVC maintenance
>>
>> 16:30-17:00: Steve Cho:
>>
>> - V4L2 testing on Chromium using virtual video decode driver (visl)
>> - V4L2 video decoding testing with KernelCI
>>
>> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>> See here for more info:
>> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>>
>> 17:30-18:00: Any other topics and feedback on what can be improved next media summit.
>>
>> Hope to see you all on Monday!
>>
>> Regards,
>>
>>        Hans
>>
>>
>>
> 
> We continuously commit to comply with the applicable data protection laws and ensure fair and transparent processing of your personal data.
> Please read our privacy statement including an information notice and data protection policy for detailed information on our website.

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

[Hans Verkuil]

Etherpad for the meeting notes:

https://pad.systemli.org/p/media-summit-2024

Regards,

	Hans

On 9/16/24 7:27 AM, Hans Verkuil wrote:
> +linux-media
> 
> Sorry, I'd removed that in my previous reply, but some people may not 
> have access to their company email while on the road, but are subscribed 
> to linux-media with their private email.
> 
> So read the instructions below on where to find the Avnet office, and 
> use WienMobil app to determine the route to the office, since Google 
> Maps still thinks the U4 U-Bahn can get there, which isn't true due to 
> flooding.
> 
> Regards,
> 
>      Hans
> 
> On 9/16/24 1:03 AM, Hecht, Martin (Avnet Silica) wrote:
>> Hi all,
>>
>> please apologize the late update.
>>
>> When you arrive at Schoenbrunner Strasse 297 please use the vehicle 
>> entry to enter the area und walk through the tunnel to pass the first 
>> building. Turn to right and walk until you see the entrance of the 
>> building in the second row of that area labelled with "Grunbergstrasse 
>> 15 - Stiege 1" above a glass door. This is the correct entry and you 
>> will see a white plate showing the names "Avnet" and "EBV".
>> Please take the lift and go up to meet us in the Avnet office at Level 4.
>>
>> If you need further assistance, please don't hesitate to send me an 
>> email or call me on my mobile phone +491728906019.
>>
>> BR Martin
>>
>>
>> ________________________________________
>> Von: Hans Verkuil <hverkuil@xs4all.nl>
>> Gesendet: Sonntag, 15. September 2024 17:10
>> An: Sakari Ailus; Daniel Almeida; Mauro Carvalho Chehab; Sebastian 
>> Fricke; Hecht, Martin (Avnet Silica); Tommaso Merciai; Jacopo Mondi; 
>> Benjamin Mugnier; Laurent Pinchart; Ricardo Ribalda; Michael Tretter; 
>> Alain Volmat; Sean Young; Steve Cho; Tomasz Figa; Hidenori Kobayashi; 
>> Hu, Jerry W; Suresh Vankadara; Devarsh Thakkar; r-donadkar@ti.com; 
>> Dave Stevenson; Mehdi Djait; Nicolas Dufresne; Salahaldeen Altous
>> Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda 
>> (v7)
>>
>> Hi all,
>>
>> The large amount of rain in Vienna affected the public transport, in
>> particular the U4 U-Bahn is partially closed, including the station
>> closest to the Avnet office. I noticed that Google Maps still doesn't
>> take that into account when calculating the route to take. Instead I
>> advice to use the WienMobil app, that is kept up to date.
>>
>> For me it means 15-20 minutes extra travel time.
>>
>> Another problem is that I couldn't find the entrance to the Avnet office
>> when I went there on Saturday (scouting the place!). Schönbrunner Str.
>> 297 is easy enough to find, but I couldn't find Avnet mentioned on the
>> list of companies at either entrance.
>>
>> Martin Hecht will try to figure that out, so hopefully he can give an
>> update later today.
>>
>> Regards,
>>
>>          Hans
>>
>> On 9/11/24 11:03 AM, Hans Verkuil wrote:
>>> Hi all,
>>>
>>> Here is my seventh and final version of the agenda for the media 
>>> summit. As always,
>>> all times (except lunch time) are guesstimates!
>>>
>>> The media summit will be held on Monday September 16th. Avnet Silica 
>>> has very
>>> kindly offered to host this summit at their Vienna office, which is 
>>> about 35
>>> minutes by public transport from the Open Source Summit Europe venue
>>> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>>>
>>> Avnet Silica Office Location:
>>>
>>> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>>>
>>> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>>>
>>> Refreshments are available during the day.
>>>
>>> Lunch is held at Schönbrunner Stöckl 
>>> (https://www.schoenbrunnerstoeckl.com/), close
>>> to the Avnet Silica office. The lunch is sponsored by Ideas on Board 
>>> and Cisco Systems
>>> Norway.
>>>
>>> Regarding the face mask policy: we will follow the same guidance that 
>>> the
>>> Linux Foundation gives for the EOSS conference:
>>>
>>> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>>>
>>>
>>> In-Person Attendees:
>>>
>>> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>>> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>>> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica 
>>> Camera AG)
>>> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel 
>>> Maintainer)
>>> Steve Cho <stevecho@chromium.org> (Google)
>>> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>>> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>>> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>>> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>>> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>>> Ricardo Ribalda <ribalda@chromium.org> (Google)
>>> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>>> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>>> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>>> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>>> Sean Young <sean@mess.org>
>>> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>>>
>>> Remote Attendees (using MS Teams):
>>>
>>> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>>> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>>> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>>> Tomasz Figa <tfiga@chromium.org> (Google)
>>> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>>> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>>> Devarsh Thakkar <devarsht@ti.com> (TI)
>>>
>>> All remote participants listed above should have received an invite 
>>> with connection details.
>>> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>>>
>>> If any information above is incorrect, or if I missed someone, then 
>>> please let me know.
>>>
>>> We have 18 confirmed in-person participants, so we're full.
>>> If you want to join remotely, then contact me and I'll add you to 
>>> that list.
>>>
>>> Draft agenda:
>>>
>>> 8:45-9:15: Get settled :-)
>>>
>>> 9:15-9:25: Hans: Quick introduction
>>>
>>> 9:25-11:00: Ricardo: multi-committer model using gitlab
>>>
>>> 11:00-11:15: break
>>>
>>> 11:15-12:15: Jacopo: Multi-context support in V4L2
>>>
>>> 12:15-13:30: Lunch at Schönbrunner Stöckl
>>>
>>> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and 
>>> the paths forward.
>>>
>>> 14:00-14:45: Laurent: subdevs, state, and usage of the media 
>>> controller device to submit requests.
>>>
>>> 14:45-15:00: break
>>>
>>> 15:00-15:30: Sean: new tooling for infrared:
>>>
>>> - What it is and what it can do (love to hear any feedback of course)
>>> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>>> - What needs to be in place for a release?
>>> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>>>
>>> 15:30-16:00: Daniel: Rust in the media subsystem
>>>
>>> 16:00-16:15: break
>>>
>>> 16:15-16:30: Hans: UVC maintenance
>>>
>>> 16:30-17:00: Steve Cho:
>>>
>>> - V4L2 testing on Chromium using virtual video decode driver (visl)
>>> - V4L2 video decoding testing with KernelCI
>>>
>>> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>>> See here for more info:
>>> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>>>
>>> 17:30-18:00: Any other topics and feedback on what can be improved 
>>> next media summit.
>>>
>>> Hope to see you all on Monday!
>>>
>>> Regards,
>>>
>>>        Hans
>>>
>>>
>>>
>>
>> We continuously commit to comply with the applicable data protection 
>> laws and ensure fair and transparent processing of your personal data.
>> Please read our privacy statement including an information notice and 
>> data protection policy for detailed information on our website.

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

[Sebastian Fricke]

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

Regards,
Sebastian

On 11.09.2024 11:03, Hans Verkuil wrote:
>Hi all,
>
>Here is my seventh and final version of the agenda for the media summit. As always,
>all times (except lunch time) are guesstimates!
>
>The media summit will be held on Monday September 16th. Avnet Silica has very
>kindly offered to host this summit at their Vienna office, which is about 35
>minutes by public transport from the Open Source Summit Europe venue
>(https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>
>Avnet Silica Office Location:
>
>Schönbrunner Str. 297/307, 1120 Vienna, Austria
>
>https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>
>Refreshments are available during the day.
>
>Lunch is held at Schönbrunner Stöckl (https://www.schoenbrunnerstoeckl.com/), close
>to the Avnet Silica office. The lunch is sponsored by Ideas on Board and Cisco Systems
>Norway.
>
>Regarding the face mask policy: we will follow the same guidance that the
>Linux Foundation gives for the EOSS conference:
>
>https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>
>
>In-Person Attendees:
>
>Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera AG)
>Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel Maintainer)
>Steve Cho <stevecho@chromium.org> (Google)
>Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>Ricardo Ribalda <ribalda@chromium.org> (Google)
>Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>Sean Young <sean@mess.org>
>Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>
>Remote Attendees (using MS Teams):
>
>Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>Tomasz Figa <tfiga@chromium.org> (Google)
>Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>Devarsh Thakkar <devarsht@ti.com> (TI)
>
>All remote participants listed above should have received an invite with connection details.
>If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>
>If any information above is incorrect, or if I missed someone, then please let me know.
>
>We have 18 confirmed in-person participants, so we're full.
>If you want to join remotely, then contact me and I'll add you to that list.
>
>Draft agenda:
>
>8:45-9:15: Get settled :-)
>
>9:15-9:25: Hans: Quick introduction
>
>9:25-11:00: Ricardo: multi-committer model using gitlab
>
>11:00-11:15: break
>
>11:15-12:15: Jacopo: Multi-context support in V4L2
>
>12:15-13:30: Lunch at Schönbrunner Stöckl
>
>13:30-14:00: Tomasz: Current state of videobuf2, its limitations and the paths forward.
>
>14:00-14:45: Laurent: subdevs, state, and usage of the media controller device to submit requests.
>
>14:45-15:00: break
>
>15:00-15:30: Sean: new tooling for infrared:
>
>- What it is and what it can do (love to hear any feedback of course)
>- Where it should be hosted? (I hope gitlab fdo, who do I ask)
>- What needs to be in place for a release?
>- This tool replaces ir-ctl and ir-keytable. How we phase them out?
>
>15:30-16:00: Daniel: Rust in the media subsystem
>
>16:00-16:15: break
>
>16:15-16:30: Hans: UVC maintenance
>
>16:30-17:00: Steve Cho:
>
>- V4L2 testing on Chromium using virtual video decode driver (visl)
>- V4L2 video decoding testing with KernelCI
>
>17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>See here for more info:
>https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>
>17:30-18:00: Any other topics and feedback on what can be improved next media summit.
>
>Hope to see you all on Monday!
>
>Regards,
>
>	Hans
>
>
>
Sebastian Fricke
Consultant Software Engineer

Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales no 5513718.

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

[Sakari Ailus]

Hi Steve,

On Tue, Sep 17, 2024 at 12:18:21PM +0200, Steve Cho wrote:
> If it were to happen on Wed, I can book at a room for some times at OSS
> venue.

Not everyone is attending OSS. It'd be the best if this would take place
outside both OSS and LPC but I'm not sure if this is doable.

-- 
Sakari Ailus

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

[Laurent Pinchart]

On Tue, Sep 17, 2024 at 10:34:40AM +0000, Sakari Ailus wrote:
> Hi Steve,
> 
> On Tue, Sep 17, 2024 at 12:18:21PM +0200, Steve Cho wrote:
> > If it were to happen on Wed, I can book at a room for some times at OSS
> > venue.
> 
> Not everyone is attending OSS. It'd be the best if this would take place
> outside both OSS and LPC but I'm not sure if this is doable.

I'm personally available on Friday only, or possibly on Thursday after
the complex camera micro-conference.

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

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?

For me I think Friday afternoon (probably after 14:00) is the only 
option, or perhaps Thursday after the Camera MC.

Regards,

	Hans

> 
> Regards,
> Sebastian
> 
> On 11.09.2024 11:03, Hans Verkuil wrote:
>> Hi all,
>>
>> Here is my seventh and final version of the agenda for the media 
>> summit. As always,
>> all times (except lunch time) are guesstimates!
>>
>> The media summit will be held on Monday September 16th. Avnet Silica 
>> has very
>> kindly offered to host this summit at their Vienna office, which is 
>> about 35
>> minutes by public transport from the Open Source Summit Europe venue
>> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>>
>> Avnet Silica Office Location:
>>
>> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>>
>> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>>
>> Refreshments are available during the day.
>>
>> Lunch is held at Schönbrunner Stöckl 
>> (https://www.schoenbrunnerstoeckl.com/), close
>> to the Avnet Silica office. The lunch is sponsored by Ideas on Board 
>> and Cisco Systems
>> Norway.
>>
>> Regarding the face mask policy: we will follow the same guidance that the
>> Linux Foundation gives for the EOSS conference:
>>
>> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>>
>>
>> In-Person Attendees:
>>
>> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera 
>> AG)
>> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel 
>> Maintainer)
>> Steve Cho <stevecho@chromium.org> (Google)
>> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>> Ricardo Ribalda <ribalda@chromium.org> (Google)
>> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>> Sean Young <sean@mess.org>
>> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>>
>> Remote Attendees (using MS Teams):
>>
>> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>> Tomasz Figa <tfiga@chromium.org> (Google)
>> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>> Devarsh Thakkar <devarsht@ti.com> (TI)
>>
>> All remote participants listed above should have received an invite 
>> with connection details.
>> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>>
>> If any information above is incorrect, or if I missed someone, then 
>> please let me know.
>>
>> We have 18 confirmed in-person participants, so we're full.
>> If you want to join remotely, then contact me and I'll add you to that 
>> list.
>>
>> Draft agenda:
>>
>> 8:45-9:15: Get settled :-)
>>
>> 9:15-9:25: Hans: Quick introduction
>>
>> 9:25-11:00: Ricardo: multi-committer model using gitlab
>>
>> 11:00-11:15: break
>>
>> 11:15-12:15: Jacopo: Multi-context support in V4L2
>>
>> 12:15-13:30: Lunch at Schönbrunner Stöckl
>>
>> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and 
>> the paths forward.
>>
>> 14:00-14:45: Laurent: subdevs, state, and usage of the media 
>> controller device to submit requests.
>>
>> 14:45-15:00: break
>>
>> 15:00-15:30: Sean: new tooling for infrared:
>>
>> - What it is and what it can do (love to hear any feedback of course)
>> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>> - What needs to be in place for a release?
>> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>>
>> 15:30-16:00: Daniel: Rust in the media subsystem
>>
>> 16:00-16:15: break
>>
>> 16:15-16:30: Hans: UVC maintenance
>>
>> 16:30-17:00: Steve Cho:
>>
>> - V4L2 testing on Chromium using virtual video decode driver (visl)
>> - V4L2 video decoding testing with KernelCI
>>
>> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>> See here for more info:
>> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>>
>> 17:30-18:00: Any other topics and feedback on what can be improved 
>> next media summit.
>>
>> Hope to see you all on Monday!
>>
>> Regards,
>>
>>     Hans
>>
>>
>>
> Sebastian Fricke
> Consultant Software Engineer
> 
> Collabora Ltd
> Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
> Registered in England & Wales no 5513718.

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

[Mauro Carvalho Chehab]

Em Tue, 17 Sep 2024 14:52:19 +0200
Hans Verkuil <hverkuil@xs4all.nl> 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?

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.

From my personal notes, this will be the new process:

- committers will merge patches at media-committers.git tree at fdo,
  provided that they'll follow the rules defined on a committers agreement
  and (partially?) enforced by media-ci checks;
- core committers follow the same rules, with a broader privilege of
  changing kernel API/ABI;
- committers will ensure that patchwork will reflect the review process of
  the patches;
- maintainers will double-check if everything is ok and, if ok, merge the
  changes at linuxtv.org. We intend to rename the tree there to "media.git",
  being the main tree to be used for development;
- pull requests will keep using the same process as currently. The only
  change is that the media-stage.git tree will be renamed to "media.git";
- maintainers will periodically send patches upstream.

The media-commiters.git tree at fdo might be rebased if needed; the 
media.git tree at linuxtv.org is stable. A large effort will be taken to
avoid rebasing it.

We may need some helper scripts and/or use pwclient to keep patchwork
updated after committers reviews.

Such process will start after -rc1. 

We intend to rename media-state to media at linuxtv after -rc1.

It is up to maintainers to invite and decide who will be a committer.

All committers/core-committers need to explicitly accept a committers
agreement. We may end starting without it at the beginning, but as soon
as a final version of such agreement is written, everyone with access to
the media-committers tree have to explicitly accept to keep their
commit rights on such tree.

The only part that still require some work is the committers
agreement. I'm working on it together with Hans. As soon as we have
a version, we'll submit a patch to the kernel, to add it to the
media developer's profile[1].

[1] Documentation/driver-api/media/maintainer-entry-profile.rst

> 
> For me I think Friday afternoon (probably after 14:00) is the only 
> option, or perhaps Thursday after the Camera MC.

I can't meet on Friday afternoon. I probably will be on another
event on Thursday (Openeuler MC).

> 
> Regards,
> 
> 	Hans
> 
> > 
> > Regards,
> > Sebastian
> > 
> > On 11.09.2024 11:03, Hans Verkuil wrote:  
> >> Hi all,
> >>
> >> Here is my seventh and final version of the agenda for the media 
> >> summit. As always,
> >> all times (except lunch time) are guesstimates!
> >>
> >> The media summit will be held on Monday September 16th. Avnet Silica 
> >> has very
> >> kindly offered to host this summit at their Vienna office, which is 
> >> about 35
> >> minutes by public transport from the Open Source Summit Europe venue
> >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
> >>
> >> Avnet Silica Office Location:
> >>
> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
> >>
> >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
> >>
> >> Refreshments are available during the day.
> >>
> >> Lunch is held at Schönbrunner Stöckl 
> >> (https://www.schoenbrunnerstoeckl.com/), close
> >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board 
> >> and Cisco Systems
> >> Norway.
> >>
> >> Regarding the face mask policy: we will follow the same guidance that the
> >> Linux Foundation gives for the EOSS conference:
> >>
> >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
> >>
> >>
> >> In-Person Attendees:
> >>
> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
> >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
> >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera 
> >> AG)
> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel 
> >> Maintainer)
> >> Steve Cho <stevecho@chromium.org> (Google)
> >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
> >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
> >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
> >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
> >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
> >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
> >> Ricardo Ribalda <ribalda@chromium.org> (Google)
> >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
> >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
> >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
> >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
> >> Sean Young <sean@mess.org>
> >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
> >>
> >> Remote Attendees (using MS Teams):
> >>
> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
> >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
> >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
> >> Tomasz Figa <tfiga@chromium.org> (Google)
> >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
> >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
> >> Devarsh Thakkar <devarsht@ti.com> (TI)
> >>
> >> All remote participants listed above should have received an invite 
> >> with connection details.
> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
> >>
> >> If any information above is incorrect, or if I missed someone, then 
> >> please let me know.
> >>
> >> We have 18 confirmed in-person participants, so we're full.
> >> If you want to join remotely, then contact me and I'll add you to that 
> >> list.
> >>
> >> Draft agenda:
> >>
> >> 8:45-9:15: Get settled :-)
> >>
> >> 9:15-9:25: Hans: Quick introduction
> >>
> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
> >>
> >> 11:00-11:15: break
> >>
> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
> >>
> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
> >>
> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and 
> >> the paths forward.
> >>
> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media 
> >> controller device to submit requests.
> >>
> >> 14:45-15:00: break
> >>
> >> 15:00-15:30: Sean: new tooling for infrared:
> >>
> >> - What it is and what it can do (love to hear any feedback of course)
> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
> >> - What needs to be in place for a release?
> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
> >>
> >> 15:30-16:00: Daniel: Rust in the media subsystem
> >>
> >> 16:00-16:15: break
> >>
> >> 16:15-16:30: Hans: UVC maintenance
> >>
> >> 16:30-17:00: Steve Cho:
> >>
> >> - V4L2 testing on Chromium using virtual video decode driver (visl)
> >> - V4L2 video decoding testing with KernelCI
> >>
> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
> >> See here for more info:
> >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
> >>
> >> 17:30-18:00: Any other topics and feedback on what can be improved 
> >> next media summit.
> >>
> >> Hope to see you all on Monday!
> >>
> >> Regards,
> >>
> >>     Hans
> >>
> >>
> >>  
> > Sebastian Fricke
> > Consultant Software Engineer
> > 
> > Collabora Ltd
> > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
> > Registered in England & Wales no 5513718.  

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

[Sebastian Fricke]

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@xs4all.nl> 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

Also there were topics like how to handle backports. 

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

Regards,
Sebastian

>
>From my personal notes, this will be the new process:
>
>- committers will merge patches at media-committers.git tree at fdo,
>  provided that they'll follow the rules defined on a committers agreement
>  and (partially?) enforced by media-ci checks;
>- core committers follow the same rules, with a broader privilege of
>  changing kernel API/ABI;
>- committers will ensure that patchwork will reflect the review process of
>  the patches;
>- maintainers will double-check if everything is ok and, if ok, merge the
>  changes at linuxtv.org. We intend to rename the tree there to "media.git",
>  being the main tree to be used for development;
>- pull requests will keep using the same process as currently. The only
>  change is that the media-stage.git tree will be renamed to "media.git";
>- maintainers will periodically send patches upstream.
>
>The media-commiters.git tree at fdo might be rebased if needed; the
>media.git tree at linuxtv.org is stable. A large effort will be taken to
>avoid rebasing it.
>
>We may need some helper scripts and/or use pwclient to keep patchwork
>updated after committers reviews.
>
>Such process will start after -rc1.
>
>We intend to rename media-state to media at linuxtv after -rc1.
>
>It is up to maintainers to invite and decide who will be a committer.
>
>All committers/core-committers need to explicitly accept a committers
>agreement. We may end starting without it at the beginning, but as soon
>as a final version of such agreement is written, everyone with access to
>the media-committers tree have to explicitly accept to keep their
>commit rights on such tree.
>
>The only part that still require some work is the committers
>agreement. I'm working on it together with Hans. As soon as we have
>a version, we'll submit a patch to the kernel, to add it to the
>media developer's profile[1].
>
>[1] Documentation/driver-api/media/maintainer-entry-profile.rst
>
>>
>> For me I think Friday afternoon (probably after 14:00) is the only
>> option, or perhaps Thursday after the Camera MC.
>
>I can't meet on Friday afternoon. I probably will be on another
>event on Thursday (Openeuler MC).
>
>>
>> Regards,
>>
>> 	Hans
>>
>> >
>> > Regards,
>> > Sebastian
>> >
>> > On 11.09.2024 11:03, Hans Verkuil wrote:
>> >> Hi all,
>> >>
>> >> Here is my seventh and final version of the agenda for the media
>> >> summit. As always,
>> >> all times (except lunch time) are guesstimates!
>> >>
>> >> The media summit will be held on Monday September 16th. Avnet Silica
>> >> has very
>> >> kindly offered to host this summit at their Vienna office, which is
>> >> about 35
>> >> minutes by public transport from the Open Source Summit Europe venue
>> >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>> >>
>> >> Avnet Silica Office Location:
>> >>
>> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>> >>
>> >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>> >>
>> >> Refreshments are available during the day.
>> >>
>> >> Lunch is held at Schönbrunner Stöckl
>> >> (https://www.schoenbrunnerstoeckl.com/), close
>> >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board
>> >> and Cisco Systems
>> >> Norway.
>> >>
>> >> Regarding the face mask policy: we will follow the same guidance that the
>> >> Linux Foundation gives for the EOSS conference:
>> >>
>> >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>> >>
>> >>
>> >> In-Person Attendees:
>> >>
>> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>> >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>> >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera
>> >> AG)
>> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel
>> >> Maintainer)
>> >> Steve Cho <stevecho@chromium.org> (Google)
>> >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>> >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>> >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>> >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>> >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>> >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>> >> Ricardo Ribalda <ribalda@chromium.org> (Google)
>> >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>> >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>> >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>> >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>> >> Sean Young <sean@mess.org>
>> >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>> >>
>> >> Remote Attendees (using MS Teams):
>> >>
>> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>> >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>> >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>> >> Tomasz Figa <tfiga@chromium.org> (Google)
>> >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>> >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>> >> Devarsh Thakkar <devarsht@ti.com> (TI)
>> >>
>> >> All remote participants listed above should have received an invite
>> >> with connection details.
>> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>> >>
>> >> If any information above is incorrect, or if I missed someone, then
>> >> please let me know.
>> >>
>> >> We have 18 confirmed in-person participants, so we're full.
>> >> If you want to join remotely, then contact me and I'll add you to that
>> >> list.
>> >>
>> >> Draft agenda:
>> >>
>> >> 8:45-9:15: Get settled :-)
>> >>
>> >> 9:15-9:25: Hans: Quick introduction
>> >>
>> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
>> >>
>> >> 11:00-11:15: break
>> >>
>> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
>> >>
>> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
>> >>
>> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and
>> >> the paths forward.
>> >>
>> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media
>> >> controller device to submit requests.
>> >>
>> >> 14:45-15:00: break
>> >>
>> >> 15:00-15:30: Sean: new tooling for infrared:
>> >>
>> >> - What it is and what it can do (love to hear any feedback of course)
>> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>> >> - What needs to be in place for a release?
>> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>> >>
>> >> 15:30-16:00: Daniel: Rust in the media subsystem
>> >>
>> >> 16:00-16:15: break
>> >>
>> >> 16:15-16:30: Hans: UVC maintenance
>> >>
>> >> 16:30-17:00: Steve Cho:
>> >>
>> >> - V4L2 testing on Chromium using virtual video decode driver (visl)
>> >> - V4L2 video decoding testing with KernelCI
>> >>
>> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>> >> See here for more info:
>> >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>> >>
>> >> 17:30-18:00: Any other topics and feedback on what can be improved
>> >> next media summit.
>> >>
>> >> Hope to see you all on Monday!
>> >>
>> >> Regards,
>> >>
>> >>     Hans
>> >>
>> >>
>> >>
>> > Sebastian Fricke
>> > Consultant Software Engineer
>> >
>> > Collabora Ltd
>> > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
>> > Registered in England & Wales no 5513718.
>
Sebastian Fricke
Consultant Software Engineer

Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales no 5513718.

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

[Mauro Carvalho Chehab]

Em Wed, 18 Sep 2024 11:30:20 +0200
Sebastian Fricke <sebastian.fricke@collabora.com> 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@xs4all.nl> 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

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

[Laurent Pinchart]

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

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

[Mauro Carvalho Chehab]

Em Wed, 25 Sep 2024 22:56:53 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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.

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

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

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

Thanks,
Mauro

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

[Laurent Pinchart]

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@ideasonboard.com> 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

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

[Sakari Ailus]

Hi Laurent,

On Thu, Sep 26, 2024 at 01:30:02PM +0300, Laurent Pinchart wrote:
> > 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.

I was under the impression the tree at linuxtv.org would be synchronised
(very) often or even updated based on a git hook, effectively making it a
mirror.

-- 
Kind regards,

Sakari Ailus

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

[Laurent Pinchart]

On Thu, Sep 26, 2024 at 10:38:40AM +0000, Sakari Ailus wrote:
> Hi Laurent,
> 
> On Thu, Sep 26, 2024 at 01:30:02PM +0300, Laurent Pinchart wrote:
> > > 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.
> 
> I was under the impression the tree at linuxtv.org would be synchronised
> (very) often or even updated based on a git hook, effectively making it a
> mirror.

If it's a mirror then it doesn't matter which tree people use :-)

-- 
Regards,

Laurent Pinchart

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

[Sakari Ailus]

On Thu, Sep 26, 2024 at 01:41:54PM +0300, Laurent Pinchart wrote:
> On Thu, Sep 26, 2024 at 10:38:40AM +0000, Sakari Ailus wrote:
> > Hi Laurent,
> > 
> > On Thu, Sep 26, 2024 at 01:30:02PM +0300, Laurent Pinchart wrote:
> > > > 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.
> > 
> > I was under the impression the tree at linuxtv.org would be synchronised
> > (very) often or even updated based on a git hook, effectively making it a
> > mirror.
> 
> If it's a mirror then it doesn't matter which tree people use :-)

No, it doesn't. We should probably provide both but do the synchronisation
better than it's done for linux-firmware.git.

-- 
Sakari Ailus

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 10:38:40 +0000
Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:

> Hi Laurent,
> 
> On Thu, Sep 26, 2024 at 01:30:02PM +0300, Laurent Pinchart wrote:
> > > 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.  
> 
> I was under the impression the tree at linuxtv.org would be synchronised
> (very) often or even updated based on a git hook, effectively making it a
> mirror.

No. There will be an ancillary tree there doing that, just to override
some gitlab limitations on its public version, but the actual merge at
linuxtv.org "media" tree will be after maintainers check that if the merges 
are OK.

This won't be a normal patch-per-patch review. We'll be mainly looking at 
the merge diffstat, commit authors and such. We'll be triggered by
automatic e-mails sent from linuxtv.org when patches got merged at the
ancillary tree there.

Thanks,
Mauro

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 13:30:02 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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@ideasonboard.com> 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.

Also, we prefer drivers going directly to drivers/media, so staging
should be used only on unusual cases. 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.

Thanks,
Mauro

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

[Laurent Pinchart]

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@ideasonboard.com> 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@ideasonboard.com> 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

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 14:13:07 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

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

Nobody like rebases, including subsystem maintainers. A rebase means
lots of manual work that we would very much prefer not to do it.

You don't want rebases, fine. There shouldn't be any rebases if every
committer ensures that each patch they merged were properly 
reviewed/accepted and have the proper license and tags, including
SPDX, SoBs, A-B, R-B, etc.

Yet, if a committer screws up somehow (intentionally or not), subsystem 
maintainers will handle it the way they think it is the best, deciding 
either to rebases or revert, depending on the case.

Thanks,
Mauro

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

[Hans Verkuil]

On 26/09/2024 13:35, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Sep 2024 14:13:07 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> 
>>>>> 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.
> 
> Nobody like rebases, including subsystem maintainers. A rebase means
> lots of manual work that we would very much prefer not to do it.
> 
> You don't want rebases, fine. There shouldn't be any rebases if every
> committer ensures that each patch they merged were properly 
> reviewed/accepted and have the proper license and tags, including
> SPDX, SoBs, A-B, R-B, etc.
> 
> Yet, if a committer screws up somehow (intentionally or not), subsystem 
> maintainers will handle it the way they think it is the best, deciding 
> either to rebases or revert, depending on the case.

We just need to have the rebase option as a last resort. The CI should help
to prevent rebases, and if we do need to rebase, we need to look whether a
better/new check should be added to the CI to prevent that in the future.

Especially in the beginning things may slip through (I made mistakes when I
started as co-maintainer!), but let's just learn from the mistakes, improve
the CI and processes, and after 2-3 kernel cycles we take another look where
we are.

It doesn't have to be perfect from the start, and as long as we continuously
improve the process, I'm happy.

So let's all relax, take a nice cup of tea/coffee/wine/beer/whisky/etc. and
raise it to Ricardo for doing the great work on the CI system, since that was
a very important step forward!

Regards,

	Hans

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

[Laurent Pinchart]

On Thu, Sep 26, 2024 at 01:43:10PM +0200, Hans Verkuil wrote:
> On 26/09/2024 13:35, Mauro Carvalho Chehab wrote:
> > Em Thu, 26 Sep 2024 14:13:07 +0300 Laurent Pinchart escreveu:
> > 
> >>>>> 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.
> > 
> > Nobody like rebases, including subsystem maintainers. A rebase means

I'm glad we at least agree on that :-)

> > lots of manual work that we would very much prefer not to do it.
> > 
> > You don't want rebases, fine. There shouldn't be any rebases if every
> > committer ensures that each patch they merged were properly 
> > reviewed/accepted and have the proper license and tags, including
> > SPDX, SoBs, A-B, R-B, etc.
> > 
> > Yet, if a committer screws up somehow (intentionally or not), subsystem 
> > maintainers will handle it the way they think it is the best, deciding 
> > either to rebases or revert, depending on the case.
> 
> We just need to have the rebase option as a last resort. The CI should help
> to prevent rebases, and if we do need to rebase, we need to look whether a
> better/new check should be added to the CI to prevent that in the future.
> 
> Especially in the beginning things may slip through (I made mistakes when I
> started as co-maintainer!), but let's just learn from the mistakes, improve
> the CI and processes, and after 2-3 kernel cycles we take another look where
> we are.
> 
> It doesn't have to be perfect from the start, and as long as we continuously
> improve the process, I'm happy.

Incremental improvements are crucial. For this reason, I would like
every rebase to be discussed with core committers, so that we all
understand the issues and have a change to improve the tools to ensure
they won't happen again (malicious behaviour is a different case). Can
we try that, and handle rebases with a consensus-seeking process ?

> So let's all relax, take a nice cup of tea/coffee/wine/beer/whisky/etc. and
> raise it to Ricardo for doing the great work on the CI system, since that was
> a very important step forward!

Ricardo has done an amazing job there, I'm really grateful. Sebastian
also deserves big kudos, and we should be thankful for all the other
contributions. I'm personally thankful to you and Mauro for agreeing to
move forward. There's no secret that I'd like a faster pace (possibly
due to all the accumulated frustrations over the years), but there is
clear progress and I want to acknowledge that.

-- 
Regards,

Laurent Pinchart

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 15:02:00 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> > It doesn't have to be perfect from the start, and as long as we continuously
> > improve the process, I'm happy.  

As Sakari pointed, CI will prevent a lot of possible cases.

> Incremental improvements are crucial. For this reason, I would like
> every rebase to be discussed with core committers, so that we all
> understand the issues and have a change to improve the tools to ensure
> they won't happen again (malicious behaviour is a different case). Can
> we try that, and handle rebases with a consensus-seeking process ?

Good idea! Yeah, it makes sense to discuss it to improve the process
after the facts. As we're planning to do periodic meetings with committers,
this can be added to the agenda of the next meeting when this happens for
committers, core committers and maintainers to be aware of what happened
and how this can be prevented in the future.

Thanks,
Mauro

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

[Sakari Ailus]

Hi Mauro, Laurent,

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@ideasonboard.com> 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@ideasonboard.com> 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.
> 
> Also, we prefer drivers going directly to drivers/media, so staging
> should be used only on unusual cases. 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'd like to just see how this works out in practice instead while
disagreeing to agree to disagree. The CI system should catch plenty of
issues we've only noticed later on in the past. The committers are also
aware of the requirements here.

My stance is fixing (typically small) issues on top or reverting a patch,
partially or wholly, is much less trouble for everyone involved. This is
what we've done in the past, too. I'd like to have Hans's view on this,
too.

-- 
Kind regards,

Sakari Ailus

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

[Hecht, Martin (Avnet Silica)]

Hey Hans and Mauro,

I remember also on a very little point regarding hardware for testing. But we didn't go in detail again during the summit.

How do we can go ahead here? Are there some test systems up and running somewhere centralized or how it is organized right now?

BR Martin

________________________________________
Von: Sebastian Fricke <sebastian.fricke@collabora.com>
Gesendet: Mittwoch, 18. September 2024 11:30
An: Mauro Carvalho Chehab
Cc: Hans Verkuil; Linux Media Mailing List; Sakari Ailus; Daniel Almeida; Mauro Carvalho Chehab; Hecht, Martin (Avnet Silica); Tommaso Merciai; Jacopo Mondi; Benjamin Mugnier; Laurent Pinchart; Ricardo Ribalda; Michael Tretter; Alain Volmat; Sean Young; Steve Cho; Tomasz Figa; Hidenori Kobayashi; Hu, Jerry W; Suresh Vankadara; Devarsh Thakkar; r-donadkar@ti.com; Dave Stevenson; Mehdi Djait; Nicolas Dufresne; Salahaldeen Altous
Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda (v7)

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@xs4all.nl> 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

Also there were topics like how to handle backports.

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

Regards,
Sebastian

>
>From my personal notes, this will be the new process:
>
>- committers will merge patches at media-committers.git tree at fdo,
>  provided that they'll follow the rules defined on a committers agreement
>  and (partially?) enforced by media-ci checks;
>- core committers follow the same rules, with a broader privilege of
>  changing kernel API/ABI;
>- committers will ensure that patchwork will reflect the review process of
>  the patches;
>- maintainers will double-check if everything is ok and, if ok, merge the
>  changes at linuxtv.org. We intend to rename the tree there to "media.git",
>  being the main tree to be used for development;
>- pull requests will keep using the same process as currently. The only
>  change is that the media-stage.git tree will be renamed to "media.git";
>- maintainers will periodically send patches upstream.
>
>The media-commiters.git tree at fdo might be rebased if needed; the
>media.git tree at linuxtv.org is stable. A large effort will be taken to
>avoid rebasing it.
>
>We may need some helper scripts and/or use pwclient to keep patchwork
>updated after committers reviews.
>
>Such process will start after -rc1.
>
>We intend to rename media-state to media at linuxtv after -rc1.
>
>It is up to maintainers to invite and decide who will be a committer.
>
>All committers/core-committers need to explicitly accept a committers
>agreement. We may end starting without it at the beginning, but as soon
>as a final version of such agreement is written, everyone with access to
>the media-committers tree have to explicitly accept to keep their
>commit rights on such tree.
>
>The only part that still require some work is the committers
>agreement. I'm working on it together with Hans. As soon as we have
>a version, we'll submit a patch to the kernel, to add it to the
>media developer's profile[1].
>
>[1] Documentation/driver-api/media/maintainer-entry-profile.rst
>
>>
>> For me I think Friday afternoon (probably after 14:00) is the only
>> option, or perhaps Thursday after the Camera MC.
>
>I can't meet on Friday afternoon. I probably will be on another
>event on Thursday (Openeuler MC).
>
>>
>> Regards,
>>
>>      Hans
>>
>> >
>> > Regards,
>> > Sebastian
>> >
>> > On 11.09.2024 11:03, Hans Verkuil wrote:
>> >> Hi all,
>> >>
>> >> Here is my seventh and final version of the agenda for the media
>> >> summit. As always,
>> >> all times (except lunch time) are guesstimates!
>> >>
>> >> The media summit will be held on Monday September 16th. Avnet Silica
>> >> has very
>> >> kindly offered to host this summit at their Vienna office, which is
>> >> about 35
>> >> minutes by public transport from the Open Source Summit Europe venue
>> >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>> >>
>> >> Avnet Silica Office Location:
>> >>
>> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>> >>
>> >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>> >>
>> >> Refreshments are available during the day.
>> >>
>> >> Lunch is held at Schönbrunner Stöckl
>> >> (https://www.schoenbrunnerstoeckl.com/), close
>> >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board
>> >> and Cisco Systems
>> >> Norway.
>> >>
>> >> Regarding the face mask policy: we will follow the same guidance that the
>> >> Linux Foundation gives for the EOSS conference:
>> >>
>> >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>> >>
>> >>
>> >> In-Person Attendees:
>> >>
>> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>> >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>> >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera
>> >> AG)
>> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel
>> >> Maintainer)
>> >> Steve Cho <stevecho@chromium.org> (Google)
>> >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>> >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>> >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>> >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>> >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>> >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>> >> Ricardo Ribalda <ribalda@chromium.org> (Google)
>> >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>> >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>> >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>> >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>> >> Sean Young <sean@mess.org>
>> >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>> >>
>> >> Remote Attendees (using MS Teams):
>> >>
>> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>> >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>> >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>> >> Tomasz Figa <tfiga@chromium.org> (Google)
>> >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>> >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>> >> Devarsh Thakkar <devarsht@ti.com> (TI)
>> >>
>> >> All remote participants listed above should have received an invite
>> >> with connection details.
>> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>> >>
>> >> If any information above is incorrect, or if I missed someone, then
>> >> please let me know.
>> >>
>> >> We have 18 confirmed in-person participants, so we're full.
>> >> If you want to join remotely, then contact me and I'll add you to that
>> >> list.
>> >>
>> >> Draft agenda:
>> >>
>> >> 8:45-9:15: Get settled :-)
>> >>
>> >> 9:15-9:25: Hans: Quick introduction
>> >>
>> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
>> >>
>> >> 11:00-11:15: break
>> >>
>> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
>> >>
>> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
>> >>
>> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and
>> >> the paths forward.
>> >>
>> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media
>> >> controller device to submit requests.
>> >>
>> >> 14:45-15:00: break
>> >>
>> >> 15:00-15:30: Sean: new tooling for infrared:
>> >>
>> >> - What it is and what it can do (love to hear any feedback of course)
>> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>> >> - What needs to be in place for a release?
>> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>> >>
>> >> 15:30-16:00: Daniel: Rust in the media subsystem
>> >>
>> >> 16:00-16:15: break
>> >>
>> >> 16:15-16:30: Hans: UVC maintenance
>> >>
>> >> 16:30-17:00: Steve Cho:
>> >>
>> >> - V4L2 testing on Chromium using virtual video decode driver (visl)
>> >> - V4L2 video decoding testing with KernelCI
>> >>
>> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>> >> See here for more info:
>> >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>> >>
>> >> 17:30-18:00: Any other topics and feedback on what can be improved
>> >> next media summit.
>> >>
>> >> Hope to see you all on Monday!
>> >>
>> >> Regards,
>> >>
>> >>     Hans
>> >>
>> >>
>> >>
>> > Sebastian Fricke
>> > Consultant Software Engineer
>> >
>> > Collabora Ltd
>> > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
>> > Registered in England & Wales no 5513718.
>
Sebastian Fricke
Consultant Software Engineer

Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales no 5513718.

We continuously commit to comply with the applicable data protection laws and ensure fair and transparent processing of your personal data. 
Please read our privacy statement including an information notice and data protection policy for detailed information on our website.

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

[Laurent Pinchart]

Hi Martin,

On Fri, Sep 20, 2024 at 12:16:29PM +0000, Hecht, Martin (Avnet Silica) wrote:
> Hey Hans and Mauro,
> 
> I remember also on a very little point regarding hardware for testing.
> But we didn't go in detail again during the summit.
> 
> How do we can go ahead here? Are there some test systems up and
> running somewhere centralized or how it is organized right now?

Testing on real hardware is among our goals, but will require quite som
extra work. We will likely need to setup lava labs and integrate them
with media-ci. We had a discussion on Friday with kernel-ci developers,
and we will probably benefit from ongoing work on their side. I don't
think there's a plan to address this on our side in the very short term
(mostly due to lack of time, we're currently focusing on getting
media-ci up and running and integrated with the maintenance workflow).

> ________________________________________
> Von: Sebastian Fricke <sebastian.fricke@collabora.com>
> Gesendet: Mittwoch, 18. September 2024 11:30
> An: Mauro Carvalho Chehab
> Cc: Hans Verkuil; Linux Media Mailing List; Sakari Ailus; Daniel Almeida; Mauro Carvalho Chehab; Hecht, Martin (Avnet Silica); Tommaso Merciai; Jacopo Mondi; Benjamin Mugnier; Laurent Pinchart; Ricardo Ribalda; Michael Tretter; Alain Volmat; Sean Young; Steve Cho; Tomasz Figa; Hidenori Kobayashi; Hu, Jerry W; Suresh Vankadara; Devarsh Thakkar; r-donadkar@ti.com; Dave Stevenson; Mehdi Djait; Nicolas Dufresne; Salahaldeen Altous
> Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda (v7)
> 
> 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@xs4all.nl> 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
> 
> Also there were topics like how to handle backports.
> 
> >
> >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.
> 
> Regards,
> Sebastian
> 
> >
> >From my personal notes, this will be the new process:
> >
> >- committers will merge patches at media-committers.git tree at fdo,
> >  provided that they'll follow the rules defined on a committers agreement
> >  and (partially?) enforced by media-ci checks;
> >- core committers follow the same rules, with a broader privilege of
> >  changing kernel API/ABI;
> >- committers will ensure that patchwork will reflect the review process of
> >  the patches;
> >- maintainers will double-check if everything is ok and, if ok, merge the
> >  changes at linuxtv.org. We intend to rename the tree there to "media.git",
> >  being the main tree to be used for development;
> >- pull requests will keep using the same process as currently. The only
> >  change is that the media-stage.git tree will be renamed to "media.git";
> >- maintainers will periodically send patches upstream.
> >
> >The media-commiters.git tree at fdo might be rebased if needed; the
> >media.git tree at linuxtv.org is stable. A large effort will be taken to
> >avoid rebasing it.
> >
> >We may need some helper scripts and/or use pwclient to keep patchwork
> >updated after committers reviews.
> >
> >Such process will start after -rc1.
> >
> >We intend to rename media-state to media at linuxtv after -rc1.
> >
> >It is up to maintainers to invite and decide who will be a committer.
> >
> >All committers/core-committers need to explicitly accept a committers
> >agreement. We may end starting without it at the beginning, but as soon
> >as a final version of such agreement is written, everyone with access to
> >the media-committers tree have to explicitly accept to keep their
> >commit rights on such tree.
> >
> >The only part that still require some work is the committers
> >agreement. I'm working on it together with Hans. As soon as we have
> >a version, we'll submit a patch to the kernel, to add it to the
> >media developer's profile[1].
> >
> >[1] Documentation/driver-api/media/maintainer-entry-profile.rst
> >
> >>
> >> For me I think Friday afternoon (probably after 14:00) is the only
> >> option, or perhaps Thursday after the Camera MC.
> >
> >I can't meet on Friday afternoon. I probably will be on another
> >event on Thursday (Openeuler MC).
> >
> >>
> >> Regards,
> >>
> >>      Hans
> >>
> >> >
> >> > Regards,
> >> > Sebastian
> >> >
> >> > On 11.09.2024 11:03, Hans Verkuil wrote:
> >> >> Hi all,
> >> >>
> >> >> Here is my seventh and final version of the agenda for the media
> >> >> summit. As always,
> >> >> all times (except lunch time) are guesstimates!
> >> >>
> >> >> The media summit will be held on Monday September 16th. Avnet Silica
> >> >> has very
> >> >> kindly offered to host this summit at their Vienna office, which is
> >> >> about 35
> >> >> minutes by public transport from the Open Source Summit Europe venue
> >> >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
> >> >>
> >> >> Avnet Silica Office Location:
> >> >>
> >> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
> >> >>
> >> >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
> >> >>
> >> >> Refreshments are available during the day.
> >> >>
> >> >> Lunch is held at Schönbrunner Stöckl
> >> >> (https://www.schoenbrunnerstoeckl.com/), close
> >> >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board
> >> >> and Cisco Systems
> >> >> Norway.
> >> >>
> >> >> Regarding the face mask policy: we will follow the same guidance that the
> >> >> Linux Foundation gives for the EOSS conference:
> >> >>
> >> >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
> >> >>
> >> >>
> >> >> In-Person Attendees:
> >> >>
> >> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
> >> >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
> >> >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera
> >> >> AG)
> >> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel
> >> >> Maintainer)
> >> >> Steve Cho <stevecho@chromium.org> (Google)
> >> >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
> >> >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
> >> >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
> >> >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
> >> >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
> >> >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
> >> >> Ricardo Ribalda <ribalda@chromium.org> (Google)
> >> >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
> >> >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
> >> >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
> >> >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
> >> >> Sean Young <sean@mess.org>
> >> >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
> >> >>
> >> >> Remote Attendees (using MS Teams):
> >> >>
> >> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
> >> >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
> >> >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
> >> >> Tomasz Figa <tfiga@chromium.org> (Google)
> >> >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
> >> >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
> >> >> Devarsh Thakkar <devarsht@ti.com> (TI)
> >> >>
> >> >> All remote participants listed above should have received an invite
> >> >> with connection details.
> >> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
> >> >>
> >> >> If any information above is incorrect, or if I missed someone, then
> >> >> please let me know.
> >> >>
> >> >> We have 18 confirmed in-person participants, so we're full.
> >> >> If you want to join remotely, then contact me and I'll add you to that
> >> >> list.
> >> >>
> >> >> Draft agenda:
> >> >>
> >> >> 8:45-9:15: Get settled :-)
> >> >>
> >> >> 9:15-9:25: Hans: Quick introduction
> >> >>
> >> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
> >> >>
> >> >> 11:00-11:15: break
> >> >>
> >> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
> >> >>
> >> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
> >> >>
> >> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and
> >> >> the paths forward.
> >> >>
> >> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media
> >> >> controller device to submit requests.
> >> >>
> >> >> 14:45-15:00: break
> >> >>
> >> >> 15:00-15:30: Sean: new tooling for infrared:
> >> >>
> >> >> - What it is and what it can do (love to hear any feedback of course)
> >> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
> >> >> - What needs to be in place for a release?
> >> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
> >> >>
> >> >> 15:30-16:00: Daniel: Rust in the media subsystem
> >> >>
> >> >> 16:00-16:15: break
> >> >>
> >> >> 16:15-16:30: Hans: UVC maintenance
> >> >>
> >> >> 16:30-17:00: Steve Cho:
> >> >>
> >> >> - V4L2 testing on Chromium using virtual video decode driver (visl)
> >> >> - V4L2 video decoding testing with KernelCI
> >> >>
> >> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
> >> >> See here for more info:
> >> >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
> >> >>
> >> >> 17:30-18:00: Any other topics and feedback on what can be improved
> >> >> next media summit.
> >> >>
> >> >> Hope to see you all on Monday!

-- 
Regards,

Laurent Pinchart

Kernel CI media test - Was: Re: [ANN] Media Summit September 16th: Final Agenda (v7)

[Mauro Carvalho Chehab]

Hi Martin,

Em Wed, 25 Sep 2024 22:53:42 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> Hi Martin,
> 
> On Fri, Sep 20, 2024 at 12:16:29PM +0000, Hecht, Martin (Avnet Silica) wrote:
> > Hey Hans and Mauro,
> > 
> > I remember also on a very little point regarding hardware for testing.
> > But we didn't go in detail again during the summit.
> > 
> > How do we can go ahead here? Are there some test systems up and
> > running somewhere centralized or how it is organized right now?  
> 
> Testing on real hardware is among our goals, but will require quite som
> extra work. We will likely need to setup lava labs and integrate them
> with media-ci. We had a discussion on Friday with kernel-ci developers,
> and we will probably benefit from ongoing work on their side. I don't
> think there's a plan to address this on our side in the very short term
> (mostly due to lack of time, we're currently focusing on getting
> media-ci up and running and integrated with the maintenance workflow).

With regards to integrating Avnet Silica labs for doing CI tests on
media hardware with upstream kernels, this is something I always wanted.

Yet, as Laurent mentioned, right now we're not doing it directly 
(but I guess Collabora is doing it for some media drivers they're 
developing).

From the discussions I had during LPC and the ones I also had one year
ago at ELCE, it seems that the best way to do it is by using Kernel CI
to aggregate results from different test labs.

The main idea is to use Kernel CI for such purpose.

With such purpose, let's start a separate thread to discuss it together
with the Kernel CI community. 

So, I'm c/c Kernel CI public ML here and Gustavo Padovan that have been 
involved on several efforts related to that. I had some hallway 
discussions with him during LPC.

It I recall correctly, we need to is:

1. To define a common test set (probably a subset of what we do 
   already for the virtual drivers);
2. add hardware platforms to Kernel CI infrastructure;
3. add some logic at Kernel CI to execute the tests at the hardware
   that will be made available at the labs.

From our discussions during the Media Summit, my understanding is that
Avnet Silica can help us with that by providing some hardware platforms
that could be integrated at Kernel CI infra and test real drivers with
real hardware. If you have someone to spare, maybe you can also contribute
with (1) and (3).

Anyway, this is just an introduction e-mail with what I captured so far
to start our discussions.


Thanks,
Mauro

Re: Kernel CI media test - Was: Re: [ANN] Media Summit September 16th: Final Agenda (v7)

[Gustavo Padovan]

Hello,


---- On Thu, 26 Sep 2024 11:14:50 -0300 Mauro Carvalho Chehab  wrote ---

 > Hi Martin, 
 >  
 > Em Wed, 25 Sep 2024 22:53:42 +0300 
 > Laurent Pinchart laurent.pinchart@ideasonboard.com> escreveu: 
 >  
 > > Hi Martin, 
 > > 
 > > On Fri, Sep 20, 2024 at 12:16:29PM +0000, Hecht, Martin (Avnet Silica) wrote: 
 > > > Hey Hans and Mauro, 
 > > > 
 > > > I remember also on a very little point regarding hardware for testing. 
 > > > But we didn't go in detail again during the summit. 
 > > > 
 > > > How do we can go ahead here? Are there some test systems up and 
 > > > running somewhere centralized or how it is organized right now? 
 > > 
 > > Testing on real hardware is among our goals, but will require quite som 
 > > extra work. We will likely need to setup lava labs and integrate them 
 > > with media-ci. We had a discussion on Friday with kernel-ci developers, 
 > > and we will probably benefit from ongoing work on their side. I don't 
 > > think there's a plan to address this on our side in the very short term 
 > > (mostly due to lack of time, we're currently focusing on getting 
 > > media-ci up and running and integrated with the maintenance workflow). 
 >  
 > With regards to integrating Avnet Silica labs for doing CI tests on 
 > media hardware with upstream kernels, this is something I always wanted. 
 >  
 > Yet, as Laurent mentioned, right now we're not doing it directly 
 > (but I guess Collabora is doing it for some media drivers they're 
 > developing). 
 >  
 > From the discussions I had during LPC and the ones I also had one year 
 > ago at ELCE, it seems that the best way to do it is by using Kernel CI 
 > to aggregate results from different test labs. 
 >  
 > The main idea is to use Kernel CI for such purpose. 
 >  
 > With such purpose, let's start a separate thread to discuss it together 
 > with the Kernel CI community. 
 >  
 > So, I'm c/c Kernel CI public ML here and Gustavo Padovan that have been 
 > involved on several efforts related to that. I had some hallway 
 > discussions with him during LPC. 
 >  
 > It I recall correctly, we need to is: 
 >  
 > 1. To define a common test set (probably a subset of what we do 
 >  already for the virtual drivers); 
 > 2. add hardware platforms to Kernel CI infrastructure; 
 > 3. add some logic at Kernel CI to execute the tests at the hardware 
 >  that will be made available at the labs. 

That is correct. We can connect labs into the KernelCI infrastructure through a
lab-runtime in maestro or if you have a CI system in place you can just listen
to tests events generate by KernelCI, execute them and send the results into
KCIDB for data aggregation as explained by Mauro.

 >  
 > From our discussions during the Media Summit, my understanding is that 
 > Avnet Silica can help us with that by providing some hardware platforms 
 > that could be integrated at Kernel CI infra and test real drivers with 
 > real hardware. If you have someone to spare, maybe you can also contribute 
 > with (1) and (3). 
 >  
 > Anyway, this is just an introduction e-mail with what I captured so far 
 > to start our discussions.

I'd happy to have a video meeting to look at the details or attend one
of the Media CI syncs.

Best, 

- Gus

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

[Sebastian Fricke]

Hey Martin,

On 20.09.2024 12:16, Hecht, Martin (Avnet Silica) wrote:
>Hey Hans and Mauro,
>
>I remember also on a very little point regarding hardware for testing. But we didn't go in detail again during the summit.
>
>How do we can go ahead here? Are there some test systems up and running somewhere centralized or how it is organized right now?

Currently, different companies host their own hardware labs (Collabora,
Qualcomm, Google, etc.) and these labs serve CI systems like KernelCI or
DRM-CI (and we are currently working on setting these tests up on the
Media-CI). The first step is to either add your devices to an existing
lab or create your own one, by setting up your hardware with the
necessary software, usually Lava, but you can also use Labgrid or
something similar. Let me know which way you prefer, and I can assist
you with that approach.

>
>BR Martin

Regards,
Sebastian

>
>________________________________________
>Von: Sebastian Fricke <sebastian.fricke@collabora.com>
>Gesendet: Mittwoch, 18. September 2024 11:30
>An: Mauro Carvalho Chehab
>Cc: Hans Verkuil; Linux Media Mailing List; Sakari Ailus; Daniel Almeida; Mauro Carvalho Chehab; Hecht, Martin (Avnet Silica); Tommaso Merciai; Jacopo Mondi; Benjamin Mugnier; Laurent Pinchart; Ricardo Ribalda; Michael Tretter; Alain Volmat; Sean Young; Steve Cho; Tomasz Figa; Hidenori Kobayashi; Hu, Jerry W; Suresh Vankadara; Devarsh Thakkar; r-donadkar@ti.com; Dave Stevenson; Mehdi Djait; Nicolas Dufresne; Salahaldeen Altous
>Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda (v7)
>
>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@xs4all.nl> 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
>
>Also there were topics like how to handle backports.
>
>>
>>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.
>
>Regards,
>Sebastian
>
>>
>>From my personal notes, this will be the new process:
>>
>>- committers will merge patches at media-committers.git tree at fdo,
>>  provided that they'll follow the rules defined on a committers agreement
>>  and (partially?) enforced by media-ci checks;
>>- core committers follow the same rules, with a broader privilege of
>>  changing kernel API/ABI;
>>- committers will ensure that patchwork will reflect the review process of
>>  the patches;
>>- maintainers will double-check if everything is ok and, if ok, merge the
>>  changes at linuxtv.org. We intend to rename the tree there to "media.git",
>>  being the main tree to be used for development;
>>- pull requests will keep using the same process as currently. The only
>>  change is that the media-stage.git tree will be renamed to "media.git";
>>- maintainers will periodically send patches upstream.
>>
>>The media-commiters.git tree at fdo might be rebased if needed; the
>>media.git tree at linuxtv.org is stable. A large effort will be taken to
>>avoid rebasing it.
>>
>>We may need some helper scripts and/or use pwclient to keep patchwork
>>updated after committers reviews.
>>
>>Such process will start after -rc1.
>>
>>We intend to rename media-state to media at linuxtv after -rc1.
>>
>>It is up to maintainers to invite and decide who will be a committer.
>>
>>All committers/core-committers need to explicitly accept a committers
>>agreement. We may end starting without it at the beginning, but as soon
>>as a final version of such agreement is written, everyone with access to
>>the media-committers tree have to explicitly accept to keep their
>>commit rights on such tree.
>>
>>The only part that still require some work is the committers
>>agreement. I'm working on it together with Hans. As soon as we have
>>a version, we'll submit a patch to the kernel, to add it to the
>>media developer's profile[1].
>>
>>[1] Documentation/driver-api/media/maintainer-entry-profile.rst
>>
>>>
>>> For me I think Friday afternoon (probably after 14:00) is the only
>>> option, or perhaps Thursday after the Camera MC.
>>
>>I can't meet on Friday afternoon. I probably will be on another
>>event on Thursday (Openeuler MC).
>>
>>>
>>> Regards,
>>>
>>>      Hans
>>>
>>> >
>>> > Regards,
>>> > Sebastian
>>> >
>>> > On 11.09.2024 11:03, Hans Verkuil wrote:
>>> >> Hi all,
>>> >>
>>> >> Here is my seventh and final version of the agenda for the media
>>> >> summit. As always,
>>> >> all times (except lunch time) are guesstimates!
>>> >>
>>> >> The media summit will be held on Monday September 16th. Avnet Silica
>>> >> has very
>>> >> kindly offered to host this summit at their Vienna office, which is
>>> >> about 35
>>> >> minutes by public transport from the Open Source Summit Europe venue
>>> >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>>> >>
>>> >> Avnet Silica Office Location:
>>> >>
>>> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>>> >>
>>> >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>>> >>
>>> >> Refreshments are available during the day.
>>> >>
>>> >> Lunch is held at Schönbrunner Stöckl
>>> >> (https://www.schoenbrunnerstoeckl.com/), close
>>> >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board
>>> >> and Cisco Systems
>>> >> Norway.
>>> >>
>>> >> Regarding the face mask policy: we will follow the same guidance that the
>>> >> Linux Foundation gives for the EOSS conference:
>>> >>
>>> >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>>> >>
>>> >>
>>> >> In-Person Attendees:
>>> >>
>>> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>>> >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>>> >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera
>>> >> AG)
>>> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel
>>> >> Maintainer)
>>> >> Steve Cho <stevecho@chromium.org> (Google)
>>> >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>>> >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>>> >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>>> >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>>> >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>>> >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>>> >> Ricardo Ribalda <ribalda@chromium.org> (Google)
>>> >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>>> >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>>> >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>>> >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>>> >> Sean Young <sean@mess.org>
>>> >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>>> >>
>>> >> Remote Attendees (using MS Teams):
>>> >>
>>> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>>> >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>>> >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>>> >> Tomasz Figa <tfiga@chromium.org> (Google)
>>> >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>>> >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>>> >> Devarsh Thakkar <devarsht@ti.com> (TI)
>>> >>
>>> >> All remote participants listed above should have received an invite
>>> >> with connection details.
>>> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>>> >>
>>> >> If any information above is incorrect, or if I missed someone, then
>>> >> please let me know.
>>> >>
>>> >> We have 18 confirmed in-person participants, so we're full.
>>> >> If you want to join remotely, then contact me and I'll add you to that
>>> >> list.
>>> >>
>>> >> Draft agenda:
>>> >>
>>> >> 8:45-9:15: Get settled :-)
>>> >>
>>> >> 9:15-9:25: Hans: Quick introduction
>>> >>
>>> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
>>> >>
>>> >> 11:00-11:15: break
>>> >>
>>> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
>>> >>
>>> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
>>> >>
>>> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and
>>> >> the paths forward.
>>> >>
>>> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media
>>> >> controller device to submit requests.
>>> >>
>>> >> 14:45-15:00: break
>>> >>
>>> >> 15:00-15:30: Sean: new tooling for infrared:
>>> >>
>>> >> - What it is and what it can do (love to hear any feedback of course)
>>> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>>> >> - What needs to be in place for a release?
>>> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>>> >>
>>> >> 15:30-16:00: Daniel: Rust in the media subsystem
>>> >>
>>> >> 16:00-16:15: break
>>> >>
>>> >> 16:15-16:30: Hans: UVC maintenance
>>> >>
>>> >> 16:30-17:00: Steve Cho:
>>> >>
>>> >> - V4L2 testing on Chromium using virtual video decode driver (visl)
>>> >> - V4L2 video decoding testing with KernelCI
>>> >>
>>> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>>> >> See here for more info:
>>> >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>>> >>
>>> >> 17:30-18:00: Any other topics and feedback on what can be improved
>>> >> next media summit.
>>> >>
>>> >> Hope to see you all on Monday!
>>> >>
>>> >> Regards,
>>> >>
>>> >>     Hans
>>> >>
>>> >>
>>> >>
>>> > Sebastian Fricke
>>> > Consultant Software Engineer
>>> >
>>> > Collabora Ltd
>>> > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
>>> > Registered in England & Wales no 5513718.
>>
>Sebastian Fricke
>Consultant Software Engineer
>
>Collabora Ltd
>Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
>Registered in England & Wales no 5513718.
>
>We continuously commit to comply with the applicable data protection laws and ensure fair and transparent processing of your personal data.
>Please read our privacy statement including an information notice and data protection policy for detailed information on our website.
Sebastian Fricke
Consultant Software Engineer

Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales no 5513718.

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

[Laurent Pinchart]

On Sat, Nov 09, 2024 at 09:04:56AM +0100, Sebastian Fricke wrote:
> Hey Martin,
> 
> On 20.09.2024 12:16, Hecht, Martin (Avnet Silica) wrote:
> >Hey Hans and Mauro,
> >
> >I remember also on a very little point regarding hardware for testing. But we didn't go in detail again during the summit.
> >
> >How do we can go ahead here? Are there some test systems up and running somewhere centralized or how it is organized right now?
> 
> Currently, different companies host their own hardware labs (Collabora,
> Qualcomm, Google, etc.) and these labs serve CI systems like KernelCI or
> DRM-CI (and we are currently working on setting these tests up on the
> Media-CI). The first step is to either add your devices to an existing
> lab or create your own one, by setting up your hardware with the
> necessary software, usually Lava, but you can also use Labgrid or
> something similar.

There's also https://gfx-ci.pages.freedesktop.org/ci-tron/ which seems
to be an interesting fast-moving project to keep an eye on.

> Let me know which way you prefer, and I can assist
> you with that approach.
> 
> >
> >BR Martin
> 
> Regards,
> Sebastian
> 
> >
> >________________________________________
> >Von: Sebastian Fricke <sebastian.fricke@collabora.com>
> >Gesendet: Mittwoch, 18. September 2024 11:30
> >An: Mauro Carvalho Chehab
> >Cc: Hans Verkuil; Linux Media Mailing List; Sakari Ailus; Daniel Almeida; Mauro Carvalho Chehab; Hecht, Martin (Avnet Silica); Tommaso Merciai; Jacopo Mondi; Benjamin Mugnier; Laurent Pinchart; Ricardo Ribalda; Michael Tretter; Alain Volmat; Sean Young; Steve Cho; Tomasz Figa; Hidenori Kobayashi; Hu, Jerry W; Suresh Vankadara; Devarsh Thakkar; r-donadkar@ti.com; Dave Stevenson; Mehdi Djait; Nicolas Dufresne; Salahaldeen Altous
> >Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda (v7)
> >
> >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@xs4all.nl> 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
> >
> >Also there were topics like how to handle backports.
> >
> >>
> >>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.
> >
> >Regards,
> >Sebastian
> >
> >>
> >>From my personal notes, this will be the new process:
> >>
> >>- committers will merge patches at media-committers.git tree at fdo,
> >>  provided that they'll follow the rules defined on a committers agreement
> >>  and (partially?) enforced by media-ci checks;
> >>- core committers follow the same rules, with a broader privilege of
> >>  changing kernel API/ABI;
> >>- committers will ensure that patchwork will reflect the review process of
> >>  the patches;
> >>- maintainers will double-check if everything is ok and, if ok, merge the
> >>  changes at linuxtv.org. We intend to rename the tree there to "media.git",
> >>  being the main tree to be used for development;
> >>- pull requests will keep using the same process as currently. The only
> >>  change is that the media-stage.git tree will be renamed to "media.git";
> >>- maintainers will periodically send patches upstream.
> >>
> >>The media-commiters.git tree at fdo might be rebased if needed; the
> >>media.git tree at linuxtv.org is stable. A large effort will be taken to
> >>avoid rebasing it.
> >>
> >>We may need some helper scripts and/or use pwclient to keep patchwork
> >>updated after committers reviews.
> >>
> >>Such process will start after -rc1.
> >>
> >>We intend to rename media-state to media at linuxtv after -rc1.
> >>
> >>It is up to maintainers to invite and decide who will be a committer.
> >>
> >>All committers/core-committers need to explicitly accept a committers
> >>agreement. We may end starting without it at the beginning, but as soon
> >>as a final version of such agreement is written, everyone with access to
> >>the media-committers tree have to explicitly accept to keep their
> >>commit rights on such tree.
> >>
> >>The only part that still require some work is the committers
> >>agreement. I'm working on it together with Hans. As soon as we have
> >>a version, we'll submit a patch to the kernel, to add it to the
> >>media developer's profile[1].
> >>
> >>[1] Documentation/driver-api/media/maintainer-entry-profile.rst
> >>
> >>>
> >>> For me I think Friday afternoon (probably after 14:00) is the only
> >>> option, or perhaps Thursday after the Camera MC.
> >>
> >>I can't meet on Friday afternoon. I probably will be on another
> >>event on Thursday (Openeuler MC).
> >>
> >>>
> >>> Regards,
> >>>
> >>>      Hans
> >>>
> >>> >
> >>> > Regards,
> >>> > Sebastian
> >>> >
> >>> > On 11.09.2024 11:03, Hans Verkuil wrote:
> >>> >> Hi all,
> >>> >>
> >>> >> Here is my seventh and final version of the agenda for the media
> >>> >> summit. As always,
> >>> >> all times (except lunch time) are guesstimates!
> >>> >>
> >>> >> The media summit will be held on Monday September 16th. Avnet Silica
> >>> >> has very
> >>> >> kindly offered to host this summit at their Vienna office, which is
> >>> >> about 35
> >>> >> minutes by public transport from the Open Source Summit Europe venue
> >>> >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
> >>> >>
> >>> >> Avnet Silica Office Location:
> >>> >>
> >>> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
> >>> >>
> >>> >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
> >>> >>
> >>> >> Refreshments are available during the day.
> >>> >>
> >>> >> Lunch is held at Schönbrunner Stöckl
> >>> >> (https://www.schoenbrunnerstoeckl.com/), close
> >>> >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board
> >>> >> and Cisco Systems
> >>> >> Norway.
> >>> >>
> >>> >> Regarding the face mask policy: we will follow the same guidance that the
> >>> >> Linux Foundation gives for the EOSS conference:
> >>> >>
> >>> >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
> >>> >>
> >>> >>
> >>> >> In-Person Attendees:
> >>> >>
> >>> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
> >>> >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
> >>> >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera
> >>> >> AG)
> >>> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel
> >>> >> Maintainer)
> >>> >> Steve Cho <stevecho@chromium.org> (Google)
> >>> >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
> >>> >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
> >>> >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
> >>> >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
> >>> >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
> >>> >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
> >>> >> Ricardo Ribalda <ribalda@chromium.org> (Google)
> >>> >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
> >>> >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
> >>> >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
> >>> >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
> >>> >> Sean Young <sean@mess.org>
> >>> >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
> >>> >>
> >>> >> Remote Attendees (using MS Teams):
> >>> >>
> >>> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
> >>> >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
> >>> >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
> >>> >> Tomasz Figa <tfiga@chromium.org> (Google)
> >>> >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
> >>> >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
> >>> >> Devarsh Thakkar <devarsht@ti.com> (TI)
> >>> >>
> >>> >> All remote participants listed above should have received an invite
> >>> >> with connection details.
> >>> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
> >>> >>
> >>> >> If any information above is incorrect, or if I missed someone, then
> >>> >> please let me know.
> >>> >>
> >>> >> We have 18 confirmed in-person participants, so we're full.
> >>> >> If you want to join remotely, then contact me and I'll add you to that
> >>> >> list.
> >>> >>
> >>> >> Draft agenda:
> >>> >>
> >>> >> 8:45-9:15: Get settled :-)
> >>> >>
> >>> >> 9:15-9:25: Hans: Quick introduction
> >>> >>
> >>> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
> >>> >>
> >>> >> 11:00-11:15: break
> >>> >>
> >>> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
> >>> >>
> >>> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
> >>> >>
> >>> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and
> >>> >> the paths forward.
> >>> >>
> >>> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media
> >>> >> controller device to submit requests.
> >>> >>
> >>> >> 14:45-15:00: break
> >>> >>
> >>> >> 15:00-15:30: Sean: new tooling for infrared:
> >>> >>
> >>> >> - What it is and what it can do (love to hear any feedback of course)
> >>> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
> >>> >> - What needs to be in place for a release?
> >>> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
> >>> >>
> >>> >> 15:30-16:00: Daniel: Rust in the media subsystem
> >>> >>
> >>> >> 16:00-16:15: break
> >>> >>
> >>> >> 16:15-16:30: Hans: UVC maintenance
> >>> >>
> >>> >> 16:30-17:00: Steve Cho:
> >>> >>
> >>> >> - V4L2 testing on Chromium using virtual video decode driver (visl)
> >>> >> - V4L2 video decoding testing with KernelCI
> >>> >>
> >>> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
> >>> >> See here for more info:
> >>> >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
> >>> >>
> >>> >> 17:30-18:00: Any other topics and feedback on what can be improved
> >>> >> next media summit.
> >>> >>
> >>> >> Hope to see you all on Monday!
> >>> >>
> >>> >> Regards,
> >>> >>
> >>> >>     Hans
> >>> >>
> >>> >>
> >>> >>
> >>> > Sebastian Fricke
> >>> > Consultant Software Engineer
> >>> >
> >>> > Collabora Ltd
> >>> > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
> >>> > Registered in England & Wales no 5513718.

-- 
Regards,

Laurent Pinchart

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

[Hecht, Martin (Avnet Silica)]

Hi Sebastian,

Thank you. I will come back on your offer later. Your hint are very welcome.

BR Martin

> -----Original Message-----
> From: Sebastian Fricke <sebastian.fricke@collabora.com>
> Sent: Samstag, 9. November 2024 09:05
> To: Hecht, Martin (Avnet Silica) <Martin.Hecht@avnet.eu>
> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>; Hans Verkuil
> <hverkuil@xs4all.nl>; Linux Media Mailing List <linux-media@vger.kernel.org>;
> Sakari Ailus <sakari.ailus@linux.intel.com>; Daniel Almeida
> <daniel.almeida@collabora.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Tommaso Merciai <tomm.merciai@gmail.com>;
> Jacopo Mondi <jacopo.mondi@ideasonboard.com>; Benjamin Mugnier
> <benjamin.mugnier@foss.st.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Ricardo Ribalda
> <ribalda@chromium.org>; Michael Tretter <m.tretter@pengutronix.de>; Alain
> Volmat <alain.volmat@foss.st.com>; Sean Young <sean@mess.org>; Steve
> Cho <stevecho@chromium.org>; Tomasz Figa <tfiga@chromium.org>;
> Hidenori Kobayashi <hidenorik@chromium.org>; Hu, Jerry W
> <jerry.w.hu@intel.com>; Suresh Vankadara <svankada@qti.qualcomm.com>;
> Devarsh Thakkar <devarsht@ti.com>; r-donadkar@ti.com; Dave Stevenson
> <dave.stevenson@raspberrypi.com>; Mehdi Djait
> <mehdi.djait@linux.intel.com>; Nicolas Dufresne <nicolas@ndufresne.ca>;
> Salahaldeen Altous <salahaldeen.altous@leica-camera.com>;
> sjoerd.simons@collabora.com; guy.lunardi@collabora.com;
> gustavo.padovan@collabora.com
> Subject: [External]Re: [ANN] Media Summit September 16th: Final Agenda
> (v7)
> 
> Hey Martin,
> 
> On 20.09.2024 12:16, Hecht, Martin (Avnet Silica) wrote:
> >Hey Hans and Mauro,
> >
> >I remember also on a very little point regarding hardware for testing. But we
> didn't go in detail again during the summit.
> >
> >How do we can go ahead here? Are there some test systems up and running
> somewhere centralized or how it is organized right now?
> 
> Currently, different companies host their own hardware labs (Collabora,
> Qualcomm, Google, etc.) and these labs serve CI systems like KernelCI or DRM-
> CI (and we are currently working on setting these tests up on the Media-CI).
> The first step is to either add your devices to an existing lab or create your own
> one, by setting up your hardware with the necessary software, usually Lava,
> but you can also use Labgrid or something similar. Let me know which way you
> prefer, and I can assist you with that approach.
> 
> >
> >BR Martin
> 
> Regards,
> Sebastian
> 
> >
> >________________________________________
> >Von: Sebastian Fricke <sebastian.fricke@collabora.com>
> >Gesendet: Mittwoch, 18. September 2024 11:30
> >An: Mauro Carvalho Chehab
> >Cc: Hans Verkuil; Linux Media Mailing List; Sakari Ailus; Daniel
> >Almeida; Mauro Carvalho Chehab; Hecht, Martin (Avnet Silica); Tommaso
> >Merciai; Jacopo Mondi; Benjamin Mugnier; Laurent Pinchart; Ricardo
> >Ribalda; Michael Tretter; Alain Volmat; Sean Young; Steve Cho; Tomasz
> >Figa; Hidenori Kobayashi; Hu, Jerry W; Suresh Vankadara; Devarsh
> >Thakkar; r-donadkar@ti.com; Dave Stevenson; Mehdi Djait; Nicolas
> >Dufresne; Salahaldeen Altous
> >Betreff: [External]Re: [ANN] Media Summit September 16th: Final Agenda
> >(v7)
> >
> >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@xs4all.nl> 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
> >
> >Also there were topics like how to handle backports.
> >
> >>
> >>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.
> >
> >Regards,
> >Sebastian
> >
> >>
> >>From my personal notes, this will be the new process:
> >>
> >>- committers will merge patches at media-committers.git tree at fdo,
> >>  provided that they'll follow the rules defined on a committers
> >>agreement
> >>  and (partially?) enforced by media-ci checks;
> >>- core committers follow the same rules, with a broader privilege of
> >>  changing kernel API/ABI;
> >>- committers will ensure that patchwork will reflect the review
> >>process of
> >>  the patches;
> >>- maintainers will double-check if everything is ok and, if ok, merge
> >>the
> >>  changes at linuxtv.org. We intend to rename the tree there to
> >>"media.git",
> >>  being the main tree to be used for development;
> >>- pull requests will keep using the same process as currently. The
> >>only
> >>  change is that the media-stage.git tree will be renamed to
> >>"media.git";
> >>- maintainers will periodically send patches upstream.
> >>
> >>The media-commiters.git tree at fdo might be rebased if needed; the
> >>media.git tree at linuxtv.org is stable. A large effort will be taken
> >>to avoid rebasing it.
> >>
> >>We may need some helper scripts and/or use pwclient to keep patchwork
> >>updated after committers reviews.
> >>
> >>Such process will start after -rc1.
> >>
> >>We intend to rename media-state to media at linuxtv after -rc1.
> >>
> >>It is up to maintainers to invite and decide who will be a committer.
> >>
> >>All committers/core-committers need to explicitly accept a committers
> >>agreement. We may end starting without it at the beginning, but as
> >>soon as a final version of such agreement is written, everyone with
> >>access to the media-committers tree have to explicitly accept to keep
> >>their commit rights on such tree.
> >>
> >>The only part that still require some work is the committers
> >>agreement. I'm working on it together with Hans. As soon as we have a
> >>version, we'll submit a patch to the kernel, to add it to the media
> >>developer's profile[1].
> >>
> >>[1] Documentation/driver-api/media/maintainer-entry-profile.rst
> >>
> >>>
> >>> For me I think Friday afternoon (probably after 14:00) is the only
> >>> option, or perhaps Thursday after the Camera MC.
> >>
> >>I can't meet on Friday afternoon. I probably will be on another event
> >>on Thursday (Openeuler MC).
> >>
> >>>
> >>> Regards,
> >>>
> >>>      Hans
> >>>
> >>> >
> >>> > Regards,
> >>> > Sebastian
> >>> >
> >>> > On 11.09.2024 11:03, Hans Verkuil wrote:
> >>> >> Hi all,
> >>> >>
> >>> >> Here is my seventh and final version of the agenda for the media
> >>> >> summit. As always, all times (except lunch time) are
> >>> >> guesstimates!
> >>> >>
> >>> >> The media summit will be held on Monday September 16th. Avnet
> >>> >> Silica has very kindly offered to host this summit at their
> >>> >> Vienna office, which is about 35 minutes by public transport from
> >>> >> the Open Source Summit Europe venue
> >>> >> (https://events.linuxfoundation.org/open-source-summit-
> europe/OSSE).
> >>> >>
> >>> >> Avnet Silica Office Location:
> >>> >>
> >>> >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
> >>> >>
> >>> >>
> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteil
> >>> >>
> e+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da
> >>> >>
> 80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16
> s%2
> >>> >> Fg%2F1tcy32vt?entry=ttu
> >>> >>
> >>> >> Refreshments are available during the day.
> >>> >>
> >>> >> Lunch is held at Schönbrunner Stöckl
> >>> >> (https://www.schoenbrunnerstoeckl.com/), close to the Avnet
> >>> >> Silica office. The lunch is sponsored by Ideas on Board and Cisco
> >>> >> Systems Norway.
> >>> >>
> >>> >> Regarding the face mask policy: we will follow the same guidance
> >>> >> that the Linux Foundation gives for the EOSS conference:
> >>> >>
> >>> >> https://events.linuxfoundation.org/open-source-summit-europe/atte
> >>> >> nd/health-and-safety/#onsite-health-and-safety
> >>> >>
> >>> >>
> >>> >> In-Person Attendees:
> >>> >>
> >>> >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel) Daniel
> >>> >> Almeida <daniel.almeida@collabora.com> (Collabora) Salahaldeen
> >>> >> Altous <salahaldeen.altous@leica-camera.com> (Leica Camera
> >>> >> AG)
> >>> >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media
> Kernel
> >>> >> Maintainer)
> >>> >> Steve Cho <stevecho@chromium.org> (Google) Sebastian Fricke
> >>> >> <sebastian.fricke@collabora.com> (Collabora) Martin Hecht
> >>> >> <martin.hecht@avnet.eu> (Avnet) Tommaso Merciai
> >>> >> <tomm.merciai@gmail.com> (Avnet) Jacopo Mondi
> >>> >> <jacopo.mondi@ideasonboard.com> (Ideas On Board) Benjamin
> Mugnier
> >>> >> <benjamin.mugnier@foss.st.com> (ST Electronics) Laurent Pinchart
> >>> >> <laurent.pinchart@ideasonboard.com> (Ideas On Board) Ricardo
> >>> >> Ribalda <ribalda@chromium.org> (Google) Michael Tretter
> >>> >> <m.tretter@pengutronix.de> (Pengutronix) Suresh Vankadara
> >>> >> <svankada@qti.qualcomm.com> (Qualcomm) Hans Verkuil
> >>> >> <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway) Alain Volmat
> >>> >> <alain.volmat@foss.st.com> (ST Electronics) Sean Young
> >>> >> <sean@mess.org> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
> >>> >>
> >>> >> Remote Attendees (using MS Teams):
> >>> >>
> >>> >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel) Rishikesh
> >>> >> Donadkar <r-donadkar@ti.com> (TI) Nicolas Dufresne
> >>> >> <nicolas@ndufresne.ca> (Collabora) Tomasz Figa
> >>> >> <tfiga@chromium.org> (Google) Hidenori Kobayashi
> >>> >> <hidenorik@chromium.org> (Google) Dave Stevenson
> >>> >> <dave.stevenson@raspberrypi.com> (Raspberry Pi) Devarsh Thakkar
> >>> >> <devarsht@ti.com> (TI)
> >>> >>
> >>> >> All remote participants listed above should have received an
> >>> >> invite with connection details.
> >>> >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
> >>> >>
> >>> >> If any information above is incorrect, or if I missed someone,
> >>> >> then please let me know.
> >>> >>
> >>> >> We have 18 confirmed in-person participants, so we're full.
> >>> >> If you want to join remotely, then contact me and I'll add you to
> >>> >> that list.
> >>> >>
> >>> >> Draft agenda:
> >>> >>
> >>> >> 8:45-9:15: Get settled :-)
> >>> >>
> >>> >> 9:15-9:25: Hans: Quick introduction
> >>> >>
> >>> >> 9:25-11:00: Ricardo: multi-committer model using gitlab
> >>> >>
> >>> >> 11:00-11:15: break
> >>> >>
> >>> >> 11:15-12:15: Jacopo: Multi-context support in V4L2
> >>> >>
> >>> >> 12:15-13:30: Lunch at Schönbrunner Stöckl
> >>> >>
> >>> >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations
> >>> >> and the paths forward.
> >>> >>
> >>> >> 14:00-14:45: Laurent: subdevs, state, and usage of the media
> >>> >> controller device to submit requests.
> >>> >>
> >>> >> 14:45-15:00: break
> >>> >>
> >>> >> 15:00-15:30: Sean: new tooling for infrared:
> >>> >>
> >>> >> - What it is and what it can do (love to hear any feedback of
> >>> >> course)
> >>> >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
> >>> >> - What needs to be in place for a release?
> >>> >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
> >>> >>
> >>> >> 15:30-16:00: Daniel: Rust in the media subsystem
> >>> >>
> >>> >> 16:00-16:15: break
> >>> >>
> >>> >> 16:15-16:30: Hans: UVC maintenance
> >>> >>
> >>> >> 16:30-17:00: Steve Cho:
> >>> >>
> >>> >> - V4L2 testing on Chromium using virtual video decode driver
> >>> >> (visl)
> >>> >> - V4L2 video decoding testing with KernelCI
> >>> >>
> >>> >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
> >>> >> See here for more info:
> >>> >> https://lore.kernel.org/linux-
> media/20240825222455.GA24390@pendra
> >>> >> gon.ideasonboard.com/
> >>> >>
> >>> >> 17:30-18:00: Any other topics and feedback on what can be
> >>> >> improved next media summit.
> >>> >>
> >>> >> Hope to see you all on Monday!
> >>> >>
> >>> >> Regards,
> >>> >>
> >>> >>     Hans
> >>> >>
> >>> >>
> >>> >>
> >>> > Sebastian Fricke
> >>> > Consultant Software Engineer
> >>> >
> >>> > Collabora Ltd
> >>> > Platinum Building, St John's Innovation Park, Cambridge CB4 0DS,
> >>> > UK Registered in England & Wales no 5513718.
> >>
> >Sebastian Fricke
> >Consultant Software Engineer
> >
> >Collabora Ltd
> >Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
> >Registered in England & Wales no 5513718.
> >
> >We continuously commit to comply with the applicable data protection laws
> and ensure fair and transparent processing of your personal data.
> >Please read our privacy statement including an information notice and data
> protection policy for detailed information on our website.
> Sebastian Fricke
> Consultant Software Engineer
> 
> Collabora Ltd
> Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
> Registered in England & Wales no 5513718.

We continuously commit to comply with the applicable data protection laws and ensure fair and transparent processing of your personal data. 
Please read our privacy statement including an information notice and data protection policy for detailed information on our website.

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

[Laurent Pinchart]

Hi Mauro,

On Wed, Sep 18, 2024 at 09:24:54AM +0200, 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?
> 
> 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.
> 
> From my personal notes, this will be the new process:
> 
> - committers will merge patches at media-committers.git tree at fdo,
>   provided that they'll follow the rules defined on a committers agreement
>   and (partially?) enforced by media-ci checks;
> - core committers follow the same rules, with a broader privilege of
>   changing kernel API/ABI;
> - committers will ensure that patchwork will reflect the review process of
>   the patches;
> - maintainers will double-check if everything is ok and, if ok, merge the
>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
>   being the main tree to be used for development;
> - pull requests will keep using the same process as currently. The only
>   change is that the media-stage.git tree will be renamed to "media.git";
> - maintainers will periodically send patches upstream.
> 
> The media-commiters.git tree at fdo might be rebased if needed; the 
> media.git tree at linuxtv.org is stable. A large effort will be taken to
> avoid rebasing it.
> 
> We may need some helper scripts and/or use pwclient to keep patchwork
> updated after committers reviews.

What will happen if we update the status of patches in patchwork when
merging them to the fdo tree, and the tree is later rebased to drop
commits ? Will the person rebasing handle updating patchwork to move the
patches back from accepted to a different status ?

> Such process will start after -rc1. 
> 
> We intend to rename media-state to media at linuxtv after -rc1.
> 
> It is up to maintainers to invite and decide who will be a committer.
> 
> All committers/core-committers need to explicitly accept a committers
> agreement. We may end starting without it at the beginning, but as soon
> as a final version of such agreement is written, everyone with access to
> the media-committers tree have to explicitly accept to keep their
> commit rights on such tree.
> 
> The only part that still require some work is the committers
> agreement. I'm working on it together with Hans. As soon as we have
> a version, we'll submit a patch to the kernel, to add it to the
> media developer's profile[1].
> 
> [1] Documentation/driver-api/media/maintainer-entry-profile.rst
> 
> > For me I think Friday afternoon (probably after 14:00) is the only 
> > option, or perhaps Thursday after the Camera MC.
> 
> I can't meet on Friday afternoon. I probably will be on another
> event on Thursday (Openeuler MC).
> 
> > > On 11.09.2024 11:03, Hans Verkuil wrote:  
> > >> Hi all,
> > >>
> > >> Here is my seventh and final version of the agenda for the media 
> > >> summit. As always,
> > >> all times (except lunch time) are guesstimates!
> > >>
> > >> The media summit will be held on Monday September 16th. Avnet Silica 
> > >> has very
> > >> kindly offered to host this summit at their Vienna office, which is 
> > >> about 35
> > >> minutes by public transport from the Open Source Summit Europe venue
> > >> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
> > >>
> > >> Avnet Silica Office Location:
> > >>
> > >> Schönbrunner Str. 297/307, 1120 Vienna, Austria
> > >>
> > >> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
> > >>
> > >> Refreshments are available during the day.
> > >>
> > >> Lunch is held at Schönbrunner Stöckl 
> > >> (https://www.schoenbrunnerstoeckl.com/), close
> > >> to the Avnet Silica office. The lunch is sponsored by Ideas on Board 
> > >> and Cisco Systems
> > >> Norway.
> > >>
> > >> Regarding the face mask policy: we will follow the same guidance that the
> > >> Linux Foundation gives for the EOSS conference:
> > >>
> > >> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
> > >>
> > >>
> > >> In-Person Attendees:
> > >>
> > >> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
> > >> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
> > >> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera 
> > >> AG)
> > >> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel 
> > >> Maintainer)
> > >> Steve Cho <stevecho@chromium.org> (Google)
> > >> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
> > >> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
> > >> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
> > >> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
> > >> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
> > >> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
> > >> Ricardo Ribalda <ribalda@chromium.org> (Google)
> > >> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
> > >> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
> > >> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
> > >> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
> > >> Sean Young <sean@mess.org>
> > >> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
> > >>
> > >> Remote Attendees (using MS Teams):
> > >>
> > >> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
> > >> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
> > >> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
> > >> Tomasz Figa <tfiga@chromium.org> (Google)
> > >> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
> > >> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
> > >> Devarsh Thakkar <devarsht@ti.com> (TI)
> > >>
> > >> All remote participants listed above should have received an invite 
> > >> with connection details.
> > >> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
> > >>
> > >> If any information above is incorrect, or if I missed someone, then 
> > >> please let me know.
> > >>
> > >> We have 18 confirmed in-person participants, so we're full.
> > >> If you want to join remotely, then contact me and I'll add you to that 
> > >> list.
> > >>
> > >> Draft agenda:
> > >>
> > >> 8:45-9:15: Get settled :-)
> > >>
> > >> 9:15-9:25: Hans: Quick introduction
> > >>
> > >> 9:25-11:00: Ricardo: multi-committer model using gitlab
> > >>
> > >> 11:00-11:15: break
> > >>
> > >> 11:15-12:15: Jacopo: Multi-context support in V4L2
> > >>
> > >> 12:15-13:30: Lunch at Schönbrunner Stöckl
> > >>
> > >> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and 
> > >> the paths forward.
> > >>
> > >> 14:00-14:45: Laurent: subdevs, state, and usage of the media 
> > >> controller device to submit requests.
> > >>
> > >> 14:45-15:00: break
> > >>
> > >> 15:00-15:30: Sean: new tooling for infrared:
> > >>
> > >> - What it is and what it can do (love to hear any feedback of course)
> > >> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
> > >> - What needs to be in place for a release?
> > >> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
> > >>
> > >> 15:30-16:00: Daniel: Rust in the media subsystem
> > >>
> > >> 16:00-16:15: break
> > >>
> > >> 16:15-16:30: Hans: UVC maintenance
> > >>
> > >> 16:30-17:00: Steve Cho:
> > >>
> > >> - V4L2 testing on Chromium using virtual video decode driver (visl)
> > >> - V4L2 video decoding testing with KernelCI
> > >>
> > >> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
> > >> See here for more info:
> > >> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
> > >>
> > >> 17:30-18:00: Any other topics and feedback on what can be improved 
> > >> next media summit.
> > >>
> > >> Hope to see you all on Monday!

-- 
Regards,

Laurent Pinchart

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

[Hans Verkuil]

On 25/09/2024 21:58, Laurent Pinchart wrote:
> Hi Mauro,
> 
> On Wed, Sep 18, 2024 at 09:24:54AM +0200, 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?
>>
>> 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.
>>
>> From my personal notes, this will be the new process:
>>
>> - committers will merge patches at media-committers.git tree at fdo,
>>   provided that they'll follow the rules defined on a committers agreement
>>   and (partially?) enforced by media-ci checks;
>> - core committers follow the same rules, with a broader privilege of
>>   changing kernel API/ABI;
>> - committers will ensure that patchwork will reflect the review process of
>>   the patches;
>> - maintainers will double-check if everything is ok and, if ok, merge the
>>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
>>   being the main tree to be used for development;
>> - pull requests will keep using the same process as currently. The only
>>   change is that the media-stage.git tree will be renamed to "media.git";
>> - maintainers will periodically send patches upstream.
>>
>> The media-commiters.git tree at fdo might be rebased if needed; the 
>> media.git tree at linuxtv.org is stable. A large effort will be taken to
>> avoid rebasing it.
>>
>> We may need some helper scripts and/or use pwclient to keep patchwork
>> updated after committers reviews.
> 
> What will happen if we update the status of patches in patchwork when
> merging them to the fdo tree, and the tree is later rebased to drop
> commits ? Will the person rebasing handle updating patchwork to move the
> patches back from accepted to a different status ?

That should be the responsibility of the person doing the rebase. I think
that's what is done today as well in the rare cases we rebase.

Regards,

	Hans

> 
>> Such process will start after -rc1. 
>>
>> We intend to rename media-state to media at linuxtv after -rc1.
>>
>> It is up to maintainers to invite and decide who will be a committer.
>>
>> All committers/core-committers need to explicitly accept a committers
>> agreement. We may end starting without it at the beginning, but as soon
>> as a final version of such agreement is written, everyone with access to
>> the media-committers tree have to explicitly accept to keep their
>> commit rights on such tree.
>>
>> The only part that still require some work is the committers
>> agreement. I'm working on it together with Hans. As soon as we have
>> a version, we'll submit a patch to the kernel, to add it to the
>> media developer's profile[1].
>>
>> [1] Documentation/driver-api/media/maintainer-entry-profile.rst
>>
>>> For me I think Friday afternoon (probably after 14:00) is the only 
>>> option, or perhaps Thursday after the Camera MC.
>>
>> I can't meet on Friday afternoon. I probably will be on another
>> event on Thursday (Openeuler MC).
>>
>>>> On 11.09.2024 11:03, Hans Verkuil wrote:  
>>>>> Hi all,
>>>>>
>>>>> Here is my seventh and final version of the agenda for the media 
>>>>> summit. As always,
>>>>> all times (except lunch time) are guesstimates!
>>>>>
>>>>> The media summit will be held on Monday September 16th. Avnet Silica 
>>>>> has very
>>>>> kindly offered to host this summit at their Vienna office, which is 
>>>>> about 35
>>>>> minutes by public transport from the Open Source Summit Europe venue
>>>>> (https://events.linuxfoundation.org/open-source-summit-europe/OSSE).
>>>>>
>>>>> Avnet Silica Office Location:
>>>>>
>>>>> Schönbrunner Str. 297/307, 1120 Vienna, Austria
>>>>>
>>>>> https://www.google.com/maps/place/Avnet+EMG+Elektronische+Bauteile+GmbH+(Silica)/@48.183203,16.3100937,15z/data=!4m6!3m5!1s0x476da80e20b26d5b:0x2c5d2a77bbd43334!8m2!3d48.1832035!4d16.320372!16s%2Fg%2F1tcy32vt?entry=ttu
>>>>>
>>>>> Refreshments are available during the day.
>>>>>
>>>>> Lunch is held at Schönbrunner Stöckl 
>>>>> (https://www.schoenbrunnerstoeckl.com/), close
>>>>> to the Avnet Silica office. The lunch is sponsored by Ideas on Board 
>>>>> and Cisco Systems
>>>>> Norway.
>>>>>
>>>>> Regarding the face mask policy: we will follow the same guidance that the
>>>>> Linux Foundation gives for the EOSS conference:
>>>>>
>>>>> https://events.linuxfoundation.org/open-source-summit-europe/attend/health-and-safety/#onsite-health-and-safety
>>>>>
>>>>>
>>>>> In-Person Attendees:
>>>>>
>>>>> Sakari Ailus <sakari.ailus@linux.intel.com> (Intel)
>>>>> Daniel Almeida <daniel.almeida@collabora.com> (Collabora)
>>>>> Salahaldeen Altous <salahaldeen.altous@leica-camera.com> (Leica Camera 
>>>>> AG)
>>>>> Mauro Carvalho Chehab <mchehab@kernel.org> (Huawei, Media Kernel 
>>>>> Maintainer)
>>>>> Steve Cho <stevecho@chromium.org> (Google)
>>>>> Sebastian Fricke <sebastian.fricke@collabora.com> (Collabora)
>>>>> Martin Hecht <martin.hecht@avnet.eu> (Avnet)
>>>>> Tommaso Merciai <tomm.merciai@gmail.com> (Avnet)
>>>>> Jacopo Mondi <jacopo.mondi@ideasonboard.com> (Ideas On Board)
>>>>> Benjamin Mugnier <benjamin.mugnier@foss.st.com> (ST Electronics)
>>>>> Laurent Pinchart <laurent.pinchart@ideasonboard.com> (Ideas On Board)
>>>>> Ricardo Ribalda <ribalda@chromium.org> (Google)
>>>>> Michael Tretter <m.tretter@pengutronix.de> (Pengutronix)
>>>>> Suresh Vankadara <svankada@qti.qualcomm.com> (Qualcomm)
>>>>> Hans Verkuil <hverkuil-cisco@xs4all.nl> (Cisco Systems Norway)
>>>>> Alain Volmat <alain.volmat@foss.st.com> (ST Electronics)
>>>>> Sean Young <sean@mess.org>
>>>>> Jerry W Hu <jerry.w.hu@intel.com> (Intel)
>>>>>
>>>>> Remote Attendees (using MS Teams):
>>>>>
>>>>> Mehdi Djait <mehdi.djait@linux.intel.com> (Intel)
>>>>> Rishikesh Donadkar <r-donadkar@ti.com> (TI)
>>>>> Nicolas Dufresne <nicolas@ndufresne.ca> (Collabora)
>>>>> Tomasz Figa <tfiga@chromium.org> (Google)
>>>>> Hidenori Kobayashi <hidenorik@chromium.org> (Google)
>>>>> Dave Stevenson <dave.stevenson@raspberrypi.com> (Raspberry Pi)
>>>>> Devarsh Thakkar <devarsht@ti.com> (TI)
>>>>>
>>>>> All remote participants listed above should have received an invite 
>>>>> with connection details.
>>>>> If not, please contact Martin Hecht <martin.hecht@avnet.eu> asap.
>>>>>
>>>>> If any information above is incorrect, or if I missed someone, then 
>>>>> please let me know.
>>>>>
>>>>> We have 18 confirmed in-person participants, so we're full.
>>>>> If you want to join remotely, then contact me and I'll add you to that 
>>>>> list.
>>>>>
>>>>> Draft agenda:
>>>>>
>>>>> 8:45-9:15: Get settled :-)
>>>>>
>>>>> 9:15-9:25: Hans: Quick introduction
>>>>>
>>>>> 9:25-11:00: Ricardo: multi-committer model using gitlab
>>>>>
>>>>> 11:00-11:15: break
>>>>>
>>>>> 11:15-12:15: Jacopo: Multi-context support in V4L2
>>>>>
>>>>> 12:15-13:30: Lunch at Schönbrunner Stöckl
>>>>>
>>>>> 13:30-14:00: Tomasz: Current state of videobuf2, its limitations and 
>>>>> the paths forward.
>>>>>
>>>>> 14:00-14:45: Laurent: subdevs, state, and usage of the media 
>>>>> controller device to submit requests.
>>>>>
>>>>> 14:45-15:00: break
>>>>>
>>>>> 15:00-15:30: Sean: new tooling for infrared:
>>>>>
>>>>> - What it is and what it can do (love to hear any feedback of course)
>>>>> - Where it should be hosted? (I hope gitlab fdo, who do I ask)
>>>>> - What needs to be in place for a release?
>>>>> - This tool replaces ir-ctl and ir-keytable. How we phase them out?
>>>>>
>>>>> 15:30-16:00: Daniel: Rust in the media subsystem
>>>>>
>>>>> 16:00-16:15: break
>>>>>
>>>>> 16:15-16:30: Hans: UVC maintenance
>>>>>
>>>>> 16:30-17:00: Steve Cho:
>>>>>
>>>>> - V4L2 testing on Chromium using virtual video decode driver (visl)
>>>>> - V4L2 video decoding testing with KernelCI
>>>>>
>>>>> 17:00-17:30: Laurent: Should media drivers depend on CONFIG_PM?
>>>>> See here for more info:
>>>>> https://lore.kernel.org/linux-media/20240825222455.GA24390@pendragon.ideasonboard.com/
>>>>>
>>>>> 17:30-18:00: Any other topics and feedback on what can be improved 
>>>>> next media summit.
>>>>>
>>>>> Hope to see you all on Monday!
> 

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

[Sakari Ailus]

Hi Hans, others,

On Thu, Sep 26, 2024 at 09:27:20AM +0200, Hans Verkuil wrote:
> On 25/09/2024 21:58, Laurent Pinchart wrote:
> > Hi Mauro,
> > 
> > On Wed, Sep 18, 2024 at 09:24:54AM +0200, 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?
> >>
> >> 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.
> >>
> >> From my personal notes, this will be the new process:
> >>
> >> - committers will merge patches at media-committers.git tree at fdo,
> >>   provided that they'll follow the rules defined on a committers agreement
> >>   and (partially?) enforced by media-ci checks;
> >> - core committers follow the same rules, with a broader privilege of
> >>   changing kernel API/ABI;
> >> - committers will ensure that patchwork will reflect the review process of
> >>   the patches;
> >> - maintainers will double-check if everything is ok and, if ok, merge the
> >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> >>   being the main tree to be used for development;
> >> - pull requests will keep using the same process as currently. The only
> >>   change is that the media-stage.git tree will be renamed to "media.git";
> >> - maintainers will periodically send patches upstream.
> >>
> >> The media-commiters.git tree at fdo might be rebased if needed; the 
> >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> >> avoid rebasing it.
> >>
> >> We may need some helper scripts and/or use pwclient to keep patchwork
> >> updated after committers reviews.
> > 
> > What will happen if we update the status of patches in patchwork when
> > merging them to the fdo tree, and the tree is later rebased to drop
> > commits ? Will the person rebasing handle updating patchwork to move the
> > patches back from accepted to a different status ?
> 
> That should be the responsibility of the person doing the rebase. I think
> that's what is done today as well in the rare cases we rebase.

Sounds reasonable. I'd also like to avoid rebases as much as possible.

Do we have a list of cases where a rebase would be needed? A license issue
or a missing Sob line, perhaps?

-- 
Kind regards,

Sakari Ailus

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 09:30:34 +0000
Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:

> > >>> Can you refresh my memory which processes need more work?  
> > >>
> > >> 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.
> > >>
> > >> From my personal notes, this will be the new process:
> > >>
> > >> - committers will merge patches at media-committers.git tree at fdo,
> > >>   provided that they'll follow the rules defined on a committers agreement
> > >>   and (partially?) enforced by media-ci checks;
> > >> - core committers follow the same rules, with a broader privilege of
> > >>   changing kernel API/ABI;
> > >> - committers will ensure that patchwork will reflect the review process of
> > >>   the patches;
> > >> - maintainers will double-check if everything is ok and, if ok, merge the
> > >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> > >>   being the main tree to be used for development;
> > >> - pull requests will keep using the same process as currently. The only
> > >>   change is that the media-stage.git tree will be renamed to "media.git";
> > >> - maintainers will periodically send patches upstream.
> > >>
> > >> The media-commiters.git tree at fdo might be rebased if needed; the 
> > >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> > >> avoid rebasing it.
> > >>
> > >> We may need some helper scripts and/or use pwclient to keep patchwork
> > >> updated after committers reviews.  
> > > 
> > > What will happen if we update the status of patches in patchwork when
> > > merging them to the fdo tree, and the tree is later rebased to drop
> > > commits ? Will the person rebasing handle updating patchwork to move the
> > > patches back from accepted to a different status ?  
> > 
> > That should be the responsibility of the person doing the rebase. I think
> > that's what is done today as well in the rare cases we rebase.  
> 
> Sounds reasonable. I'd also like to avoid rebases as much as possible.
> 
> Do we have a list of cases where a rebase would be needed? A license issue
> or a missing Sob line, perhaps?

No, and I don't think we can write a rule to cover such cases. The only rule
is that it is up to maintainers to decide to do a rebase or not, and this
will be done case by case.

With regards to the cases you mentioned, it is almost surely that license 
issues will call for a rebase. The same may apply up to some point for 
missing/refused SoBs from authors, co-developers and from the committers.

Yet, I would expect that a more common case is if someone touches the code
and another committer/developer/author nacks with such changes.

So, for instance, suppose you maintain driver A. Some other committer
may end merging a patch for driver A without your ack. Depending on the
patch that could be OK (trivial/doc changes, bugs with bug fixes that
are available for some time, etc).

Yet, even if the committer did an honest handling of the patch, you may 
still disagree or want some changes at the original patch. On such cases, 
the maintainers may decide to drop the changes and do a normal review
process. They may otherwise request a patch on the top of the applied
one to address the pointed issues.

There is also worse case scenarios, like a committer violating the
committer's agreement.


Thanks,
Mauro

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

[Laurent Pinchart]

On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Sep 2024 09:30:34 +0000
> Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> 
> > > >>> Can you refresh my memory which processes need more work?  
> > > >>
> > > >> 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.
> > > >>
> > > >> From my personal notes, this will be the new process:
> > > >>
> > > >> - committers will merge patches at media-committers.git tree at fdo,
> > > >>   provided that they'll follow the rules defined on a committers agreement
> > > >>   and (partially?) enforced by media-ci checks;
> > > >> - core committers follow the same rules, with a broader privilege of
> > > >>   changing kernel API/ABI;
> > > >> - committers will ensure that patchwork will reflect the review process of
> > > >>   the patches;
> > > >> - maintainers will double-check if everything is ok and, if ok, merge the
> > > >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> > > >>   being the main tree to be used for development;
> > > >> - pull requests will keep using the same process as currently. The only
> > > >>   change is that the media-stage.git tree will be renamed to "media.git";
> > > >> - maintainers will periodically send patches upstream.
> > > >>
> > > >> The media-commiters.git tree at fdo might be rebased if needed; the 
> > > >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> > > >> avoid rebasing it.
> > > >>
> > > >> We may need some helper scripts and/or use pwclient to keep patchwork
> > > >> updated after committers reviews.  
> > > > 
> > > > What will happen if we update the status of patches in patchwork when
> > > > merging them to the fdo tree, and the tree is later rebased to drop
> > > > commits ? Will the person rebasing handle updating patchwork to move the
> > > > patches back from accepted to a different status ?  
> > > 
> > > That should be the responsibility of the person doing the rebase. I think
> > > that's what is done today as well in the rare cases we rebase.  
> > 
> > Sounds reasonable. I'd also like to avoid rebases as much as possible.
> > 
> > Do we have a list of cases where a rebase would be needed? A license issue
> > or a missing Sob line, perhaps?
> 
> No, and I don't think we can write a rule to cover such cases. The only rule
> is that it is up to maintainers to decide to do a rebase or not, and this
> will be done case by case.
> 
> With regards to the cases you mentioned, it is almost surely that license 
> issues will call for a rebase. The same may apply up to some point for 
> missing/refused SoBs from authors, co-developers and from the committers.
> 
> Yet, I would expect that a more common case is if someone touches the code
> and another committer/developer/author nacks with such changes.
> 
> So, for instance, suppose you maintain driver A. Some other committer
> may end merging a patch for driver A without your ack. Depending on the
> patch that could be OK (trivial/doc changes, bugs with bug fixes that
> are available for some time, etc).
> 
> Yet, even if the committer did an honest handling of the patch, you may 
> still disagree or want some changes at the original patch. On such cases, 
> the maintainers may decide to drop the changes and do a normal review
> process. They may otherwise request a patch on the top of the applied
> one to address the pointed issues.

Let's do a revert in that case, and keep rebases for cases where having
content in the git history causes issues other than bisection problems.

I'd argue that even a missing SoB may not be a cause for rebase if it's
an accident, but that's not worth debating because CI will make sure
this never happens.

> There is also worse case scenarios, like a committer violating the
> committer's agreement.

I'm fine with rebases if someone gets rogue and merges malicious code,
or commits with insults in the commit message. I don't foresee that
happening regularly, if ever.

-- 
Regards,

Laurent Pinchart

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

[Sakari Ailus]

Hi Laurent,

On Thu, Sep 26, 2024 at 01:24:48PM +0300, Laurent Pinchart wrote:
> On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 26 Sep 2024 09:30:34 +0000
> > Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> > 
> > > > >>> Can you refresh my memory which processes need more work?  
> > > > >>
> > > > >> 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.
> > > > >>
> > > > >> From my personal notes, this will be the new process:
> > > > >>
> > > > >> - committers will merge patches at media-committers.git tree at fdo,
> > > > >>   provided that they'll follow the rules defined on a committers agreement
> > > > >>   and (partially?) enforced by media-ci checks;
> > > > >> - core committers follow the same rules, with a broader privilege of
> > > > >>   changing kernel API/ABI;
> > > > >> - committers will ensure that patchwork will reflect the review process of
> > > > >>   the patches;
> > > > >> - maintainers will double-check if everything is ok and, if ok, merge the
> > > > >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> > > > >>   being the main tree to be used for development;
> > > > >> - pull requests will keep using the same process as currently. The only
> > > > >>   change is that the media-stage.git tree will be renamed to "media.git";
> > > > >> - maintainers will periodically send patches upstream.
> > > > >>
> > > > >> The media-commiters.git tree at fdo might be rebased if needed; the 
> > > > >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> > > > >> avoid rebasing it.
> > > > >>
> > > > >> We may need some helper scripts and/or use pwclient to keep patchwork
> > > > >> updated after committers reviews.  
> > > > > 
> > > > > What will happen if we update the status of patches in patchwork when
> > > > > merging them to the fdo tree, and the tree is later rebased to drop
> > > > > commits ? Will the person rebasing handle updating patchwork to move the
> > > > > patches back from accepted to a different status ?  
> > > > 
> > > > That should be the responsibility of the person doing the rebase. I think
> > > > that's what is done today as well in the rare cases we rebase.  
> > > 
> > > Sounds reasonable. I'd also like to avoid rebases as much as possible.
> > > 
> > > Do we have a list of cases where a rebase would be needed? A license issue
> > > or a missing Sob line, perhaps?
> > 
> > No, and I don't think we can write a rule to cover such cases. The only rule
> > is that it is up to maintainers to decide to do a rebase or not, and this
> > will be done case by case.
> > 
> > With regards to the cases you mentioned, it is almost surely that license 
> > issues will call for a rebase. The same may apply up to some point for 
> > missing/refused SoBs from authors, co-developers and from the committers.
> > 
> > Yet, I would expect that a more common case is if someone touches the code
> > and another committer/developer/author nacks with such changes.
> > 
> > So, for instance, suppose you maintain driver A. Some other committer
> > may end merging a patch for driver A without your ack. Depending on the
> > patch that could be OK (trivial/doc changes, bugs with bug fixes that
> > are available for some time, etc).
> > 
> > Yet, even if the committer did an honest handling of the patch, you may 
> > still disagree or want some changes at the original patch. On such cases, 
> > the maintainers may decide to drop the changes and do a normal review
> > process. They may otherwise request a patch on the top of the applied
> > one to address the pointed issues.
> 
> Let's do a revert in that case, and keep rebases for cases where having
> content in the git history causes issues other than bisection problems.

I'd very much prefer this as well: revert or fix, if at all reasonable,
instead of rebasing should be a rule.

> 
> I'd argue that even a missing SoB may not be a cause for rebase if it's
> an accident, but that's not worth debating because CI will make sure
> this never happens.

Does it?

checkpatch.pl checks should just be warnings. And that should probably
stay. Sob: and From: being different isn't necessarily that far-fetched as
having an address in .mailmap may change From: field but not Sob:,
resulting in a checkpatch.pl warning.

I wonder if checkpatch.pl should know about .mailmap actually, currently it
doesn't. I could send a patch.

> 
> > There is also worse case scenarios, like a committer violating the
> > committer's agreement.
> 
> I'm fine with rebases if someone gets rogue and merges malicious code,
> or commits with insults in the commit message. I don't foresee that
> happening regularly, if ever.

I'm more concerned of a malicious actor getting access to the committer's
credentials rather than the committer him-/herself going crazy. And if this
happens, changes are it won't be noticed immediately.

Reminding of
<URL:https://github.com/lfit/itpol/blob/master/linux-workstation-security.md>
in the instructions might not be a bad idea.

-- 
Kind regards,

Sakari Ailus

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

[Laurent Pinchart]

On Thu, Sep 26, 2024 at 10:35:34AM +0000, Sakari Ailus wrote:
> Hi Laurent,
> 
> On Thu, Sep 26, 2024 at 01:24:48PM +0300, Laurent Pinchart wrote:
> > On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 26 Sep 2024 09:30:34 +0000
> > > Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> > > 
> > > > > >>> Can you refresh my memory which processes need more work?  
> > > > > >>
> > > > > >> 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.
> > > > > >>
> > > > > >> From my personal notes, this will be the new process:
> > > > > >>
> > > > > >> - committers will merge patches at media-committers.git tree at fdo,
> > > > > >>   provided that they'll follow the rules defined on a committers agreement
> > > > > >>   and (partially?) enforced by media-ci checks;
> > > > > >> - core committers follow the same rules, with a broader privilege of
> > > > > >>   changing kernel API/ABI;
> > > > > >> - committers will ensure that patchwork will reflect the review process of
> > > > > >>   the patches;
> > > > > >> - maintainers will double-check if everything is ok and, if ok, merge the
> > > > > >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> > > > > >>   being the main tree to be used for development;
> > > > > >> - pull requests will keep using the same process as currently. The only
> > > > > >>   change is that the media-stage.git tree will be renamed to "media.git";
> > > > > >> - maintainers will periodically send patches upstream.
> > > > > >>
> > > > > >> The media-commiters.git tree at fdo might be rebased if needed; the 
> > > > > >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> > > > > >> avoid rebasing it.
> > > > > >>
> > > > > >> We may need some helper scripts and/or use pwclient to keep patchwork
> > > > > >> updated after committers reviews.  
> > > > > > 
> > > > > > What will happen if we update the status of patches in patchwork when
> > > > > > merging them to the fdo tree, and the tree is later rebased to drop
> > > > > > commits ? Will the person rebasing handle updating patchwork to move the
> > > > > > patches back from accepted to a different status ?  
> > > > > 
> > > > > That should be the responsibility of the person doing the rebase. I think
> > > > > that's what is done today as well in the rare cases we rebase.  
> > > > 
> > > > Sounds reasonable. I'd also like to avoid rebases as much as possible.
> > > > 
> > > > Do we have a list of cases where a rebase would be needed? A license issue
> > > > or a missing Sob line, perhaps?
> > > 
> > > No, and I don't think we can write a rule to cover such cases. The only rule
> > > is that it is up to maintainers to decide to do a rebase or not, and this
> > > will be done case by case.
> > > 
> > > With regards to the cases you mentioned, it is almost surely that license 
> > > issues will call for a rebase. The same may apply up to some point for 
> > > missing/refused SoBs from authors, co-developers and from the committers.
> > > 
> > > Yet, I would expect that a more common case is if someone touches the code
> > > and another committer/developer/author nacks with such changes.
> > > 
> > > So, for instance, suppose you maintain driver A. Some other committer
> > > may end merging a patch for driver A without your ack. Depending on the
> > > patch that could be OK (trivial/doc changes, bugs with bug fixes that
> > > are available for some time, etc).
> > > 
> > > Yet, even if the committer did an honest handling of the patch, you may 
> > > still disagree or want some changes at the original patch. On such cases, 
> > > the maintainers may decide to drop the changes and do a normal review
> > > process. They may otherwise request a patch on the top of the applied
> > > one to address the pointed issues.
> > 
> > Let's do a revert in that case, and keep rebases for cases where having
> > content in the git history causes issues other than bisection problems.
> 
> I'd very much prefer this as well: revert or fix, if at all reasonable,
> instead of rebasing should be a rule.
> 
> > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > an accident, but that's not worth debating because CI will make sure
> > this never happens.
> 
> Does it?
>
> checkpatch.pl checks should just be warnings. And that should probably
> stay. Sob: and From: being different isn't necessarily that far-fetched as
> having an address in .mailmap may change From: field but not Sob:,
> resulting in a checkpatch.pl warning.
> 
> I wonder if checkpatch.pl should know about .mailmap actually, currently it
> doesn't. I could send a patch.

We have an explicit check in the CI to ensure that both the author and the
committer have a SoB line. It's not base on checkpatch.pl. Ricardo,
could you confirm this ?

> > > There is also worse case scenarios, like a committer violating the
> > > committer's agreement.
> > 
> > I'm fine with rebases if someone gets rogue and merges malicious code,
> > or commits with insults in the commit message. I don't foresee that
> > happening regularly, if ever.
> 
> I'm more concerned of a malicious actor getting access to the committer's
> credentials rather than the committer him-/herself going crazy. And if this
> happens, changes are it won't be noticed immediately.

That's not much different than someone impersonating me or you when
sending pull requests. Signing tags helps, but if someone steals
credentials, it's also game over. With the new workflow the malicious
changes will need to pass CI, so there may be more scrutiny :-)

> Reminding of
> <URL:https://github.com/lfit/itpol/blob/master/linux-workstation-security.md>
> in the instructions might not be a bad idea.

Agreed.

-- 
Regards,

Laurent Pinchart

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

[Ricardo Ribalda]

Hi!

On Thu, 26 Sept 2024 at 12:40, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Thu, Sep 26, 2024 at 10:35:34AM +0000, Sakari Ailus wrote:
> > Hi Laurent,
> >
> > On Thu, Sep 26, 2024 at 01:24:48PM +0300, Laurent Pinchart wrote:
> > > On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > > > Em Thu, 26 Sep 2024 09:30:34 +0000
> > > > Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> > > >
> > > > > > >>> Can you refresh my memory which processes need more work?
> > > > > > >>
> > > > > > >> 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.
> > > > > > >>
> > > > > > >> From my personal notes, this will be the new process:
> > > > > > >>
> > > > > > >> - committers will merge patches at media-committers.git tree at fdo,
> > > > > > >>   provided that they'll follow the rules defined on a committers agreement
> > > > > > >>   and (partially?) enforced by media-ci checks;
> > > > > > >> - core committers follow the same rules, with a broader privilege of
> > > > > > >>   changing kernel API/ABI;
> > > > > > >> - committers will ensure that patchwork will reflect the review process of
> > > > > > >>   the patches;
> > > > > > >> - maintainers will double-check if everything is ok and, if ok, merge the
> > > > > > >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> > > > > > >>   being the main tree to be used for development;
> > > > > > >> - pull requests will keep using the same process as currently. The only
> > > > > > >>   change is that the media-stage.git tree will be renamed to "media.git";
> > > > > > >> - maintainers will periodically send patches upstream.
> > > > > > >>
> > > > > > >> The media-commiters.git tree at fdo might be rebased if needed; the
> > > > > > >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> > > > > > >> avoid rebasing it.
> > > > > > >>
> > > > > > >> We may need some helper scripts and/or use pwclient to keep patchwork
> > > > > > >> updated after committers reviews.
> > > > > > >
> > > > > > > What will happen if we update the status of patches in patchwork when
> > > > > > > merging them to the fdo tree, and the tree is later rebased to drop
> > > > > > > commits ? Will the person rebasing handle updating patchwork to move the
> > > > > > > patches back from accepted to a different status ?
> > > > > >
> > > > > > That should be the responsibility of the person doing the rebase. I think
> > > > > > that's what is done today as well in the rare cases we rebase.
> > > > >
> > > > > Sounds reasonable. I'd also like to avoid rebases as much as possible.
> > > > >
> > > > > Do we have a list of cases where a rebase would be needed? A license issue
> > > > > or a missing Sob line, perhaps?
> > > >
> > > > No, and I don't think we can write a rule to cover such cases. The only rule
> > > > is that it is up to maintainers to decide to do a rebase or not, and this
> > > > will be done case by case.
> > > >
> > > > With regards to the cases you mentioned, it is almost surely that license
> > > > issues will call for a rebase. The same may apply up to some point for
> > > > missing/refused SoBs from authors, co-developers and from the committers.
> > > >
> > > > Yet, I would expect that a more common case is if someone touches the code
> > > > and another committer/developer/author nacks with such changes.
> > > >
> > > > So, for instance, suppose you maintain driver A. Some other committer
> > > > may end merging a patch for driver A without your ack. Depending on the
> > > > patch that could be OK (trivial/doc changes, bugs with bug fixes that
> > > > are available for some time, etc).
> > > >
> > > > Yet, even if the committer did an honest handling of the patch, you may
> > > > still disagree or want some changes at the original patch. On such cases,
> > > > the maintainers may decide to drop the changes and do a normal review
> > > > process. They may otherwise request a patch on the top of the applied
> > > > one to address the pointed issues.
> > >
> > > Let's do a revert in that case, and keep rebases for cases where having
> > > content in the git history causes issues other than bisection problems.
> >
> > I'd very much prefer this as well: revert or fix, if at all reasonable,
> > instead of rebasing should be a rule.
> >
> > > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > > an accident, but that's not worth debating because CI will make sure
> > > this never happens.
> >
> > Does it?
> >
> > checkpatch.pl checks should just be warnings. And that should probably
> > stay. Sob: and From: being different isn't necessarily that far-fetched as
> > having an address in .mailmap may change From: field but not Sob:,
> > resulting in a checkpatch.pl warning.
> >
> > I wonder if checkpatch.pl should know about .mailmap actually, currently it
> > doesn't. I could send a patch.
>
> We have an explicit check in the CI to ensure that both the author and the
> committer have a SoB line. It's not base on checkpatch.pl. Ricardo,
> could you confirm this ?

CI checks that there are at least 2 committers that agree with the
code (SoB, Reviewed-by or Ack-by)
https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/lib/test-trust.py?ref_type=heads

We also have a separate check for SoB:
https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-media-patchstyle.sh?ref_type=heads#L61


>
> > > > There is also worse case scenarios, like a committer violating the
> > > > committer's agreement.
> > >
> > > I'm fine with rebases if someone gets rogue and merges malicious code,
> > > or commits with insults in the commit message. I don't foresee that
> > > happening regularly, if ever.
> >
> > I'm more concerned of a malicious actor getting access to the committer's
> > credentials rather than the committer him-/herself going crazy. And if this
> > happens, changes are it won't be noticed immediately.
>
> That's not much different than someone impersonating me or you when
> sending pull requests. Signing tags helps, but if someone steals
> credentials, it's also game over. With the new workflow the malicious
> changes will need to pass CI, so there may be more scrutiny :-)
>
> > Reminding of
> > <URL:https://github.com/lfit/itpol/blob/master/linux-workstation-security.md>
> > in the instructions might not be a bad idea.
>
> Agreed.
>
> --
> Regards,
>
> Laurent Pinchart



--
Ricardo Ribalda

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

[Sakari Ailus]

Hi Ricardo,

On Thu, Sep 26, 2024 at 12:46:49PM +0200, Ricardo Ribalda wrote:
> > > > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > > > an accident, but that's not worth debating because CI will make sure
> > > > this never happens.
> > >
> > > Does it?
> > >
> > > checkpatch.pl checks should just be warnings. And that should probably
> > > stay. Sob: and From: being different isn't necessarily that far-fetched as
> > > having an address in .mailmap may change From: field but not Sob:,
> > > resulting in a checkpatch.pl warning.
> > >
> > > I wonder if checkpatch.pl should know about .mailmap actually, currently it
> > > doesn't. I could send a patch.
> >
> > We have an explicit check in the CI to ensure that both the author and the
> > committer have a SoB line. It's not base on checkpatch.pl. Ricardo,
> > could you confirm this ?
> 
> CI checks that there are at least 2 committers that agree with the
> code (SoB, Reviewed-by or Ack-by)
> https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/lib/test-trust.py?ref_type=heads
> 
> We also have a separate check for SoB:
> https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-media-patchstyle.sh?ref_type=heads#L61

This script appears to be also ignoring .mailmap.

-- 
Sakari Ailus

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

[Ricardo Ribalda]

Hi

On Thu, 26 Sept 2024 at 12:54, Sakari Ailus
<sakari.ailus@linux.intel.com> wrote:
>
> Hi Ricardo,
>
> On Thu, Sep 26, 2024 at 12:46:49PM +0200, Ricardo Ribalda wrote:
> > > > > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > > > > an accident, but that's not worth debating because CI will make sure
> > > > > this never happens.
> > > >
> > > > Does it?
> > > >
> > > > checkpatch.pl checks should just be warnings. And that should probably
> > > > stay. Sob: and From: being different isn't necessarily that far-fetched as
> > > > having an address in .mailmap may change From: field but not Sob:,
> > > > resulting in a checkpatch.pl warning.
> > > >
> > > > I wonder if checkpatch.pl should know about .mailmap actually, currently it
> > > > doesn't. I could send a patch.
> > >
> > > We have an explicit check in the CI to ensure that both the author and the
> > > committer have a SoB line. It's not base on checkpatch.pl. Ricardo,
> > > could you confirm this ?
> >
> > CI checks that there are at least 2 committers that agree with the
> > code (SoB, Reviewed-by or Ack-by)
> > https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/lib/test-trust.py?ref_type=heads
> >
> > We also have a separate check for SoB:
> > https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-media-patchstyle.sh?ref_type=heads#L61
>
> This script appears to be also ignoring .mailmap.
test-trust does not ignore mailmap:
https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/lib/test-trust.py?ref_type=heads#L56

Do you see any scenario where the committer and the author are
different users? "git commit" will set the same value for boths
I am not against to modify the code if we find that usecase

>
> --
> Sakari Ailus



-- 
Ricardo Ribalda

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

[Sakari Ailus]

Hi Ricardo,

On Thu, Sep 26, 2024 at 12:59:35PM +0200, Ricardo Ribalda wrote:
> Hi
> 
> On Thu, 26 Sept 2024 at 12:54, Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
> >
> > Hi Ricardo,
> >
> > On Thu, Sep 26, 2024 at 12:46:49PM +0200, Ricardo Ribalda wrote:
> > > > > > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > > > > > an accident, but that's not worth debating because CI will make sure
> > > > > > this never happens.
> > > > >
> > > > > Does it?
> > > > >
> > > > > checkpatch.pl checks should just be warnings. And that should probably
> > > > > stay. Sob: and From: being different isn't necessarily that far-fetched as
> > > > > having an address in .mailmap may change From: field but not Sob:,
> > > > > resulting in a checkpatch.pl warning.
> > > > >
> > > > > I wonder if checkpatch.pl should know about .mailmap actually, currently it
> > > > > doesn't. I could send a patch.
> > > >
> > > > We have an explicit check in the CI to ensure that both the author and the
> > > > committer have a SoB line. It's not base on checkpatch.pl. Ricardo,
> > > > could you confirm this ?
> > >
> > > CI checks that there are at least 2 committers that agree with the
> > > code (SoB, Reviewed-by or Ack-by)
> > > https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/lib/test-trust.py?ref_type=heads
> > >
> > > We also have a separate check for SoB:
> > > https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/test-media-patchstyle.sh?ref_type=heads#L61
> >
> > This script appears to be also ignoring .mailmap.
> test-trust does not ignore mailmap:
> https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/lib/test-trust.py?ref_type=heads#L56

Ack, nice!

> 
> Do you see any scenario where the committer and the author are
> different users? "git commit" will set the same value for boths
> I am not against to modify the code if we find that usecase

Not apart from the From: e-mail address change due to .mailmap.

-- 
Kind regards,

Sakari Ailus

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

[Sakari Ailus]

On Thu, Sep 26, 2024 at 01:40:22PM +0300, Laurent Pinchart wrote:
> On Thu, Sep 26, 2024 at 10:35:34AM +0000, Sakari Ailus wrote:
> > Hi Laurent,
> > 
> > On Thu, Sep 26, 2024 at 01:24:48PM +0300, Laurent Pinchart wrote:
> > > On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > > > Em Thu, 26 Sep 2024 09:30:34 +0000
> > > > Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> > > > 
> > > > > > >>> Can you refresh my memory which processes need more work?  
> > > > > > >>
> > > > > > >> 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.
> > > > > > >>
> > > > > > >> From my personal notes, this will be the new process:
> > > > > > >>
> > > > > > >> - committers will merge patches at media-committers.git tree at fdo,
> > > > > > >>   provided that they'll follow the rules defined on a committers agreement
> > > > > > >>   and (partially?) enforced by media-ci checks;
> > > > > > >> - core committers follow the same rules, with a broader privilege of
> > > > > > >>   changing kernel API/ABI;
> > > > > > >> - committers will ensure that patchwork will reflect the review process of
> > > > > > >>   the patches;
> > > > > > >> - maintainers will double-check if everything is ok and, if ok, merge the
> > > > > > >>   changes at linuxtv.org. We intend to rename the tree there to "media.git",
> > > > > > >>   being the main tree to be used for development;
> > > > > > >> - pull requests will keep using the same process as currently. The only
> > > > > > >>   change is that the media-stage.git tree will be renamed to "media.git";
> > > > > > >> - maintainers will periodically send patches upstream.
> > > > > > >>
> > > > > > >> The media-commiters.git tree at fdo might be rebased if needed; the 
> > > > > > >> media.git tree at linuxtv.org is stable. A large effort will be taken to
> > > > > > >> avoid rebasing it.
> > > > > > >>
> > > > > > >> We may need some helper scripts and/or use pwclient to keep patchwork
> > > > > > >> updated after committers reviews.  
> > > > > > > 
> > > > > > > What will happen if we update the status of patches in patchwork when
> > > > > > > merging them to the fdo tree, and the tree is later rebased to drop
> > > > > > > commits ? Will the person rebasing handle updating patchwork to move the
> > > > > > > patches back from accepted to a different status ?  
> > > > > > 
> > > > > > That should be the responsibility of the person doing the rebase. I think
> > > > > > that's what is done today as well in the rare cases we rebase.  
> > > > > 
> > > > > Sounds reasonable. I'd also like to avoid rebases as much as possible.
> > > > > 
> > > > > Do we have a list of cases where a rebase would be needed? A license issue
> > > > > or a missing Sob line, perhaps?
> > > > 
> > > > No, and I don't think we can write a rule to cover such cases. The only rule
> > > > is that it is up to maintainers to decide to do a rebase or not, and this
> > > > will be done case by case.
> > > > 
> > > > With regards to the cases you mentioned, it is almost surely that license 
> > > > issues will call for a rebase. The same may apply up to some point for 
> > > > missing/refused SoBs from authors, co-developers and from the committers.
> > > > 
> > > > Yet, I would expect that a more common case is if someone touches the code
> > > > and another committer/developer/author nacks with such changes.
> > > > 
> > > > So, for instance, suppose you maintain driver A. Some other committer
> > > > may end merging a patch for driver A without your ack. Depending on the
> > > > patch that could be OK (trivial/doc changes, bugs with bug fixes that
> > > > are available for some time, etc).
> > > > 
> > > > Yet, even if the committer did an honest handling of the patch, you may 
> > > > still disagree or want some changes at the original patch. On such cases, 
> > > > the maintainers may decide to drop the changes and do a normal review
> > > > process. They may otherwise request a patch on the top of the applied
> > > > one to address the pointed issues.
> > > 
> > > Let's do a revert in that case, and keep rebases for cases where having
> > > content in the git history causes issues other than bisection problems.
> > 
> > I'd very much prefer this as well: revert or fix, if at all reasonable,
> > instead of rebasing should be a rule.
> > 
> > > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > > an accident, but that's not worth debating because CI will make sure
> > > this never happens.
> > 
> > Does it?
> >
> > checkpatch.pl checks should just be warnings. And that should probably
> > stay. Sob: and From: being different isn't necessarily that far-fetched as
> > having an address in .mailmap may change From: field but not Sob:,
> > resulting in a checkpatch.pl warning.
> > 
> > I wonder if checkpatch.pl should know about .mailmap actually, currently it
> > doesn't. I could send a patch.
> 
> We have an explicit check in the CI to ensure that both the author and the
> committer have a SoB line. It's not base on checkpatch.pl. Ricardo,
> could you confirm this ?

checkpatch.pl nevertheless produces a warning on this and I think it's not
what it should do.

> 
> > > > There is also worse case scenarios, like a committer violating the
> > > > committer's agreement.
> > > 
> > > I'm fine with rebases if someone gets rogue and merges malicious code,
> > > or commits with insults in the commit message. I don't foresee that
> > > happening regularly, if ever.
> > 
> > I'm more concerned of a malicious actor getting access to the committer's
> > credentials rather than the committer him-/herself going crazy. And if this
> > happens, changes are it won't be noticed immediately.
> 
> That's not much different than someone impersonating me or you when
> sending pull requests. Signing tags helps, but if someone steals
> credentials, it's also game over. With the new workflow the malicious
> changes will need to pass CI, so there may be more scrutiny :-)

There are two main differences from the current workflow that aggravate the
effects of this risk if it materialises:

- there will be more committers than core developers now and

- Hans and Mauro have paid additional attention to what's in the PRs. That
  won't be the case going forward, as there are no PRs to send.

> 
> > Reminding of
> > <URL:https://github.com/lfit/itpol/blob/master/linux-workstation-security.md>
> > in the instructions might not be a bad idea.
> 
> Agreed.
> 

-- 
Kind regards,

Sakari Ailus

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 10:35:34 +0000
Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:

> > > Yet, even if the committer did an honest handling of the patch, you may 
> > > still disagree or want some changes at the original patch. On such cases, 
> > > the maintainers may decide to drop the changes and do a normal review
> > > process. They may otherwise request a patch on the top of the applied
> > > one to address the pointed issues.  
> > 
> > Let's do a revert in that case, and keep rebases for cases where having
> > content in the git history causes issues other than bisection problems.  
> 
> I'd very much prefer this as well: revert or fix, if at all reasonable,
> instead of rebasing should be a rule.

As I answered already, the only rule is that such decision is up to the
subsystem's maintainers, as they'll need to handle the consequences of
upstreaming broken/reverted stuff.

> > I'd argue that even a missing SoB may not be a cause for rebase if it's
> > an accident, but that's not worth debating because CI will make sure
> > this never happens.  
> 
> Does it?
> 
> checkpatch.pl checks should just be warnings. And that should probably
> stay. Sob: and From: being different isn't necessarily that far-fetched as
> having an address in .mailmap may change From: field but not Sob:,
> resulting in a checkpatch.pl warning.
> 
> I wonder if checkpatch.pl should know about .mailmap actually, currently it
> doesn't. I could send a patch.

It does. Basically, if the media-ci does its work well, we shouldn't have
such cases in practice. 

That said, I guess the logic may require some changes, as there are some
complex rules with regards to patches developed by multiple authors.
Basically, patches shall follow an exact order of SoBs and tags to
indicate other authors for patches with multiple authors. Not sure if CI
or checkpatch enforces it currently.

> > > There is also worse case scenarios, like a committer violating the
> > > committer's agreement.  
> > 
> > I'm fine with rebases if someone gets rogue and merges malicious code,
> > or commits with insults in the commit message. I don't foresee that
> > happening regularly, if ever.  
> 
> I'm more concerned of a malicious actor getting access to the committer's
> credentials rather than the committer him-/herself going crazy. And if this
> happens, changes are it won't be noticed immediately.

This could happen as well. From subsystem's maintainer perspective,
they both will look the same when checking if a merge is ok.

> 
> Reminding of
> <URL:https://github.com/lfit/itpol/blob/master/linux-workstation-security.md>
> in the instructions might not be a bad idea.

Good point. We're writing a documentation about the new process. Once done,
we'll post at media ML for review. Please reply to it if we forget adding
it.

Thanks,
Mauro

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

[Mauro Carvalho Chehab]

Em Thu, 26 Sep 2024 13:24:48 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:

> On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 26 Sep 2024 09:30:34 +0000
> > Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> >   

> > Yet, even if the committer did an honest handling of the patch, you may 
> > still disagree or want some changes at the original patch. On such cases, 
> > the maintainers may decide to drop the changes and do a normal review
> > process. They may otherwise request a patch on the top of the applied
> > one to address the pointed issues.  
> 
> Let's do a revert in that case, and keep rebases for cases where having
> content in the git history causes issues other than bisection problems.

Rebasing or not is a subsystem maintainers decision. Reverting pollutes
git history upstream, and it should be done in cases were we want to 
preserve the history upstream. On cases where the preserving the history 
doesn't matter, a rebase is better.

There is also a bad side effect of doing:

- patch 1: some fixes with c/c stable + fixes tag
- patch 2: revert patch 1
- patch 3: apply patch 1 on a different way

Even with just 3 patches, this can get messy when backporting to fixes,
as we don't want all three patches backported. We want just patch 3.

There are also cases like:

- patch 1: some fixes with c/c stable + fixes tag
- patch 2: revert patch 1
- patch 3: a patch needed by patch 1 to not break compilation
- patch 4: re-apply patch 1

in this case, patch 3 (or a variant of it) may or may not needed
to be in fixes.

This becomes even more complex if there is a pile of patches with
some with c/c stable and some without. 

I saw already enough badly solved merge conflicts risen on different
trees because one change was reverted and then applied back with
about the same content. 

Thanks,
Mauro

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

[Laurent Pinchart]

On Thu, Sep 26, 2024 at 12:53:58PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 26 Sep 2024 13:24:48 +0300 Laurent Pinchart escreveu:
> 
> > On Thu, Sep 26, 2024 at 12:19:14PM +0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 26 Sep 2024 09:30:34 +0000 Sakari Ailus escreveu:
> > >   
> 
> > > Yet, even if the committer did an honest handling of the patch, you may 
> > > still disagree or want some changes at the original patch. On such cases, 
> > > the maintainers may decide to drop the changes and do a normal review
> > > process. They may otherwise request a patch on the top of the applied
> > > one to address the pointed issues.  
> > 
> > Let's do a revert in that case, and keep rebases for cases where having
> > content in the git history causes issues other than bisection problems.
> 
> Rebasing or not is a subsystem maintainers decision.

The job of a maintainer is to make their subsystem thrive. The power of
making decisions comes with the responsibility of cattering for the
needs of the community. In this case, I think the community wants to
avoid rebases as much as possible. Let's work together on avoiding them
by improving whatever processes need to be improved.

> Reverting pollutes
> git history upstream, and it should be done in cases were we want to 
> preserve the history upstream. On cases where the preserving the history 
> doesn't matter, a rebase is better.
> 
> There is also a bad side effect of doing:
> 
> - patch 1: some fixes with c/c stable + fixes tag
> - patch 2: revert patch 1
> - patch 3: apply patch 1 on a different way
> 
> Even with just 3 patches, this can get messy when backporting to fixes,
> as we don't want all three patches backported. We want just patch 3.
> 
> There are also cases like:
> 
> - patch 1: some fixes with c/c stable + fixes tag
> - patch 2: revert patch 1
> - patch 3: a patch needed by patch 1 to not break compilation
> - patch 4: re-apply patch 1
> 
> in this case, patch 3 (or a variant of it) may or may not needed
> to be in fixes.
> 
> This becomes even more complex if there is a pile of patches with
> some with c/c stable and some without. 

We're talking about rare cases here. Let's focus the process on avoiding
rebases. If you think a rebase is needed at some point, let's discuss it
and find consensus.

> I saw already enough badly solved merge conflicts risen on different
> trees because one change was reverted and then applied back with
> about the same content. 

-- 
Regards,

Laurent Pinchart