Am 08.04.2017 um 23:55 schrieb Michal Marek:
Dne 8.4.2017 v 21:59 Andreas Färber napsal(a):
config/armv7hl/lpae is [...] not converted, because armv6 and armv7 are currently disabled. [...] Finally, on the topic of updating ARM configs, I am still annoyed about
Am 07.04.2017 um 10:38 schrieb Michal Marek: 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?
Both. Packages on boards that already run openSUSE, and a few branched JeOS images that build against Kernel:HEAD for unfinished boards. We also have a public devel:ARM:Factory:Contrib:HEAD project building against Kernel:HEAD. (Apart from JeOS-efi image, other images were usually temporary there, favoring manual addition of Kernel:HEAD for build power reasons.)
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.
Thanks for that tip! That was much faster than trying to build locally in tmp/current/ (takes all weekend), and OBS makes installation easier.
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.
I'm not worried about scalability, just about review and coordination. Unlike the upstream kernel workflow with scripts/get_maintainer.pl CC'ing sub-maintainers about certain changes, I don't get notified if anyone else touches config/arm*/*. Takashi, Jean and others doing cross-architecture cleanups have been so kind to ask on this list first before performing config changes. However if someone were to push a for-next branch with updated ARM configs in my absence, I wouldn't get any automatic email, because the "... is ready to be merged" mails only go to Jeff (and an internal list with quite some traffic), and there is no diffstat or other indication (apart from voluntary commit message conventions for ARM-only changes) to indicate that it is something for me to be aware of. With help from Jeff I've managed to set up email filters so that I now see when -rc1 has arrived in master. But by the time I get such update notifications it would be too late to object to any particular ARM-side change, only reverts or fix-ups would be possible at that point - for example, Dirk once simply disabled all Renesas options without any discussion or notification - thus it remained that way. (And as seen, email filters don't guarantee I read it immediately or can react to it when on travels - thanks to Stefan who ping'ed me on IRC.) kernel.opensuse.org only shows merged commits, not pending branches, so Matwey didn't see either when I had partial updates queued already and spent time on patches at some point. Master branch shouldn't contain any embargoed patches, so making branch existence or contents visible externally would seem thinkable. Wouldn't it be possible to extend your branch-checking scripts to address these issues in some form or another? Also, nobody seemed to notice that a while ago there was a dtb packaging pull request on GitHub - I only learned via pings on #opensuse-arm (after I had declined an SR against the old dtb-source). So it seems that each branch maintainer/reviewer needs to set the GitHub "watch" settings for that repository to get notified of pulls that affect them? No automatic mirroring from GitHub into SUSE, no kbuild notifications? Overall it just feels like the assumption still is that everything is handled by the SUSE kernel team, with little provisions for the openSUSE community to participate, myself being somewhere in between. Patches on opensuse-kernel have been working best so far, so should I simply integrate some git-send-email --to=opensuse-kernel@opensuse.org or maybe better opensuse-arm@opensuse.org into my git-push scripts, to lead by example? Absence of emails would then likely mean no update done yet. Might cause some list "spam" though. Ideas welcome. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org