On 16-11-16 09:54, Koen Vandeputte wrote: > Hi Paul, > > First of all, thank you for reviewing and testing the patch. > > > Let me share in detail how I prepare the kernel update patch: > > - Pull the latest git state 3 times > - On two of them, I apply my custom .config and feeds for the hardware > targets I use (1 for cns3xxx, 1 for imx6) > - On each of the 2 targets: Adapt the kernel-version.mk file to > include the new kernel > - Do a full build (tools, toolchain, packages, ...) > - Run the following command: |"make target/linux/refresh V=s"| > --> which is instructed here: > https://wiki.openwrt.org/doc/devel/patches#refreshing_patches > - From one of the build, copy all pathes from > "target/linux/generic/patches-4.4" to the unused git source clone > - From each seperate build, copy all pathes from > target/linux/"target"/patches-4.4 to the unused git source clone > ("target" being cns3xxx or imx6) > - Read all changes in git > - Commit + clearly specifiy it has been compiled/tested only on my 2 > targets. > > (If anyone thinks this is not the correct approach, please provide > feedback by all means!) > > > To be honest .. I share your opinion that it sometimes feels .. > dangerous. > - Will it build on other targets except my 2? > - As some patches appear to lack refreshes, is something wrong with > the refresh system? (I followed the previous discussion with the jump > to kernel .30 extensively) > You should use the script, and trust the refresh mechanism over yourself. > > > Personal thoughts regarding possible solutions: > > 1) > - Having a separate staging tree which is a copy of the main Source > tree, but only used for updating/testing kernel updates. > This way different people using different targets could easily test a > kernel update on their targets and reply if it's working or not. (and > supply refresh-patches for target-specific kernel patches) > If all major targets are refreshed, tested & confirmed, it should be > safer to merge it to main. > > 2) > - An alternate approach would be to create a script which auto-builds > & refresh every possible target.
We already have this script, it was mentioned in a previous thread about the subject. > --> Huge workload for 1 person > --> Would still leave some targets untested (unless someone has all > the time + hardware? :) ) I've done this before, https://git.lede-project.org/8072264b. It took a long time, but it's doable. > > 3) > - When a kernel update patch is posted, it requires at least 2 > additional "tested-by"'s on different targets before it can be > considered for merging. (Covering 5 .. 6 targets in total) > > > Any other ideas? anyone? > > > > Thanks again, > > Koen > > > > On 2016-11-16 08:00, p.wa...@gmx.at wrote: >> As I've just sent in 4.4.32, I came across other changes from which >> I think they should have already been done in 4.4.31: >> /apm821xx/patches-4.4/801-usb-xhci-add-firmware-loader-for-uPD720201-and-uPD72.patch >> >> /apm821xx/patches-4.4/802-usb-xhci-force-msi-renesas-xhci.patch >> >> Changes to xhci-pci.c were made upstream during release of 4.4.31 >> [1], which introduce >> two lines offset. Of course I know, that missing this refreshing >> doesn't break anything. >> However, it's not clear for me why some patches are refreshed, while >> others are not. This >> looks so indeterministic to me. Or am I still producing false positives? >> >> Best regards, >> P. Wassi >> >> [1]: >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/diff/?id=v4.4.31&id2=v4.4.30&dt=2 >> >> >>> + Refresh patches >>> compile/run-tested on cns3xxx & imx6. >>> >>> Signed-off-by: Koen Vandeputte <koen.vandepu...@ncentric.com> >>> --- >>> include/kernel-version.mk | 4 ++-- >>> ...-override-creds-with-the-ones-from-the-superblock.patch | 6 >>> +++--- >>> .../patches-4.4/052-01-ubifs-Implement-O_TMPFILE.patch | 2 +- >>> .../052-02-ubifs-Implement-RENAME_WHITEOUT.patch | 14 >>> +++++++------- >>> .../052-03-ubifs-Implement-RENAME_EXCHANGE.patch | 6 >>> +++--- >>> ...ac-stop-clearing-DMA-receive-control-register-rig.patch | 9 >>> ++------- >>> .../linux/generic/patches-4.4/201-extra_optimization.patch | 4 ++-- >>> 7 files changed, 20 insertions(+), 25 deletions(-) > I started the script to do this for 4.4.31, and I already have more changes than you, so NAK. While I appreciate the effort, I would like to ask you to not send these kind of patches anymore until you are sure you completely understand what you are doing. Thanks, Stijn _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
