Em Thu, 5 Sep 2024 09:16:27 +0200 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > Hi all, > > Here is my fifth (and likely final) stab at an agenda for the media summit. As always, > it is subject to change and all times 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@xxxxxxxxxxxxxxx> (Intel) > Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx> (Collabora) > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> (Huawei, Media Kernel Maintainer) > Steve Cho <stevecho@xxxxxxxxxxxx> (Google) > Sebastian Fricke <sebastian.fricke@xxxxxxxxxxxxx> (Collabora) > Martin Hecht <martin.hecht@xxxxxxxx> (Avnet) > Tommaso Merciai <tomm.merciai@xxxxxxxxx> (Avnet) > Jacopo Mondi <jacopo.mondi@xxxxxxxxxxxxxxxx> (Ideas On Board) > Benjamin Mugnier <benjamin.mugnier@xxxxxxxxxxx> (ST Electronics) > Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> (Ideas On Board) > Ricardo Ribalda <ribalda@xxxxxxxxxxxx> (Google) > Michael Tretter <m.tretter@xxxxxxxxxxxxxx> (Pengutronix) > Suresh Vankadara <svankada@xxxxxxxxxxxxxxxx> (Qualcomm) > Hans Verkuil <hverkuil-cisco@xxxxxxxxx> (Cisco Systems Norway) > Alain Volmat <alain.volmat@xxxxxxxxxxx> (ST Electronics) > Sean Young <sean@xxxxxxxx> > Jerry W Hu <jerry.w.hu@xxxxxxxxx> (Intel) > > Remote Attendees (using MS Teams): > > Rishikesh Donadkar <r-donadkar@xxxxxx> (TI) > Tomasz Figa <tfiga@xxxxxxxxxxxx> (Google) > Hidenori Kobayashi <hidenorik@xxxxxxxxxxxx> (Google) > Devarsh Thakkar <devarsht@xxxxxx> (TI) > > Note: information on how to connect remotely will come later. > > If any information above is incorrect, or if I missed someone, then please let me know. > > We are currently 17 confirmed in-person participants, so we're pretty much 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 As part of such discussion, IMO some topics that should be covered: 1. All committers shall use a common procedure for all merges. This is easy said than done. So, IMO, it is needed some common scripts to be used by all committers. On my tests when merging two PRs there, those seems to be the minimal set of scripts that are needed: a) script to create a new topic branch at linux-media/users/<user> The input parameter is the message-ID, e. g. something like: create_media_staging_topic <topic_name> <message_id> (eventually with an extra parameter with the name of the tree) It shall use patchwork REST interface to get the patches - or at least to check if all patches are there (and then use b4). such script needs to work with a single patch, a patch series and a pull request. the message ID of every patch, including the PR should be stored at the MR, as this will be needed to later update patchwork. b) once gitlab CI runs, there are two possible outcomes: patches may pass or not. If they pass, a MR will be created and eventually be merged. Either merged or not (because something failed or the patches require more work), the patchwork status of the patch require changes to reflect what happened. IMO, another script is needed to update the patch/patch series/PR on patchwork on a consistent way. This is actually a *big* gap we have here. I have a script that manually check patchwork status and the gap is huge. currently, there are 73 patches that seems to be merged, but patchwork was not updated. From what I noticed, some PR submitters almost never update patchwork after the merges. So another script to solve this gap is needed, doing updates on all patches that were picked by the first script. Something like: update_patchwork_from_topic <topic_name> <new_status> This would likely need to use some logic to pick the message IDs of the patch inside the MR. Such script could also check for previous versions of the patch and for identical patches (it is somewhat common to receive identical patches with trivial fixes from different developers). Someone needs to work on such script, as otherwise the multi committers model may fail, and we risk needing to return back to the current model. 2. The mailbomb script that notifies when a patch is merged at media-stage we're using right now doesn't work with well with multiple committers. Right now, the tree at linuxtv runs it, but it might end sending patches to the author and to linuxtv-commits ML that reached upstream from other trees. It has some logic to prevent that, but it is not bulletproof. A replacement script is needed. Perhaps this can be executed together with the patchwork script (1B) at the committer's machine. 3. Staging require different rules, as smatch/spatch/sparse/checkpatch warnings and errors can be acceptable. 4. We need to have some sort of "honour code": if undesired behavior is noticed, maintainers may temporarily (or permanently) revoke committer rights. Hopefully, this will never happen, but, if it happens, a rebase of media-staging tree may be needed. 5. The procedure for fixes wil remain the same. We'll have already enough things to make it work. Let's not add fixes complexity just yet. Depending on how well the new multi-committers experimental model works, we may think using it for fixes as well. Thanks, Mauro
