* [PATCH v3 0/1] update MAINTAINERS file with git trailers @ 2023-06-28 12:42 Bruno Larsen 2023-06-28 12:42 ` [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS Bruno Larsen 0 siblings, 1 reply; 7+ messages in thread From: Bruno Larsen @ 2023-06-28 12:42 UTC (permalink / raw) To: gdb-patches Cc: pedro, aburgess, kevinb, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz, Bruno Larsen Some private chats highlighted that the currently in use git trailers aren't explained well enough. This patch aims to fix that by adding the information in a more verbose way to guarantee that everyone is on the same page about them and refine anything that might still need work. The first (and second) version of this update didn't get much traction, so I decided to add every active global maintainer as CC, since everyone is affected by this and I want some consensus before comitting. Right now there is one big unanswered question: Should we have a specific tag to explicitly signal when a patch has been partially approved? Eli asked for it to avoid people mechanically reading tags from thinking that a patch has been fully approved when it was only partial. If we agree that there should be one, what would it look like? I suggested using Acked-By, but Simon uses it differently, and I opted to keep his usage of it. Thoughts? Comments? Suggestions? Bruno Larsen (1): [gdb]: add git trailer information on gdb/MAINTAINERS gdb/MAINTAINERS | 66 +++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 58 insertions(+), 8 deletions(-) -- 2.41.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS 2023-06-28 12:42 [PATCH v3 0/1] update MAINTAINERS file with git trailers Bruno Larsen @ 2023-06-28 12:42 ` Bruno Larsen 2023-06-30 21:07 ` Kevin Buettner 2023-07-03 16:25 ` Andrew Burgess 0 siblings, 2 replies; 7+ messages in thread From: Bruno Larsen @ 2023-06-28 12:42 UTC (permalink / raw) To: gdb-patches Cc: pedro, aburgess, kevinb, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz, Bruno Larsen The project has been using Tested-By (tb), Reviewed-By (rb) and Approved-By (ab) for some time, but there has been no information to be found in the actual repository. This commit changes that by adding information about all git trailers to the MAINTAINERS file, so that it can be easily double-checked. The upstream discussion also brought up the use of Acked-by, which is better defined in this commit. Finally, for completeness sake, the trailers Co-Authored-By and Bug were added, even though they have been in use for some time already --- gdb/MAINTAINERS | 66 +++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 58 insertions(+), 8 deletions(-) diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS index 7fa608fd82c..cd9d299ea42 100644 --- a/gdb/MAINTAINERS +++ b/gdb/MAINTAINERS @@ -43,14 +43,9 @@ patch without review from another maintainer. This especially includes patches which change internal interfaces (e.g. global functions, data structures) or external interfaces (e.g. user, remote, MI, et cetera). -The term "review" is used in this file to describe several kinds of feedback -from a maintainer: approval, rejection, and requests for changes or -clarification with the intention of approving a revised version. Review is -a privilege and/or responsibility of various positions among the GDB -Maintainers. Of course, anyone - whether they hold a position but not the -relevant one for a particular patch, or are just following along on the -mailing lists for fun, or anything in between - may suggest changes or -ask questions about a patch! +The word "contributor" is used in this document to refer to any GDB +developer listed above as well as folks who may have suggested some +patches but aren't part of one of those categories for any reason. There's also a couple of other people who play special roles in the GDB community, separately from the patch process: @@ -78,6 +73,61 @@ consensus among the global maintainers and any other involved parties. In cases where consensus can not be reached, the global maintainers may ask the official FSF-appointed GDB maintainers for a final decision. +The term "review" is used in this file to describe several kinds of +feedback from a maintainer: approval, rejection, and requests for changes +or clarification with the intention of approving a revised version. +Approval is a privilege and/or responsibility of various positions among +the GDB Maintainers. Of course, anyone - whether they hold a position, but +not the relevant one for a particular patch, or are just following along on +the mailing lists for fun, or anything in between - may suggest changes, ask +questions about a patch or say if they believe a patch is fit for upstreaming! + +To ensure that patches are only pushed when approved, and to properly credit +the contributors who take the time to improve this project, the following +trailers are used to identify who contributed and how. All patches pushed +upstream should have at least one Approved-By patches (with the exception of +obvious patches, see below). The trailers (or tags) currently in use are: + + - Acked-By: + + Used when a contributor has taken a quick glance at a patch and agrees + with the direction outlined in the commit message, but hasn't evaluated + the code for correctness or regressions. + + - Tested-by: + + Used when a contributor has tested the patch and finds that it + fixes the claimed problem. It may also be used to indicate that + the contributor has performed regression testing. By itself, this + tag says nothing about the quality of the fix implemented by the + patch. + + - Reviewed-by: + + Used when a contributor has looked at code and agrees with the + changes, but either doesn't have the authority or doesn't feel + comfortable approving the patch. + + - Approved-by: + + Used by responsible maintainers or global maintainers when a patch is + ready to be upstreamed. Some patches may touch multiple areas and + require multiple approvals before landing (such as a maintainer only + approving documentation), it is up to the maintainer giving the approval + tag to make it clear when that a tag is not sufficient. Responsible, + Global and Official FSF-appointed maintainers may approve their own + patches, but it is recommended that they seek external approval before + doing so. + + - Co-Authored-By: + + Used when the commit includes meaningful conrtibutions from multiple people. + + - Bug: + + This trailer is added with a link to the GDB bug tracker for added context + on relevant commits. + The Obvious Fix Rule -------------------- -- 2.41.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS 2023-06-28 12:42 ` [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS Bruno Larsen @ 2023-06-30 21:07 ` Kevin Buettner 2023-07-03 8:36 ` Bruno Larsen 2023-07-03 16:25 ` Andrew Burgess 1 sibling, 1 reply; 7+ messages in thread From: Kevin Buettner @ 2023-06-30 21:07 UTC (permalink / raw) To: Bruno Larsen Cc: gdb-patches, pedro, aburgess, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz Hi, See my comments in-line below. Kevin On Wed, 28 Jun 2023 14:42:06 +0200 Bruno Larsen <blarsen@redhat.com> wrote: > The project has been using Tested-By (tb), Reviewed-By (rb) and > Approved-By (ab) for some time, but there has been no information to be > found in the actual repository. This commit changes that by adding > information about all git trailers to the MAINTAINERS file, so that it > can be easily double-checked. > > The upstream discussion also brought up the use of Acked-by, which is > better defined in this commit. Finally, for completeness sake, the > trailers Co-Authored-By and Bug were added, even though they have been > in use for some time already > --- > gdb/MAINTAINERS | 66 +++++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 58 insertions(+), 8 deletions(-) > > diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS > index 7fa608fd82c..cd9d299ea42 100644 > --- a/gdb/MAINTAINERS > +++ b/gdb/MAINTAINERS > @@ -43,14 +43,9 @@ patch without review from another maintainer. This especially includes > patches which change internal interfaces (e.g. global functions, data > structures) or external interfaces (e.g. user, remote, MI, et cetera). > > -The term "review" is used in this file to describe several kinds of feedback > -from a maintainer: approval, rejection, and requests for changes or > -clarification with the intention of approving a revised version. Review is > -a privilege and/or responsibility of various positions among the GDB > -Maintainers. Of course, anyone - whether they hold a position but not the > -relevant one for a particular patch, or are just following along on the > -mailing lists for fun, or anything in between - may suggest changes or > -ask questions about a patch! > +The word "contributor" is used in this document to refer to any GDB > +developer listed above as well as folks who may have suggested some > +patches but aren't part of one of those categories for any reason. > > There's also a couple of other people who play special roles in the GDB > community, separately from the patch process: > @@ -78,6 +73,61 @@ consensus among the global maintainers and any other involved parties. > In cases where consensus can not be reached, the global maintainers may > ask the official FSF-appointed GDB maintainers for a final decision. > > +The term "review" is used in this file to describe several kinds of > +feedback from a maintainer: approval, rejection, and requests for changes > +or clarification with the intention of approving a revised version. > +Approval is a privilege and/or responsibility of various positions among > +the GDB Maintainers. Of course, anyone - whether they hold a position, but > +not the relevant one for a particular patch, or are just following along on > +the mailing lists for fun, or anything in between - may suggest changes, ask > +questions about a patch or say if they believe a patch is fit for upstreaming! > + > +To ensure that patches are only pushed when approved, and to properly credit > +the contributors who take the time to improve this project, the following > +trailers are used to identify who contributed and how. All patches pushed > +upstream should have at least one Approved-By patches (with the exception of > +obvious patches, see below). The trailers (or tags) currently in use are: > + > + - Acked-By: > + > + Used when a contributor has taken a quick glance at a patch and agrees > + with the direction outlined in the commit message, but hasn't evaluated > + the code for correctness or regressions. > + > + - Tested-by: > + > + Used when a contributor has tested the patch and finds that it > + fixes the claimed problem. It may also be used to indicate that > + the contributor has performed regression testing. By itself, this > + tag says nothing about the quality of the fix implemented by the > + patch. > + > + - Reviewed-by: > + > + Used when a contributor has looked at code and agrees with the s/code/the code/ > + changes, but either doesn't have the authority or doesn't feel > + comfortable approving the patch. > + > + - Approved-by: > + > + Used by responsible maintainers or global maintainers when a patch is > + ready to be upstreamed. Some patches may touch multiple areas and > + require multiple approvals before landing (such as a maintainer only > + approving documentation), it is up to the maintainer giving the approval > + tag to make it clear when that a tag is not sufficient. Responsible, > + Global and Official FSF-appointed maintainers may approve their own > + patches, but it is recommended that they seek external approval before > + doing so. > + > + - Co-Authored-By: > + > + Used when the commit includes meaningful conrtibutions from multiple people. For all of the above trailers/tags, I think it's worth mentioning what should follow the ":". As I understand it, the name and email address should be specified - like this: Approved-by: Jane Doe <jane@doe.org> > + > + - Bug: > + > + This trailer is added with a link to the GDB bug tracker for added context Maybe s/GDB bug tracker/GDB bug tracker bug/ ? I.e. we want to specify a link to a specific bug, not a link to the top level for the bug tracking site. > + on relevant commits. > + > > The Obvious Fix Rule > -------------------- > -- > 2.41.0 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS 2023-06-30 21:07 ` Kevin Buettner @ 2023-07-03 8:36 ` Bruno Larsen 0 siblings, 0 replies; 7+ messages in thread From: Bruno Larsen @ 2023-07-03 8:36 UTC (permalink / raw) To: Kevin Buettner Cc: gdb-patches, pedro, aburgess, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz On 30/06/2023 23:07, Kevin Buettner wrote: > Hi, > > See my comments in-line below. > > Kevin > > On Wed, 28 Jun 2023 14:42:06 +0200 > Bruno Larsen <blarsen@redhat.com> wrote: > >> The project has been using Tested-By (tb), Reviewed-By (rb) and >> Approved-By (ab) for some time, but there has been no information to be >> found in the actual repository. This commit changes that by adding >> information about all git trailers to the MAINTAINERS file, so that it >> can be easily double-checked. >> >> The upstream discussion also brought up the use of Acked-by, which is >> better defined in this commit. Finally, for completeness sake, the >> trailers Co-Authored-By and Bug were added, even though they have been >> in use for some time already >> --- >> gdb/MAINTAINERS | 66 +++++++++++++++++++++++++++++++++++++++++++------ >> 1 file changed, 58 insertions(+), 8 deletions(-) >> >> diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS >> index 7fa608fd82c..cd9d299ea42 100644 >> --- a/gdb/MAINTAINERS >> +++ b/gdb/MAINTAINERS >> @@ -43,14 +43,9 @@ patch without review from another maintainer. This especially includes >> patches which change internal interfaces (e.g. global functions, data >> structures) or external interfaces (e.g. user, remote, MI, et cetera). >> >> -The term "review" is used in this file to describe several kinds of feedback >> -from a maintainer: approval, rejection, and requests for changes or >> -clarification with the intention of approving a revised version. Review is >> -a privilege and/or responsibility of various positions among the GDB >> -Maintainers. Of course, anyone - whether they hold a position but not the >> -relevant one for a particular patch, or are just following along on the >> -mailing lists for fun, or anything in between - may suggest changes or >> -ask questions about a patch! >> +The word "contributor" is used in this document to refer to any GDB >> +developer listed above as well as folks who may have suggested some >> +patches but aren't part of one of those categories for any reason. >> >> There's also a couple of other people who play special roles in the GDB >> community, separately from the patch process: >> @@ -78,6 +73,61 @@ consensus among the global maintainers and any other involved parties. >> In cases where consensus can not be reached, the global maintainers may >> ask the official FSF-appointed GDB maintainers for a final decision. >> >> +The term "review" is used in this file to describe several kinds of >> +feedback from a maintainer: approval, rejection, and requests for changes >> +or clarification with the intention of approving a revised version. >> +Approval is a privilege and/or responsibility of various positions among >> +the GDB Maintainers. Of course, anyone - whether they hold a position, but >> +not the relevant one for a particular patch, or are just following along on >> +the mailing lists for fun, or anything in between - may suggest changes, ask >> +questions about a patch or say if they believe a patch is fit for upstreaming! >> + >> +To ensure that patches are only pushed when approved, and to properly credit >> +the contributors who take the time to improve this project, the following >> +trailers are used to identify who contributed and how. All patches pushed >> +upstream should have at least one Approved-By patches (with the exception of >> +obvious patches, see below). The trailers (or tags) currently in use are: >> + >> + - Acked-By: >> + >> + Used when a contributor has taken a quick glance at a patch and agrees >> + with the direction outlined in the commit message, but hasn't evaluated >> + the code for correctness or regressions. >> + >> + - Tested-by: >> + >> + Used when a contributor has tested the patch and finds that it >> + fixes the claimed problem. It may also be used to indicate that >> + the contributor has performed regression testing. By itself, this >> + tag says nothing about the quality of the fix implemented by the >> + patch. >> + >> + - Reviewed-by: >> + >> + Used when a contributor has looked at code and agrees with the > s/code/the code/ fixed > >> + changes, but either doesn't have the authority or doesn't feel >> + comfortable approving the patch. >> + >> + - Approved-by: >> + >> + Used by responsible maintainers or global maintainers when a patch is >> + ready to be upstreamed. Some patches may touch multiple areas and >> + require multiple approvals before landing (such as a maintainer only >> + approving documentation), it is up to the maintainer giving the approval >> + tag to make it clear when that a tag is not sufficient. Responsible, >> + Global and Official FSF-appointed maintainers may approve their own >> + patches, but it is recommended that they seek external approval before >> + doing so. >> + >> + - Co-Authored-By: >> + >> + Used when the commit includes meaningful conrtibutions from multiple people. > For all of the above trailers/tags, I think it's worth mentioning what should follow > the ":". As I understand it, the name and email address should be specified - like > this: > > Approved-by: Jane Doe <jane@doe.org> That's a good point. I added a section saying Usage: "Approved-By: Your Name <your@email>" not sure if that is the best way to do it, though... > >> + >> + - Bug: >> + >> + This trailer is added with a link to the GDB bug tracker for added context > Maybe s/GDB bug tracker/GDB bug tracker bug/ ? I.e. we want to specify a link > to a specific bug, not a link to the top level for the bug tracking site. good point, I changed it > >> + on relevant commits. >> + >> >> The Obvious Fix Rule >> -------------------- >> -- >> 2.41.0 >> -- Cheers, Bruno ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS 2023-06-28 12:42 ` [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS Bruno Larsen 2023-06-30 21:07 ` Kevin Buettner @ 2023-07-03 16:25 ` Andrew Burgess 2023-07-04 15:08 ` Bruno Larsen 1 sibling, 1 reply; 7+ messages in thread From: Andrew Burgess @ 2023-07-03 16:25 UTC (permalink / raw) To: Bruno Larsen, gdb-patches Cc: pedro, kevinb, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz, Bruno Larsen Bruno Larsen <blarsen@redhat.com> writes: > The project has been using Tested-By (tb), Reviewed-By (rb) and > Approved-By (ab) for some time, but there has been no information to be > found in the actual repository. This commit changes that by adding > information about all git trailers to the MAINTAINERS file, so that it > can be easily double-checked. > > The upstream discussion also brought up the use of Acked-by, which is > better defined in this commit. Finally, for completeness sake, the > trailers Co-Authored-By and Bug were added, even though they have been > in use for some time already > --- > gdb/MAINTAINERS | 66 +++++++++++++++++++++++++++++++++++++++++++------ > 1 file changed, 58 insertions(+), 8 deletions(-) > > diff --git a/gdb/MAINTAINERS b/gdb/MAINTAINERS > index 7fa608fd82c..cd9d299ea42 100644 > --- a/gdb/MAINTAINERS > +++ b/gdb/MAINTAINERS > @@ -43,14 +43,9 @@ patch without review from another maintainer. This especially includes > patches which change internal interfaces (e.g. global functions, data > structures) or external interfaces (e.g. user, remote, MI, et cetera). > > -The term "review" is used in this file to describe several kinds of feedback > -from a maintainer: approval, rejection, and requests for changes or > -clarification with the intention of approving a revised version. Review is > -a privilege and/or responsibility of various positions among the GDB > -Maintainers. Of course, anyone - whether they hold a position but not the > -relevant one for a particular patch, or are just following along on the > -mailing lists for fun, or anything in between - may suggest changes or > -ask questions about a patch! > +The word "contributor" is used in this document to refer to any GDB > +developer listed above as well as folks who may have suggested some > +patches but aren't part of one of those categories for any reason. > > There's also a couple of other people who play special roles in the GDB > community, separately from the patch process: > @@ -78,6 +73,61 @@ consensus among the global maintainers and any other involved parties. > In cases where consensus can not be reached, the global maintainers may > ask the official FSF-appointed GDB maintainers for a final decision. > > +The term "review" is used in this file to describe several kinds of > +feedback from a maintainer: approval, rejection, and requests for changes > +or clarification with the intention of approving a revised version. > +Approval is a privilege and/or responsibility of various positions among > +the GDB Maintainers. Of course, anyone - whether they hold a position, but > +not the relevant one for a particular patch, or are just following along on > +the mailing lists for fun, or anything in between - may suggest changes, ask > +questions about a patch or say if they believe a patch is fit for upstreaming! > + > +To ensure that patches are only pushed when approved, and to properly credit > +the contributors who take the time to improve this project, the following > +trailers are used to identify who contributed and how. All patches pushed > +upstream should have at least one Approved-By patches (with the exception of > +obvious patches, see below). The trailers (or tags) currently in use are: > + > + - Acked-By: > + > + Used when a contributor has taken a quick glance at a patch and agrees > + with the direction outlined in the commit message, but hasn't evaluated > + the code for correctness or regressions. > + > + - Tested-by: > + > + Used when a contributor has tested the patch and finds that it > + fixes the claimed problem. It may also be used to indicate that > + the contributor has performed regression testing. By itself, this > + tag says nothing about the quality of the fix implemented by the > + patch. Given the number of different ways that tests can be run, and that you specifically say "It _may_ also be used to indicate ...", I wonder if it's worth extending the last sentence to specifically say: By itself, this tag says nothing about the quality of the fix implemented by the patch, nor the amount of testing that was actually performed. Some people might give a (tb) tag just for running the tests added by the commit in question, while others might run the full testsuite on a unix board, while others might do a full regression test using multiple different boards. The tag itself tells us very little really. Thanks, Andrew > + > + - Reviewed-by: > + > + Used when a contributor has looked at code and agrees with the > + changes, but either doesn't have the authority or doesn't feel > + comfortable approving the patch. > + > + - Approved-by: > + > + Used by responsible maintainers or global maintainers when a patch is > + ready to be upstreamed. Some patches may touch multiple areas and > + require multiple approvals before landing (such as a maintainer only > + approving documentation), it is up to the maintainer giving the approval > + tag to make it clear when that a tag is not sufficient. Responsible, > + Global and Official FSF-appointed maintainers may approve their own > + patches, but it is recommended that they seek external approval before > + doing so. > + > + - Co-Authored-By: > + > + Used when the commit includes meaningful conrtibutions from multiple people. > + > + - Bug: > + > + This trailer is added with a link to the GDB bug tracker for added context > + on relevant commits. > + > > The Obvious Fix Rule > -------------------- > -- > 2.41.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS 2023-07-03 16:25 ` Andrew Burgess @ 2023-07-04 15:08 ` Bruno Larsen 2023-07-06 1:46 ` Kevin Buettner 0 siblings, 1 reply; 7+ messages in thread From: Bruno Larsen @ 2023-07-04 15:08 UTC (permalink / raw) To: Andrew Burgess, gdb-patches Cc: pedro, kevinb, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz On 03/07/2023 18:25, Andrew Burgess wrote: >> + - Tested-by: >> + >> + Used when a contributor has tested the patch and finds that it >> + fixes the claimed problem. It may also be used to indicate that >> + the contributor has performed regression testing. By itself, this >> + tag says nothing about the quality of the fix implemented by the >> + patch. > Given the number of different ways that tests can be run, and that you > specifically say "It_may_ also be used to indicate ...", I wonder if > it's worth extending the last sentence to specifically say: > > By itself, this tag says nothing about the quality of the fix > implemented by the patch, nor the amount of testing that was actually > performed. > > Some people might give a (tb) tag just for running the tests added by > the commit in question, while others might run the full testsuite on a > unix board, while others might do a full regression test using multiple > different boards. The tag itself tells us very little really. > I'm not opposed to making this document somewhat prescriptive. If you think (and folks agree, of course) that as the tag is describe it tells us TOO little, we could instead require that people do some level of testing. My original idea would be that the person giving the tb tag would at least run a full run of the testsuite on the default board, but I changed it based on previous feedback. Or I can just add this change, whichever you prefer -- Cheers, Bruno ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS 2023-07-04 15:08 ` Bruno Larsen @ 2023-07-06 1:46 ` Kevin Buettner 0 siblings, 0 replies; 7+ messages in thread From: Kevin Buettner @ 2023-07-06 1:46 UTC (permalink / raw) To: Bruno Larsen Cc: gdb-patches, Andrew Burgess, pedro, brobecker, simon.marchi, tom, tdevries, ulrich.weigand, eliz On Tue, 4 Jul 2023 17:08:47 +0200 Bruno Larsen <blarsen@redhat.com> wrote: > On 03/07/2023 18:25, Andrew Burgess wrote: > >> + - Tested-by: > >> + > >> + Used when a contributor has tested the patch and finds that it > >> + fixes the claimed problem. It may also be used to indicate that > >> + the contributor has performed regression testing. By itself, this > >> + tag says nothing about the quality of the fix implemented by the > >> + patch. > > Given the number of different ways that tests can be run, and that you > > specifically say "It_may_ also be used to indicate ...", I wonder if > > it's worth extending the last sentence to specifically say: > > > > By itself, this tag says nothing about the quality of the fix > > implemented by the patch, nor the amount of testing that was actually > > performed. > > > > Some people might give a (tb) tag just for running the tests added by > > the commit in question, while others might run the full testsuite on a > > unix board, while others might do a full regression test using multiple > > different boards. The tag itself tells us very little really. > > > I'm not opposed to making this document somewhat prescriptive. If you > think (and folks agree, of course) that as the tag is describe it tells > us TOO little, we could instead require that people do some level of > testing. My original idea would be that the person giving the tb tag > would at least run a full run of the testsuite on the default board, but > I changed it based on previous feedback. Or I can just add this change, > whichever you prefer I'm fine with Andrew's proposed wording. For a patch which is supposed to fix a bug, I'm most appreciative of testing which checks that the patch actually fixes the bug, especially if it's for a platform which I don't have easy access to. I know I've proposed a patch in the past saying that this should fix some problem, but don't know that for sure until someone with access to that platform applies the patch and does some testing. As for regression testing, my understanding is that the patch contributor should do this for at least one platform. If a tester does regression testing for his or her favorite oddball platform, that's also very much appreciated. Kevin ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-07-06 1:47 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-28 12:42 [PATCH v3 0/1] update MAINTAINERS file with git trailers Bruno Larsen 2023-06-28 12:42 ` [PATCH v3 1/1] [gdb]: add git trailer information on gdb/MAINTAINERS Bruno Larsen 2023-06-30 21:07 ` Kevin Buettner 2023-07-03 8:36 ` Bruno Larsen 2023-07-03 16:25 ` Andrew Burgess 2023-07-04 15:08 ` Bruno Larsen 2023-07-06 1:46 ` Kevin Buettner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).