Thank you Hannu for taking you time and writing those lines, which clarify the whole situation for me. Now I also understand why the mvebu-patch is done here.
If I take some of your words > From Openwrt/LEDE perspective, the kernel source is the original kernel > source + the ~100 generic + the 10-50 platform-specific patches. > So, that patch 053- got refreshed now to match the new reality (of the added > rango line by the current 010- ). > Yeah, there could be a separate "refresh patches for earlier changes" patch > before the kernel bump, but that would just be additional work (...) I come to this conclusion: it may happen, that local changes/patches have effect on other patches in the chain, resulting in a fuzzed applying of these. I'll give it a try an do the following: write a simple script that -) downloads upstream kernel -) applies local generic patches -) then, one-by-one, applies platform patches if all patches are refreshed correctly, there shouldn't be any FAILED or fuzz results. Those could then be reported to find such 'issues' just in time (before the kernel bump). Furthermore this intermediate refreshing could also be automated? (I've done all my patches using 'diff' and am using 'git diff' for a month or so to do so, so I have no idea of 'quilt' and other tools :) ) I agree on you, that seperating kernel-refreshing and internal refreshing is additional work, but if the process of internal refreshing could be automated, it would detect issues introduces by local changes (which may result in a fuzz) on time and in the same turn shorten kernel bumps+refreshing. I mean if I sent in a patch that introduced such issues, I'd be glad to know on time in order to be more careful at the next patch. If my patch caused those 'problems' (offsets), I'd not notice them a week/weeks later during a kernel upgrade. Or am I overall totally going in the wrong direction and refreshing is not that big deal I'm currently facing? Best regards, P. Wassi _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
