[U-Boot] Include patchwork patch ID in commit message?
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
* Access to comments on patches * Clarity on exactly which version of a patch was applied * No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
What do you (or anyone else) think?
Thanks, -Joe
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
Thanks, -Joe
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is: 1) Assign all unassigned patches 2) Open my todo list in patchwork 3) Create a bundle with all of the patches I want based on my critera at the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Are you being funny (more and less == not)? Or did you miss-read? :)
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the
Doesn't that mean it will very soon not be traceable exactly which patch version was applied? What I was proposing would mean that the commit message could continue to refer back to the patch even if archived.
last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Gotcha. Thanks!
I'm trying to improve my workflow now, and this Patch tag was something that came out of it. It's not required for the workflow, but it is free to do within it. It has the potential to slightly simplify one possible workflow, so no big deal.
If people think it will be simply noise, I'll leave it out.
I think this may speed up cross-referencing. Seemed like a good thing.
Cheers, -Joe
On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Are you being funny (more and less == not)? Or did you miss-read? :)
Oops, yes, misread, yes, I like that.
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the
Doesn't that mean it will very soon not be traceable exactly which patch version was applied? What I was proposing would mean that the commit message could continue to refer back to the patch even if archived.
It means the the link I gave for the bundle will be gone. The patches will be there, but I will also move them from Under Review to Accepted.
last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Gotcha. Thanks!
I'm trying to improve my workflow now, and this Patch tag was something that came out of it. It's not required for the workflow, but it is free to do within it. It has the potential to slightly simplify one possible workflow, so no big deal.
If people think it will be simply noise, I'll leave it out.
I think this may speed up cross-referencing. Seemed like a good thing.
My concern is that since it's not injected by patchwork already I would have to add it to each commit. Today, unless I need to either make something apply or do a minor fixup to the contents, I don't modify any commit message, so my git am is it.
On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Are you being funny (more and less == not)? Or did you miss-read? :)
Oops, yes, misread, yes, I like that.
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the
Doesn't that mean it will very soon not be traceable exactly which patch version was applied? What I was proposing would mean that the commit message could continue to refer back to the patch even if archived.
It means the the link I gave for the bundle will be gone. The patches will be there, but I will also move them from Under Review to Accepted.
last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Gotcha. Thanks!
I'm trying to improve my workflow now, and this Patch tag was something that came out of it. It's not required for the workflow, but it is free to do within it. It has the potential to slightly simplify one possible workflow, so no big deal.
If people think it will be simply noise, I'll leave it out.
I think this may speed up cross-referencing. Seemed like a good thing.
My concern is that since it's not injected by patchwork already I would have to add it to each commit. Today, unless I need to either make something apply or do a minor fixup to the contents, I don't modify any commit message, so my git am is it.
Does it make sense to enhance patchwork to inject such link into the commit automatically? It can also be a project configuration option so that other projects tracked by patchwork can turn it on on their needs.
Regards, Bin
Hello Bin,
Am 28.01.2016 um 02:49 schrieb Bin Meng:
On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote: > Hi Tom, > > I'm playing with the idea of including the patchwork patch ID in the > commit message of each commit that I apply to provide better > cross-reference ability. > > * Access to comments on patches > * Clarity on exactly which version of a patch was applied > * No need to search by patch subject > > Here is an example in a working branch: > > http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Are you being funny (more and less == not)? Or did you miss-read? :)
Oops, yes, misread, yes, I like that.
> What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the
Doesn't that mean it will very soon not be traceable exactly which patch version was applied? What I was proposing would mean that the commit message could continue to refer back to the patch even if archived.
It means the the link I gave for the bundle will be gone. The patches will be there, but I will also move them from Under Review to Accepted.
last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Gotcha. Thanks!
I'm trying to improve my workflow now, and this Patch tag was something that came out of it. It's not required for the workflow, but it is free to do within it. It has the potential to slightly simplify one possible workflow, so no big deal.
If people think it will be simply noise, I'll leave it out.
I think this may speed up cross-referencing. Seemed like a good thing.
My concern is that since it's not injected by patchwork already I would have to add it to each commit. Today, unless I need to either make something apply or do a minor fixup to the contents, I don't modify any commit message, so my git am is it.
Does it make sense to enhance patchwork to inject such link into the commit automatically? It can also be a project configuration option so that other projects tracked by patchwork can turn it on on their needs.
+1
bye, Heiko
On Thu, Jan 28, 2016 at 07:49:40AM +0100, Heiko Schocher wrote:
Hello Bin,
Am 28.01.2016 um 02:49 schrieb Bin Meng:
On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote: >On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote: >>Hi Tom, >> >>I'm playing with the idea of including the patchwork patch ID in the >>commit message of each commit that I apply to provide better >>cross-reference ability. >> >>* Access to comments on patches >>* Clarity on exactly which version of a patch was applied >>* No need to search by patch subject >> >>Here is an example in a working branch: >> >>http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45... > >I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Are you being funny (more and less == not)? Or did you miss-read? :)
Oops, yes, misread, yes, I like that.
>>What do you (or anyone else) think? > >Well, I'm not a super fan of it. For your second point, this is why I >use bundles, mutt and a macro. For the other points, at least I find >google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the
Doesn't that mean it will very soon not be traceable exactly which patch version was applied? What I was proposing would mean that the commit message could continue to refer back to the patch even if archived.
It means the the link I gave for the bundle will be gone. The patches will be there, but I will also move them from Under Review to Accepted.
last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Gotcha. Thanks!
I'm trying to improve my workflow now, and this Patch tag was something that came out of it. It's not required for the workflow, but it is free to do within it. It has the potential to slightly simplify one possible workflow, so no big deal.
If people think it will be simply noise, I'll leave it out.
I think this may speed up cross-referencing. Seemed like a good thing.
My concern is that since it's not injected by patchwork already I would have to add it to each commit. Today, unless I need to either make something apply or do a minor fixup to the contents, I don't modify any commit message, so my git am is it.
Does it make sense to enhance patchwork to inject such link into the commit automatically? It can also be a project configuration option so that other projects tracked by patchwork can turn it on on their needs.
+1
Well, code it up and send the patchwork list a patch and see how it goes :)
On Wed, Jan 27, 2016 at 7:49 PM, Bin Meng bmeng.cn@gmail.com wrote:
On Thu, Jan 28, 2016 at 9:30 AM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 06:05:01PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 5:45 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote: > Hi Tom, > > I'm playing with the idea of including the patchwork patch ID in the > commit message of each commit that I apply to provide better > cross-reference ability. > > * Access to comments on patches > * Clarity on exactly which version of a patch was applied > * No need to search by patch subject > > Here is an example in a working branch: > > http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Are you being funny (more and less == not)? Or did you miss-read? :)
Oops, yes, misread, yes, I like that.
> What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the
Doesn't that mean it will very soon not be traceable exactly which patch version was applied? What I was proposing would mean that the commit message could continue to refer back to the patch even if archived.
It means the the link I gave for the bundle will be gone. The patches will be there, but I will also move them from Under Review to Accepted.
last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Gotcha. Thanks!
I'm trying to improve my workflow now, and this Patch tag was something that came out of it. It's not required for the workflow, but it is free to do within it. It has the potential to slightly simplify one possible workflow, so no big deal.
If people think it will be simply noise, I'll leave it out.
I think this may speed up cross-referencing. Seemed like a good thing.
My concern is that since it's not injected by patchwork already I would have to add it to each commit. Today, unless I need to either make something apply or do a minor fixup to the contents, I don't modify any commit message, so my git am is it.
Does it make sense to enhance patchwork to inject such link into the commit automatically? It can also be a project configuration option so that other projects tracked by patchwork can turn it on on their needs.
That would certainly make it a more unified implementation. The way I'm doing it is simply with an automatic git commit --amend after the git am in my script that downloads and applies mbox files from patchwork.
-Joe
Hello Tom,
Am 28.01.2016 um 00:45 schrieb Tom Rini:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Sorry, for dummy question ... what should I see in the above link?
What do you (or anyone else) think?
Well, I'm not a super fan of it. For your second point, this is why I use bundles, mutt and a macro. For the other points, at least I find google does a good job pulling up the right patch at least.
Bundles seem awkward. Perhaps I'm just not using them effectively. What benefit do they give you? How are they part of your workflow?
OK, I'm going to delete this in a few days but here's my bundle for the last import I did: https://patchwork.ozlabs.org/bundle/trini/2016-01-25-master-imports/ My flow is:
- Assign all unassigned patches
- Open my todo list in patchwork
- Create a bundle with all of the patches I want based on my critera at
the time. 4) Download bundle as mbox, git am -3 it, get big build going. 5) Open each patch link, check for Nak/Changed/Uncertanty that I missed at first 6) Assuming no repeats of part 4 of the cycle, mutt -f the bundle, for each email group reply, run macro to insert applied message, postponed 7) Check output from big build, assuming good results, push and spam out all of my queued messages.
Out of topic .... maybe tbot can help you here a lot. I have an automated build for example for the smartweb board [1], which does:
+ - clone u-boot.git + - set toolchain + - get a list of patchwork patches from my U-Boots ToDo list + - download all of them, and check them with checkpatch + and apply them to u-boot.git + - compile U-Boot for the smartweb board + - install the resulting images on the smartweb board + - boot U-boot + - test DFU + - more TC should be added here for testing U-Boot
added to this list in the meantime some ported DUTS tests now, last build see: http://xeidos.ddns.net/buildbot/builders/smartweb_dfu/builds/48/steps/shell/... (currently I have 3 boards doing such tests periodically)
So, if you have a well-kept ToDo list in patchwork, this testcase does a lot automatically (incl. execute testcases on board(s)) ... You have only to look in the morning on for example a webpage if all tests are "green" [2] ...
Then you can be sure, all patches in your ToDo list are checkpatch clena, apply without errors to current master, compile clean and do not break the boards you test u-boot ... (at last the testcases you run on it).
Ok, I did not tried it with bundles, but it should also be possible to download all patches you have in a bundle ... simple add a testcase for downloading patches in a bundle only ...
Also an idea could be, to send an automated EMail if checkpatch drops warnings/errors or if "git am" fails" ... but I do not really know, if this would be a good idea ...
Also with the idea of tbot, you do not really need the hw at the place where tbot runs ... for my example I run tbot on a raspberry pi in Letkes/hungary, the boards are in munich/germany. So it is possible, to test on boards, which other people have somewhere and give you access to them ...
bye, Heiko [1] http://lists.denx.de/pipermail/u-boot/2016-January/243248.html search there for: "automated Testsetup with buildbot and tbot doing cyclic tests"
[2] http://xeidos.ddns.net/buildbot/tgrid
Hi Heiko,
On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher hs@denx.de wrote:
Hello Tom,
Am 28.01.2016 um 00:45 schrieb Tom Rini:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Sorry, for dummy question ... what should I see in the above link?
The link is the think to see, not what it points to. The idea is that instead of just the patch number, include the patch number in a full URL for even easier access to the patch.
Cheers, -Joe
Hello Joe,
Am 28.01.2016 um 16:15 schrieb Joe Hershberger:
Hi Heiko,
On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher hs@denx.de wrote:
Hello Tom,
Am 28.01.2016 um 00:45 schrieb Tom Rini:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Sorry, for dummy question ... what should I see in the above link?
The link is the think to see, not what it points to. The idea is that instead of just the patch number, include the patch number in a full URL for even easier access to the patch.
Uh, ah, got it ... I think the patchworks patchnumber would be enough. I like Bins proposal, that patchwork add it automatically ...
bye, Heiko
2016-01-29 14:14 GMT+09:00 Heiko Schocher hs@denx.de:
Hello Joe,
Am 28.01.2016 um 16:15 schrieb Joe Hershberger:
Hi Heiko,
On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher hs@denx.de wrote:
Hello Tom,
Am 28.01.2016 um 00:45 schrieb Tom Rini:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote:
On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote: > > > Hi Tom, > > I'm playing with the idea of including the patchwork patch ID in the > commit message of each commit that I apply to provide better > cross-reference ability. > > * Access to comments on patches > * Clarity on exactly which version of a patch was applied > * No need to search by patch subject > > Here is an example in a working branch: > > > > http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Sorry, for dummy question ... what should I see in the above link?
The link is the think to see, not what it points to. The idea is that instead of just the patch number, include the patch number in a full URL for even easier access to the patch.
Uh, ah, got it ... I think the patchworks patchnumber would be enough. I like Bins proposal, that patchwork add it automatically ...
X-Patchwork-Id: 561384
I assume this tag points to the last version which was actually applied to the git tree.
If you want to know the whole history of each patch, you should see former versions as well as the last one.
The last version is often mature, so it may end up with just having "Applied to u-boot/master, thanks!", which does not carry useful information at all.
Nor do I want to see something as follows. X-Pachwork-Id-v1: 561184 X-Pachwork-Id-v2: 561284 X-Pachwork-Id-v3: 561384
Hello Masahiro,
On Fri, 29 Jan 2016 18:57:28 +0900, Masahiro Yamada yamada.masahiro@socionext.com wrote:
2016-01-29 14:14 GMT+09:00 Heiko Schocher hs@denx.de:
Hello Joe,
Am 28.01.2016 um 16:15 schrieb Joe Hershberger:
Hi Heiko,
On Thu, Jan 28, 2016 at 12:39 AM, Heiko Schocher hs@denx.de wrote:
Hello Tom,
Am 28.01.2016 um 00:45 schrieb Tom Rini:
On Wed, Jan 27, 2016 at 05:15:17PM -0600, Joe Hershberger wrote:
On Wed, Jan 27, 2016 at 4:22 PM, Tom Rini trini@konsulko.com wrote: > > > On Wed, Jan 27, 2016 at 03:08:09PM -0600, Joe Hershberger wrote: >> >> >> Hi Tom, >> >> I'm playing with the idea of including the patchwork patch ID in the >> commit message of each commit that I apply to provide better >> cross-reference ability. >> >> * Access to comments on patches >> * Clarity on exactly which version of a patch was applied >> * No need to search by patch subject >> >> Here is an example in a working branch: >> >> >> >> http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45... > > > > I'd prfer Patchwork or Patchwork-ID or something not just Patch.
Would it be more or less compelling if it had a format similar this?
Patchwork: https://patchwork.ozlabs.org/patch/571773/
Yes.
Sorry, for dummy question ... what should I see in the above link?
The link is the think to see, not what it points to. The idea is that instead of just the patch number, include the patch number in a full URL for even easier access to the patch.
Uh, ah, got it ... I think the patchworks patchnumber would be enough. I like Bins proposal, that patchwork add it automatically ...
X-Patchwork-Id: 561384
I assume this tag points to the last version which was actually applied to the git tree.
It points to the message in Patchwork -- patchwork does not apply patches on any tree; in fact, patchwork is totally unrelated to git.
If you want to know the whole history of each patch, you should see former versions as well as the last one.
The last version is often mature, so it may end up with just having "Applied to u-boot/master, thanks!", which does not carry useful information at all.
The last message in the thread started by the patch will have this. But that last message will be unknown by patchwork, which only records patches [apart from rare false positive cases where PW thinks a message is a patch, because there is git diff extract pasted into it].
Nor do I want to see something as follows. X-Pachwork-Id-v1: 561184 X-Pachwork-Id-v2: 561284 X-Pachwork-Id-v3: 561384
AFAICT, patchwork is not able tell which patch is the vN-1 of a given vN patch, and probably never will, as there is in fact no reliable way to reconstruct this. A vN patch does not necessarily have the same subject line as its vN-1, and does not necessarily have its vN-1's message-Id listed in its 'Reference:' header.
So you would never see the above anyway.
What I have personally set up recently is a Python script which goes through my Claws Mail U-Boot mail directory and, for each mail, queries Patchwork with the Message-ID and, failing that, with each Reference in turn, and adds X-Patchwork-{id,delegate,state...} to the mail. There is some ad hoc logic for things like cover letters, and of course, a caching mechanism so that I query PW only once per message-ID -- so for a long thread about a single patch, there will be a single actual query.
Oh, and it adds both an X-Patchwork-Id and an W-Patchwork-URL. :)
I run this regularly on my U-Boot inbox.
(if anyone knows how to query patchwork for "details for every patch which has changed since the date I last asked", let me know.)
Amicalement,
On Thu, Jan 28, 2016 at 07:39:54AM +0100, Heiko Schocher wrote:
[snip]
Out of topic .... maybe tbot can help you here a lot. I have an automated build for example for the smartweb board [1], which does:
- clone u-boot.git- set toolchain- get a list of patchwork patches from my U-Boots ToDo list- download all of them, and check them with checkpatchand apply them to u-boot.git- compile U-Boot for the smartweb board- install the resulting images on the smartweb board- boot U-boot- test DFU- more TC should be added here for testing U-Boot
I do need to play with tbot and kind of want to use that locally. For my build tests however, it's a shared server elsewhere that doesn't have access to the targets.
Hello Joe,
Am 27.01.2016 um 22:08 schrieb Joe Hershberger:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
What do you (or anyone else) think?
Good idea, I would prefer:
X-Patchwork-Id: 561384
Thats what is in the mbox file, you download from patchwork ...
bye, Heiko
On Thu, Jan 28, 2016 at 12:13 AM, Heiko Schocher hs@denx.de wrote:
Hello Joe,
Am 27.01.2016 um 22:08 schrieb Joe Hershberger:
Hi Tom,
I'm playing with the idea of including the patchwork patch ID in the commit message of each commit that I apply to provide better cross-reference ability.
- Access to comments on patches
- Clarity on exactly which version of a patch was applied
- No need to search by patch subject
Here is an example in a working branch:
http://git.denx.de/?p=u-boot/u-boot-net.git;a=commit;h=48f9a0c786d0a3cbfdf45...
What do you (or anyone else) think?
Good idea, I would prefer:
X-Patchwork-Id: 561384
Thats what is in the mbox file, you download from patchwork ...
Good point. I think that makes sense if we end up not including the link.
bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
participants (6)
-
Albert ARIBAUD -
Bin Meng -
Heiko Schocher -
Joe Hershberger -
Masahiro Yamada -
Tom Rini