Hi Diederik, On Tue, May 7, 2024, at 11:17 AM, Diederik de Haas wrote: > On Tuesday, 7 May 2024 15:49:45 CEST Mark Pearson wrote: >> > As I see it, the primary problem is the lack of people actively >> > contributing to the Debian kernel team's work. In general. >> >> Interesting read, and combined with my notes to Didier - is this something >> where I and some in my team could maybe help? If you think it would be >> worthwhile, does it make sense to setup a training session to walk me >> through the steps so I can attempt a first pass, and then review where the >> problems are and which bits are useful/not-useful. If the review/link >> updating/etc was all done - would it make it easier for a DM to look at it >> and go "yeah, that's solid" and release? > > *I* don't see where you/your team could help now. At least not for this > particular issue. General help with f.e. bug triaging would still be welcomed > I presume. > > At https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/ > you > can find the MRs I made to make the firmware-nonfree packages all up to date. > MR 85 is 'the BIG one' and in there I also mentioned that I also have an > update to 20240312 in my fork which I can submit as MR too. > > MR 85 is also reviewed by a DD, but while they are *allowed* to make uploads > for any package, they choose not to. And FWIW: I agree with that. > > I already mentioned that MR 85 is a BIG one (but the only one which needs to > go through NEW), which in turn means that reviewing takes more then 10 > minutes > (to put it mildly). > The update to 20230804 is also larger then average as some changes needed to > be 'postponed' due to needing a new upstream version. > > The updates after that are indicative of what I suspect/hope future updates > will look like. Unless a kernel-team member thinks that I didn't do it > correctly. While I did my best, that's surely a possibility. > > So if you want to know what's generally involved into updating the firmware- > nonfree packages, I suggest to look into my MRs. > I have a tendency to be verbose in my commit messages, which may help. > And the procedure I described earlier should match what you'll see in the > updates after 20230804. >
Cool - I have taken a very quick look and kudos - amazing job. A few follow on questions: - It looks like it is stuck on someone doing the upload (guessing nobody has time to do that). Unfortunately I can't help with that bit - not a DM and nowhere near enough experience. Any recommendations on how to unblock that? It doesn't seem like testing/reviewing would help - but if you have any insight as to what would make a difference let me know. And, thinking about the comment previously about funding - is this something where somebody needs some paid time to do the exercise? It's not something I can promise (and dealing with Lenovo procurement is a special form of hell), but if that's the blocker then I am happy to go and shake some branches and see if there's a way we can help out. I don't want to cause offence and assume that's the answer though (and FWIW, I would prefer my team to contribute directly through knowledge/skills as I think it's better in the long term). - I love what you've done with the monthly cadence of updates, that seems smart to me but I appreciate it's a chunk of work every month. I also noted in one of the commits you mentioned "I don't particularly care about this package, but just wanted to do something about the (big) backlog AND make it easier to prevent a backlog from appearing again in the future (by making it easier for everyone to make an update)", so I'm assuming you'd like done with it ASAP. You noted earlier that it wasn't documented and added some useful notes. Would it be helpful to work through that process with an idiot (aka...me) to get an initial document down as a starting point? With the last MR being a few months old now, would it be reasonable for me to take a stab at doing an update and (worst-case) learning from it? I don't want to tread on any toes, and I will almost certainly need some guidance, but it seems like there is interest in helping out from other users too (based on the comment thread). If we can figure out the upload piece, it looks like the infrastructure work you've put in would pay off. - Previously you noted "Upstream now also produces a deb package per tag/release" - I had a look for those but couldn't find it. Do you have a location I can check those out? Figured it would be interesting to have a look. >> I can't highlight all patches needed for Meteorlake/Hawkpoint support - that >> would be huge. I can highlight that a 6.8 kernel is needed; and which FW >> packages are needed. > > While firmware package updates have lagged before, the kernel packages are > normally quite up-to-date. But sometimes there are other factors which cause > delays which normally aren't there. The time64 transition f.e. caused 'some' > disruptions. > But (my) update-to-6.8 MR has now been merged into master, so an update to > the > 6.8 kernel is in the works. > That's awesome. If you want any sanity checks run on it, let me know - I have a number of platforms running Debian that I usually use for testing the firmware-sof package updates. Thank you for all the insights. Mark
