Am 08.04.2017 um 23:55 schrieb Michal Marek:
Dne 8.4.2017 v 21:59 Andreas Färber napsal(a):
> Am 07.04.2017 um 10:38 schrieb Michal Marek:
>> config/armv7hl/lpae is [...] not converted, because armv6 and armv7 are
>> currently disabled.
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
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.
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.)
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
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(a)opensuse.org
or maybe better opensuse-arm(a)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.
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(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org