On Fri, Sep 06, 2024 at 10:11:48AM +0200, Mauro Carvalho Chehab wrote: > 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. I think this last point should still be discussed in Vienna. I want to design a clear workflow that covers -next and -fixes. I'm fine if we decide to then implement part of the workflow only as an initial step, if there are good enough reasons to do so. -- Regards, Laurent Pinchart
