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.

---

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

-- 
2.47.1

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 ?

-- 
Regards,

Laurent Pinchart

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

On 09/12/2024 09:15, Mauro Carvalho Chehab wrote:
> 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;

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.

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
>

Em Fri, 7 Feb 2025 12:54:52 +0100
Hans Verkuil <hverkuil@xs4all.nl> 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@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;  
> 
> 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