Am Mittwoch, 11. Dezember 2013, 00:25:08 schrieb Adrian Schröter:
Am Dienstag, 10. Dezember 2013, 21:47:27 schrieb Michal Marek:
Dne 6.12.2013 09:50, Adrian Schröter napsal(a): ...
The reason why I want to have this spec file as part of the kernel package is that it should be also branched, when someone is branching any kernel-* package. OBS does create branches for all local linked packages, so the new and modified kernel will be used also directly in this project branching the kernel.
So if I upload a kernel that panics during boot to my home project, the whole project will stop building forever?
yes
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. We would notice before it got merged into mainline. Otherwise our users would be the first who notice that the kernel is not booting.
And there would be a way out of this, kernel developers (mainline and people who branched it) would just able to call "osc wipebinaries". If we have it only in mainline you would rely on OBS admins to fix the situation, no one else would be able to do it.
So, I would really like to ask to re-think this position. it is just one small text file in addition. And I am happy to take over the responsibility in case there are bug reports for it.
re-think sounds harsh, sorry it was late. It was a friendly request to re-consider :) Also, there would be also a way out without OBS admins, but not so obvious. However, I still think that testing the kernel before submission is still the way to go. It fits to the recently discussion about improving factory quality. A kernel which gets submited should have been at least tested once in some proven way. Also we would break some builds in future by branching a kernel into a project, because we will rely on the running kernel matching the installed kernel modules. And people would need to know the hidden magic behind kernel-obs-build package to branch it manually in addition. But with the package as part of the kernel-source, you can just fix the sources and enable builds again via wipebinaries (since it would use the kernel from the project below, eg. openSUSE:Factory). But the breakage would have been noticed. good morning adrian -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org