On Sat, Sep 07, 2024 at 10:02:07AM +0200, Hans Verkuil wrote: > 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. Tags should be sent to the list as part of the review process, right ? In that case they can be collected from there. b4 does so automatically. We also sometimes give Rb tags in IRC as a shortcut, they can be added manually, or we can decide that tags always have to be posted to the list. I don't really see the issue, am I missing something ? -- Regards, Laurent Pinchart
