(apologies if there's typos and stuff, I got cut a bit short in time and I haven't tested my draft folder yet - time for my dad's bday dinner :D)
On Mon, Mar 17, 2025 at 03:01:38PM +0200, Jonathan Carter wrote: > Dear candidates! > > Firstly, thanks for stepping up for running for DPL. > > Unfortunately, outside of maintaining my own packages I've had little Debian > time for the last few months, so I'm not as up to date with all the Debian > problems as I'd like to be. > > But, lucky for you, there's enough difficult questions to go around! (sorry, > you're all experienced DD's, so no low-ball questions here, take it as an > opportunity!). Some of it is very specific and some more open-ended, answer > as little or much as you like. > > 1. Community Team > > How do you feel about the Community Team? > > Is there something you would change? > > Do you have any ideas in how to support them so that they can help our > community better? I have conflicting feelings about the community team. I think they are doing a very important job, but they must also be careful not to let themselves get weaponised by targeted hate campaigns. I had my own conflict there last May when I had a particular poor choice of words in the KeePassXC bug tracker and then got chased by an angry mob for the next days on multiple channels. Some people enjoy destroying another person's life. What was upsetting there, was that while we resolved the technical aspects the same day pretty much, it took the community team 16 days to get involved and send me an email about receiving complaints just as I was about to forget about it and get some closure. Can we do something about that? I don't know. The complaints may have been going on all those weeks, and how to get all the information to them without asking the accused party? But anyway, personal anecdote aside, I think the more challenging aspect for the community team is emotional damage. I think this incident was comparatively mild to what else they have to deal with; and it makes me wonder how we can support them emotionally. I wouldn't want to leave a community team member on their own with emotional damage from that work, if they need some counciling and therapy. Depending on where they are, getting help is almost impossible because it can take months and calling hundreds of therapists to find someone and then you need to potentially travel for hours to them because nobody closer is available. On the other hand there are therapy service providers that maybe we could contract to provide support to the people doing these critical jobs. But frankly this is a topic where I'd need a better understanding of the emotional challenges and also the financial aspects. > 2. VCS > > Salsa has been stable for a number of years now, and git is clearly a good > choice of default VCS (even though not perfect or preferred for all). > > How do you feel about VCS requirements in Debian? Should it be required that > Debian packages are maintained in Salsa? How do you feel about dgit and > tag2upload? > > Do you have any ideas about VCS use in Debian that you would promote as DPL? I disagree with some of the technical choices in dgit, that shouldn't be a particular surprise, given I filed bugs about it. I do believe that every package in Debian should be in a git repository, auto-imported if needed, and that should be on equal footings in our expectations for maintainers to accepting patches in the BTS - maintainers should participate in merge proposal workflows for their packages and merge patches submitted that way. I mentioned this in another email recently, Ubuntu has automatic git imports of most of its packages, and treats merge requests in those git repositories as equal or more recommended than debdiffs; and I think this has tremendously improved quality of life, both in submitting changes as well as reviewing changes. > > A while back someone told me that they want to NMU one of my packages. It > was maintained in /debian on salsa, so I reminded them that this is > basically collab-maint these days and they did the right thing and just did > a team upload instead. Julian mentioned common package maintenance in how > it's done in Ubuntu. What do you think about the /debian team and would you > want to promote the use of that as DPL? I think I famously had a disagreement there where I don't think that the debian teams implies low NMU or a team maintenance; but I may be the odd duck out in that I am strongly attached to my packages (which for apt makes a whole lot more sense than for dh-autoreconf...). In any case while general team maintenance of that sort provides opportunities to get stuff done, it - some of us in Ubuntu had a bit of a discussion about that just this year I believe - also presents significant challenges in that there is no strong sense of ownership and responsibility. > 3. DebConf > > DebConf is great. I hate the process of getting a visa to travel (often at > least a whole day's worth of admin), and I don't like airports or travel by > plane (which is usually at least two days in each direction). And yet, I > sacrifice about 1% of my year just to get to DebConf, because it's worth it. > > Often though, I feel like DebConf can be better. My biggest wish is to have > more core Debian people there. Often, sessions are planned to discuss really > important and crucial things, but then we don't have the key people present > to really dig into it and bring it forward. At some point I've wondered if > we should invite-by-default certain members of certain teams. Make it clear > that there will be travel and accommodation and food for them if they want > to come. It might not be enough to convince people with children or other > commitments at home, but perhaps it could help a little. It's an interesting thought and I always wonder how to get DonKult to a DebConf again to have an APT hackathon :D I think that may have been a bit of an extreme issue in the last two years because we had been in Asian countries, and core team members are usually somewhat American and Eurocentric. So I think you can approach this by making core teams more regionally diverse, such that you have someone in each time who doesn't need to fly around half the globe and can represent their team at that DebConf. > > I digress, this isn't about my gripes with DebConf, it's about yours. What > do you think are the biggest problems with DebConf, and if you had a magic > wish or two as DPL to change things, what would that be? I'd love to see more team workshops and sprints, talks are a way to talk mostly about what you have done but not a good tool for planning things or getting work done which is where in-person meetings really excel at. One thing I find challenging of at DebConf, and skipped the past 2 years is the conference dinner. The one-off catering choices always result in no decent food for vegans, and it can be quite loud and I can't have a conversation because I don't understand people anymore. > > 4. Installation media > > It's amazing how much Linux distributions offer in the variations of > installation media (like ISO images) they provide. > > For example, Ubuntu differentiates between a Desktop and Server installation > image. OpenSUSE too and they also have LEAP (a rolling release) and some > distributions also offer immutable install options. In Debian we offer the > netinst iso as the default from our home page, with a link that leads to > larger installation images, live images and cloud images. > > Do you have any opinion on the selection of images that we provide? Is it > optimal? Can we do better? Are there features that you would consider > missing? > > Not an essential question for a DPL candidate, but it's interesting to know > your thoughts on this and get more insight on how you think about Debian. I think having separate install media for separate use cases is good; and I'm not a huge fan of the way we produce pool media that if you apt-cdrom add them, there is no validation as they're not signed; so my preference generally is install media for bootstrapping new systems from fixed images or layers of images, rather than debs; that also should be significantly faster. I would _love_ to have an official Debian version with an immutable base system and containerised apps. On that note, I'd also like to get the hybrid approach SUSE takes where you install to btrfs and then you upgrade the snapshots instead of the live system; this way you get all the flexibility of individual packages but also the reliability of image-based upgrades: if the upgrade fails half-way through, you just discard the broken snapshot. If it fails to boot, just revert to the old one, etc. > 5. Favourite colour > > Ok, I lied, here's an easy question for you, what's your favourite colour? I feel like this is the second hardest question ofthe 5 :D Back when I was a child I believed red was my favourite colour. These days I am not sure I have one, to be honest. Some things just have iconic colors. Like if I bought a Ferrari, it would be red. If I bought a Bianchi bicycle, it would be Celeste. A Pinarello, red. Crazy how this goes. I do quite like white bikes, though. My clothes are very muted in color choices. With the jeans comes a lot of blue, and on practical terms while I like black it also looks bad to soon. But you know I also have very aggressive yellow colored t-shirts and a lot of crazy neon cycling kit. Sometimes in summer, I just like to break my norms and wear extremely colorful things. Sometimes I wear pink armband to also break gender expectations lol. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
