Tianocore community page on who we are - please review

Tianocore community page on who we are - please review

[Soumya Guptha]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Dear Community members,



I have drafted a document "who we are", explaining Tianocore community structure, members of the community, their role and the current development process. I have drafted this document with the help of the Tianocore Stewards.

We view this as a living document, as our development processes evolve, I will keep this document updated.



Please review the draft version of the document (link below) and provide your feedback. Please send it to me, no need to reply all.

I appreciate your input by Friday, Oct 2. After this, I plan on make it live on our TianoCore wiki site.



Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are

Thanks,
Soumya

Soumya Guptha
TianoCore Community Manager





[-- Attachment #2: Type: text/html, Size: 3756 bytes --]

Re: Tianocore community page on who we are - please review

[Yao, Jiewen]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

Thanks Soumya. I think this is a good start.

Recently we are discussing the maintainer's work in EDKII mailing list, with title "more development process failure".

I feel the process mentioned in https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process is not clear enough to follow, especially for the maintainer who is not full time working on EDKII.

I wish we can have this opportunity to revisit the "Follow the EDK II development process<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process>" and make "the process" simpler and clearer.

Then all maintainers can sign to follow one rule. The rule we define and the rule we agree with.

Thank you
Yao Jiewen


From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Soumya Guptha
Sent: Saturday, September 26, 2020 6:35 AM
To: announce@edk2.groups.io; devel@edk2.groups.io
Subject: [edk2-devel] Tianocore community page on who we are - please review


Dear Community members,



I have drafted a document "who we are", explaining Tianocore community structure, members of the community, their role and the current development process. I have drafted this document with the help of the Tianocore Stewards.

We view this as a living document, as our development processes evolve, I will keep this document updated.



Please review the draft version of the document (link below) and provide your feedback. Please send it to me, no need to reply all.

I appreciate your input by Friday, Oct 2. After this, I plan on make it live on our TianoCore wiki site.



Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are

Thanks,
Soumya

Soumya Guptha
TianoCore Community Manager





[-- Attachment #2: Type: text/html, Size: 6254 bytes --]

Re: [edk2-devel] Tianocore community page on who we are - please review

[Yao, Jiewen]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

Some other thought is about maintainer's role definition:

The role of a maintainer is to:

  1.  Maintainer assignments to packages and source file name patterns are provided in the "Maintainers.txt"<https://github.com/tianocore/edk2/blob/master/Maintainers.txt> file.
  2.  Subscribe to the "edk2-bugs" mailing list https://edk2.groups.io/g/bugs, which propagates TianoCore Bugzilla https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new issues reported for their assigned packages. Participate in triaging and analyzing bugs filed for their assigned packages.
  3.  Responsible for reviewing patches and answering questions from contributors, on the edk2-devel mailing list https://edk2.groups.io/g/devel/.
  4.  Responsible for coordinating patch review with co-maintainers and reviewers of the same package.
  5.  Has push / merge access to the merge branch.
  6.  Responsible for merging approved patches into the master branch.
  7.  Follow the EDK II development process<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process>.

IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
Logically, the can be two separated roles and be done by two different persons.
A people who has strong technical expertise might NOT be the best person to do the integration, and vice versa. I hope we can let right person do right thing in right way.
For example, to avoid mistake during check in, 5~7 can be done by a role named "integrator".

My dream is that check-in process is just one click button. But it seems we are still far from it...

My two cents.

Thank you
Yao Jiewen

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao, Jiewen
Sent: Saturday, September 26, 2020 1:09 PM
To: devel@edk2.groups.io; Guptha, Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
Subject: Re: [edk2-devel] Tianocore community page on who we are - please review

Thanks Soumya. I think this is a good start.

Recently we are discussing the maintainer's work in EDKII mailing list, with title "more development process failure".

I feel the process mentioned in https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process is not clear enough to follow, especially for the maintainer who is not full time working on EDKII.

I wish we can have this opportunity to revisit the "Follow the EDK II development process<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process>" and make "the process" simpler and clearer.

Then all maintainers can sign to follow one rule. The rule we define and the rule we agree with.

Thank you
Yao Jiewen


From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Soumya Guptha
Sent: Saturday, September 26, 2020 6:35 AM
To: announce@edk2.groups.io<mailto:announce@edk2.groups.io>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] Tianocore community page on who we are - please review


Dear Community members,



I have drafted a document "who we are", explaining Tianocore community structure, members of the community, their role and the current development process. I have drafted this document with the help of the Tianocore Stewards.

We view this as a living document, as our development processes evolve, I will keep this document updated.



Please review the draft version of the document (link below) and provide your feedback. Please send it to me, no need to reply all.

I appreciate your input by Friday, Oct 2. After this, I plan on make it live on our TianoCore wiki site.



Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are

Thanks,
Soumya

Soumya Guptha
TianoCore Community Manager




[-- Attachment #2: Type: text/html, Size: 13668 bytes --]

回复: [edk2-devel] Tianocore community page on who we are - please review

[gaoliming]

[-- Attachment #1: Type: text/plain, Size: 6319 bytes --]

Jiewen:

 Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
Maintainer takes role 1~7. If the people know edk2 process well, they mostly
know edk2 one or more packages (modules). So, they can take Maintainer role.
If the people only focus on the technical review, they can take reviewer
role. I would suggest there is at lease one Maintainer for each package.
There are more reviewers for each package.

 

Soumya:

 Here are my comments. 

  Guidelines for a Maintainer. Never let a pending request get older than a
calendar week. This requirement is too strict to the maintainer or reviewer.
The maintainer or reviewer should try to give the response in one week. But,
they may not fully review one patch set in one week, es for the feature or
the complex change. 

Role of a Contributor/developer. We need to highlight the role &
responsibility for the incompatible change. If the contributor proposes the
incompatible change, he needs to coordinate with the impacted platform
maintainer and make the agreement who will follow up to update the impacted
platforms before he requests to merge his patch set. The impacted platforms
include all ones in Edk2 and Edk2Platforms. 

 

Last, this page also needs to include release maintainer Definition and
Role. The release maintainer is to create the quarterly stable tag. He takes
the role to collect the feature planning for each stable tag, schedule the
release date, and create the stable tag with the release notes on tag page.
He will also send the announcement of soft feature freeze, hard feature
freeze and the stable tag completement to edk2 community. 

 

Thanks

Liming

发件人: bounce+27952+65655+4905953+8761045@groups.io
<bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
发送时间: 2020年9月26日 13:33
收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
主题: Re: [edk2-devel] Tianocore community page on who we are - please
review

 

Some other thought is about maintainer’s role definition:

 

The role of a maintainer is to:

1.	Maintainer assignments to packages and source file name patterns are
provided in the "
<https://github.com/tianocore/edk2/blob/master/Maintainers.txt> Maintainers.
txt" file.
2.	Subscribe to the "edk2-bugs" mailing list
<https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new
issues reported for their assigned packages. Participate in triaging and
analyzing bugs filed for their assigned packages.
3.	Responsible for reviewing patches and answering questions from
contributors, on the edk2-devel mailing list
<https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
4.	Responsible for coordinating patch review with co-maintainers and
reviewers of the same package.
5.	Has push / merge access to the merge branch.
6.	Responsible for merging approved patches into the master branch.
7.	Follow the EDK II development
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
ocess> process.

 

IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.

Logically, the can be two separated roles and be done by two different
persons.

A people who has strong technical expertise might NOT be the best person to
do the integration, and vice versa. I hope we can let right person do right
thing in right way.

For example, to avoid mistake during check in, 5~7 can be done by a role
named “integrator”.

 

My dream is that check-in process is just one click button. But it seems we
are still far from it…

 

My two cents.

 

Thank you

Yao Jiewen

 

From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Yao,
Jiewen
Sent: Saturday, September 26, 2020 1:09 PM
To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha, Soumya K
<soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
announce@edk2.groups.io <mailto:announce@edk2.groups.io> 
Subject: Re: [edk2-devel] Tianocore community page on who we are - please
review

 

Thanks Soumya. I think this is a good start.

 

Recently we are discussing the maintainer’s work in EDKII mailing list,
with title “more development process failure”.

 

I feel the process mentioned in
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pro
cess is not clear enough to follow, especially for the maintainer who is not
full time working on EDKII.

 

I wish we can have this opportunity to revisit the “Follow the EDK II
development
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
ocess> process” and make “the process” simpler and clearer.

 

Then all maintainers can sign to follow one rule. The rule we define and the
rule we agree with.

 

Thank you

Yao Jiewen

 

 

From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
<devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Soumya
Guptha
Sent: Saturday, September 26, 2020 6:35 AM
To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
devel@edk2.groups.io <mailto:devel@edk2.groups.io> 
Subject: [edk2-devel] Tianocore community page on who we are - please review

 

Dear Community members, 

 

I have drafted a document “who we are”, explaining Tianocore community
structure, members of the community, their role and the current development
process. I have drafted this document with the help of the Tianocore
Stewards. 

We view this as a living document, as our development processes evolve, I
will keep this document updated. 

 

Please review the draft version of the document (link below) and provide
your feedback. Please send it to me, no need to reply all.

I appreciate your input by Friday, Oct 2. After this, I plan on make it live
on our TianoCore wiki site. 

 

Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are

 

Thanks,

Soumya

 

Soumya Guptha
TianoCore Community Manager

 




[-- Attachment #2: Type: text/html, Size: 21893 bytes --]

Re: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

[Yao, Jiewen]

Thanks Liming.

It seems I have some misunderstanding here.

According to current process, I feel that only maintainer has right to *approve* the patch.
The reviewer cannot approve the patch. 
Do you mean the reviewer can also approve the patch?

According to https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am confused here ... So please do correct me if I am wrong.)
=================
Role of a Reviewer
Reviewers help maintainers review code, but don't have push access.

A designated Package Reviewer:

shall be reasonably familiar with the Package (or some modules thereof)

will be copied on the patch discussions,

and/or provides testing or regression testing for the Package (or some modules thereof), in certain platforms and environments.
================

Thank you
Yao Jiewen


> -----Original Message-----
> From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of
> gaoliming
> Sent: Sunday, September 27, 2020 10:33 AM
> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)' <leif@nuviainc.com>;
> Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
> <afish@apple.com>
> Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community page on
> who we are - please review
> 
> Jiewen:
> 
>  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> Maintainer takes role 1~7. If the people know edk2 process well, they mostly
> know edk2 one or more packages (modules). So, they can take Maintainer role.
> If the people only focus on the technical review, they can take reviewer
> role. I would suggest there is at lease one Maintainer for each package.
> There are more reviewers for each package.
> 
> 
> 
> Soumya:
> 
>  Here are my comments.
> 
>   Guidelines for a Maintainer. Never let a pending request get older than a
> calendar week. This requirement is too strict to the maintainer or reviewer.
> The maintainer or reviewer should try to give the response in one week. But,
> they may not fully review one patch set in one week, es for the feature or
> the complex change.
> 
> Role of a Contributor/developer. We need to highlight the role &
> responsibility for the incompatible change. If the contributor proposes the
> incompatible change, he needs to coordinate with the impacted platform
> maintainer and make the agreement who will follow up to update the impacted
> platforms before he requests to merge his patch set. The impacted platforms
> include all ones in Edk2 and Edk2Platforms.
> 
> 
> 
> Last, this page also needs to include release maintainer Definition and
> Role. The release maintainer is to create the quarterly stable tag. He takes
> the role to collect the feature planning for each stable tag, schedule the
> release date, and create the stable tag with the release notes on tag page.
> He will also send the announcement of soft feature freeze, hard feature
> freeze and the stable tag completement to edk2 community.
> 
> 
> 
> Thanks
> 
> Liming
> 
> 发件人: bounce+27952+65655+4905953+8761045@groups.io
> <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
> 发送时间: 2020年9月26日 13:33
> 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> 主题: Re: [edk2-devel] Tianocore community page on who we are - please
> review
> 
> 
> 
> Some other thought is about maintainer’s role definition:
> 
> 
> 
> The role of a maintainer is to:
> 
> 1.	Maintainer assignments to packages and source file name patterns are
> provided in the "
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt> Maintainers.
> txt" file.
> 2.	Subscribe to the "edk2-bugs" mailing list
> <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new
> issues reported for their assigned packages. Participate in triaging and
> analyzing bugs filed for their assigned packages.
> 3.	Responsible for reviewing patches and answering questions from
> contributors, on the edk2-devel mailing list
> <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> 4.	Responsible for coordinating patch review with co-maintainers and
> reviewers of the same package.
> 5.	Has push / merge access to the merge branch.
> 6.	Responsible for merging approved patches into the master branch.
> 7.	Follow the EDK II development
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
> ocess> process.
> 
> 
> 
> IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
> 
> Logically, the can be two separated roles and be done by two different
> persons.
> 
> A people who has strong technical expertise might NOT be the best person to
> do the integration, and vice versa. I hope we can let right person do right
> thing in right way.
> 
> For example, to avoid mistake during check in, 5~7 can be done by a role
> named “integrator”.
> 
> 
> 
> My dream is that check-in process is just one click button. But it seems we
> are still far from it…
> 
> 
> 
> My two cents.
> 
> 
> 
> Thank you
> 
> Yao Jiewen
> 
> 
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Yao,
> Jiewen
> Sent: Saturday, September 26, 2020 1:09 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha, Soumya K
> <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
> announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> Subject: Re: [edk2-devel] Tianocore community page on who we are - please
> review
> 
> 
> 
> Thanks Soumya. I think this is a good start.
> 
> 
> 
> Recently we are discussing the maintainer’s work in EDKII mailing list,
> with title “more development process failure”.
> 
> 
> 
> I feel the process mentioned in
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pro
> cess is not clear enough to follow, especially for the maintainer who is not
> full time working on EDKII.
> 
> 
> 
> I wish we can have this opportunity to revisit the “Follow the EDK II
> development
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
> ocess> process” and make “the process” simpler and clearer.
> 
> 
> 
> Then all maintainers can sign to follow one rule. The rule we define and the
> rule we agree with.
> 
> 
> 
> Thank you
> 
> Yao Jiewen
> 
> 
> 
> 
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Soumya
> Guptha
> Sent: Saturday, September 26, 2020 6:35 AM
> To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Subject: [edk2-devel] Tianocore community page on who we are - please review
> 
> 
> 
> Dear Community members,
> 
> 
> 
> I have drafted a document “who we are”, explaining Tianocore community
> structure, members of the community, their role and the current development
> process. I have drafted this document with the help of the Tianocore
> Stewards.
> 
> We view this as a living document, as our development processes evolve, I
> will keep this document updated.
> 
> 
> 
> Please review the draft version of the document (link below) and provide
> your feedback. Please send it to me, no need to reply all.
> 
> I appreciate your input by Friday, Oct 2. After this, I plan on make it live
> on our TianoCore wiki site.
> 
> 
> 
> Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> 
> 
> 
> Thanks,
> 
> Soumya
> 
> 
> 
> Soumya Guptha
> TianoCore Community Manager
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

[Leif Lindholm]

Hi Jiewen,

On Sun, Sep 27, 2020 at 03:25:24 +0000, Yao, Jiewen wrote:
> Thanks Liming.
> 
> It seems I have some misunderstanding here.
> 
> According to current process, I feel that only maintainer has right to *approve* the patch.
> The reviewer cannot approve the patch. 
> Do you mean the reviewer can also approve the patch?

My view is that a reviewer has a right to "approve" a patch, but they
do not have access to actually push the patch. A maintainer is needed
for that. In instances where a designated maintainer is unavaliable to
do so, another maintainer would be permitted to push the patch.

In instances where the designated maintainer disagrees with the
reviewer, the patch should not be pushed. However, the same should be
true for a patch where two designated maintainers or two designated
reviewers disagree.

Best Regards,

Leif

> According to https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am confused here ... So please do correct me if I am wrong.)
> =================
> Role of a Reviewer
> Reviewers help maintainers review code, but don't have push access.
> 
> A designated Package Reviewer:
> 
> shall be reasonably familiar with the Package (or some modules thereof)
> 
> will be copied on the patch discussions,
> 
> and/or provides testing or regression testing for the Package (or some modules thereof), in certain platforms and environments.
> ================
> 
> Thank you
> Yao Jiewen
> 
> 
> > -----Original Message-----
> > From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of
> > gaoliming
> > Sent: Sunday, September 27, 2020 10:33 AM
> > To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)' <leif@nuviainc.com>;
> > Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
> > <afish@apple.com>
> > Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community page on
> > who we are - please review
> > 
> > Jiewen:
> > 
> >  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> > Maintainer takes role 1~7. If the people know edk2 process well, they mostly
> > know edk2 one or more packages (modules). So, they can take Maintainer role.
> > If the people only focus on the technical review, they can take reviewer
> > role. I would suggest there is at lease one Maintainer for each package.
> > There are more reviewers for each package.
> > 
> > 
> > 
> > Soumya:
> > 
> >  Here are my comments.
> > 
> >   Guidelines for a Maintainer. Never let a pending request get older than a
> > calendar week. This requirement is too strict to the maintainer or reviewer.
> > The maintainer or reviewer should try to give the response in one week. But,
> > they may not fully review one patch set in one week, es for the feature or
> > the complex change.
> > 
> > Role of a Contributor/developer. We need to highlight the role &
> > responsibility for the incompatible change. If the contributor proposes the
> > incompatible change, he needs to coordinate with the impacted platform
> > maintainer and make the agreement who will follow up to update the impacted
> > platforms before he requests to merge his patch set. The impacted platforms
> > include all ones in Edk2 and Edk2Platforms.
> > 
> > 
> > 
> > Last, this page also needs to include release maintainer Definition and
> > Role. The release maintainer is to create the quarterly stable tag. He takes
> > the role to collect the feature planning for each stable tag, schedule the
> > release date, and create the stable tag with the release notes on tag page.
> > He will also send the announcement of soft feature freeze, hard feature
> > freeze and the stable tag completement to edk2 community.
> > 
> > 
> > 
> > Thanks
> > 
> > Liming
> > 
> > 发件人: bounce+27952+65655+4905953+8761045@groups.io
> > <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
> > 发送时间: 2020年9月26日 13:33
> > 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > 主题: Re: [edk2-devel] Tianocore community page on who we are - please
> > review
> > 
> > 
> > 
> > Some other thought is about maintainer’s role definition:
> > 
> > 
> > 
> > The role of a maintainer is to:
> > 
> > 1.	Maintainer assignments to packages and source file name patterns are
> > provided in the "
> > <https://github.com/tianocore/edk2/blob/master/Maintainers.txt> Maintainers.
> > txt" file.
> > 2.	Subscribe to the "edk2-bugs" mailing list
> > <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> > propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> > https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new
> > issues reported for their assigned packages. Participate in triaging and
> > analyzing bugs filed for their assigned packages.
> > 3.	Responsible for reviewing patches and answering questions from
> > contributors, on the edk2-devel mailing list
> > <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> > 4.	Responsible for coordinating patch review with co-maintainers and
> > reviewers of the same package.
> > 5.	Has push / merge access to the merge branch.
> > 6.	Responsible for merging approved patches into the master branch.
> > 7.	Follow the EDK II development
> > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
> > ocess> process.
> > 
> > 
> > 
> > IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
> > 
> > Logically, the can be two separated roles and be done by two different
> > persons.
> > 
> > A people who has strong technical expertise might NOT be the best person to
> > do the integration, and vice versa. I hope we can let right person do right
> > thing in right way.
> > 
> > For example, to avoid mistake during check in, 5~7 can be done by a role
> > named “integrator”.
> > 
> > 
> > 
> > My dream is that check-in process is just one click button. But it seems we
> > are still far from it…
> > 
> > 
> > 
> > My two cents.
> > 
> > 
> > 
> > Thank you
> > 
> > Yao Jiewen
> > 
> > 
> > 
> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Yao,
> > Jiewen
> > Sent: Saturday, September 26, 2020 1:09 PM
> > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha, Soumya K
> > <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
> > announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> > Subject: Re: [edk2-devel] Tianocore community page on who we are - please
> > review
> > 
> > 
> > 
> > Thanks Soumya. I think this is a good start.
> > 
> > 
> > 
> > Recently we are discussing the maintainer’s work in EDKII mailing list,
> > with title “more development process failure”.
> > 
> > 
> > 
> > I feel the process mentioned in
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pro
> > cess is not clear enough to follow, especially for the maintainer who is not
> > full time working on EDKII.
> > 
> > 
> > 
> > I wish we can have this opportunity to revisit the “Follow the EDK II
> > development
> > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
> > ocess> process” and make “the process” simpler and clearer.
> > 
> > 
> > 
> > Then all maintainers can sign to follow one rule. The rule we define and the
> > rule we agree with.
> > 
> > 
> > 
> > Thank you
> > 
> > Yao Jiewen
> > 
> > 
> > 
> > 
> > 
> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Soumya
> > Guptha
> > Sent: Saturday, September 26, 2020 6:35 AM
> > To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> > devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > Subject: [edk2-devel] Tianocore community page on who we are - please review
> > 
> > 
> > 
> > Dear Community members,
> > 
> > 
> > 
> > I have drafted a document “who we are”, explaining Tianocore community
> > structure, members of the community, their role and the current development
> > process. I have drafted this document with the help of the Tianocore
> > Stewards.
> > 
> > We view this as a living document, as our development processes evolve, I
> > will keep this document updated.
> > 
> > 
> > 
> > Please review the draft version of the document (link below) and provide
> > your feedback. Please send it to me, no need to reply all.
> > 
> > I appreciate your input by Friday, Oct 2. After this, I plan on make it live
> > on our TianoCore wiki site.
> > 
> > 
> > 
> > Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> > 
> > 
> > 
> > Thanks,
> > 
> > Soumya
> > 
> > 
> > 
> > Soumya Guptha
> > TianoCore Community Manager
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 

Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

