Hi Cyril, sorry for my late reply - I was basically offline the last couple of days.
Am Sun, May 26, 2024 at 08:55:37PM +0200 schrieb Cyril Brulebois: > What follows is only my point of view, and anyone active within the > installer team is welcome to share their own. Thanks a lot for your extensive answer. Your personal view is really important to me. I did not (yet) received so many extensive responses to my contact mails. > ACK. TL;DR: no strong organization, mainly some coordination around > releases, but otherwise debian-boot gets to consume whatever ends up in > testing/unstable, and has to adapt accordingly. Of course we have some > packages on our own in addition to all the dependencies that we don't > maintain. > > You might have notice some heavy pushes in the past to get firmware > support improved (enough to avoid black or unreadable screens post > installation, in earlier releases), or to get non-free-firmware included > (in Debian 12). I need to admit I rarely use your great work - just when buying a new machine or setting up some machine of a friend which finally boils down to once a year in average. But I confirm things became better each time. So thanks for all your work. > I don't have any important or urgent needs at the moment, but I won't > hesitate if I spot something that could benefit from your input. Fine. > > I'm sure not everybody will be able to travel this distance but it > > would be great if you would at least consider joining that BoF > > remotely. I'll care for a somehow TimeZone aware scheduling - if > > needed we'll organise two BoFs to match all time zones. I'm also > > aware that we have pretty different teams and it might make sense to > > do some infrastructure related BoF with your team and other teams that > > are caring for Debian infrastructure. > > Anticipating and planning a full week (or more) off that much in the > future is something I can't do at this point, but I'm usually fairly > flexible when it comes to timezones, so joining remotely should work, at > least in principle. Thanks for confirming. The BoF will definitely happen in the first half of DebConf since I need to leave before DebConf ends. > > I have some specific questions to the Debian Boot team. > > > > - Do you feel good when doing your work in Debian Boot team? > > That's been the case from the moment I joined (around 2012, even if > first contact happened in 2010-2011 with the DirectFB → X.Org > transition, see https://mraw.org/blog/2010/01/31/Saving_private_GI/). Good so far. > And until last year, right after the Bookworm release, for reasons I > cannot and wouldn't want to express publicly at this time (relevant team > Bcc'd). What should have been a thumbs-up-all-around celebration turned > into the most severe burnout I've ever felt, personally, professionally, > and “debian-ly”, right after having sacrificed a lot (on all 3 > accounts). > > I can endure hard work. Feelings like betrayal or distrust is something > else entirely. This sounds like the things I wanted to learn. Feel free to contact me in private if you think I can be of any help. > I've come back to doing a few things here and there (including dealing > with 64-bit time_t fallouts on the d-i side, reviewing Netplan's initial > integration, or blends stuff as you know), but I'm nowhere near to > feeling good again about doing d-i things. Thanks a lot for expressing this. > Which is absolutely heartbreaking because I've been doing that for a > while, still enjoy doing it, and really don't want to leave it. And even > if I'm not one to boast, I thought I had been doing a pretty fucking > good job. Until last year that is. My personal perception was always that you are actually debian-boot team in person since >10 years (which might be unfair for other team members) and my personal thanks (independently from my DPL position) goes to you. > We have a very diverse team with people dealing mostly (but not only!) > with i18n/l10n coordination (Holger), with QA (Phil), with some specific > components (flash-kernel), with specific set(s) of images, etc. It's > more a bits & pieces depending on one's area(s) of interest. Thank you for the explanation fixing my perception I mentioned above. > In the end, I'm the one making sure things look “good enough” when > preparing a release makes sense, usually in coordination with various > teams (see frequent mails to -boot, -release, -kernel, -cd, and -live > during the bookworm release cycle, and also in previous ones). I don't > think I need to prepare any statistical analysis, but if memory serves, > those mails have usually been met with silence, tacit or explicit > approval, and I don't remember any crazy ideas from mine needing to be > shot down or rehashed differently -- even I wouldn't mind if it > happened: I know freezing testing can impact any maintainer, but the > -boot/-cd release process has been quite improved over the years (also > with the help of -ftp), and it's usually about skipping a few britney > runs for /some/ packages anyway, so overall impact should still be > minimal. Must be some fascinating work. > > - Do you have some strategy to gather new contributors for your team? > > I've always tried to communicate about what we're doing (via list, blog, > talks…), but I don't have any plan to get more people involved. > > Even if we had brand new people joining all of a sudden, the learning > curve is steep, and they would likely need some mentor to guide them > through, which also requires time and effort, and time is the scarcest > resource in the world in my view. ACK for the time resource. The steep learning curve is something I expected. I keep some mental note to advertise debian-boot team in case somebody might ask me how to help Debian. > ... > As alluded to above, 2023 was different, since we've had a decision via > GR about non-free-firmware for several months and nobody doing anything, > and I ended doing most of the work in many areas (thankfully with people > ACKing/deploying changes I submitted and/or further changes where I > couldn't do that myself), which required sacrifices. I wouldn't want > that to happen again, but I'm not aware of any more such game changers, > so a redux seems unlikely (famous last words, eh?). Thank you for pushing through such a change. I admit I'm just coming from "the user side" of debian-boot and IMHO non-free firmware is a big enhancement from this point of view. Before this I simply had to use the inofficial images which simply nothing we really want. > > - I recently had some discussion on Chemnitzer Linuxtage what might > > be the reason for derivatives to write their own installers. While > > I'm personally perfectly happy with the way I can install Debian I'm > > somehow wondering why others are spending time into a problem we > > are considering "solved" and whether we can learn something from this, > > I've already said that multiple times: we have people regularly coming > up with brand new ideas on how d-i sucks and how they're going to do > better. They're absolutely free to do that, and we already have various > ways to use d-i, plus debian-live's installer. > > Actual work and commitment, that I haven't quite seen. :-) ... or rather :-(( I'm aware of this problem in principle from the long term work I'm doing. Luckily I also made positive experiences when people started realising changes they suggested. > I don't want to put words into debian-cd's mouth, but I think Steve and > I already agreed a few times we could be running extra build steps to > generate different images with different approaches to the install > process, and I've never stopped anyone from doing so. > > Keeping the status quo requires quite some work already, and I cannot > (and also don't want) to lead any “let's break it all down” revamp. But > again, I'm not stopping anyone from proposing something different. Its the attitude "I know better but have no time to implement it" we are facing frequently. Answering those ideas costs extra time with no result. However, my question was rather whether you know some valid reasons why derivatives are exchanging the install method - maybe that question should be better asked on Debian-Boot (if so feel free to ignore this question). I was rather wondering about the motivation for the usage of Ubiquity or Calamares (or others?). I might be naive but from my perspective installing is something that just needs to work and having a lot of ways to make this working is somehow burning developer time. So what according to your insight is motivating derivatives to solve a problem in a different way that is IMHO solved by Debian. > > - I once had a amr64 based laptop (Pinebook) and had to learn that I > > can't use the Debian installer which was frustrating. I was told > > that this is the case for hardware that is not featuring some BIOS-like > > boot system. > > [citation needed] > > > Do you see any chance to let the installer work for > > non-Intel architectures (or should I rather ask this question on > > Debian CD (sorry for my ignorance if I miss responsibility here.) > > debian-boot is fine, and we work hand-in-hand with debian-cd anyway > (the intersection between team rosters is… not empty). > > I'm not sure why you have the impression the installer only work on > Intel… See the architectures for which we provide images, Sure there is an arm64 image and I started with copying this to some USB stick. But that hardware did not booted from an USB device but only from eprom that had to be flashed via SD card. Its not your fault definitely but was frustrating for me not beeing able to simply run the Debian installer. > the installer > is expected to work on all of them. Of course there could still be > specific problems for this or that model of a given architecture. But > that means filing a bug with details, then see what it can be done. In this case I should rather have filed a bug to the pinebook manufacturers. > arm* are special as they can be booted in many different ways, like a > specific bootloader (Raspberry), u-boot (maybe a vendored copy), and/or > flash-kernel (details depend on the board, revision, configuration, > etc.), and possibly others. I don't mind any more. I've given away that machine to some other DD and will wait until some hardware is available that can simply boot the official Debian install media. > Last I heard about Pinebook, some patches were missing in the upstream > (and Debian's kernel) to work at full speed, but the claim above is > overly broad and totally false. It was not really a claim but a question based on my experience with a single piece of hardware. I was hoping for some ideas how we could motivate hardware vendors to deliver hardware that can be easily booted by simply plugging in some USB device featuring the installer images we provide on our web page. > > - Can I do anything for you? > > Not at this time. Just keep in mind my offer to contact me in private if needed. > Tschüs! Salut! Andreas. -- https://fam-tille.de
signature.asc
Description: PGP signature
