[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions for all candidates



Hello,


>1. Community Team
>
>How do you feel about the Community Team?
>
>Is there something you would change?

Hello, to be honest I didn't ever follow closely the Community Team work. For this reason my main answer is that I
would like to see more visibility on the Team activities and existence, I'll contact them shortly after this email.
 
>Do you have any ideas in how to support them so that they can help our 
>community better?

yes, I think they might have some higher privileges, to speak with DAM, since their work is a little bit overlapping, maybe some
of them might have a role in DAM work about voting for people restrictions.
We might have some way to make the two team interact more closely when needed.

>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 *really*, *really*, *really* like to use git, and I don't really use/like anything that is not git at this point of
my life.
I have used SVN/mercurial/CVS and something more, but right now git is so far my preferred
choice for coding activities, and I would like to not change it for anything else unless proven to be
superior, and right now there are none with this level of superiority/adoption out there.

I really like salsa, and I don't think we need anything to change except for improving, and this is already happening
(hey ci/cd people, thanks for your work!)

>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?

Yes, we have many cases where (I did) use debian namespace as collab-maint,
and did a Team Upload (salsa.d.o/debian namespace)
as changelog entry.

I'm probably the person using most this debian collab repo to quick upload fixes
for packages we care about.
I would promote a new salsa.debian.org/debian-non-collab or something similar
if somebody wants to maintain in collaborative way, but without people team uploading.
Or maybe we can add some debian/README text explicitly saying so to make
people aware that Team Upload si not allowed.

For me allowing people to touch a package and not upload it is a non-sense (personal point of view, of course)
the reasons are:
1) even if broken, we can always followup with a new upload
2) we care about users, not git. What is committed in git might not end up in stable release, and then not be seen/installed
by end users/derivatives.

If we consider end users as our main "customers", we need to bring fixes to them, and not to git.
(I don't like the word customers, in this context, but I think what makes Debian great is the usability, and this is why
I prefer fixes to go in testing as soon as possible. An user not noticing a bug because it is already fixes is an user that
will probably continue using Debian)

>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.
>
>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 support this idea, for reasons I couldn't attend any DebConf yet, but I plan to
start attending them in the future.
One idea (probably bad I know), might be to consider shifting the time of the DebConf
by some days every year, to allow people have higher chances to attend if they
coudln't have vacation period in august.

Not sure if this is a good idea or not, but might be worth a discussion

>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 use nowadays a netinst iso, because internet is cheap, and I don't want to
install something already outdated and update it later, but I understand the
people using people using the complete installation media.

I think we might have some feedback page on the download page, to know
what the end users think and want, this might be the best way to really understand
if what we are providing is used/useful or not.

Also download count statistics are useful (although not always, because also mirrors
exists)

>5. Favourite colour
>
>Ok, I lied, here's an easy question for you, what's your favourite colour?

I don't have the knowledge background to answer this question.
I would pass the artistic things to the people with the right skills :)

I think we shouldn't have right to vote on everything, but rather ask people of art team to make the choice for
us, and similarly, every domain should know/decide for their specific activities whenever possible.

I'm a coding man, I enjoy art, but I can't make it :)

thanks for reading!

Gianfranco


Reply to: