Em Tue, 3 Dec 2024 13:22:09 +0200 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> escreveu: > On Tue, Dec 03, 2024 at 08:19:58AM +0100, Mauro Carvalho Chehab wrote: > > Em Mon, 2 Dec 2024 16:03:45 +0100 Hans Verkuil escreveu: > > > On 02/12/2024 10:26, Mauro Carvalho Chehab wrote: > > > > The media subsystem used to have a multi-commiter's model in the > > > > past, but things didn't go well on that time, and we had to move to > > > > a centralized model. > > > > > > > > As the community has evolved, and as there are now new policies in > > > > place like CoC, let's experiment with a multi-committers again. > > > > > > > > The model we're using was inspired by the DRM multi-committers > > > > model. Yet, media subsystem is different on several aspects, so the > > > > model is not exactly the same. > > > > > > > > The implementation will be in phases. For this phase, the goal is that > > > > all committers will be people listed at MAINTAINERS. > > > > > > > > On this series,: > > > > > > > > patch 1: updates the media maintainer's entry profile and adds the > > > > workflow that will be used with the new model. While here, it also > > > > adds a missing "P:" tag at the MAINTAINERS file, pointing to it; > > > > > > > > patch 2: adds a new document focused at the new maintainers > > > > process. Its target is for developers that will be granted with > > > > commit rights at the new media-maintainers.git tree. It also > > > > contains a reference tag addition to kernel.org PGP chain > > > > at process/maintainer-pgp-guide.rst. > > > > > > > > patch 3: make documents cleared about maintainership duties. > > > > > > At least from my perspective, v3 is close to being ready and I hope > > > that v4 will be good enough to be merged. > > > > > > That said, what is missing in all this is that there is nothing here > > > that explains why you would want to become a media committer. It is all > > > very dry stuff, lots of 'shall's, and 'rights' and 'trust' and obligations, > > > but nothing about the satisfaction you get when you get the responsibility > > > of a part of the kernel and being able to guide the development of that > > > area. > > > > > > It's good enough to get the multi-committer process off the ground, but > > > it definitely needs more work to make it more inviting to become a media > > > committer. Because right now it is as dry as dust. > > > > Agreed. We focused on getting a document describing what it is expected > > by committers, in order to start with the model. My view is that it works > > fine for such purpose. I also feel that we're close to the final document. > > > > I'm sending today a v4 addressing the comments since last review. > > > > Once we get people that are already interested and ready to be on board, > > and we know that the model and infrastructure works properly, we may implement > > a phase 2 focusing on allowing more committers. For such purpose, we need to > > document the benefits/satisfaction of becoming a new committer. Depending how > > it goes, either on phase 2 or on phase 3, we can change the model from > > invitation-only to volunteer-requests. > > What's phase 3 ? 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. Thanks, Mauro
