Hi Didier On Tue, May 7, 2024, at 2:25 AM, Didier 'OdyX' Raboud wrote: > Hello there Mark, > > thanks for your email, and for the followup ping; weeks are well-filled with > $job, baby and other involvements.
Congrats! Exciting times (my eldest just passed her driving test last week...the time flies by far too fast...enjoy it!) > > Regarding firmware-nonfree updates, I have related my last-years' experience > on d-devel: https://lists.debian.org/msgid-search/2390124.3VsfAaAtOV@turnagra > Interesting read. I do skim the debian lists and I'd missed it. Some notes further below that I think are related to the points you raise in there. > I insist: I am absolutely not implying that Ben is doing anything wrong; I > just observed that he was mostly alone in a bottleneck position for that > package. > > What I did back then to try to help getting the firmware package in better > shape was to dive in the (complex) packaging and try to produce "ready-to- > merge" merge-requests for new upstream releases, fixes, etc, then pinging Ben > at (what I considered) reasonable intervals. I see that Diederik (CC'ed) has > started to do the same for recent versions. > > The package is complex and a mined land of legal concerns, the upstream repo > needs repacking, and the (upstream & debian/) repositories are split; I have > not found this a very pleasant experience, sadly. And again; no-one to blame > here: there _is_ tooling to help, and immense work has been put towards > making > this manageable! I'm merely saying it's not a matter of running "debian/rules > get-new-upstream" at all. > > From where I sit (that is: I only modestly contributed in the past, and > cannot > commit to much these days), there are two angles to address: > A) lift the bottleneck: there needs to be more Debian Developers confident to > comment and merge MRs, and then upload. > B) regular commitment: I feel it would be easier to get regular updates > merged, rather than doing the huge batch shortly before release; that would > also appease the tensions that many probably feel when they get new hardware > but no available package. So, this may be naive, but I think this is potentially a good place for myself and (hopefully) some of the Lenovo team to get involved and contribute - at least on (B) in the short term and maybe eventually on (A) in the longer term. I really want to support the community distros that are at the core of Linux - I think it's important. It's also, honestly, what makes me happiest. I also think that, realistically, nobody really wants to mess around with non-free FW because it's just not very interesting. But it's needed as the vendors themselves don't particularly want to get involved with packaging (I do the Debian firmware-sof-signed package for the Intel audio FW because of this). Lenovo has a big advantage in that we have the hardware available, earlier, so are able to identify what's needed and do testing. My biggest problem is how to get started. As noted above, I do the SOF firmware packaging so I'm not a complete noob, but I'm not particularly experienced either. I have the steps I need to follow, and I do that, test, sometimes fix minor issues and that's it. I should flag, I'm not a DD or DM (FWIW, I'd like to be one day, I've just not earned it yet :)) I'm open to ideas and suggestions, but (particularly for the linux-firmware pieces) I think we (Lenovo) can help here, if someone is willing to give some help to get started. I appreciate there needs to be appropriate mentoring and checking in place - but if there's something we can do to get some of the grunt work done so that MR's can be checked please let me know how to do that. > > As to how I can get involved in any of the above; I can't reasonably add this > to my plate these days (and would rather _not do_, than commit to do and > fail). > > But I wonder if some financial sponsorship (if Lenovo and others would be > open > to something like that) could help, via Freexian for example (disclaimer: not > for me to do it; I'm not a Freexian person). I'd be concerned that this would > only solve B above though. It would feel like a 1-2 hours job / week. > If $'s solve it - I'm open to suggestions. I have to caveat it with the fact the Linux project here is not making money...I don't have budget to burn. I'd rather get involved directly and contribute and enable others in my team to contribute directly too, I think that has more real value. If the answer is just money, then let me know and where I should take that discussion - I'm not averse to it, but my previous experience is that money doesn't solve the problem - the issue is more having hands to do the work (I think the Debian budget reports confirm this FWIW - money is not lacking). > I hope the above helps you navigate that question, and that it helps the > situation in general. > Thank you for all the pointers! Mark
