Dne 11.12.2013 09:47, Adrian Schröter napsal(a):
Am Mittwoch, 11. Dezember 2013, 09:27:29 schrieb Michal Marek:
Dne 11.12.2013 00:25, Adrian Schröter napsal(a):
Am Dienstag, 10. Dezember 2013, 21:47:27 schrieb Michal Marek:
For me and I guess most other developers on this list, it is actually an advantage that the kernel does not need itself to build.
it won't be different as like updating to a broken glibc.
Yes, and that precisely is the problem - we do not want to deal with the bootstrap issues that the toolchain guys have to. For you, it's probably not such a big difference if one more package becomes part of the bootstrap set, but for us, being or not being in the bootstrap set matters.
well, since we are forced to use the distro kernel for package builds now you have also little choice. This is just going to happen to be able to load kernel modules, which are required meanwhile by some tools.
That's fine. I only object to forcing the bootstrap on everyone who wants to build their kernel.
The discussion where to place the OBS vm kernel spec file will not change that. It will just become even harder for you and everybody else get out of the kernel-not-booting situation again :(
Well, what would most likely happen is that the automated kernel builds in the Kernel:$branch projects would exclude the kernel-obs spec file to avoid this situation, so the QA gain would be minimal. Only individual developers who build their kernel in the OBS/IBS would be tricked into the bootstrap. But we have scripts even for that, so...
I actually plan to boot test each kernel pushed to the git, before actual users see it. But failure to boot will not affect subsequent attempts to build a fixed package. Hardware for that is ordered, it will not cover ppc64(le|be) though, only x86_64 (unless there is already usable qemu emulation for ppc64le?)
and how will eg a broken tool chain be detected or a broken mkinitrd?
It would not. We have enough fun with broken kernels already ;-).
And how would this become visible to the other packagers and release managers?
The kernels that the branch maintainers submit for online updates or for the next beta _do_ pass some basic testing. Those matter for other packagers and release managers. What we plan is a continuous integration thing, so that the repository remains in a usable state for development between online updates or betas. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org