[Yao, Jiewen]

Hi Leif and Liming
I have double checked with Mike Kinney on the role and responsibility of reviewers.
Mike and I reach the consensus below (a short version, detail will be added to the wiki page later):

1) Maintainers are the ONLY ones who can approve a patch.
2) Reviewers CANNOT approve the patch. (*)
3) A maintainer CANNOT approve his/her own patch.
4) Maintainers MAY delegate the approval work to reviewers.

So the final state of the commit message as a minimum must be either:
             Reviewed-by: <Package Maintainer>
Or:
             Acked-by: <Package Maintainer>
             Reviewed-by: <Package Reviewer>

All in all, I don’t think it is correct to say "Reviewers can approve the patch. The only additional work from maintainers is to check in the patch".

Please let us know if you have different thought.

Thank you
Yao Jiewen

> -----Original Message-----
> From: Leif Lindholm <leif@nuviainc.com>
> Sent: Monday, September 28, 2020 8:02 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io; Guptha,
> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io;
> lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew
> Fish' <afish@apple.com>
> Subject: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore
> community page on who we are - please review
> 
> Hi Jiewen,
> 
> On Sun, Sep 27, 2020 at 03:25:24 +0000, Yao, Jiewen wrote:
> > Thanks Liming.
> >
> > It seems I have some misunderstanding here.
> >
> > According to current process, I feel that only maintainer has right to
> *approve* the patch.
> > The reviewer cannot approve the patch.
> > Do you mean the reviewer can also approve the patch?
> 
> My view is that a reviewer has a right to "approve" a patch, but they
> do not have access to actually push the patch. A maintainer is needed
> for that. In instances where a designated maintainer is unavaliable to
> do so, another maintainer would be permitted to push the patch.
> 
> In instances where the designated maintainer disagrees with the
> reviewer, the patch should not be pushed. However, the same should be
> true for a patch where two designated maintainers or two designated
> reviewers disagree.
> 
> Best Regards,
> 
> Leif
> 
> > According to https://github.com/tianocore/tianocore.github.io/wiki/Who-we-
> are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am confused
> here ... So please do correct me if I am wrong.)
> > =================
> > Role of a Reviewer
> > Reviewers help maintainers review code, but don't have push access.
> >
> > A designated Package Reviewer:
> >
> > shall be reasonably familiar with the Package (or some modules thereof)
> >
> > will be copied on the patch discussions,
> >
> > and/or provides testing or regression testing for the Package (or some
> modules thereof), in certain platforms and environments.
> > ================
> >
> > Thank you
> > Yao Jiewen
> >
> >
> > > -----Original Message-----
> > > From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of
> > > gaoliming
> > > Sent: Sunday, September 27, 2020 10:33 AM
> > > To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > > Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)' <leif@nuviainc.com>;
> > > Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
> > > <afish@apple.com>
> > > Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community page on
> > > who we are - please review
> > >
> > > Jiewen:
> > >
> > >  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> > > Maintainer takes role 1~7. If the people know edk2 process well, they mostly
> > > know edk2 one or more packages (modules). So, they can take Maintainer
> role.
> > > If the people only focus on the technical review, they can take reviewer
> > > role. I would suggest there is at lease one Maintainer for each package.
> > > There are more reviewers for each package.
> > >
> > >
> > >
> > > Soumya:
> > >
> > >  Here are my comments.
> > >
> > >   Guidelines for a Maintainer. Never let a pending request get older than a
> > > calendar week. This requirement is too strict to the maintainer or reviewer.
> > > The maintainer or reviewer should try to give the response in one week. But,
> > > they may not fully review one patch set in one week, es for the feature or
> > > the complex change.
> > >
> > > Role of a Contributor/developer. We need to highlight the role &
> > > responsibility for the incompatible change. If the contributor proposes the
> > > incompatible change, he needs to coordinate with the impacted platform
> > > maintainer and make the agreement who will follow up to update the
> impacted
> > > platforms before he requests to merge his patch set. The impacted platforms
> > > include all ones in Edk2 and Edk2Platforms.
> > >
> > >
> > >
> > > Last, this page also needs to include release maintainer Definition and
> > > Role. The release maintainer is to create the quarterly stable tag. He takes
> > > the role to collect the feature planning for each stable tag, schedule the
> > > release date, and create the stable tag with the release notes on tag page.
> > > He will also send the announcement of soft feature freeze, hard feature
> > > freeze and the stable tag completement to edk2 community.
> > >
> > >
> > >
> > > Thanks
> > >
> > > Liming
> > >
> > > 发件人: bounce+27952+65655+4905953+8761045@groups.io
> > > <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
> > > 发送时间: 2020年9月26日 13:33
> > > 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> Guptha,
> > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > > 主题: Re: [edk2-devel] Tianocore community page on who we are - please
> > > review
> > >
> > >
> > >
> > > Some other thought is about maintainer’s role definition:
> > >
> > >
> > >
> > > The role of a maintainer is to:
> > >
> > > 1.	Maintainer assignments to packages and source file name patterns are
> > > provided in the "
> > > <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
> Maintainers.
> > > txt" file.
> > > 2.	Subscribe to the "edk2-bugs" mailing list
> > > <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> > > propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> > > https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new
> > > issues reported for their assigned packages. Participate in triaging and
> > > analyzing bugs filed for their assigned packages.
> > > 3.	Responsible for reviewing patches and answering questions from
> > > contributors, on the edk2-devel mailing list
> > > <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> > > 4.	Responsible for coordinating patch review with co-maintainers and
> > > reviewers of the same package.
> > > 5.	Has push / merge access to the merge branch.
> > > 6.	Responsible for merging approved patches into the master branch.
> > > 7.	Follow the EDK II development
> > > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> Development-Pr
> > > ocess> process.
> > >
> > >
> > >
> > > IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
> > >
> > > Logically, the can be two separated roles and be done by two different
> > > persons.
> > >
> > > A people who has strong technical expertise might NOT be the best person
> to
> > > do the integration, and vice versa. I hope we can let right person do right
> > > thing in right way.
> > >
> > > For example, to avoid mistake during check in, 5~7 can be done by a role
> > > named “integrator”.
> > >
> > >
> > >
> > > My dream is that check-in process is just one click button. But it seems we
> > > are still far from it…
> > >
> > >
> > >
> > > My two cents.
> > >
> > >
> > >
> > > Thank you
> > >
> > > Yao Jiewen
> > >
> > >
> > >
> > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Yao,
> > > Jiewen
> > > Sent: Saturday, September 26, 2020 1:09 PM
> > > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha,
> Soumya K
> > > <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
> > > announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> > > Subject: Re: [edk2-devel] Tianocore community page on who we are - please
> > > review
> > >
> > >
> > >
> > > Thanks Soumya. I think this is a good start.
> > >
> > >
> > >
> > > Recently we are discussing the maintainer’s work in EDKII mailing list,
> > > with title “more development process failure”.
> > >
> > >
> > >
> > > I feel the process mentioned in
> > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> Development-Pro
> > > cess is not clear enough to follow, especially for the maintainer who is not
> > > full time working on EDKII.
> > >
> > >
> > >
> > > I wish we can have this opportunity to revisit the “Follow the EDK II
> > > development
> > > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> Development-Pr
> > > ocess> process” and make “the process” simpler and clearer.
> > >
> > >
> > >
> > > Then all maintainers can sign to follow one rule. The rule we define and the
> > > rule we agree with.
> > >
> > >
> > >
> > > Thank you
> > >
> > > Yao Jiewen
> > >
> > >
> > >
> > >
> > >
> > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> Soumya
> > > Guptha
> > > Sent: Saturday, September 26, 2020 6:35 AM
> > > To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> > > devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > Subject: [edk2-devel] Tianocore community page on who we are - please
> review
> > >
> > >
> > >
> > > Dear Community members,
> > >
> > >
> > >
> > > I have drafted a document “who we are”, explaining Tianocore community
> > > structure, members of the community, their role and the current
> development
> > > process. I have drafted this document with the help of the Tianocore
> > > Stewards.
> > >
> > > We view this as a living document, as our development processes evolve, I
> > > will keep this document updated.
> > >
> > >
> > >
> > > Please review the draft version of the document (link below) and provide
> > > your feedback. Please send it to me, no need to reply all.
> > >
> > > I appreciate your input by Friday, Oct 2. After this, I plan on make it live
> > > on our TianoCore wiki site.
> > >
> > >
> > >
> > > Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Soumya
> > >
> > >
> > >
> > > Soumya Guptha
> > > TianoCore Community Manager
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 
> > >
> >

回复: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

[gaoliming]

Jiewen:
  Frankly speaking, I don't know this rule that the patch needs to get review or ack from the maintainer. When the reviewer name is formally added into maintainers.txt, I think the maintainer has delegated the approval work to reviewers. So, I think that the reviewer takes the same role to the maintainer except for the patch merge.

Thanks
Liming
> -----邮件原件-----
> 发件人: bounce+27952+65748+4905953+8761045@groups.io
> <bounce+27952+65748+4905953+8761045@groups.io> 代表 Yao, Jiewen
> 发送时间: 2020年9月30日 10:12
> 收件人: Leif Lindholm <leif@nuviainc.com>
> 抄送: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
> Guptha, Soumya K <soumya.k.guptha@intel.com>;
> announce@edk2.groups.io; lersek@redhat.com; Kinney, Michael D
> <michael.d.kinney@intel.com>; 'Andrew Fish' <afish@apple.com>
> 主题: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore
> community page on who we are - please review
> 
> Hi Leif and Liming
> I have double checked with Mike Kinney on the role and responsibility of
> reviewers.
> Mike and I reach the consensus below (a short version, detail will be added to
> the wiki page later):
> 
> 1) Maintainers are the ONLY ones who can approve a patch.
> 2) Reviewers CANNOT approve the patch. (*)
> 3) A maintainer CANNOT approve his/her own patch.
> 4) Maintainers MAY delegate the approval work to reviewers.
> 
> So the final state of the commit message as a minimum must be either:
>              Reviewed-by: <Package Maintainer>
> Or:
>              Acked-by: <Package Maintainer>
>              Reviewed-by: <Package Reviewer>
> 
> All in all, I don’t think it is correct to say "Reviewers can approve the patch.
> The only additional work from maintainers is to check in the patch".
> 
> Please let us know if you have different thought.
> 
> Thank you
> Yao Jiewen
> 
> > -----Original Message-----
> > From: Leif Lindholm <leif@nuviainc.com>
> > Sent: Monday, September 28, 2020 8:02 PM
> > To: Yao, Jiewen <jiewen.yao@intel.com>
> > Cc: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
> Guptha,
> > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io;
> > lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>;
> 'Andrew
> > Fish' <afish@apple.com>
> > Subject: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel]
> Tianocore
> > community page on who we are - please review
> >
> > Hi Jiewen,
> >
> > On Sun, Sep 27, 2020 at 03:25:24 +0000, Yao, Jiewen wrote:
> > > Thanks Liming.
> > >
> > > It seems I have some misunderstanding here.
> > >
> > > According to current process, I feel that only maintainer has right to
> > *approve* the patch.
> > > The reviewer cannot approve the patch.
> > > Do you mean the reviewer can also approve the patch?
> >
> > My view is that a reviewer has a right to "approve" a patch, but they
> > do not have access to actually push the patch. A maintainer is needed
> > for that. In instances where a designated maintainer is unavaliable to
> > do so, another maintainer would be permitted to push the patch.
> >
> > In instances where the designated maintainer disagrees with the
> > reviewer, the patch should not be pushed. However, the same should be
> > true for a patch where two designated maintainers or two designated
> > reviewers disagree.
> >
> > Best Regards,
> >
> > Leif
> >
> > > According to
> https://github.com/tianocore/tianocore.github.io/wiki/Who-we-
> > are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am
> confused
> > here ... So please do correct me if I am wrong.)
> > > =================
> > > Role of a Reviewer
> > > Reviewers help maintainers review code, but don't have push access.
> > >
> > > A designated Package Reviewer:
> > >
> > > shall be reasonably familiar with the Package (or some modules thereof)
> > >
> > > will be copied on the patch discussions,
> > >
> > > and/or provides testing or regression testing for the Package (or some
> > modules thereof), in certain platforms and environments.
> > > ================
> > >
> > > Thank you
> > > Yao Jiewen
> > >
> > >
> > > > -----Original Message-----
> > > > From: announce@edk2.groups.io <announce@edk2.groups.io> On
> Behalf Of
> > > > gaoliming
> > > > Sent: Sunday, September 27, 2020 10:33 AM
> > > > To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> Guptha,
> > > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > > > Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)'
> <leif@nuviainc.com>;
> > > > Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
> > > > <afish@apple.com>
> > > > Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community
> page on
> > > > who we are - please review
> > > >
> > > > Jiewen:
> > > >
> > > >  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> > > > Maintainer takes role 1~7. If the people know edk2 process well, they
> mostly
> > > > know edk2 one or more packages (modules). So, they can take
> Maintainer
> > role.
> > > > If the people only focus on the technical review, they can take reviewer
> > > > role. I would suggest there is at lease one Maintainer for each package.
> > > > There are more reviewers for each package.
> > > >
> > > >
> > > >
> > > > Soumya:
> > > >
> > > >  Here are my comments.
> > > >
> > > >   Guidelines for a Maintainer. Never let a pending request get older
> than a
> > > > calendar week. This requirement is too strict to the maintainer or
> reviewer.
> > > > The maintainer or reviewer should try to give the response in one week.
> But,
> > > > they may not fully review one patch set in one week, es for the feature
> or
> > > > the complex change.
> > > >
> > > > Role of a Contributor/developer. We need to highlight the role &
> > > > responsibility for the incompatible change. If the contributor proposes
> the
> > > > incompatible change, he needs to coordinate with the impacted platform
> > > > maintainer and make the agreement who will follow up to update the
> > impacted
> > > > platforms before he requests to merge his patch set. The impacted
> platforms
> > > > include all ones in Edk2 and Edk2Platforms.
> > > >
> > > >
> > > >
> > > > Last, this page also needs to include release maintainer Definition and
> > > > Role. The release maintainer is to create the quarterly stable tag. He
> takes
> > > > the role to collect the feature planning for each stable tag, schedule the
> > > > release date, and create the stable tag with the release notes on tag
> page.
> > > > He will also send the announcement of soft feature freeze, hard feature
> > > > freeze and the stable tag completement to edk2 community.
> > > >
> > > >
> > > >
> > > > Thanks
> > > >
> > > > Liming
> > > >
> > > > 发件人: bounce+27952+65655+4905953+8761045@groups.io
> > > > <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao,
> Jiewen
> > > > 发送时间: 2020年9月26日 13:33
> > > > 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> > Guptha,
> > > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > > > 主题: Re: [edk2-devel] Tianocore community page on who we are -
> please
> > > > review
> > > >
> > > >
> > > >
> > > > Some other thought is about maintainer’s role definition:
> > > >
> > > >
> > > >
> > > > The role of a maintainer is to:
> > > >
> > > > 1.	Maintainer assignments to packages and source file name patterns
> are
> > > > provided in the "
> > > > <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
> > Maintainers.
> > > > txt" file.
> > > > 2.	Subscribe to the "edk2-bugs" mailing list
> > > > <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> > > > propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> > > > https://bugzilla.tianocore.org/ actions via email. Keep a close eye on
> new
> > > > issues reported for their assigned packages. Participate in triaging and
> > > > analyzing bugs filed for their assigned packages.
> > > > 3.	Responsible for reviewing patches and answering questions from
> > > > contributors, on the edk2-devel mailing list
> > > > <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> > > > 4.	Responsible for coordinating patch review with co-maintainers and
> > > > reviewers of the same package.
> > > > 5.	Has push / merge access to the merge branch.
> > > > 6.	Responsible for merging approved patches into the master branch.
> > > > 7.	Follow the EDK II development
> > > > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > Development-Pr
> > > > ocess> process.
> > > >
> > > >
> > > >
> > > > IMHO, the 1~4 need technical expertise, while 5~7 need process
> expertise.
> > > >
> > > > Logically, the can be two separated roles and be done by two different
> > > > persons.
> > > >
> > > > A people who has strong technical expertise might NOT be the best
> person
> > to
> > > > do the integration, and vice versa. I hope we can let right person do right
> > > > thing in right way.
> > > >
> > > > For example, to avoid mistake during check in, 5~7 can be done by a role
> > > > named “integrator”.
> > > >
> > > >
> > > >
> > > > My dream is that check-in process is just one click button. But it seems
> we
> > > > are still far from it…
> > > >
> > > >
> > > >
> > > > My two cents.
> > > >
> > > >
> > > >
> > > > Thank you
> > > >
> > > > Yao Jiewen
> > > >
> > > >
> > > >
> > > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> Yao,
> > > > Jiewen
> > > > Sent: Saturday, September 26, 2020 1:09 PM
> > > > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha,
> > Soumya K
> > > > <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
> > > > announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> > > > Subject: Re: [edk2-devel] Tianocore community page on who we are -
> please
> > > > review
> > > >
> > > >
> > > >
> > > > Thanks Soumya. I think this is a good start.
> > > >
> > > >
> > > >
> > > > Recently we are discussing the maintainer’s work in EDKII mailing list,
> > > > with title “more development process failure”.
> > > >
> > > >
> > > >
> > > > I feel the process mentioned in
> > > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > Development-Pro
> > > > cess is not clear enough to follow, especially for the maintainer who is
> not
> > > > full time working on EDKII.
> > > >
> > > >
> > > >
> > > > I wish we can have this opportunity to revisit the “Follow the EDK II
> > > > development
> > > > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > Development-Pr
> > > > ocess> process” and make “the process” simpler and clearer.
> > > >
> > > >
> > > >
> > > > Then all maintainers can sign to follow one rule. The rule we define and
> the
> > > > rule we agree with.
> > > >
> > > >
> > > >
> > > > Thank you
> > > >
> > > > Yao Jiewen
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> > Soumya
> > > > Guptha
> > > > Sent: Saturday, September 26, 2020 6:35 AM
> > > > To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> > > > devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > > Subject: [edk2-devel] Tianocore community page on who we are -
> please
> > review
> > > >
> > > >
> > > >
> > > > Dear Community members,
> > > >
> > > >
> > > >
> > > > I have drafted a document “who we are”, explaining Tianocore
> community
> > > > structure, members of the community, their role and the current
> > development
> > > > process. I have drafted this document with the help of the Tianocore
> > > > Stewards.
> > > >
> > > > We view this as a living document, as our development processes evolve,
> I
> > > > will keep this document updated.
> > > >
> > > >
> > > >
> > > > Please review the draft version of the document (link below) and provide
> > > > your feedback. Please send it to me, no need to reply all.
> > > >
> > > > I appreciate your input by Friday, Oct 2. After this, I plan on make it live
> > > > on our TianoCore wiki site.
> > > >
> > > >
> > > >
> > > > Link:
> https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Soumya
> > > >
> > > >
> > > >
> > > > Soumya Guptha
> > > > TianoCore Community Manager
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> 
> 
> 
> 

回复: [edk2-devel] Tianocore community page on who we are - please review

[Leif Lindholm]

Agreed.

Reviever or Maintainer can approve a patch. Any Maintainer can push a
patch that has been approved. This can happen either:
- when the designated Maintainer for that patch is
  unavailable/unresponsive
- if the patch submitter is also a Maintainer of some other part of
  the repo.

No one can approve their own patches.

The act of adding a Reviewer means delegating the approval work to
them.

Best Regards,

Leif

