Re: Questions for all candidates
(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
Reply to: