Dne 8.4.2017 v 21:59 Andreas Färber napsal(a):
Hi Michal,
Am 07.04.2017 um 10:38 schrieb Michal Marek:
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* [...] 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla [...] 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled.
"still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging.
I meant to simply say "lpae is not converted."
How do you expect I maintain the lpae config as a fragment? By hand?! Saying "m" a few times more seems way easier to me.
In that case, just continue maintaining it this way.
vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one.
I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the
I'm not forcing this model on anyone. I think it's a good idea to do it for -debug, because the diff to default is minimal. i386/default is also largely similar it i386/pae. Let's see how it will work in practice. Regarding linux-next for lpae, it can be done. It just needs to be switched in 4 different places, so please let me know upfront.
Finally, on the topic of updating ARM configs, I am still annoyed about the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend.
Do you only test packages, or images built with the Kernel:HEAD packages? If it's the former, then simply do scripts/tar-up.sh && scripts/osc_wrapper upload home:a_faerber:... and have the packages built in your home project while waiting for Jeff to merge your changes.
Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model.
There is no sub-maintainer model and to be honest, I do not think we have a scalability problem to require a formal solution like this. Having multiple maintainers per branch with a verbal agreement about the areas of responsibility should work as well, shouldn't it? I can't speak for Jeff, of course. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org