On Wed, Sep 30, 2020 at 17:25:38 +0800, gaoliming wrote:
> Jiewen:
>   Frankly speaking, I don't know this rule that the patch needs to
>   get review or ack from the maintainer. When the reviewer name is
>   formally added into maintainers.txt, I think the maintainer has
>   delegated the approval work to reviewers. So, I think that the
>   reviewer takes the same role to the maintainer except for the
>   patch merge.
> 
> Thanks
> Liming
> > -----邮件原件-----
> > 发件人: bounce+27952+65748+4905953+8761045@groups.io
> > <bounce+27952+65748+4905953+8761045@groups.io> 代表 Yao, Jiewen
> > 发送时间: 2020年9月30日 10:12
> > 收件人: Leif Lindholm <leif@nuviainc.com>
> > 抄送: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
> > Guptha, Soumya K <soumya.k.guptha@intel.com>;
> > announce@edk2.groups.io; lersek@redhat.com; Kinney, Michael D
> > <michael.d.kinney@intel.com>; 'Andrew Fish' <afish@apple.com>
> > 主题: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore
> > community page on who we are - please review
> > 
> > Hi Leif and Liming
> > I have double checked with Mike Kinney on the role and responsibility of
> > reviewers.
> > Mike and I reach the consensus below (a short version, detail will be added to
> > the wiki page later):
> > 
> > 1) Maintainers are the ONLY ones who can approve a patch.
> > 2) Reviewers CANNOT approve the patch. (*)
> > 3) A maintainer CANNOT approve his/her own patch.
> > 4) Maintainers MAY delegate the approval work to reviewers.
> > 
> > So the final state of the commit message as a minimum must be either:
> >              Reviewed-by: <Package Maintainer>
> > Or:
> >              Acked-by: <Package Maintainer>
> >              Reviewed-by: <Package Reviewer>
> > 
> > All in all, I don’t think it is correct to say "Reviewers can approve the patch.
> > The only additional work from maintainers is to check in the patch".
> > 
> > Please let us know if you have different thought.
> > 
> > Thank you
> > Yao Jiewen
> > 
> > > -----Original Message-----
> > > From: Leif Lindholm <leif@nuviainc.com>
> > > Sent: Monday, September 28, 2020 8:02 PM
> > > To: Yao, Jiewen <jiewen.yao@intel.com>
> > > Cc: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
> > Guptha,
> > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io;
> > > lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>;
> > 'Andrew
> > > Fish' <afish@apple.com>
> > > Subject: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel]
> > Tianocore
> > > community page on who we are - please review
> > >
> > > Hi Jiewen,
> > >
> > > On Sun, Sep 27, 2020 at 03:25:24 +0000, Yao, Jiewen wrote:
> > > > Thanks Liming.
> > > >
> > > > It seems I have some misunderstanding here.
> > > >
> > > > According to current process, I feel that only maintainer has right to
> > > *approve* the patch.
> > > > The reviewer cannot approve the patch.
> > > > Do you mean the reviewer can also approve the patch?
> > >
> > > My view is that a reviewer has a right to "approve" a patch, but they
> > > do not have access to actually push the patch. A maintainer is needed
> > > for that. In instances where a designated maintainer is unavaliable to
> > > do so, another maintainer would be permitted to push the patch.
> > >
> > > In instances where the designated maintainer disagrees with the
> > > reviewer, the patch should not be pushed. However, the same should be
> > > true for a patch where two designated maintainers or two designated
> > > reviewers disagree.
> > >
> > > Best Regards,
> > >
> > > Leif
> > >
> > > > According to
> > https://github.com/tianocore/tianocore.github.io/wiki/Who-we-
> > > are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am
> > confused
> > > here ... So please do correct me if I am wrong.)
> > > > =================
> > > > Role of a Reviewer
> > > > Reviewers help maintainers review code, but don't have push access.
> > > >
> > > > A designated Package Reviewer:
> > > >
> > > > shall be reasonably familiar with the Package (or some modules thereof)
> > > >
> > > > will be copied on the patch discussions,
> > > >
> > > > and/or provides testing or regression testing for the Package (or some
> > > modules thereof), in certain platforms and environments.
> > > > ================
> > > >
> > > > Thank you
> > > > Yao Jiewen
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: announce@edk2.groups.io <announce@edk2.groups.io> On
> > Behalf Of
> > > > > gaoliming
> > > > > Sent: Sunday, September 27, 2020 10:33 AM
> > > > > To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> > Guptha,
> > > > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > > > > Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)'
> > <leif@nuviainc.com>;
> > > > > Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
> > > > > <afish@apple.com>
> > > > > Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community
> > page on
> > > > > who we are - please review
> > > > >
> > > > > Jiewen:
> > > > >
> > > > >  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> > > > > Maintainer takes role 1~7. If the people know edk2 process well, they
> > mostly
> > > > > know edk2 one or more packages (modules). So, they can take
> > Maintainer
> > > role.
> > > > > If the people only focus on the technical review, they can take reviewer
> > > > > role. I would suggest there is at lease one Maintainer for each package.
> > > > > There are more reviewers for each package.
> > > > >
> > > > >
> > > > >
> > > > > Soumya:
> > > > >
> > > > >  Here are my comments.
> > > > >
> > > > >   Guidelines for a Maintainer. Never let a pending request get older
> > than a
> > > > > calendar week. This requirement is too strict to the maintainer or
> > reviewer.
> > > > > The maintainer or reviewer should try to give the response in one week.
> > But,
> > > > > they may not fully review one patch set in one week, es for the feature
> > or
> > > > > the complex change.
> > > > >
> > > > > Role of a Contributor/developer. We need to highlight the role &
> > > > > responsibility for the incompatible change. If the contributor proposes
> > the
> > > > > incompatible change, he needs to coordinate with the impacted platform
> > > > > maintainer and make the agreement who will follow up to update the
> > > impacted
> > > > > platforms before he requests to merge his patch set. The impacted
> > platforms
> > > > > include all ones in Edk2 and Edk2Platforms.
> > > > >
> > > > >
> > > > >
> > > > > Last, this page also needs to include release maintainer Definition and
> > > > > Role. The release maintainer is to create the quarterly stable tag. He
> > takes
> > > > > the role to collect the feature planning for each stable tag, schedule the
> > > > > release date, and create the stable tag with the release notes on tag
> > page.
> > > > > He will also send the announcement of soft feature freeze, hard feature
> > > > > freeze and the stable tag completement to edk2 community.
> > > > >
> > > > >
> > > > >
> > > > > Thanks
> > > > >
> > > > > Liming
> > > > >
> > > > > 发件人: bounce+27952+65655+4905953+8761045@groups.io
> > > > > <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao,
> > Jiewen
> > > > > 发送时间: 2020年9月26日 13:33
> > > > > 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
> > > Guptha,
> > > > > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > > > > 主题: Re: [edk2-devel] Tianocore community page on who we are -
> > please
> > > > > review
> > > > >
> > > > >
> > > > >
> > > > > Some other thought is about maintainer’s role definition:
> > > > >
> > > > >
> > > > >
> > > > > The role of a maintainer is to:
> > > > >
> > > > > 1.	Maintainer assignments to packages and source file name patterns
> > are
> > > > > provided in the "
> > > > > <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
> > > Maintainers.
> > > > > txt" file.
> > > > > 2.	Subscribe to the "edk2-bugs" mailing list
> > > > > <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> > > > > propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> > > > > https://bugzilla.tianocore.org/ actions via email. Keep a close eye on
> > new
> > > > > issues reported for their assigned packages. Participate in triaging and
> > > > > analyzing bugs filed for their assigned packages.
> > > > > 3.	Responsible for reviewing patches and answering questions from
> > > > > contributors, on the edk2-devel mailing list
> > > > > <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> > > > > 4.	Responsible for coordinating patch review with co-maintainers and
> > > > > reviewers of the same package.
> > > > > 5.	Has push / merge access to the merge branch.
> > > > > 6.	Responsible for merging approved patches into the master branch.
> > > > > 7.	Follow the EDK II development
> > > > > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > > Development-Pr
> > > > > ocess> process.
> > > > >
> > > > >
> > > > >
> > > > > IMHO, the 1~4 need technical expertise, while 5~7 need process
> > expertise.
> > > > >
> > > > > Logically, the can be two separated roles and be done by two different
> > > > > persons.
> > > > >
> > > > > A people who has strong technical expertise might NOT be the best
> > person
> > > to
> > > > > do the integration, and vice versa. I hope we can let right person do right
> > > > > thing in right way.
> > > > >
> > > > > For example, to avoid mistake during check in, 5~7 can be done by a role
> > > > > named “integrator”.
> > > > >
> > > > >
> > > > >
> > > > > My dream is that check-in process is just one click button. But it seems
> > we
> > > > > are still far from it…
> > > > >
> > > > >
> > > > >
> > > > > My two cents.
> > > > >
> > > > >
> > > > >
> > > > > Thank you
> > > > >
> > > > > Yao Jiewen
> > > > >
> > > > >
> > > > >
> > > > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > > > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> > Yao,
> > > > > Jiewen
> > > > > Sent: Saturday, September 26, 2020 1:09 PM
> > > > > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha,
> > > Soumya K
> > > > > <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
> > > > > announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> > > > > Subject: Re: [edk2-devel] Tianocore community page on who we are -
> > please
> > > > > review
> > > > >
> > > > >
> > > > >
> > > > > Thanks Soumya. I think this is a good start.
> > > > >
> > > > >
> > > > >
> > > > > Recently we are discussing the maintainer’s work in EDKII mailing list,
> > > > > with title “more development process failure”.
> > > > >
> > > > >
> > > > >
> > > > > I feel the process mentioned in
> > > > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > > Development-Pro
> > > > > cess is not clear enough to follow, especially for the maintainer who is
> > not
> > > > > full time working on EDKII.
> > > > >
> > > > >
> > > > >
> > > > > I wish we can have this opportunity to revisit the “Follow the EDK II
> > > > > development
> > > > > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
> > > Development-Pr
> > > > > ocess> process” and make “the process” simpler and clearer.
> > > > >
> > > > >
> > > > >
> > > > > Then all maintainers can sign to follow one rule. The rule we define and
> > the
> > > > > rule we agree with.
> > > > >
> > > > >
> > > > >
> > > > > Thank you
> > > > >
> > > > > Yao Jiewen
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > > > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> > > Soumya
> > > > > Guptha
> > > > > Sent: Saturday, September 26, 2020 6:35 AM
> > > > > To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> > > > > devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > > > > Subject: [edk2-devel] Tianocore community page on who we are -
> > please
> > > review
> > > > >
> > > > >
> > > > >
> > > > > Dear Community members,
> > > > >
> > > > >
> > > > >
> > > > > I have drafted a document “who we are”, explaining Tianocore
> > community
> > > > > structure, members of the community, their role and the current
> > > development
> > > > > process. I have drafted this document with the help of the Tianocore
> > > > > Stewards.
> > > > >
> > > > > We view this as a living document, as our development processes evolve,
> > I
> > > > > will keep this document updated.
> > > > >
> > > > >
> > > > >
> > > > > Please review the draft version of the document (link below) and provide
> > > > > your feedback. Please send it to me, no need to reply all.
> > > > >
> > > > > I appreciate your input by Friday, Oct 2. After this, I plan on make it live
> > > > > on our TianoCore wiki site.
> > > > >
> > > > >
> > > > >
> > > > > Link:
> > https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Soumya
> > > > >
> > > > >
> > > > >
> > > > > Soumya Guptha
> > > > > TianoCore Community Manager
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 
> 
> 
> 

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Laszlo Ersek]

On 09/30/20 12:13, Leif Lindholm wrote:
> Agreed.
> 
> Reviever or Maintainer can approve a patch. Any Maintainer can push a
> patch that has been approved.

I disagree.

Assume Ard and myself are away and Jordan fails to report back in a week
or so, but Rebecca or Peter have reviewed a patch on the list for
OvmfPkg/Bhyve.

In that case, the patch should *NOT* be merged by (for example) you,
just because you have push rights. The community will have to wait until
Ard, Jordan, or myself return and provide an ACK.

If the maintainers are *consistently* irresponsive, then new maintainers
need to be added, possibly with a larger community discussion. But if
it's just a week (especially if we discussed our absence in advance),
then maintainer absence is completely sufficient and justified for
holding back patches, even if designated reviewers are OK with those
patches.

I've been *really* disliking that, for example, the chief MdeModulePkg
reviewers don't regularly ACK patches that have been reviewed by
designated reviewers. If those reviewers are considered authoritative
enough to fully approve patches -- and most of them they have push
access already, anyway --, then we should rework Maintainers.txt so that
Maintainer roles be handed out with a finer granularity. If you will:
promote those reviewers to Maintainers, on their respective turfs.

> This can happen either:
> - when the designated Maintainer for that patch is
>   unavailable/unresponsive
> - if the patch submitter is also a Maintainer of some other part of
>   the repo.
> 
> No one can approve their own patches.
> 
> The act of adding a Reviewer means delegating the approval work to
> them.

I don't see it like that; I think Maintainers should have the last word
on every patch going in. And yes, this *requires* maintainers to be
responsive.

... Hm. Perhaps this is a sign that we really have two concepts here,
we've just not been distinguishing them clearly enough. Maybe we need to
split the reviewer role in two: "Approving Reviewer" and "Assistant
Reviewer".

For example, on OvmfPkg, I would suggest marking all current Reviewers
as "Assistant Reviewers". On ArmVirtPkg, I'd likely propose you as an
Approving Reviewer (you have stood in for Ard and myself anyway, for
years now), and suggest Assistant Reviewer role for Julien. On
MdeModulePkg and other core packages, I'd defer the re-classification to
Intel; we'd likely see a really large number of Approving Reviewers
(justifiedly, I think).

Thanks,
Laszlo

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Laszlo Ersek]

On 10/01/20 10:44, Laszlo Ersek wrote:

> I've been *really* disliking that, for example, the chief MdeModulePkg
> reviewers

oops, this was a meaning-destroying typo. I meant: "chief maintainers".

