Message ID | 20240524-b4-support-v1-1-0c4334c36cc7@cherry.de |
---|---|
State | New |
Headers | show |
Series | add basic b4 config file | expand |
On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: > > From: Quentin Schulz <quentin.schulz@cherry.de> > > b4[1] is a very nice tool for mail-based contribution. A config[2] file > exists to set up a few defaults. We can use it to set the Cc recipients > to always add, in our case the mailing list. > > This shouldn't be necessary if we had a script that b4 prep --auto-to-cc > could call to find the mail address(es) to send to. While we could do > that, this opens the door to people trying to add a way to notify some > people (e.g. a MAINTAINERS file) which is not somewhere the project > wants to go right now, and this also makes sure the address is always > added even if one forgets to run b4 prep --auto-to-cc (which is part of > the typical workflow for U-Boot and Linux kernel, but is not necessary > thanks to this patch). > > [1] https://pypi.org/project/b4/ > [2] https://b4.docs.kernel.org/en/latest/config.html > > Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> > --- > This adds a basic config file for b4 to avoid to have to add the mailing > list by hand. For documentation patches, one will still need to run > b4 send --cc docs@lists.yoctoproject.org > manually for sending it to the docs ML as well. > > Note that b4 supports patchwork, c.f. > https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings > though I have no clue what it does with it as I am no maintainer, but > maybe something worth having a look at if some maintainer of this repo > wants to use b4 to merge stuff? I use b4 regularly for meta-openembedded maintenance and it also updates patchwork when patch is accepted, I have this config. [b4] pw-url = "https://patchwork.yoctoproject.org/" pw-key = "<mykey>" pw-project = "oe" pw-review-state = "under-review" pw-accept-state = "accepted" pw-discard-state = "rejected" send-series-to = "openembedded-devel@lists.openembedded.org" > --- > .b4-config | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/.b4-config b/.b4-config > new file mode 100644 > index 000000000..632e39db4 > --- /dev/null > +++ b/.b4-config > @@ -0,0 +1,2 @@ > +[b4] > + send-series-cc = bitbake-devel@lists.openembedded.org > > --- > base-commit: ce166ae25793c11b0a190c531bef0c296fd74497 > change-id: 20240524-b4-support-e9855fc54d40 > > Best regards, > -- > Quentin Schulz <quentin.schulz@cherry.de> > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#16251): https://lists.openembedded.org/g/bitbake-devel/message/16251 > Mute This Topic: https://lists.openembedded.org/mt/106281674/1997914 > Group Owner: bitbake-devel+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Hi Khem, On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: > On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via > lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: >> >> From: Quentin Schulz <quentin.schulz@cherry.de> >> >> b4[1] is a very nice tool for mail-based contribution. A config[2] file >> exists to set up a few defaults. We can use it to set the Cc recipients >> to always add, in our case the mailing list. >> >> This shouldn't be necessary if we had a script that b4 prep --auto-to-cc >> could call to find the mail address(es) to send to. While we could do >> that, this opens the door to people trying to add a way to notify some >> people (e.g. a MAINTAINERS file) which is not somewhere the project >> wants to go right now, and this also makes sure the address is always >> added even if one forgets to run b4 prep --auto-to-cc (which is part of >> the typical workflow for U-Boot and Linux kernel, but is not necessary >> thanks to this patch). >> >> [1] https://pypi.org/project/b4/ >> [2] https://b4.docs.kernel.org/en/latest/config.html >> >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> >> --- >> This adds a basic config file for b4 to avoid to have to add the mailing >> list by hand. For documentation patches, one will still need to run >> b4 send --cc docs@lists.yoctoproject.org >> manually for sending it to the docs ML as well. >> >> Note that b4 supports patchwork, c.f. >> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings >> though I have no clue what it does with it as I am no maintainer, but >> maybe something worth having a look at if some maintainer of this repo >> wants to use b4 to merge stuff? > > I use b4 regularly for meta-openembedded maintenance and it also updates > patchwork when patch is accepted, I have this config. > > [b4] > pw-url = "https://patchwork.yoctoproject.org/" > pw-key = "<mykey>" > pw-project = "oe" > pw-review-state = "under-review" > pw-accept-state = "accepted" > pw-discard-state = "rejected" > send-series-to = "openembedded-devel@lists.openembedded.org" > Thanks for the example! Would it make sense for me to add the pw parts to this patch as well (in a v2 for example)? I'm perplexed about the pw-key though. This is very much something we don't want to version nor potentially leak by mistake. I assume it is not possible to add to the global ~/.config/git/config or ~/.gitconfig because the URL would change for example between projects (I assume we may have a different patchwork for OE and YP, but for sure if people maintain kernel stuff as well, then they would have one for kernel.org for example). Mmmm but maybe a simple git config b4.pw-key "<mykey>" from within the local git repo would be enough :) BTW, I see you have -to instead of what I sent (-cc), is there a preference here? (I took Cc since this is what we document in the README). Cheers, Quentin
On Fri, May 24, 2024 at 8:33 AM Quentin Schulz <quentin.schulz@cherry.de> wrote: > > Hi Khem, > > On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: > > On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via > > lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: > >> > >> From: Quentin Schulz <quentin.schulz@cherry.de> > >> > >> b4[1] is a very nice tool for mail-based contribution. A config[2] file > >> exists to set up a few defaults. We can use it to set the Cc recipients > >> to always add, in our case the mailing list. > >> > >> This shouldn't be necessary if we had a script that b4 prep --auto-to-cc > >> could call to find the mail address(es) to send to. While we could do > >> that, this opens the door to people trying to add a way to notify some > >> people (e.g. a MAINTAINERS file) which is not somewhere the project > >> wants to go right now, and this also makes sure the address is always > >> added even if one forgets to run b4 prep --auto-to-cc (which is part of > >> the typical workflow for U-Boot and Linux kernel, but is not necessary > >> thanks to this patch). > >> > >> [1] https://pypi.org/project/b4/ > >> [2] https://b4.docs.kernel.org/en/latest/config.html > >> > >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> > >> --- > >> This adds a basic config file for b4 to avoid to have to add the mailing > >> list by hand. For documentation patches, one will still need to run > >> b4 send --cc docs@lists.yoctoproject.org > >> manually for sending it to the docs ML as well. > >> > >> Note that b4 supports patchwork, c.f. > >> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings > >> though I have no clue what it does with it as I am no maintainer, but > >> maybe something worth having a look at if some maintainer of this repo > >> wants to use b4 to merge stuff? > > > > I use b4 regularly for meta-openembedded maintenance and it also updates > > patchwork when patch is accepted, I have this config. > > > > [b4] > > pw-url = "https://patchwork.yoctoproject.org/" > > pw-key = "<mykey>" > > pw-project = "oe" > > pw-review-state = "under-review" > > pw-accept-state = "accepted" > > pw-discard-state = "rejected" > > send-series-to = "openembedded-devel@lists.openembedded.org" > > > > Thanks for the example! Would it make sense for me to add the pw parts > to this patch as well (in a v2 for example)? Maybe, it can be documented like this but I would leave it to the maintainers to promote using b4 not. > > I'm perplexed about the pw-key though. This is very much something we > don't want to version nor potentially leak by mistake. I assume it is > not possible to add to the global ~/.config/git/config or ~/.gitconfig > because the URL would change for example between projects (I assume we > may have a different patchwork for OE and YP, but for sure if people > maintain kernel stuff as well, then they would have one for kernel.org > for example). Mmmm but maybe a simple > > git config b4.pw-key "<mykey>" > > from within the local git repo would be enough :) right, it must be documented clearly. setting up b4 is not simple like a pull request merge. > > BTW, I see you have -to instead of what I sent (-cc), is there a > preference here? (I took Cc since this is what we document in the README). I used --to because at times to field was being left empty. > > Cheers, > Quentin
On Fri, May 24, 2024 at 9:28 AM Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > On Fri, May 24, 2024 at 8:33 AM Quentin Schulz <quentin.schulz@cherry.de> > wrote: > > > > Hi Khem, > > > > On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: > > > On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via > > > lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: > > >> > > >> From: Quentin Schulz <quentin.schulz@cherry.de> > > >> > > >> b4[1] is a very nice tool for mail-based contribution. A config[2] > file > > >> exists to set up a few defaults. We can use it to set the Cc > recipients > > >> to always add, in our case the mailing list. > > >> > > >> This shouldn't be necessary if we had a script that b4 prep > --auto-to-cc > > >> could call to find the mail address(es) to send to. While we could do > > >> that, this opens the door to people trying to add a way to notify some > > >> people (e.g. a MAINTAINERS file) which is not somewhere the project > > >> wants to go right now, and this also makes sure the address is always > > >> added even if one forgets to run b4 prep --auto-to-cc (which is part > of > > >> the typical workflow for U-Boot and Linux kernel, but is not necessary > > >> thanks to this patch). > > >> > > >> [1] https://pypi.org/project/b4/ > > >> [2] https://b4.docs.kernel.org/en/latest/config.html > > >> > > >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> > > >> --- > > >> This adds a basic config file for b4 to avoid to have to add the > mailing > > >> list by hand. For documentation patches, one will still need to run > > >> b4 send --cc docs@lists.yoctoproject.org > > >> manually for sending it to the docs ML as well. > > >> > > >> Note that b4 supports patchwork, c.f. > > >> > https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings > > >> though I have no clue what it does with it as I am no maintainer, but > > >> maybe something worth having a look at if some maintainer of this repo > > >> wants to use b4 to merge stuff? > > > > > > I use b4 regularly for meta-openembedded maintenance and it also > updates > > > patchwork when patch is accepted, I have this config. > > > > > > [b4] > > > pw-url = "https://patchwork.yoctoproject.org/" > > > pw-key = "<mykey>" > > > pw-project = "oe" > > > pw-review-state = "under-review" > > > pw-accept-state = "accepted" > > > pw-discard-state = "rejected" > > > send-series-to = "openembedded-devel@lists.openembedded.org" > This inspired me to revisit the issue I was having with "b4 shazam < message.id for an AUH upgrade>", where shazam would stumble because of the "scissors line" (--- >8 ---) Turns out the solution appears to be [b4] stdin-pipe-sep = "--- >8 ---" > > > > > > > Thanks for the example! Would it make sense for me to add the pw parts > > to this patch as well (in a v2 for example)? > > Maybe, it can be documented like this but I would leave it to the > maintainers > to promote using b4 not. > > > > > I'm perplexed about the pw-key though. This is very much something we > > don't want to version nor potentially leak by mistake. I assume it is > > not possible to add to the global ~/.config/git/config or ~/.gitconfig > > because the URL would change for example between projects (I assume we > > may have a different patchwork for OE and YP, but for sure if people > > maintain kernel stuff as well, then they would have one for kernel.org > > for example). Mmmm but maybe a simple > > > > git config b4.pw-key "<mykey>" > > > > from within the local git repo would be enough :) > > right, it must be documented clearly. setting up b4 is not simple like a > pull > request merge. > > > > > BTW, I see you have -to instead of what I sent (-cc), is there a > > preference here? (I took Cc since this is what we document in the > README). > > I used --to because at times to field was being left empty. > > > > Cheers, > > Quentin > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#16264): > https://lists.openembedded.org/g/bitbake-devel/message/16264 > Mute This Topic: https://lists.openembedded.org/mt/106281674/924729 > Group Owner: bitbake-devel+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [ > ticotimo@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Fri, May 24, 2024 at 11:24 AM Tim Orling <ticotimo@gmail.com> wrote: > > > On Fri, May 24, 2024 at 9:28 AM Khem Raj via lists.openembedded.org > <raj.khem=gmail.com@lists.openembedded.org> wrote: > >> On Fri, May 24, 2024 at 8:33 AM Quentin Schulz <quentin.schulz@cherry.de> >> wrote: >> > >> > Hi Khem, >> > >> > On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: >> > > On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via >> > > lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: >> > >> >> > >> From: Quentin Schulz <quentin.schulz@cherry.de> >> > >> >> > >> b4[1] is a very nice tool for mail-based contribution. A config[2] >> file >> > >> exists to set up a few defaults. We can use it to set the Cc >> recipients >> > >> to always add, in our case the mailing list. >> > >> >> > >> This shouldn't be necessary if we had a script that b4 prep >> --auto-to-cc >> > >> could call to find the mail address(es) to send to. While we could do >> > >> that, this opens the door to people trying to add a way to notify >> some >> > >> people (e.g. a MAINTAINERS file) which is not somewhere the project >> > >> wants to go right now, and this also makes sure the address is always >> > >> added even if one forgets to run b4 prep --auto-to-cc (which is part >> of >> > >> the typical workflow for U-Boot and Linux kernel, but is not >> necessary >> > >> thanks to this patch). >> > >> >> > >> [1] https://pypi.org/project/b4/ >> > >> [2] https://b4.docs.kernel.org/en/latest/config.html >> > >> >> > >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> >> > >> --- >> > >> This adds a basic config file for b4 to avoid to have to add the >> mailing >> > >> list by hand. For documentation patches, one will still need to run >> > >> b4 send --cc docs@lists.yoctoproject.org >> > >> manually for sending it to the docs ML as well. >> > >> >> > >> Note that b4 supports patchwork, c.f. >> > >> >> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings >> > >> though I have no clue what it does with it as I am no maintainer, but >> > >> maybe something worth having a look at if some maintainer of this >> repo >> > >> wants to use b4 to merge stuff? >> > > >> > > I use b4 regularly for meta-openembedded maintenance and it also >> updates >> > > patchwork when patch is accepted, I have this config. >> > > >> > > [b4] >> > > pw-url = "https://patchwork.yoctoproject.org/" >> > > pw-key = "<mykey>" >> > > pw-project = "oe" >> > > pw-review-state = "under-review" >> > > pw-accept-state = "accepted" >> > > pw-discard-state = "rejected" >> > > send-series-to = "openembedded-devel@lists.openembedded.org" >> > > This inspired me to revisit the issue I was having with "b4 shazam < > message.id for an AUH upgrade>", where > shazam would stumble because of the "scissors line" (--- >8 ---) > > Turns out the solution appears to be > [b4] > stdin-pipe-sep = "--- >8 ---" > Correction, where I was having trouble was with "git pw patch apply" $ git pw patch apply 43726 Failed to apply patch: hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To record the empty patch as an empty commit, run "git am --allow-empty". hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false" Patch is empty. Whereas "b4 shazam 0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com" works: $ b4 shazam 0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com Grabbing thread from lore.kernel.org/all/0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com/t.mbox.gz Checking for newer revisions Grabbing search results from lore.kernel.org Analyzing 1 messages in the thread Checking attestation on all messages, may take a moment... Retrieving CI status, may take a moment... --- ✓ [PATCH] nghttp2: upgrading to 1.62.0 SUCCEEDED --- ✓ Signed: DKIM/yoctoproject.org --- Total patches: 1 --- Applying: nghttp2: upgrade 1.61.0 -> 1.62.0 Any tricks to getting the Message-Id from patchwork? > >> > > >> > >> > Thanks for the example! Would it make sense for me to add the pw parts >> > to this patch as well (in a v2 for example)? >> >> Maybe, it can be documented like this but I would leave it to the >> maintainers >> to promote using b4 not. >> >> > >> > I'm perplexed about the pw-key though. This is very much something we >> > don't want to version nor potentially leak by mistake. I assume it is >> > not possible to add to the global ~/.config/git/config or ~/.gitconfig >> > because the URL would change for example between projects (I assume we >> > may have a different patchwork for OE and YP, but for sure if people >> > maintain kernel stuff as well, then they would have one for kernel.org >> > for example). Mmmm but maybe a simple >> > >> > git config b4.pw-key "<mykey>" >> > >> > from within the local git repo would be enough :) >> >> right, it must be documented clearly. setting up b4 is not simple like a >> pull >> request merge. >> >> > >> > BTW, I see you have -to instead of what I sent (-cc), is there a >> > preference here? (I took Cc since this is what we document in the >> README). >> >> I used --to because at times to field was being left empty. >> > >> > Cheers, >> > Quentin >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#16264): >> https://lists.openembedded.org/g/bitbake-devel/message/16264 >> Mute This Topic: https://lists.openembedded.org/mt/106281674/924729 >> Group Owner: bitbake-devel+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/bitbake-devel/unsub [ >> ticotimo@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >> >>
Hi Tim, On 5/24/24 8:36 PM, Tim Orling via lists.openembedded.org wrote: > On Fri, May 24, 2024 at 11:24 AM Tim Orling <ticotimo@gmail.com> wrote: > >> >> >> On Fri, May 24, 2024 at 9:28 AM Khem Raj via lists.openembedded.org >> <raj.khem=gmail.com@lists.openembedded.org> wrote: >> >>> On Fri, May 24, 2024 at 8:33 AM Quentin Schulz <quentin.schulz@cherry.de> >>> wrote: >>>> >>>> Hi Khem, >>>> >>>> On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: >>>>> On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via >>>>> lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: >>>>>> >>>>>> From: Quentin Schulz <quentin.schulz@cherry.de> >>>>>> >>>>>> b4[1] is a very nice tool for mail-based contribution. A config[2] >>> file >>>>>> exists to set up a few defaults. We can use it to set the Cc >>> recipients >>>>>> to always add, in our case the mailing list. >>>>>> >>>>>> This shouldn't be necessary if we had a script that b4 prep >>> --auto-to-cc >>>>>> could call to find the mail address(es) to send to. While we could do >>>>>> that, this opens the door to people trying to add a way to notify >>> some >>>>>> people (e.g. a MAINTAINERS file) which is not somewhere the project >>>>>> wants to go right now, and this also makes sure the address is always >>>>>> added even if one forgets to run b4 prep --auto-to-cc (which is part >>> of >>>>>> the typical workflow for U-Boot and Linux kernel, but is not >>> necessary >>>>>> thanks to this patch). >>>>>> >>>>>> [1] https://pypi.org/project/b4/ >>>>>> [2] https://b4.docs.kernel.org/en/latest/config.html >>>>>> >>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> >>>>>> --- >>>>>> This adds a basic config file for b4 to avoid to have to add the >>> mailing >>>>>> list by hand. For documentation patches, one will still need to run >>>>>> b4 send --cc docs@lists.yoctoproject.org >>>>>> manually for sending it to the docs ML as well. >>>>>> >>>>>> Note that b4 supports patchwork, c.f. >>>>>> >>> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings >>>>>> though I have no clue what it does with it as I am no maintainer, but >>>>>> maybe something worth having a look at if some maintainer of this >>> repo >>>>>> wants to use b4 to merge stuff? >>>>> >>>>> I use b4 regularly for meta-openembedded maintenance and it also >>> updates >>>>> patchwork when patch is accepted, I have this config. >>>>> >>>>> [b4] >>>>> pw-url = "https://patchwork.yoctoproject.org/" >>>>> pw-key = "<mykey>" >>>>> pw-project = "oe" >>>>> pw-review-state = "under-review" >>>>> pw-accept-state = "accepted" >>>>> pw-discard-state = "rejected" >>>>> send-series-to = "openembedded-devel@lists.openembedded.org" >>> >> >> This inspired me to revisit the issue I was having with "b4 shazam < >> message.id for an AUH upgrade>", where >> shazam would stumble because of the "scissors line" (--- >8 ---) >> >> Turns out the solution appears to be >> [b4] >> stdin-pipe-sep = "--- >8 ---" >> > > Correction, where I was having trouble was with "git pw patch apply" > > $ git pw patch apply 43726 > Failed to apply patch: > hint: When you have resolved this problem, run "git am --continue". > hint: If you prefer to skip this patch, run "git am --skip" instead. > hint: To record the empty patch as an empty commit, run "git am > --allow-empty". > hint: To restore the original branch and stop patching, run "git am > --abort". > hint: Disable this message with "git config advice.mergeConflict false" > Patch is empty. > > Whereas "b4 shazam > 0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com" > works: > > $ b4 shazam > 0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com > Grabbing thread from > lore.kernel.org/all/0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com/t.mbox.gz > Checking for newer revisions > Grabbing search results from lore.kernel.org > Analyzing 1 messages in the thread > Checking attestation on all messages, may take a moment... > Retrieving CI status, may take a moment... > --- > ✓ [PATCH] nghttp2: upgrading to 1.62.0 SUCCEEDED > --- > ✓ Signed: DKIM/yoctoproject.org > --- > Total patches: 1 > --- > Applying: nghttp2: upgrade 1.61.0 -> 1.62.0 > > > Any tricks to getting the Message-Id from patchwork? > I assume you mean you want to use the patchwork id with b4 shazam? In any case, you can send a mail on https://lore.kernel.org/tools/ with [b4] as prefix to ask for help or suggest something :) Cheers, Quentin
Hi Khem, On 5/24/24 6:28 PM, Khem Raj wrote: > On Fri, May 24, 2024 at 8:33 AM Quentin Schulz <quentin.schulz@cherry.de> wrote: >> >> Hi Khem, >> >> On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: >>> On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via >>> lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: >>>> >>>> From: Quentin Schulz <quentin.schulz@cherry.de> >>>> >>>> b4[1] is a very nice tool for mail-based contribution. A config[2] file >>>> exists to set up a few defaults. We can use it to set the Cc recipients >>>> to always add, in our case the mailing list. >>>> >>>> This shouldn't be necessary if we had a script that b4 prep --auto-to-cc >>>> could call to find the mail address(es) to send to. While we could do >>>> that, this opens the door to people trying to add a way to notify some >>>> people (e.g. a MAINTAINERS file) which is not somewhere the project >>>> wants to go right now, and this also makes sure the address is always >>>> added even if one forgets to run b4 prep --auto-to-cc (which is part of >>>> the typical workflow for U-Boot and Linux kernel, but is not necessary >>>> thanks to this patch). >>>> >>>> [1] https://pypi.org/project/b4/ >>>> [2] https://b4.docs.kernel.org/en/latest/config.html >>>> >>>> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> >>>> --- >>>> This adds a basic config file for b4 to avoid to have to add the mailing >>>> list by hand. For documentation patches, one will still need to run >>>> b4 send --cc docs@lists.yoctoproject.org >>>> manually for sending it to the docs ML as well. >>>> >>>> Note that b4 supports patchwork, c.f. >>>> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings >>>> though I have no clue what it does with it as I am no maintainer, but >>>> maybe something worth having a look at if some maintainer of this repo >>>> wants to use b4 to merge stuff? >>> >>> I use b4 regularly for meta-openembedded maintenance and it also updates >>> patchwork when patch is accepted, I have this config. >>> >>> [b4] >>> pw-url = "https://patchwork.yoctoproject.org/" >>> pw-key = "<mykey>" >>> pw-project = "oe" >>> pw-review-state = "under-review" >>> pw-accept-state = "accepted" >>> pw-discard-state = "rejected" >>> send-series-to = "openembedded-devel@lists.openembedded.org" >>> >> >> Thanks for the example! Would it make sense for me to add the pw parts >> to this patch as well (in a v2 for example)? > > Maybe, it can be documented like this but I would leave it to the maintainers > to promote using b4 not. > Promoting != supporting. Right now, I was just planning on adding basic support for b4 so that people who are in the know can use it. We can decide whether we want to document this and/or make this the default contribution workflow later, they don't have to happen at the same time. As for the pw bits, it's one less barrier to maintainers using it if they only have to run git config b4.pw-key "<mykey>" once (which I can even put as a comment in the file). It can silently and slowly drive adoption if they only have to run one command for trying things out. Reminder that I'm not a maintainer and I'm not using b4 as a maintainer so I have no clue if this is actually useful to Yocto/OE maintainers. Paul Barker presented his use of b4+lei 3 years ago and I have a vague recollection Bruce may be doing it but cannot find a presentation of his quickly so maybe I'm misremembering. Providing those defaults (provided they work) doesn't mean people have to use b4 for contribution or as a maintainer as part of their workflow, we just make it easier for people to use that workflow if they want to. >> >> I'm perplexed about the pw-key though. This is very much something we >> don't want to version nor potentially leak by mistake. I assume it is >> not possible to add to the global ~/.config/git/config or ~/.gitconfig >> because the URL would change for example between projects (I assume we >> may have a different patchwork for OE and YP, but for sure if people >> maintain kernel stuff as well, then they would have one for kernel.org >> for example). Mmmm but maybe a simple >> >> git config b4.pw-key "<mykey>" >> >> from within the local git repo would be enough :) > > right, it must be documented clearly. setting up b4 is not simple like a pull > request merge. > Do we want to document this now. If so, where? yocto-docs and bitbake/docs? Richard "suggested" something a bit more involved for git repos merged into the poky git repo so that it finds stuff automagically, if you are writing patches for bitbake inside poky git repo, bitbake/docs, oe-core, etc... So maybe I should think about something a bit "smarter" :) Cheers, Quentin
Hi Tim, Quoting Tim Orling (2024-05-24 19:36:45) > On Fri, May 24, 2024 at 11:24 AM Tim Orling <ticotimo@gmail.com> wrote: > > > > > > > On Fri, May 24, 2024 at 9:28 AM Khem Raj via lists.openembedded.org > > <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > >> On Fri, May 24, 2024 at 8:33 AM Quentin Schulz <quentin.schulz@cherry.de> > >> wrote: > >> > > >> > Hi Khem, > >> > > >> > On 5/24/24 5:18 PM, Khem Raj via lists.openembedded.org wrote: > >> > > On Fri, May 24, 2024 at 6:49 AM Quentin Schulz via > >> > > lists.openembedded.org <foss=0leil.net@lists.openembedded.org> wrote: > >> > >> > >> > >> From: Quentin Schulz <quentin.schulz@cherry.de> > >> > >> > >> > >> b4[1] is a very nice tool for mail-based contribution. A config[2] > >> file > >> > >> exists to set up a few defaults. We can use it to set the Cc > >> recipients > >> > >> to always add, in our case the mailing list. > >> > >> > >> > >> This shouldn't be necessary if we had a script that b4 prep > >> --auto-to-cc > >> > >> could call to find the mail address(es) to send to. While we could do > >> > >> that, this opens the door to people trying to add a way to notify > >> some > >> > >> people (e.g. a MAINTAINERS file) which is not somewhere the project > >> > >> wants to go right now, and this also makes sure the address is always > >> > >> added even if one forgets to run b4 prep --auto-to-cc (which is part > >> of > >> > >> the typical workflow for U-Boot and Linux kernel, but is not > >> necessary > >> > >> thanks to this patch). > >> > >> > >> > >> [1] https://pypi.org/project/b4/ > >> > >> [2] https://b4.docs.kernel.org/en/latest/config.html > >> > >> > >> > >> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> > >> > >> --- > >> > >> This adds a basic config file for b4 to avoid to have to add the > >> mailing > >> > >> list by hand. For documentation patches, one will still need to run > >> > >> b4 send --cc docs@lists.yoctoproject.org > >> > >> manually for sending it to the docs ML as well. > >> > >> > >> > >> Note that b4 supports patchwork, c.f. > >> > >> > >> https://b4.docs.kernel.org/en/latest/config.html#patchwork-integration-settings > >> > >> though I have no clue what it does with it as I am no maintainer, but > >> > >> maybe something worth having a look at if some maintainer of this > >> repo > >> > >> wants to use b4 to merge stuff? > >> > > > >> > > I use b4 regularly for meta-openembedded maintenance and it also > >> updates > >> > > patchwork when patch is accepted, I have this config. > >> > > > >> > > [b4] > >> > > pw-url = "https://patchwork.yoctoproject.org/" > >> > > pw-key = "<mykey>" > >> > > pw-project = "oe" > >> > > pw-review-state = "under-review" > >> > > pw-accept-state = "accepted" > >> > > pw-discard-state = "rejected" > >> > > send-series-to = "openembedded-devel@lists.openembedded.org" > >> > > > > This inspired me to revisit the issue I was having with "b4 shazam < > > message.id for an AUH upgrade>", where > > shazam would stumble because of the "scissors line" (--- >8 ---) > > > > Turns out the solution appears to be > > [b4] > > stdin-pipe-sep = "--- >8 ---" > > > > Correction, where I was having trouble was with "git pw patch apply" > > $ git pw patch apply 43726 > Failed to apply patch: > hint: When you have resolved this problem, run "git am --continue". > hint: If you prefer to skip this patch, run "git am --skip" instead. > hint: To record the empty patch as an empty commit, run "git am > --allow-empty". > hint: To restore the original branch and stop patching, run "git am > --abort". > hint: Disable this message with "git config advice.mergeConflict false" > Patch is empty. > > Whereas "b4 shazam > 0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com" > works: > > $ b4 shazam > 0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com > Grabbing thread from > lore.kernel.org/all/0101018f7d589796-87eb5d6d-06ed-4275-b5bc-6bad87216833-000000@us-west-2.amazonses.com/t.mbox.gz > Checking for newer revisions > Grabbing search results from lore.kernel.org > Analyzing 1 messages in the thread > Checking attestation on all messages, may take a moment... > Retrieving CI status, may take a moment... > --- > ✓ [PATCH] nghttp2: upgrading to 1.62.0 SUCCEEDED > --- > ✓ Signed: DKIM/yoctoproject.org > --- > Total patches: 1 > --- > Applying: nghttp2: upgrade 1.61.0 -> 1.62.0 > > > Any tricks to getting the Message-Id from patchwork? I've recently been trying to tackle this for the libcamera project as well. Essentially - grab the series as json from: https://patchwork.libcamera.org/api/1.1/series/$SERIES_ID/ Then extract from data['cover_letter']['msgid'] if there's a cover letter, or data['patches'][0]['msgid'] otherwise. I'm using this (quick and dirty, please don't judge the) python code to script getting the message-id. ``` #!/usr/bin/env python3 import requests import sys PATCHWORK_API_URL = "https://patchwork.libcamera.org/api/1.1" def get_first_patch_message_id(series_id): # Get series details series_url = f"{PATCHWORK_API_URL}/series/{series_id}/" response = requests.get(series_url) response.raise_for_status() series_data = response.json() # Check for cover letter and get its msgid if series_data.get('cover_letter'): message_id = series_data['cover_letter']['msgid'] else: # If no cover letter, get the msgid of the first patch if not series_data['patches']: raise ValueError("No patches found in the series") message_id = series_data['patches'][0]['msgid'] return message_id if __name__ == "__main__": if len(sys.argv) != 2: print("Usage: python3 get-message-id.py <series_id>") sys.exit(1) series_id = sys.argv[1] try: message_id = get_first_patch_message_id(series_id) print(f"Message ID of the first patch in the series: {message_id}") except Exception as e: print(f"An error occurred: {e}") ``` -- Kieran
diff --git a/.b4-config b/.b4-config new file mode 100644 index 000000000..632e39db4 --- /dev/null +++ b/.b4-config @@ -0,0 +1,2 @@ +[b4] + send-series-cc = bitbake-devel@lists.openembedded.org