Em Fri, 7 Feb 2025 12:54:52 +0100 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > On 09/12/2024 09:15, Mauro Carvalho Chehab wrote: > > Em Tue, 3 Dec 2024 14:07:12 +0100 > > Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> escreveu: > > > >> > >> The idea is to gradually open media-committers to more people, as each > >> phase succeeds, addressing infra, procedures, etc. > >> > >> My rough idea is to do: > >> > >> - Phase 0.99: beta testers; > >> - Phase 1 is to invite people that regularly submit PRs; > >> - Phase 2 is to invite other active maintainers; > >> - Phase 3 (or 2?, TBD) to open for non-maintainers. > >> > >> We shouldn't rush it, as there are a lot to be done before opening it > >> broadly. So, I would say that: > >> - phase 0.99 would start in -rc2 (if things go well during this week); > >> - phase 1 may still happen on this merge window, but as there will be > >> only a few weeks between -rc2 and -rc6, and people usually get > >> holidays in Dec/Jan, it is more likely that it will start for > >> 6.14-rc1, again if we didn't notice big issues on phase 0.99. > >> > >> We should wait at least for a couple of releases on phase 1, > >> again to cleanup process and fine-tune infra. If things go well, > >> we can move to phase 2. > > > > After some discussions with Hans, we decided to postpone the > > beta testers phase to the next kernel cycle. There are a couple of > > reasons for that: > > > > - This should give us more time to come up with a final version of > > the media-committers documentation and agreement; > > Where are we with this? I haven't seen any updates since this post. > > Personally, I think the CI is ready for more committers, so it would be > nice if we can get some experience with that. IMO, there are still some pending issues. We still need to reach a consensus about what media maintainers will do. I have to confess that discussing last time was painful due to some arguments going too personal to my taste. Anyway, discussing it during the end of the year was not a good idea as people (including myself) were busy completing their yearly tasks. Also, people were taking vacations. At the end of the last year, I finally rewrote the scripts I use on my workflow. I'd like to test them during this cycle and see how it behaves. While doing that, I noticed that we really need to have something like margebot to help our workflow. From my side, I'd like to have one separate MR per each separate patch series, as this makes easier to document the main changes that the media subsystem is merging. I hope to test them more during this Kernel cycle to be sure that everything is in place. While using my scripts, I ended having 4 or 5 pending MRs at media-committers. As we want a clean history without being bloated with merges from temp trees/branches, we need to have some automation to help basing the commits on the top of the branches. The idea is to have margebot enabled there, meaning that committers may delegate patches to margebot and let it automatically place patches on the top of the branches. However, margebot has currently a problem: it mangles with committer's metadata. Ricardo have been working upstream and they are reaching a consensus about how to support preserving committer data with margebot. IMO, we need that before having more committers. Finally, we need to have useful data to prepare changelog summary upstream. In the past, as we were reviewing everything, it was easier to identify the core changes (besides fixes/cleanups). With a multicommitter's model, we need to rely on what committers will be providing us. The idea I've been playing with, and that's what I ended implementing on last submission(*), is to generate it based on what each merge metadata contains. (*) Yet, the level of information there were very inconsistent. We need to do better during this cycle. > Regards, > > Hans > > > > > - This would also work better with regards to end of year's vacations, > > as they'll be affecting at least 2/3 -rc versions. Plus, we all have > > things to finish before such vacations. So, better to start fresh next > > year; > > > > - Media CI still had issues with a patch series I submitted, as it picked > > the wrong baseline, causing CI to not test two patches that were > > applied on the top of media-committers/next branch. This was fixed > > by Ricardo, but it means that we may still need to polish CI before > > granting more people righs there. > > > > With that, if we want to start the media committers for 6.14, we should > > aim to close review this document by -rc6, or, at most, -rc7, getting > > the patches merged during the next merge window. > > > > Regard > > > > Thanks, > > Mauro > > > Thanks, Mauro