> don't regularly ACK patches that have been reviewed by
> designated reviewers. If those reviewers are considered authoritative
> enough to fully approve patches -- and most of them they have push
> access already, anyway --, then we should rework Maintainers.txt so that
> Maintainer roles be handed out with a finer granularity. If you will:
> promote those reviewers to Maintainers, on their respective turfs.

Thanks
Laszlo

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Leif Lindholm]

On Thu, Oct 01, 2020 at 10:44:10 +0200, Laszlo Ersek wrote:
> On 09/30/20 12:13, Leif Lindholm wrote:
> > Agreed.
> > 
> > Reviever or Maintainer can approve a patch. Any Maintainer can push a
> > patch that has been approved.
> 
> I disagree.
> 
> Assume Ard and myself are away and Jordan fails to report back in a week
> or so, but Rebecca or Peter have reviewed a patch on the list for
> OvmfPkg/Bhyve.
> 
> In that case, the patch should *NOT* be merged by (for example) you,
> just because you have push rights. The community will have to wait until
> Ard, Jordan, or myself return and provide an ACK.
> 
> If the maintainers are *consistently* irresponsive, then new maintainers
> need to be added, possibly with a larger community discussion. But if
> it's just a week (especially if we discussed our absence in advance),
> then maintainer absence is completely sufficient and justified for
> holding back patches, even if designated reviewers are OK with those
> patches.
> 
> I've been *really* disliking that, for example, the chief MdeModulePkg
> reviewers don't regularly ACK patches that have been reviewed by
> designated reviewers. If those reviewers are considered authoritative
> enough to fully approve patches -- and most of them they have push
> access already, anyway --, then we should rework Maintainers.txt so that
> Maintainer roles be handed out with a finer granularity. If you will:
> promote those reviewers to Maintainers, on their respective turfs.
> 
> > This can happen either:
> > - when the designated Maintainer for that patch is
> >   unavailable/unresponsive
> > - if the patch submitter is also a Maintainer of some other part of
> >   the repo.
> > 
> > No one can approve their own patches.
> > 
> > The act of adding a Reviewer means delegating the approval work to
> > them.
> 
> I don't see it like that; I think Maintainers should have the last word
> on every patch going in. And yes, this *requires* maintainers to be
> responsive.
> 
> ... Hm. Perhaps this is a sign that we really have two concepts here,
> we've just not been distinguishing them clearly enough. Maybe we need to
> split the reviewer role in two: "Approving Reviewer" and "Assistant
> Reviewer".

I think you're right. This is why we seem to have two sets of opinions
on this topic.

> For example, on OvmfPkg, I would suggest marking all current Reviewers
> as "Assistant Reviewers". On ArmVirtPkg, I'd likely propose you as an
> Approving Reviewer (you have stood in for Ard and myself anyway, for
> years now), and suggest Assistant Reviewer role for Julien.

Right, that makes sense to me.

If I was to start bikeshedding, I might suggest adding an A: tag for
approving reviewer. Possibly stealing the description from the current
R: tag, and adding the approving bit. And maybe nicking the QEMU R:
description outright for R:.

> On
> MdeModulePkg and other core packages, I'd defer the re-classification to
> Intel; we'd likely see a really large number of Approving Reviewers
> (justifiedly, I think).

Agreed.

/
    Leif

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Soumya Guptha]

[-- Attachment #1: Type: text/plain, Size: 6405 bytes --]

Hi Folks,

Thanks for good discussions around this topic.



The purpose of this document "Who we are" is intended to remain high level to introduce the community members and their roles. Please note that some of the feedback is very detailed that probably fits into the TianoCore development process<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process> document.



Below are my proposed changes to the document based on the emails.

Please review and let me know if you see any issues by Oct 5. Please also directly edit the document and let us know what you edited in the document.

Fyi.. my plan is for this page to go live on Oct 9th. This will be a living document and we can make changes as we discover more.



I have added a new member "Release Manager", added TianoCore admin role, added responsibilities to the Maintainer and Reviewer section.

I agree that Maintainer is the one who approves final patch. I see the argument for creating “Approving Reviewer" and "Assistant Reviewer” roles, I am holding off this proposal to discuss in the upcoming Stewards meeting and make a call.



Release Manager

Role/Responsibilities:

1)The Release Manager is responsible for driving the quarterly Stable Tags. The Release Manager will plan the features, schedule the release date, create the Stable Tag with the release notes and announce to the EDK2 community on the release milestones: Soft feature freeze, hard feature freeze and the final release of the Stable Tag.



Maintainer Responsibility

1)Maintainer or Reviewer is responsible for timely responses on emails addressed to them (preferably less than calendar week).



Reviewer Responsibility

1)Reviewer or Maintainer is responsible for timely responses on emails addressed to them(preferably less than calendar week).

2) Open – Add Approving Reviewer" and "Assistant Reviewer".



TianoCore Admin:

Role: approve/remove access to TianoCore resources such as GitHub, Bugzilla, groupsIO etc..

Responsibilities:

Respond to emails and monitor role changes in the community (adding/removing maintainers..)



The request to add the below - Contributor responsibilities. This is too detailed. I would add this to the development process document.

CONTRIBUTOR

Responsibilities:

If a contributor proposes an incompatible change, the contributor should coordinate with the platform maintainer and make an agreement on who will follow up to update the impacted platforms before merging the patch. The impacted platforms include everything in Edk2 and Edk2Platforms.



Thanks,

Soumya



-----Original Message-----
From: Leif Lindholm <leif@nuviainc.com>
Sent: Thursday, October 1, 2020 3:22 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha, Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish' <afish@apple.com>
Subject: Re: 回复: [edk2-devel] Tianocore community page on who we are - please review



On Thu, Oct 01, 2020 at 10:44:10 +0200, Laszlo Ersek wrote:

> On 09/30/20 12:13, Leif Lindholm wrote:

> > Agreed.

> >

> > Reviever or Maintainer can approve a patch. Any Maintainer can push

> > a patch that has been approved.

>

> I disagree.

>

> Assume Ard and myself are away and Jordan fails to report back in a

> week or so, but Rebecca or Peter have reviewed a patch on the list for

> OvmfPkg/Bhyve.

>

> In that case, the patch should *NOT* be merged by (for example) you,

> just because you have push rights. The community will have to wait

> until Ard, Jordan, or myself return and provide an ACK.

>

> If the maintainers are *consistently* irresponsive, then new

> maintainers need to be added, possibly with a larger community

> discussion. But if it's just a week (especially if we discussed our

> absence in advance), then maintainer absence is completely sufficient

> and justified for holding back patches, even if designated reviewers

> are OK with those patches.

>

> I've been *really* disliking that, for example, the chief MdeModulePkg

> reviewers don't regularly ACK patches that have been reviewed by

> designated reviewers. If those reviewers are considered authoritative

> enough to fully approve patches -- and most of them they have push

> access already, anyway --, then we should rework Maintainers.txt so

> that Maintainer roles be handed out with a finer granularity. If you will:

> promote those reviewers to Maintainers, on their respective turfs.

>

> > This can happen either:

> > - when the designated Maintainer for that patch is

> >   unavailable/unresponsive

> > - if the patch submitter is also a Maintainer of some other part of

> >   the repo.

> >

> > No one can approve their own patches.

> >

> > The act of adding a Reviewer means delegating the approval work to

> > them.

>

> I don't see it like that; I think Maintainers should have the last

> word on every patch going in. And yes, this *requires* maintainers to

> be responsive.

>

> ... Hm. Perhaps this is a sign that we really have two concepts here,

> we've just not been distinguishing them clearly enough. Maybe we need

> to split the reviewer role in two: "Approving Reviewer" and "Assistant

> Reviewer".



I think you're right. This is why we seem to have two sets of opinions on this topic.



> For example, on OvmfPkg, I would suggest marking all current Reviewers

> as "Assistant Reviewers". On ArmVirtPkg, I'd likely propose you as an

> Approving Reviewer (you have stood in for Ard and myself anyway, for

> years now), and suggest Assistant Reviewer role for Julien.



Right, that makes sense to me.



If I was to start bikeshedding, I might suggest adding an A: tag for approving reviewer. Possibly stealing the description from the current

R: tag, and adding the approving bit. And maybe nicking the QEMU R:

description outright for R:.



> On

> MdeModulePkg and other core packages, I'd defer the re-classification

> to Intel; we'd likely see a really large number of Approving Reviewers

> (justifiedly, I think).



Agreed.



/

    Leif

