From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Thu, 28 Jan 2016 07:39:54 +0100 Subject: [U-Boot] Include patchwork patch ID in commit message? In-Reply-To: <20160127234521.GW426@bill-the-cat> References: <20160127222209.GS426@bill-the-cat> <20160127234521.GW426@bill-the-cat> Message-ID: <56A9B7BA.8040001@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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