| Message ID | cover.1733131405.git.mchehab+huawei@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Document the new media-committer's model | expand |
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. Regards, Hans > > --- > > v3: > - added patch 3; > - addressed nits pointed by Ricardo during his review; > - did minor editorial changes to improve Sphinx html output. > > v2: I tried to address most of the suggestions where there was an agreement > from Laurent's review and further comments. As there were several changes, > on separate threads, I could have missed something. > > > Mauro Carvalho Chehab (3): > docs: media: update maintainer-entry-profile for multi-committers > docs: media: document media multi-committers rules and process > docs: media: profile: make it clearer about maintainership duties > > Documentation/driver-api/media/index.rst | 1 + > .../media/maintainer-entry-profile.rst | 219 +++++++++++--- > .../driver-api/media/media-committer.rst | 278 ++++++++++++++++++ > .../process/maintainer-pgp-guide.rst | 2 + > MAINTAINERS | 1 + > 5 files changed, 456 insertions(+), 45 deletions(-) > create mode 100644 Documentation/driver-api/media/media-committer.rst >
Em Mon, 2 Dec 2024 16:03:45 +0100 Hans Verkuil <hverkuil@xs4all.nl> 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. Thanks, Mauro
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 ?
Em Tue, 3 Dec 2024 13:22:09 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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
Em Tue, 3 Dec 2024 14:07:12 +0100 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> 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; - 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