u-boot.git/tools/patman/patchstream.py, branch v2020.07

patman: Support multi-line changes in changelogs

2020-05-30T02:55:45Z

This patch adds support to multi-line changes. That is, if one has a line in a changelog like - Do a thing but it spans multiple lines Using Series-process-log sort would sort as if those lines were unrelated. With this patch, any change line starting with whitespace will be considered part of the change before it. Signed-off-by: Sean Anderson Reviewed-by: Simon Glass

patman: Add new tags for finer-grained changelog control

2020-05-30T02:55:45Z

By default patman generates a combined changelog for the cover letter. This may not always be desirable. Many patches may have the same changes. These can be coalesced with "Series-process-log: uniq", but this is imperfect. Similar changes like "Move foo to patch 7" will not be merged with the similar "Move foo to this patch from patch 6". Changes may not make sense outside of the patch they are written for. For example, a change line of "Add check for bar" does not make sense outside of the context in which bar might be checked for. Some changes like "New" or "Lint" may be repeated many times throughout different change logs, but carry no useful information in a summary. Lastly, I like to summarize the broad strokes of the changes I have made in the cover letter, while documenting all the details in the appropriate patches. I think this makes it easier to get a good feel for what has changed, without making it difficult to wade through every change in the whole series. This patch adds two new tags to add changelog entries which only appear in the cover letter, or only appear in the commit. Changes documented with "Commit-changes" will only appear in the commit, and will not appear in the cover letter. Changes documented with "Cover-changes" will not appear in any commit, and will only appear in the cover letter. Signed-off-by: Sean Anderson Reviewed-by: Simon Glass

patman: Move to absolute imports

2020-04-26T20:25:21Z

At present patman sets the python path on startup so that it can access the libraries it needs. If we convert to use absolute imports this is not necessary. Move patman to use absolute imports. This requires changes in tools which use the patman libraries (which is most of them). Signed-off-by: Simon Glass

patman: Use unicode for file I/O

2019-11-05T01:15:32Z

At present patman test fail in some environments which don't use utf-8 as the default file encoding. Add this explicitly. Signed-off-by: Simon Glass

patman: Use the Change-Id, version, and prefix in the Message-Id

2019-10-15T14:40:03Z

As per the centithread on ksummit-discuss [1], there are folks who feel that if a Change-Id is present in a developer's local commit that said Change-Id could be interesting to include in upstream posts. Specifically if two commits are posted with the same Change-Id there's a reasonable chance that they are either the same commit or a newer version of the same commit. Specifically this is because that's how gerrit has trained people to work. There is much angst about Change-Id in upstream Linux, but one thing that seems safe and non-controversial is to include the Change-Id as part of the string of crud that makes up a Message-Id. Let's give that a try. In theory (if there is enough adoption) this could help a tool more reliably find various versions of a commit. This actually might work pretty well for U-Boot where (I believe) quite a number of developers use patman, so there could be critical mass (assuming that enough of these people also use a git hook that adds Change-Id to their commits). I was able to find this git hook by searching for "gerrit change id git hook" in my favorite search engine. In theory one could imagine something like this could be integrated into other tools, possibly even git-send-email. Getting it into patman seems like a sane first step, though. NOTE: this patch is being posted using a patman containing this patch, so you should be able to see the Message-Id of this patch and see that it contains my local Change-Id, which ends in 2b9 if you want to check. [1] https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html Signed-off-by: Douglas Anderson

SPDX: Convert all of our single license tags to Linux Kernel style

2018-05-07T13:34:12Z

When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini

patman: Add a functional test

2017-06-09T02:21:59Z

The existing test (patman --test) only covers basic checkpatch output. We have had some problems with unicode processing and could use test coverage for the various tags patman supports. Add a new functional test which runs most of the patman flow on a few test commits and checks that the results are correct. See the documentation in the test for a description of what it does. Signed-off-by: Simon Glass Tested-by: Philipp Tomsich

patman: Don't return the series in FixPatches()

2017-06-09T02:21:59Z

There is no need for this function to return the same object that was passed in. Drop the return value. Signed-off-by: Simon Glass Tested-by: Philipp Tomsich

patman: Don't report unicode character

2017-06-09T02:21:59Z

Unicode characters may appear in input patches so we should not warn about them. Drop this warning. Signed-off-by: Simon Glass Tested-by: Philipp Tomsich

patman: Make print statements python 3.x safe

2016-10-09T15:30:32Z

In python 3.x, print must be used as a function call. Convert all print statements to the function call style, importing from __future__ where we print with no trailing newline or print to a file object. Signed-off-by: Paul Burton Acked-by: Simon Glass