[-- Attachment #2: Type: text/html, Size: 13095 bytes --]

Re: Tianocore community page on who we are - please review

[Laszlo Ersek]

(Resending; my previous attempt to post this response failed, and I even
lost the original version of my response, so I'm rewriting it again from
a draft. I've also cleaned up the garbage in the address list now -- I
think that may have contirbuted to me failing to send the message at
first.)

Hello Soumya,

On 10/02/20 01:52, Guptha, Soumya K wrote:
> Hi Folks,
>
> Thanks for good discussions around this topic.
>
> The purpose of this document "Who we are" is intended to remain high
> level to introduce the community members and their roles. Please note
> that some of the feedback is very detailed that probably fits into the
> TianoCore development
> process<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process>
> document.
>
> Below are my proposed changes to the document based on the emails.
>
> Please review and let me know if you see any issues by Oct 5. Please
> also directly edit the document and let us know what you edited in the
> document.
>
> Fyi.. my plan is for this page to go live on Oct 9th. This will be a
> living document and we can make changes as we discover more.
>
> I have added a new member "Release Manager", added TianoCore admin
> role, added responsibilities to the Maintainer and Reviewer section.

I'm confused -- I understood the document was published already in the
wiki:

  https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are

and the other day Liming even posted a patch for it, introducing the
Release Manager Role:

  https://edk2.groups.io/g/devel/message/65765

I reviewed the patch (I suggested some improvements):

  https://edk2.groups.io/g/devel/message/65784

In other words, the document is already as "live" as it gets. It's up on
the wiki for anyone to read and to propose updates for.


Importantly, it's going to be difficult if we edit the document through
multiple channels.

Before publication, we edited the document through Google Docs -- that
was an acceptable collaboration tool at that stage. Now that the
document resides in the Wiki, the preferred format for proposing
changes, and discussing those changes, is the usual patch review
workflow on edk2-devel.

We've followed this method for a long time now, for important wiki
articles. For trivial changes to important articles, and for all kinds
of changes to low visibility / low impact articles, using the WebUI is
acceptable. But this is an important change to an important document.

Furthermore, for wiki contributors that do not have wiki accounts (with
write access anyway), posting patches to edk2-devel is the *only* way to
contribute to the wiki. In the future, we might want to rebase that
workflow *too* to github.com pull requests, but even then, the preferred
format to express / propose a wiki change will still remain "patch".

Apologies if I misunderstood something; my point is, if I'm supposed to
review a change to the "Who we are" article in the wiki, please point me
to a patch on edk2-devel.

Thanks,
Laszlo

Re: 回复: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

[Laszlo Ersek]

On 09/30/20 11:25, gaoliming wrote:
> Jiewen:
>   Frankly speaking, I don't know this rule that the patch needs to get review or ack from the maintainer. When the reviewer name is formally added into maintainers.txt, I think the maintainer has delegated the approval work to reviewers. So, I think that the reviewer takes the same role to the maintainer except for the patch merge.

As far as I remember, the intent to designate reviewers in the
Maintainers.txt file was (a) to highlight people that consistently
review patches for a subsystem *without* having push rights, (b) to make
sure that patch submitters would CC those people on their postings
*up-font*. Participation of reviewers does not substitute 100% for
maintainer action.

Thanks
Laszlo

> 
> Thanks
> Liming
>> -----邮件原件-----
>> 发件人: bounce+27952+65748+4905953+8761045@groups.io
>> <bounce+27952+65748+4905953+8761045@groups.io> 代表 Yao, Jiewen
>> 发送时间: 2020年9月30日 10:12
>> 收件人: Leif Lindholm <leif@nuviainc.com>
>> 抄送: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
>> Guptha, Soumya K <soumya.k.guptha@intel.com>;
>> announce@edk2.groups.io; lersek@redhat.com; Kinney, Michael D
>> <michael.d.kinney@intel.com>; 'Andrew Fish' <afish@apple.com>
>> 主题: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore
>> community page on who we are - please review
>>
>> Hi Leif and Liming
>> I have double checked with Mike Kinney on the role and responsibility of
>> reviewers.
>> Mike and I reach the consensus below (a short version, detail will be added to
>> the wiki page later):
>>
>> 1) Maintainers are the ONLY ones who can approve a patch.
>> 2) Reviewers CANNOT approve the patch. (*)
>> 3) A maintainer CANNOT approve his/her own patch.
>> 4) Maintainers MAY delegate the approval work to reviewers.
>>
>> So the final state of the commit message as a minimum must be either:
>>              Reviewed-by: <Package Maintainer>
>> Or:
>>              Acked-by: <Package Maintainer>
>>              Reviewed-by: <Package Reviewer>
>>
>> All in all, I don’t think it is correct to say "Reviewers can approve the patch.
>> The only additional work from maintainers is to check in the patch".
>>
>> Please let us know if you have different thought.
>>
>> Thank you
>> Yao Jiewen
>>
>>> -----Original Message-----
>>> From: Leif Lindholm <leif@nuviainc.com>
>>> Sent: Monday, September 28, 2020 8:02 PM
>>> To: Yao, Jiewen <jiewen.yao@intel.com>
>>> Cc: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
>> Guptha,
>>> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io;
>>> lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>;
>> 'Andrew
>>> Fish' <afish@apple.com>
>>> Subject: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel]
>> Tianocore
>>> community page on who we are - please review
>>>
>>> Hi Jiewen,
>>>
>>> On Sun, Sep 27, 2020 at 03:25:24 +0000, Yao, Jiewen wrote:
>>>> Thanks Liming.
>>>>
>>>> It seems I have some misunderstanding here.
>>>>
>>>> According to current process, I feel that only maintainer has right to
>>> *approve* the patch.
>>>> The reviewer cannot approve the patch.
>>>> Do you mean the reviewer can also approve the patch?
>>>
>>> My view is that a reviewer has a right to "approve" a patch, but they
>>> do not have access to actually push the patch. A maintainer is needed
>>> for that. In instances where a designated maintainer is unavaliable to
>>> do so, another maintainer would be permitted to push the patch.
>>>
>>> In instances where the designated maintainer disagrees with the
>>> reviewer, the patch should not be pushed. However, the same should be
>>> true for a patch where two designated maintainers or two designated
>>> reviewers disagree.
>>>
>>> Best Regards,
>>>
>>> Leif
>>>
>>>> According to
>> https://github.com/tianocore/tianocore.github.io/wiki/Who-we-
>>> are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am
>> confused
>>> here ... So please do correct me if I am wrong.)
>>>> =================
>>>> Role of a Reviewer
>>>> Reviewers help maintainers review code, but don't have push access.
>>>>
>>>> A designated Package Reviewer:
>>>>
>>>> shall be reasonably familiar with the Package (or some modules thereof)
>>>>
>>>> will be copied on the patch discussions,
>>>>
>>>> and/or provides testing or regression testing for the Package (or some
>>> modules thereof), in certain platforms and environments.
>>>> ================
>>>>
>>>> Thank you
>>>> Yao Jiewen
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: announce@edk2.groups.io <announce@edk2.groups.io> On
>> Behalf Of
>>>>> gaoliming
>>>>> Sent: Sunday, September 27, 2020 10:33 AM
>>>>> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
>> Guptha,
>>>>> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
>>>>> Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)'
>> <leif@nuviainc.com>;
>>>>> Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
>>>>> <afish@apple.com>
>>>>> Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community
>> page on
>>>>> who we are - please review
>>>>>
>>>>> Jiewen:
>>>>>
>>>>>  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
>>>>> Maintainer takes role 1~7. If the people know edk2 process well, they
>> mostly
>>>>> know edk2 one or more packages (modules). So, they can take
>> Maintainer
>>> role.
>>>>> If the people only focus on the technical review, they can take reviewer
>>>>> role. I would suggest there is at lease one Maintainer for each package.
>>>>> There are more reviewers for each package.
>>>>>
>>>>>
>>>>>
>>>>> Soumya:
>>>>>
>>>>>  Here are my comments.
>>>>>
>>>>>   Guidelines for a Maintainer. Never let a pending request get older
>> than a
>>>>> calendar week. This requirement is too strict to the maintainer or
>> reviewer.
>>>>> The maintainer or reviewer should try to give the response in one week.
>> But,
>>>>> they may not fully review one patch set in one week, es for the feature
>> or
>>>>> the complex change.
>>>>>
>>>>> Role of a Contributor/developer. We need to highlight the role &
>>>>> responsibility for the incompatible change. If the contributor proposes
>> the
>>>>> incompatible change, he needs to coordinate with the impacted platform
>>>>> maintainer and make the agreement who will follow up to update the
>>> impacted
>>>>> platforms before he requests to merge his patch set. The impacted
>> platforms
>>>>> include all ones in Edk2 and Edk2Platforms.
>>>>>
>>>>>
>>>>>
>>>>> Last, this page also needs to include release maintainer Definition and
>>>>> Role. The release maintainer is to create the quarterly stable tag. He
>> takes
>>>>> the role to collect the feature planning for each stable tag, schedule the
>>>>> release date, and create the stable tag with the release notes on tag
>> page.
>>>>> He will also send the announcement of soft feature freeze, hard feature
>>>>> freeze and the stable tag completement to edk2 community.
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Liming
>>>>>
>>>>> 发件人: bounce+27952+65655+4905953+8761045@groups.io
>>>>> <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao,
>> Jiewen
>>>>> 发送时间: 2020年9月26日 13:33
>>>>> 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
>>> Guptha,
>>>>> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
>>>>> 主题: Re: [edk2-devel] Tianocore community page on who we are -
>> please
>>>>> review
>>>>>
>>>>>
>>>>>
>>>>> Some other thought is about maintainer’s role definition:
>>>>>
>>>>>
>>>>>
>>>>> The role of a maintainer is to:
>>>>>
>>>>> 1.	Maintainer assignments to packages and source file name patterns
>> are
>>>>> provided in the "
>>>>> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
>>> Maintainers.
>>>>> txt" file.
>>>>> 2.	Subscribe to the "edk2-bugs" mailing list
>>>>> <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
>>>>> propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
>>>>> https://bugzilla.tianocore.org/ actions via email. Keep a close eye on
>> new
>>>>> issues reported for their assigned packages. Participate in triaging and
>>>>> analyzing bugs filed for their assigned packages.
>>>>> 3.	Responsible for reviewing patches and answering questions from
>>>>> contributors, on the edk2-devel mailing list
>>>>> <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
>>>>> 4.	Responsible for coordinating patch review with co-maintainers and
>>>>> reviewers of the same package.
>>>>> 5.	Has push / merge access to the merge branch.
>>>>> 6.	Responsible for merging approved patches into the master branch.
>>>>> 7.	Follow the EDK II development
>>>>> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
>>> Development-Pr
>>>>> ocess> process.
>>>>>
>>>>>
>>>>>
>>>>> IMHO, the 1~4 need technical expertise, while 5~7 need process
>> expertise.
>>>>>
>>>>> Logically, the can be two separated roles and be done by two different
>>>>> persons.
>>>>>
>>>>> A people who has strong technical expertise might NOT be the best
>> person
>>> to
>>>>> do the integration, and vice versa. I hope we can let right person do right
>>>>> thing in right way.
>>>>>
>>>>> For example, to avoid mistake during check in, 5~7 can be done by a role
>>>>> named “integrator”.
>>>>>
>>>>>
>>>>>
>>>>> My dream is that check-in process is just one click button. But it seems
>> we
>>>>> are still far from it…
>>>>>
>>>>>
>>>>>
>>>>> My two cents.
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> Yao Jiewen
>>>>>
>>>>>
>>>>>
>>>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
>> Yao,
>>>>> Jiewen
>>>>> Sent: Saturday, September 26, 2020 1:09 PM
>>>>> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha,
>>> Soumya K
>>>>> <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
>>>>> announce@edk2.groups.io <mailto:announce@edk2.groups.io>
>>>>> Subject: Re: [edk2-devel] Tianocore community page on who we are -
>> please
>>>>> review
>>>>>
>>>>>
>>>>>
>>>>> Thanks Soumya. I think this is a good start.
>>>>>
>>>>>
>>>>>
>>>>> Recently we are discussing the maintainer’s work in EDKII mailing list,
>>>>> with title “more development process failure”.
>>>>>
>>>>>
>>>>>
>>>>> I feel the process mentioned in
>>>>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
>>> Development-Pro
>>>>> cess is not clear enough to follow, especially for the maintainer who is
>> not
>>>>> full time working on EDKII.
>>>>>
>>>>>
>>>>>
>>>>> I wish we can have this opportunity to revisit the “Follow the EDK II
>>>>> development
>>>>> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
>>> Development-Pr
>>>>> ocess> process” and make “the process” simpler and clearer.
>>>>>
>>>>>
>>>>>
>>>>> Then all maintainers can sign to follow one rule. The rule we define and
>> the
>>>>> rule we agree with.
>>>>>
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> Yao Jiewen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
>>> Soumya
>>>>> Guptha
>>>>> Sent: Saturday, September 26, 2020 6:35 AM
>>>>> To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
>>>>> devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> Subject: [edk2-devel] Tianocore community page on who we are -
>> please
>>> review
>>>>>
>>>>>
>>>>>
>>>>> Dear Community members,
>>>>>
>>>>>
>>>>>
>>>>> I have drafted a document “who we are”, explaining Tianocore
>> community
>>>>> structure, members of the community, their role and the current
>>> development
>>>>> process. I have drafted this document with the help of the Tianocore
>>>>> Stewards.
>>>>>
>>>>> We view this as a living document, as our development processes evolve,
>> I
>>>>> will keep this document updated.
>>>>>
>>>>>
>>>>>
>>>>> Please review the draft version of the document (link below) and provide
>>>>> your feedback. Please send it to me, no need to reply all.
>>>>>
>>>>> I appreciate your input by Friday, Oct 2. After this, I plan on make it live
>>>>> on our TianoCore wiki site.
>>>>>
>>>>>
>>>>>
>>>>> Link:
>> https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Soumya
>>>>>
>>>>>
>>>>>
>>>>> Soumya Guptha
>>>>> TianoCore Community Manager
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>> 
>>
> 
> 
> 

Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore community page on who we are - please review

[Laszlo Ersek]

On 09/30/20 04:11, Yao, Jiewen wrote:
> Hi Leif and Liming
> I have double checked with Mike Kinney on the role and responsibility of reviewers.
> Mike and I reach the consensus below (a short version, detail will be added to the wiki page later):
> 
> 1) Maintainers are the ONLY ones who can approve a patch.
> 2) Reviewers CANNOT approve the patch. (*)
> 3) A maintainer CANNOT approve his/her own patch.
> 4) Maintainers MAY delegate the approval work to reviewers.
> 
> So the final state of the commit message as a minimum must be either:
>              Reviewed-by: <Package Maintainer>
> Or:
>              Acked-by: <Package Maintainer>
>              Reviewed-by: <Package Reviewer>

This is the best resolution in my opinion. It allows maintainers to
delegate the technical review to reviewers, but it requires maintainers
to be at least aware of the patch and the review session.

Thanks,
Laszlo

