All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Include patchwork patch ID in commit message?
Date: Thu, 28 Jan 2016 07:39:54 +0100	[thread overview]
Message-ID: <56A9B7BA.8040001@denx.de> (raw)
In-Reply-To: <20160127234521.GW426@bill-the-cat>

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=48f9a0c786d0a3cbfdf45846567deaebe27a334a
>>>
>>> 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:
> 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.

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/logs/tbotlog
(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
-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  parent reply	other threads:[~2016-01-28  6:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 21:08 [U-Boot] Include patchwork patch ID in commit message? Joe Hershberger
2016-01-27 22:22 ` Tom Rini
2016-01-27 23:15   ` Joe Hershberger
2016-01-27 23:45     ` Tom Rini
2016-01-28  0:05       ` Joe Hershberger
2016-01-28  1:30         ` Tom Rini
2016-01-28  1:49           ` Bin Meng
2016-01-28  6:49             ` Heiko Schocher
2016-01-28 15:40               ` Tom Rini
2016-01-28 15:19             ` Joe Hershberger
2016-01-28  6:39       ` Heiko Schocher [this message]
2016-01-28 15:15         ` Joe Hershberger
2016-01-29  5:14           ` Heiko Schocher
2016-01-29  9:57             ` Masahiro Yamada
2016-01-31 15:59               ` Albert ARIBAUD
2016-01-28 15:45         ` Tom Rini
2016-01-28  6:13 ` Heiko Schocher
2016-01-28 15:16   ` Joe Hershberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56A9B7BA.8040001@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.