Hey Mauro,
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.
Interesting I thought that is how it should be? I mean if I send a PR,
the one taking the PR must decide whether he wants to pull it, so the
decision whether the set is accepted should be on the one pulling the
changes and not on the one pushing them. Right?
So another script to solve this gap is needed, doing updates on all
patches that were picked by the first script. Something like:
Shouldn't the update happen after the MR has been created instead,
because only after running the CI we know whether the tests fail or
pass? From what you say above it sounds like the first script merely
prepares a topic branch to be tested.
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.
Just my personal thought: This sounds a bit extreme to me, I mean we are
currently in the first test run as preparation for the Media-summit
where we actually want to discuss policies and further requirements.
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.
I thought that we came to a consensus that only warnings are acceptable?
If we accept errors in the staging but not in media master, does that
mean that we ought to send patches to the media staging tree then?
I'd vote for only allowing patches without errors into the staging tree
and in the worst case add a list with acceptable errors.
4. We need to have some sort of "honour code": if undesired behavior
is noticed, maintainers may temporarily (or permanently) revoke
committer rights.
That sounds like something to discuss on the media summit, revoking
commit rights shouldn't be hard as you just have to remove push rights
for that GitLab tree.
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
Regards,
Sebastian Fricke
Consultant Software Engineer
Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales no 5513718.