> 
> All in all, I don’t think it is correct to say "Reviewers can approve the patch. The only additional work from maintainers is to check in the patch".
> 
> Please let us know if you have different thought.
> 
> Thank you
> Yao Jiewen
> 
>> -----Original Message-----
>> From: Leif Lindholm <leif@nuviainc.com>
>> Sent: Monday, September 28, 2020 8:02 PM
>> To: Yao, Jiewen <jiewen.yao@intel.com>
>> Cc: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io; Guptha,
>> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io;
>> lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew
>> Fish' <afish@apple.com>
>> Subject: Re: [EXTERNAL] RE: [edk2-announce] 回复: [edk2-devel] Tianocore
>> community page on who we are - please review
>>
>> Hi Jiewen,
>>
>> On Sun, Sep 27, 2020 at 03:25:24 +0000, Yao, Jiewen wrote:
>>> Thanks Liming.
>>>
>>> It seems I have some misunderstanding here.
>>>
>>> According to current process, I feel that only maintainer has right to
>> *approve* the patch.
>>> The reviewer cannot approve the patch.
>>> Do you mean the reviewer can also approve the patch?
>>
>> My view is that a reviewer has a right to "approve" a patch, but they
>> do not have access to actually push the patch. A maintainer is needed
>> for that. In instances where a designated maintainer is unavaliable to
>> do so, another maintainer would be permitted to push the patch.
>>
>> In instances where the designated maintainer disagrees with the
>> reviewer, the patch should not be pushed. However, the same should be
>> true for a patch where two designated maintainers or two designated
>> reviewers disagree.
>>
>> Best Regards,
>>
>> Leif
>>
>>> According to https://github.com/tianocore/tianocore.github.io/wiki/Who-we-
>> are#role-of-a-reviewer, I don’t think "Reviewer takes role 1~4.". (I am confused
>> here ... So please do correct me if I am wrong.)
>>> =================
>>> Role of a Reviewer
>>> Reviewers help maintainers review code, but don't have push access.
>>>
>>> A designated Package Reviewer:
>>>
>>> shall be reasonably familiar with the Package (or some modules thereof)
>>>
>>> will be copied on the patch discussions,
>>>
>>> and/or provides testing or regression testing for the Package (or some
>> modules thereof), in certain platforms and environments.
>>> ================
>>>
>>> Thank you
>>> Yao Jiewen
>>>
>>>
>>>> -----Original Message-----
>>>> From: announce@edk2.groups.io <announce@edk2.groups.io> On Behalf Of
>>>> gaoliming
>>>> Sent: Sunday, September 27, 2020 10:33 AM
>>>> To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
>>>> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
>>>> Cc: lersek@redhat.com; 'Leif Lindholm (Nuvia address)' <leif@nuviainc.com>;
>>>> Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
>>>> <afish@apple.com>
>>>> Subject: [edk2-announce] 回复: [edk2-devel] Tianocore community page on
>>>> who we are - please review
>>>>
>>>> Jiewen:
>>>>
>>>>  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
>>>> Maintainer takes role 1~7. If the people know edk2 process well, they mostly
>>>> know edk2 one or more packages (modules). So, they can take Maintainer
>> role.
>>>> If the people only focus on the technical review, they can take reviewer
>>>> role. I would suggest there is at lease one Maintainer for each package.
>>>> There are more reviewers for each package.
>>>>
>>>>
>>>>
>>>> Soumya:
>>>>
>>>>  Here are my comments.
>>>>
>>>>   Guidelines for a Maintainer. Never let a pending request get older than a
>>>> calendar week. This requirement is too strict to the maintainer or reviewer.
>>>> The maintainer or reviewer should try to give the response in one week. But,
>>>> they may not fully review one patch set in one week, es for the feature or
>>>> the complex change.
>>>>
>>>> Role of a Contributor/developer. We need to highlight the role &
>>>> responsibility for the incompatible change. If the contributor proposes the
>>>> incompatible change, he needs to coordinate with the impacted platform
>>>> maintainer and make the agreement who will follow up to update the
>> impacted
>>>> platforms before he requests to merge his patch set. The impacted platforms
>>>> include all ones in Edk2 and Edk2Platforms.
>>>>
>>>>
>>>>
>>>> Last, this page also needs to include release maintainer Definition and
>>>> Role. The release maintainer is to create the quarterly stable tag. He takes
>>>> the role to collect the feature planning for each stable tag, schedule the
>>>> release date, and create the stable tag with the release notes on tag page.
>>>> He will also send the announcement of soft feature freeze, hard feature
>>>> freeze and the stable tag completement to edk2 community.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Liming
>>>>
>>>> 发件人: bounce+27952+65655+4905953+8761045@groups.io
>>>> <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
>>>> 发送时间: 2020年9月26日 13:33
>>>> 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>;
>> Guptha,
>>>> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
>>>> 主题: Re: [edk2-devel] Tianocore community page on who we are - please
>>>> review
>>>>
>>>>
>>>>
>>>> Some other thought is about maintainer’s role definition:
>>>>
>>>>
>>>>
>>>> The role of a maintainer is to:
>>>>
>>>> 1.	Maintainer assignments to packages and source file name patterns are
>>>> provided in the "
>>>> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
>> Maintainers.
>>>> txt" file.
>>>> 2.	Subscribe to the "edk2-bugs" mailing list
>>>> <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
>>>> propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
>>>> https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new
>>>> issues reported for their assigned packages. Participate in triaging and
>>>> analyzing bugs filed for their assigned packages.
>>>> 3.	Responsible for reviewing patches and answering questions from
>>>> contributors, on the edk2-devel mailing list
>>>> <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
>>>> 4.	Responsible for coordinating patch review with co-maintainers and
>>>> reviewers of the same package.
>>>> 5.	Has push / merge access to the merge branch.
>>>> 6.	Responsible for merging approved patches into the master branch.
>>>> 7.	Follow the EDK II development
>>>> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
>> Development-Pr
>>>> ocess> process.
>>>>
>>>>
>>>>
>>>> IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
>>>>
>>>> Logically, the can be two separated roles and be done by two different
>>>> persons.
>>>>
>>>> A people who has strong technical expertise might NOT be the best person
>> to
>>>> do the integration, and vice versa. I hope we can let right person do right
>>>> thing in right way.
>>>>
>>>> For example, to avoid mistake during check in, 5~7 can be done by a role
>>>> named “integrator”.
>>>>
>>>>
>>>>
>>>> My dream is that check-in process is just one click button. But it seems we
>>>> are still far from it…
>>>>
>>>>
>>>>
>>>> My two cents.
>>>>
>>>>
>>>>
>>>> Thank you
>>>>
>>>> Yao Jiewen
>>>>
>>>>
>>>>
>>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Yao,
>>>> Jiewen
>>>> Sent: Saturday, September 26, 2020 1:09 PM
>>>> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha,
>> Soumya K
>>>> <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
>>>> announce@edk2.groups.io <mailto:announce@edk2.groups.io>
>>>> Subject: Re: [edk2-devel] Tianocore community page on who we are - please
>>>> review
>>>>
>>>>
>>>>
>>>> Thanks Soumya. I think this is a good start.
>>>>
>>>>
>>>>
>>>> Recently we are discussing the maintainer’s work in EDKII mailing list,
>>>> with title “more development process failure”.
>>>>
>>>>
>>>>
>>>> I feel the process mentioned in
>>>> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
>> Development-Pro
>>>> cess is not clear enough to follow, especially for the maintainer who is not
>>>> full time working on EDKII.
>>>>
>>>>
>>>>
>>>> I wish we can have this opportunity to revisit the “Follow the EDK II
>>>> development
>>>> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-
>> Development-Pr
>>>> ocess> process” and make “the process” simpler and clearer.
>>>>
>>>>
>>>>
>>>> Then all maintainers can sign to follow one rule. The rule we define and the
>>>> rule we agree with.
>>>>
>>>>
>>>>
>>>> Thank you
>>>>
>>>> Yao Jiewen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
>> Soumya
>>>> Guptha
>>>> Sent: Saturday, September 26, 2020 6:35 AM
>>>> To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
>>>> devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> Subject: [edk2-devel] Tianocore community page on who we are - please
>> review
>>>>
>>>>
>>>>
>>>> Dear Community members,
>>>>
>>>>
>>>>
>>>> I have drafted a document “who we are”, explaining Tianocore community
>>>> structure, members of the community, their role and the current
>> development
>>>> process. I have drafted this document with the help of the Tianocore
>>>> Stewards.
>>>>
>>>> We view this as a living document, as our development processes evolve, I
>>>> will keep this document updated.
>>>>
>>>>
>>>>
>>>> Please review the draft version of the document (link below) and provide
>>>> your feedback. Please send it to me, no need to reply all.
>>>>
>>>> I appreciate your input by Friday, Oct 2. After this, I plan on make it live
>>>> on our TianoCore wiki site.
>>>>
>>>>
>>>>
>>>> Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Soumya
>>>>
>>>>
>>>>
>>>> Soumya Guptha
>>>> TianoCore Community Manager
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Leif Lindholm]

Hi Liming,

On Sun, Sep 27, 2020 at 10:32:55 +0800, gaoliming wrote:
> Jiewen:
> 
>  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> Maintainer takes role 1~7. If the people know edk2 process well, they mostly
> know edk2 one or more packages (modules). So, they can take Maintainer role.
> If the people only focus on the technical review, they can take reviewer
> role. I would suggest there is at lease one Maintainer for each package.
> There are more reviewers for each package.
> 
> Soumya:
> 
>  Here are my comments. 
> 
>   Guidelines for a Maintainer. Never let a pending request get older than a
> calendar week. This requirement is too strict to the maintainer or reviewer.
> The maintainer or reviewer should try to give the response in one week. But,
> they may not fully review one patch set in one week, es for the feature or
> the complex change. 

My take on this is as follows (speaking as someone who has failed this
rule many times):
This document is a guideline.

In some cases we are not yet in a position to be more timely about this.
That's where we need more reviewers to help out. Whether they are
official designated reviewers or not. If some parts of the codebase
always take long time to get review feedback for, that is a sign of a
problem that needs to be addressed.

I agree that for a very invasive change, we may not be able to give a
detailed reply early on. But in those cases, we should convey that
feedback *very* early on.

> Role of a Contributor/developer. We need to highlight the role &
> responsibility for the incompatible change. If the contributor proposes the
> incompatible change, he needs to coordinate with the impacted platform
> maintainer and make the agreement who will follow up to update the impacted
> platforms before he requests to merge his patch set. The impacted platforms
> include all ones in Edk2 and Edk2Platforms. 

This is a good point. The details may need more discussion.

> Last, this page also needs to include release maintainer Definition and
> Role. The release maintainer is to create the quarterly stable tag. He takes
> the role to collect the feature planning for each stable tag, schedule the
> release date, and create the stable tag with the release notes on tag page.
> He will also send the announcement of soft feature freeze, hard feature
> freeze and the stable tag completement to edk2 community. 

This is also a good point.

Best Regards,

Leif

> Thanks
> 
> Liming
> 
> 发件人: bounce+27952+65655+4905953+8761045@groups.io
> <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
> 发送时间: 2020年9月26日 13:33
> 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> 主题: Re: [edk2-devel] Tianocore community page on who we are - please
> review
> 
>  
> 
> Some other thought is about maintainer’s role definition:
> 
>  
> 
> The role of a maintainer is to:
> 
> 1.	Maintainer assignments to packages and source file name patterns are
> provided in the "
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt> Maintainers.
> txt" file.
> 2.	Subscribe to the "edk2-bugs" mailing list
> <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> https://bugzilla.tianocore.org/ actions via email. Keep a close eye on new
> issues reported for their assigned packages. Participate in triaging and
> analyzing bugs filed for their assigned packages.
> 3.	Responsible for reviewing patches and answering questions from
> contributors, on the edk2-devel mailing list
> <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> 4.	Responsible for coordinating patch review with co-maintainers and
> reviewers of the same package.
> 5.	Has push / merge access to the merge branch.
> 6.	Responsible for merging approved patches into the master branch.
> 7.	Follow the EDK II development
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
> ocess> process.
> 
>  
> 
> IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
> 
> Logically, the can be two separated roles and be done by two different
> persons.
> 
> A people who has strong technical expertise might NOT be the best person to
> do the integration, and vice versa. I hope we can let right person do right
> thing in right way.
> 
> For example, to avoid mistake during check in, 5~7 can be done by a role
> named “integrator”.
> 
>  
> 
> My dream is that check-in process is just one click button. But it seems we
> are still far from it…
> 
>  
> 
> My two cents.
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Yao,
> Jiewen
> Sent: Saturday, September 26, 2020 1:09 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha, Soumya K
> <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> >;
> announce@edk2.groups.io <mailto:announce@edk2.groups.io> 
> Subject: Re: [edk2-devel] Tianocore community page on who we are - please
> review
> 
>  
> 
> Thanks Soumya. I think this is a good start.
> 
>  
> 
> Recently we are discussing the maintainer’s work in EDKII mailing list,
> with title “more development process failure”.
> 
>  
> 
> I feel the process mentioned in
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pro
> cess is not clear enough to follow, especially for the maintainer who is not
> full time working on EDKII.
> 
>  
> 
> I wish we can have this opportunity to revisit the “Follow the EDK II
> development
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Pr
> ocess> process” and make “the process” simpler and clearer.
> 
>  
> 
> Then all maintainers can sign to follow one rule. The rule we define and the
> rule we agree with.
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
>  
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of Soumya
> Guptha
> Sent: Saturday, September 26, 2020 6:35 AM
> To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> devel@edk2.groups.io <mailto:devel@edk2.groups.io> 
> Subject: [edk2-devel] Tianocore community page on who we are - please review
> 
>  
> 
> Dear Community members, 
> 
>  
> 
> I have drafted a document “who we are”, explaining Tianocore community
> structure, members of the community, their role and the current development
> process. I have drafted this document with the help of the Tianocore
> Stewards. 
> 
> We view this as a living document, as our development processes evolve, I
> will keep this document updated. 
> 
>  
> 
> Please review the draft version of the document (link below) and provide
> your feedback. Please send it to me, no need to reply all.
> 
> I appreciate your input by Friday, Oct 2. After this, I plan on make it live
> on our TianoCore wiki site. 
> 
>  
> 
> Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> 
>  
> 
> Thanks,
> 
> Soumya
> 
>  
> 
> Soumya Guptha
> TianoCore Community Manager
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Soumya Guptha]

