Hallo Andreas, What follows is only my point of view, and anyone active within the installer team is welcome to share their own. Andreas Tille <tille@debian.org> (2024-05-26): > I'd be really happy if you would find some time to answer my questions > at the end of this mail (preferably in public on the list but private > answers are fine as well. > > I'd like to officially contact all our teams to learn about potential > issues that might affect your work. I would love to learn how you > organise / share your workload. If you do some regular meetings - be it > on IRC, video conference or whatever I'm interested in joining one of > your next meetings. 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). > Like previous DPLs, I'm open to any inquiries or requests for > assistance. I personally prefer public discussion whenever possible, > as they can benefit a wider audience. You can find a list of contact > options at the bottom of my page on people.d.o[1]. Thanks for the reminder. We already enjoyed Jonathan Carter's ACK to get some hardware shipped to my place for “baremetal testing” (Bcc'd, thanks again!) or travel expenses for the release session last June, so that we would finalize debian-boot/debian-cd together for 12.0. 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. > I prefer being offline when I'm away from my keyboard, so I don't > carry a phone. In urgent situations, I can provide the number of my > dumb phone, though it may not always be within reach. Feel free to > ping me via email if I don't respond promptly to ensure I address your > concerns. ACK, totally reasonable, and I don't think necessary at this point. > Please let me know whether I can do something for you. I'm fine > joining your IRC channel if needed but please invite me in case I > should be informed about some urgent discussion there since I normally > do not lurk on this channel. I've been off IRC myself for some time. > I'd also like to inform you that I've registered a BoF for DebConf24 > in Busan with the following description: […] > 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. > 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/). 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. 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. 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. > - Do you consider the workload of your team equally shared amongst its > members and who actually is considered a team member? (I added some > persons in CC who have recently answered to questions on the mailing > list.) 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. 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. > - 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. > - Can you give some individual estimation how many hours per week you > are working on your tasks in youre team? Does this fit the amount of > time you can really afford for this task? Absolutely not, that's usually about “going with the flow” when time permits and a bug/transition/whatever needing some input or a bugfix comes up (can be a fraction of or several hours a piece); and some burst periods before and during (sometimes after, but I don't remember huge screwups) d-i releases. If I had to give a number, each release can be 1 to 5 full days of work depending on possible blockers to solve before, finding/confirming fixes or workarounds, getting through the archive without being a pain to ongoing transitions and other such things, then into testing. I've spent quite some time trying to streamline the debian-cd process to speed things up, but I don't see myself doing such releases again in the short terme (that effort was part of last year's push, and that's quite bittersweet in hindsight). 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?). Some details in the following blog post, even if further changes were required in many components during the following months: https://debamax.com/blog/2023/02/27/debian-versus-non-free-firmware/ > - 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. 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. > - 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, 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. 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. 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. > - Can I do anything for you? Not at this time. Tschüs! -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature