Dirk, Am 04.02.2016 um 23:45 schrieb Dirk Müller: >> Actually I think it is unfair of users to expect that SUSE engineers >> must be the ones to fix things if random boards break > > I don't think anyone was calling for a "suse engineer". Users were > asking for the openSUSE ARM contributors to take a look at the > regression. I don't think anyone excluded "non-SUSE" people from > looking at the problem and fixing it. [...]
The people that took action here - myself, Alex, Andreas - all are, and we're less than the users asking. If everyone non-SUSE waits for someone else instead of pushing up their sleeves then there's no progress, that's all I was saying. >> At FOSDEM Michal and a visitor indicated the latest downstream kernel >> for the Raspberry Pi 2 were 4.1 based, whereas we have a 3.14 based >> kernel > > Thanks for pointing out a completely irrelevant detail, my completely > irrelevant correction follows: We have an image with 3.18 > (Contrib:RaspberryPi2, working) and 4.1 (Contrib:RaspberryPi2:Staging, > not working yet) kernel. Let's be fully correct then: It's 3.18.14! >> - one that apparently no one remembers how it was created > > Maybe the person who created the kernel, who is listed as maintainer, > and who has a git repo which accepts PRs knows how though. Then why weren't you answering when people asked about it. I'm not the one you need to tell, I don't really care. It could be documented a) in the spec file, b) in the package or project description. And some README.txt file in the repository might be a useful feature for people accessing it directly from the Wiki etc. > The kernel was not the problem of the image. The problem is a) people _call_ it an openSUSE image despite not having an openSUSE kernel, and b) users keep comparing openSUSE to Raspbian and blaming openSUSE for the Raspberry Pi Foundation and Broadcom not working with the kernel community properly. If graphics are slow in the mainline kernel then that's not our fault and people should contribute to improving that there; otherwise doing a KMP against our kernel for that driver specifically would be better than offering a whole alternative kernel for laziness. Whenever there's two (or more) download locations we can be sure that someone will choose the wrong one, therefore we need to limit choices. The Contribs had packages violating OBS rules wrt binary userspace programs, misusing SUSE-Firmware license, failing for a long time, adding non-essential contrib packages to the official JeOS, ... do I need to go on? I don't understand why we still have Contrib:RaspberryPi. I would've deleted it when the download location discussion came up again had not Guillaume recently updated raspberrypi-userland. >> Mainly the convenience stuff around Kiwi images, that I am not an expert >> on, "constantly" breaks in one way or another. > > Right, which is not a problem per se, because we're all humans and we > make mistakes. Common practices like peer reviewing changes or > respecting maintainership definitions can help though. Then you could start with giving me a chance to review kernel config changes and not changing them behind my back and, without asking me first, dropping options that I invested time to make consistent! No notifications are being sent when -rc1 has been checked in (last time I checked it was upstream but not in master) or when someone pushes changes. Sometimes SRs are ignored for weeks, then someone submits and accepts their own and tells everyone else to rebase them despite seeing no issue with them. Review and times we work on things never are in sync. Other times SRs get accepted quicker than I can re-review my own diff. Also we will never get u-boot or dtb-source updated in Factory if we keep superseding each other's SRs rather than waiting while an in-flight one goes through Staging and Factory review. Missing links is a recurring pain point that some of us maintainers can't remedy ourselves. And may I remind you that there is no devel project set for JeOS. Not that it would help with the armv7l build power problems with existing images not getting rebuilt within two weeks. Part of the official OBS workflow is also using Submit Requests and not committing to Contrib projects directly, which then leaves me and other people without change notifications. Please Don't Do That. Yes, a lot of things can be done to improve the situation. Some others are limited by our build power unfortunately. Yet others could use some better support on the osc (branch) side. >> None of us on this list updated/broke systemd however, so that left us >> with no one responsible reading the armv6l complaints here. > > I don't see many people complaining at all. I do see a group of people > caring enough to report issues though, and I'm personally very happy > to see that they care about something that I care about as well. There's been at least a handful of people complaining about Raspberry Pi images specifically, I can't help you if you didn't see that. Including a cascade of self-replies by one such user that the image was still not working - obviously if no one works on it it would be surprising if it suddenly worked again. Including someone setting deadlines until when he needs a working image. Now if you want to blame me for some of the causes, say it clearly. * Had people not piled up packages in Contrib:RaspberryPi I wouldn't have needed to spend time cleaning them up (raspberrypi-firmware,pihwm). => Give less people maintainer access, reject optional packages and let them go through the usual review processes outside the ARM team. * Same if someone had been thinking earlier about updating a running system rather than piling up stuff in the JeOS image initialization only (raspberrypi-firmware-branding-openSUSE, /boot/vc). => Put BeagleBoard alsa config into alsa (Takashi can help get that upstream if needed), create individual *-branding-openSUSE packages for dracut configs. May involve splitting configs by boot media. * Would Kiwi simply put any files installed to /boot in one partition, we wouldn't need to patch Kiwi again and again (/dtb-*, /boot/vc). * Would we have Staging Rings for ARM then dtb-source and u-boot changes would not arrive via Factory accept without being tested against JeOS. Limited by build power and patience. * Would JeOS actually have build-time checks and fail when files are not in the expected location, some breakages would've been easier to spot (/boot/vc). * Would we stage dtb-source from Kernel:linux-next through Kernel:HEAD to Base:System we could test some additions much earlier (dtb-meson8b). Downside is such branches would silently break whenever someone changes Base:System. Similar merge problems exist for Contrib JeOS branches. * Would we have an archive of known working Tumbleweed images then temporary image breakages wouldn't be as severe. 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-arm+unsubscr...@opensuse.org To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