Jiewen,
Good point on the release maintainer definition - we need to add this. 
Yes I think we need to add those guidelines for maintainer. 
(Please keep in mind to separate the role vs process, process will stay in maintainers process document and we link to it.
Please hash out contributor role. 

Leif, thanks for your feedback. 

Jiewen, you should have access to update the document. Can you please add your changes and the rest of us can review and comment? 

Thanks,
Soumya

-----Original Message-----
From: Leif Lindholm <leif@nuviainc.com> 
Sent: Monday, September 28, 2020 4:57 AM
To: devel@edk2.groups.io; gaoliming@byosoft.com.cn
Cc: Yao, Jiewen <jiewen.yao@intel.com>; Guptha, Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io; lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish' <afish@apple.com>
Subject: Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

Hi Liming,

On Sun, Sep 27, 2020 at 10:32:55 +0800, gaoliming wrote:
> Jiewen:
> 
>  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> Maintainer takes role 1~7. If the people know edk2 process well, they 
> mostly know edk2 one or more packages (modules). So, they can take Maintainer role.
> If the people only focus on the technical review, they can take 
> reviewer role. I would suggest there is at lease one Maintainer for each package.
> There are more reviewers for each package.
> 
> Soumya:
> 
>  Here are my comments. 
> 
>   Guidelines for a Maintainer. Never let a pending request get older 
> than a calendar week. This requirement is too strict to the maintainer or reviewer.
> The maintainer or reviewer should try to give the response in one 
> week. But, they may not fully review one patch set in one week, es for 
> the feature or the complex change.

My take on this is as follows (speaking as someone who has failed this rule many times):
This document is a guideline.

In some cases we are not yet in a position to be more timely about this.
That's where we need more reviewers to help out. Whether they are official designated reviewers or not. If some parts of the codebase always take long time to get review feedback for, that is a sign of a problem that needs to be addressed.

I agree that for a very invasive change, we may not be able to give a detailed reply early on. But in those cases, we should convey that feedback *very* early on.

> Role of a Contributor/developer. We need to highlight the role & 
> responsibility for the incompatible change. If the contributor 
> proposes the incompatible change, he needs to coordinate with the 
> impacted platform maintainer and make the agreement who will follow up 
> to update the impacted platforms before he requests to merge his patch 
> set. The impacted platforms include all ones in Edk2 and Edk2Platforms.

This is a good point. The details may need more discussion.

> Last, this page also needs to include release maintainer Definition 
> and Role. The release maintainer is to create the quarterly stable 
> tag. He takes the role to collect the feature planning for each stable 
> tag, schedule the release date, and create the stable tag with the release notes on tag page.
> He will also send the announcement of soft feature freeze, hard 
> feature freeze and the stable tag completement to edk2 community.

This is also a good point.

Best Regards,

Leif

> Thanks
> 
> Liming
> 
> 发件人: bounce+27952+65655+4905953+8761045@groups.io
> <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
> 发送时间: 2020年9月26日 13:33
> 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha, 
> Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> 主题: Re: [edk2-devel] Tianocore community page on who we are - please 
> review
> 
>  
> 
> Some other thought is about maintainer’s role definition:
> 
>  
> 
> The role of a maintainer is to:
> 
> 1.	Maintainer assignments to packages and source file name patterns are
> provided in the "
> <https://github.com/tianocore/edk2/blob/master/Maintainers.txt> Maintainers.
> txt" file.
> 2.	Subscribe to the "edk2-bugs" mailing list
> <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which 
> propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/> 
> https://bugzilla.tianocore.org/ actions via email. Keep a close eye on 
> new issues reported for their assigned packages. Participate in 
> triaging and analyzing bugs filed for their assigned packages.
> 3.	Responsible for reviewing patches and answering questions from
> contributors, on the edk2-devel mailing list 
> <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> 4.	Responsible for coordinating patch review with co-maintainers and
> reviewers of the same package.
> 5.	Has push / merge access to the merge branch.
> 6.	Responsible for merging approved patches into the master branch.
> 7.	Follow the EDK II development
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developm
> ent-Pr
> ocess> process.
> 
>  
> 
> IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
> 
> Logically, the can be two separated roles and be done by two different 
> persons.
> 
> A people who has strong technical expertise might NOT be the best 
> person to do the integration, and vice versa. I hope we can let right 
> person do right thing in right way.
> 
> For example, to avoid mistake during check in, 5~7 can be done by a 
> role named “integrator”.
> 
>  
> 
> My dream is that check-in process is just one click button. But it 
> seems we are still far from it…
> 
>  
> 
> My two cents.
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> 
> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of 
> Yao, Jiewen
> Sent: Saturday, September 26, 2020 1:09 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha, 
> Soumya K <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com> 
> >; announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> Subject: Re: [edk2-devel] Tianocore community page on who we are - 
> please review
> 
>  
> 
> Thanks Soumya. I think this is a good start.
> 
>  
> 
> Recently we are discussing the maintainer’s work in EDKII mailing 
> list, with title “more development process failure”.
> 
>  
> 
> I feel the process mentioned in
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developme
> nt-Pro cess is not clear enough to follow, especially for the 
> maintainer who is not full time working on EDKII.
> 
>  
> 
> I wish we can have this opportunity to revisit the “Follow the EDK II 
> development 
> <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developm
> ent-Pr
> ocess> process” and make “the process” simpler and clearer.
> 
>  
> 
> Then all maintainers can sign to follow one rule. The rule we define 
> and the rule we agree with.
> 
>  
> 
> Thank you
> 
> Yao Jiewen
> 
>  
> 
>  
> 
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> 
> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of 
> Soumya Guptha
> Sent: Saturday, September 26, 2020 6:35 AM
> To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ; 
> devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Subject: [edk2-devel] Tianocore community page on who we are - please 
> review
> 
>  
> 
> Dear Community members,
> 
>  
> 
> I have drafted a document “who we are”, explaining Tianocore community 
> structure, members of the community, their role and the current 
> development process. I have drafted this document with the help of the 
> Tianocore Stewards.
> 
> We view this as a living document, as our development processes 
> evolve, I will keep this document updated.
> 
>  
> 
> Please review the draft version of the document (link below) and 
> provide your feedback. Please send it to me, no need to reply all.
> 
> I appreciate your input by Friday, Oct 2. After this, I plan on make 
> it live on our TianoCore wiki site.
> 
>  
> 
> Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> 
>  
> 
> Thanks,
> 
> Soumya
> 
>  
> 
> Soumya Guptha
> TianoCore Community Manager
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 

回复: 回复: [edk2-devel] Tianocore community page on who we are - please review

[gaoliming]

Soumya:
  Do you mean to directly modify wiki page? Or, send the update content as the patch for your integration? 

Thanks
Liming
> -----邮件原件-----
> 发件人: Guptha, Soumya K <soumya.k.guptha@intel.com>
> 发送时间: 2020年9月29日 0:20
> 收件人: Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io;
> gaoliming@byosoft.com.cn
> 抄送: Yao, Jiewen <jiewen.yao@intel.com>; announce@edk2.groups.io;
> lersek@redhat.com; Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew
> Fish' <afish@apple.com>
> 主题: RE: 回复: [edk2-devel] Tianocore community page on who we are - please
> review
> 
> Jiewen,
> Good point on the release maintainer definition - we need to add this.
> Yes I think we need to add those guidelines for maintainer.
> (Please keep in mind to separate the role vs process, process will stay in
> maintainers process document and we link to it.
> Please hash out contributor role.
> 
> Leif, thanks for your feedback.
> 
> Jiewen, you should have access to update the document. Can you please add
> your changes and the rest of us can review and comment?
> 
> Thanks,
> Soumya
> 
> -----Original Message-----
> From: Leif Lindholm <leif@nuviainc.com>
> Sent: Monday, September 28, 2020 4:57 AM
> To: devel@edk2.groups.io; gaoliming@byosoft.com.cn
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Guptha, Soumya K
> <soumya.k.guptha@intel.com>; announce@edk2.groups.io; lersek@redhat.com;
> Kinney, Michael D <michael.d.kinney@intel.com>; 'Andrew Fish'
> <afish@apple.com>
> Subject: Re: 回复: [edk2-devel] Tianocore community page on who we are -
> please review
> 
> Hi Liming,
> 
> On Sun, Sep 27, 2020 at 10:32:55 +0800, gaoliming wrote:
> > Jiewen:
> >
> >  Now, we have reviewer and maintainer role. Reviewer takes role 1~4.
> > Maintainer takes role 1~7. If the people know edk2 process well, they
> > mostly know edk2 one or more packages (modules). So, they can take
> Maintainer role.
> > If the people only focus on the technical review, they can take
> > reviewer role. I would suggest there is at lease one Maintainer for each package.
> > There are more reviewers for each package.
> >
> > Soumya:
> >
> >  Here are my comments.
> >
> >   Guidelines for a Maintainer. Never let a pending request get older
> > than a calendar week. This requirement is too strict to the maintainer or
> reviewer.
> > The maintainer or reviewer should try to give the response in one
> > week. But, they may not fully review one patch set in one week, es for
> > the feature or the complex change.
> 
> My take on this is as follows (speaking as someone who has failed this rule many
> times):
> This document is a guideline.
> 
> In some cases we are not yet in a position to be more timely about this.
> That's where we need more reviewers to help out. Whether they are official
> designated reviewers or not. If some parts of the codebase always take long time
> to get review feedback for, that is a sign of a problem that needs to be addressed.
> 
> I agree that for a very invasive change, we may not be able to give a detailed reply
> early on. But in those cases, we should convey that feedback *very* early on.
> 
> > Role of a Contributor/developer. We need to highlight the role &
> > responsibility for the incompatible change. If the contributor
> > proposes the incompatible change, he needs to coordinate with the
> > impacted platform maintainer and make the agreement who will follow up
> > to update the impacted platforms before he requests to merge his patch
> > set. The impacted platforms include all ones in Edk2 and Edk2Platforms.
> 
> This is a good point. The details may need more discussion.
> 
> > Last, this page also needs to include release maintainer Definition
> > and Role. The release maintainer is to create the quarterly stable
> > tag. He takes the role to collect the feature planning for each stable
> > tag, schedule the release date, and create the stable tag with the release notes
> on tag page.
> > He will also send the announcement of soft feature freeze, hard
> > feature freeze and the stable tag completement to edk2 community.
> 
> This is also a good point.
> 
> Best Regards,
> 
> Leif
> 
> > Thanks
> >
> > Liming
> >
> > 发件人: bounce+27952+65655+4905953+8761045@groups.io
> > <bounce+27952+65655+4905953+8761045@groups.io> 代表 Yao, Jiewen
> > 发送时间: 2020年9月26日 13:33
> > 收件人: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Guptha,
> > Soumya K <soumya.k.guptha@intel.com>; announce@edk2.groups.io
> > 主题: Re: [edk2-devel] Tianocore community page on who we are - please
> > review
> >
> >
> >
> > Some other thought is about maintainer’s role definition:
> >
> >
> >
> > The role of a maintainer is to:
> >
> > 1.	Maintainer assignments to packages and source file name patterns are
> > provided in the "
> > <https://github.com/tianocore/edk2/blob/master/Maintainers.txt>
> Maintainers.
> > txt" file.
> > 2.	Subscribe to the "edk2-bugs" mailing list
> > <https://edk2.groups.io/g/bugs> https://edk2.groups.io/g/bugs, which
> > propagates TianoCore Bugzilla  <https://bugzilla.tianocore.org/>
> > https://bugzilla.tianocore.org/ actions via email. Keep a close eye on
> > new issues reported for their assigned packages. Participate in
> > triaging and analyzing bugs filed for their assigned packages.
> > 3.	Responsible for reviewing patches and answering questions from
> > contributors, on the edk2-devel mailing list
> > <https://edk2.groups.io/g/devel/> https://edk2.groups.io/g/devel/.
> > 4.	Responsible for coordinating patch review with co-maintainers and
> > reviewers of the same package.
> > 5.	Has push / merge access to the merge branch.
> > 6.	Responsible for merging approved patches into the master branch.
> > 7.	Follow the EDK II development
> > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developm
> > ent-Pr
> > ocess> process.
> >
> >
> >
> > IMHO, the 1~4 need technical expertise, while 5~7 need process expertise.
> >
> > Logically, the can be two separated roles and be done by two different
> > persons.
> >
> > A people who has strong technical expertise might NOT be the best
> > person to do the integration, and vice versa. I hope we can let right
> > person do right thing in right way.
> >
> > For example, to avoid mistake during check in, 5~7 can be done by a
> > role named “integrator”.
> >
> >
> >
> > My dream is that check-in process is just one click button. But it
> > seems we are still far from it…
> >
> >
> >
> > My two cents.
> >
> >
> >
> > Thank you
> >
> > Yao Jiewen
> >
> >
> >
> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> > Yao, Jiewen
> > Sent: Saturday, September 26, 2020 1:09 PM
> > To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; Guptha,
> > Soumya K <soumya.k.guptha@intel.com <mailto:soumya.k.guptha@intel.com>
> > >; announce@edk2.groups.io <mailto:announce@edk2.groups.io>
> > Subject: Re: [edk2-devel] Tianocore community page on who we are -
> > please review
> >
> >
> >
> > Thanks Soumya. I think this is a good start.
> >
> >
> >
> > Recently we are discussing the maintainer’s work in EDKII mailing
> > list, with title “more development process failure”.
> >
> >
> >
> > I feel the process mentioned in
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developme
> > nt-Pro cess is not clear enough to follow, especially for the
> > maintainer who is not full time working on EDKII.
> >
> >
> >
> > I wish we can have this opportunity to revisit the “Follow the EDK II
> > development
> > <https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Developm
> > ent-Pr
> > ocess> process” and make “the process” simpler and clearer.
> >
> >
> >
> > Then all maintainers can sign to follow one rule. The rule we define
> > and the rule we agree with.
> >
> >
> >
> > Thank you
> >
> > Yao Jiewen
> >
> >
> >
> >
> >
> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io> > On Behalf Of
> > Soumya Guptha
> > Sent: Saturday, September 26, 2020 6:35 AM
> > To: announce@edk2.groups.io <mailto:announce@edk2.groups.io> ;
> > devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > Subject: [edk2-devel] Tianocore community page on who we are - please
> > review
> >
> >
> >
> > Dear Community members,
> >
> >
> >
> > I have drafted a document “who we are”, explaining Tianocore community
> > structure, members of the community, their role and the current
> > development process. I have drafted this document with the help of the
> > Tianocore Stewards.
> >
> > We view this as a living document, as our development processes
> > evolve, I will keep this document updated.
> >
> >
> >
> > Please review the draft version of the document (link below) and
> > provide your feedback. Please send it to me, no need to reply all.
> >
> > I appreciate your input by Friday, Oct 2. After this, I plan on make
> > it live on our TianoCore wiki site.
> >
> >
> >
> > Link: https://github.com/tianocore/tianocore.github.io/wiki/Who-we-are
> >
> >
> >
> > Thanks,
> >
> > Soumya
> >
> >
> >
> > Soumya Guptha
> > TianoCore Community Manager
> >
> >
> >
> >
> >
> >
> >
> > 
> >
> >

Re: 回复: [edk2-devel] Tianocore community page on who we are - please review

[Laszlo Ersek]

Hi Liming,

On 09/27/20 04:32, gaoliming wrote:

>   Guidelines for a Maintainer. Never let a pending request get older than a
> calendar week. This requirement is too strict to the maintainer or reviewer.
> The maintainer or reviewer should try to give the response in one week. But,
> they may not fully review one patch set in one week, es for the feature or
> the complex change. 

This requirement is about providing initial feedback. In other words,
about starting the review.

It's very important to provide initial feedback within a week.

I agree that more time than a week may be necessary for finishing /
completing a review.

"Letting a pending request get older than a week" means that there is
zero response within a week. If there is some response (albeit possibly
incomplete), then things are good.

Thanks
Laszlo

回复: 回复: [edk2-devel] Tianocore community page on who we are - please review

[gaoliming]

Laszlo:
  I agree this point. The guideline is to collect the feedback in one week,
not the deadline to finish the code review. 

Thanks
Liming
> -----邮件原件-----
> 发件人: Laszlo Ersek <lersek@redhat.com>
> 发送时间: 2020年9月29日 1:15
> 收件人: gaoliming <gaoliming@byosoft.com.cn>; devel@edk2.groups.io;
> jiewen.yao@intel.com; 'Guptha, Soumya K' <soumya.k.guptha@intel.com>;
> announce@edk2.groups.io
> 抄送: 'Leif Lindholm (Nuvia address)' <leif@nuviainc.com>; 'Kinney,
Michael D'
> <michael.d.kinney@intel.com>; 'Andrew Fish' <afish@apple.com>
> 主题: Re: 回复: [edk2-devel] Tianocore community page on who we are -
please
> review
> 
> Hi Liming,
> 
> On 09/27/20 04:32, gaoliming wrote:
> 
> >   Guidelines for a Maintainer. Never let a pending request get older
than a
> > calendar week. This requirement is too strict to the maintainer or
reviewer.
> > The maintainer or reviewer should try to give the response in one week.
But,
> > they may not fully review one patch set in one week, es for the feature
or
> > the complex change.
> 
> This requirement is about providing initial feedback. In other words,
> about starting the review.
> 
> It's very important to provide initial feedback within a week.
> 
> I agree that more time than a week may be necessary for finishing /
> completing a review.
> 
> "Letting a pending request get older than a week" means that there is
> zero response within a week. If there is some response (albeit possibly
> incomplete), then things are good.
> 
> Thanks
> Laszlo