On 06/09/2024 10:11, 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. 6. Since now the committer has to collect the necessary A-by/R-by tags, how do we handle that? Today it is implicit by posting a PR: the patches will be signed off by me or Mauro when we process the PR. Now you need to collect the tags by asking others. I'd like to formalize this in some way. Regards, Hans > > Thanks, > Mauro
