Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Am Tue, Apr 09, 2024 at 01:03:10PM + schrieb Stefano Rivera: > > I have also noticed that the young people we manage to recruit are > > usually not interested too much in the boring gruntwork of maintaining > > important core packages (like adduser and sudo) but instead want to do > > "new" things. But, otoh, what would Debian be without sudo? Somebody > > needs to do that work as well. > > To some degree, this is self-fulfilling. Most core packages have a > maintainer. Drive-by contributions in a bug or MR are likely to go > ignored for years. Newbies aren't going to get pulled into these > packages, easily. > > Where core packages are up for adoption, they're probably pretty complex > and maybe not the best candidate for a new contributor. The best stuff > has probably already been adopted. > > All of this leads to the position we are in, where new contributors best > road into the project is into teams. And the best way to get some > experience is packaging something new in a team. > > I see one of the goals of promoting team maintenance as increasing the > pipeline of new contributors into the maintenance of core > infrastructure. Rather than having to wait for the current maintainers > to slowly fade away and salvage the result after years of problems. Very well said. Congratulations for remotely reading my mind and turn it into those clear words. Kind regards Andreas. -- https://fam-tille.de
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Hi Marc (2024.04.08_16:48:13_+) > I have also noticed that the young people we manage to recruit are > usually not interested too much in the boring gruntwork of maintaining > important core packages (like adduser and sudo) but instead want to do > "new" things. But, otoh, what would Debian be without sudo? Somebody > needs to do that work as well. To some degree, this is self-fulfilling. Most core packages have a maintainer. Drive-by contributions in a bug or MR are likely to go ignored for years. Newbies aren't going to get pulled into these packages, easily. Where core packages are up for adoption, they're probably pretty complex and maybe not the best candidate for a new contributor. The best stuff has probably already been adopted. All of this leads to the position we are in, where new contributors best road into the project is into teams. And the best way to get some experience is packaging something new in a team. I see one of the goals of promoting team maintenance as increasing the pipeline of new contributors into the maintenance of core infrastructure. Rather than having to wait for the current maintainers to slowly fade away and salvage the result after years of problems. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
[I'm skipping most of this email because I haven't generally been keeping up with the thread, but thought it might be worth pointing out one thing.] On Mon, Apr 08, 2024 at 06:48:13PM +0200, Marc Haber wrote: > On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > > Before uploading I usually > > run `routine-update -f` which is just upgrading to latest standards by > > calling Janitor tools and does some other changes to keep up with latest > > packaging standards semi-automatically. > > I wasn't aware of that tool. We need to publish more about such things. > > I am not particularly fond of Janitor's suggestions though. For my > taste, it removes support for older versions of Debian too quickly, and > I have frequently chosen to not accept janitor MRs because this would > affect ability and ease to backport to oldstable or even to > oldoldstable. But that also is a matter of style. I'm not sure how widely known it is, but the Janitor does have a mechanism for overriding the versions of Debian it retains compatibility with based on various considerations, and I've found it useful to land changes there in the past so that its other facilities can still be useful without getting in my way. Search for "compat_release" in https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
On Monday, April 8, 2024 12:48:13 PM EDT Marc Haber wrote: > > > "we replace exim with postfix as the default MTA", > > > > A, this question always makes me wonder: If our default MTA is exim > > why do I have such a hard time to find documents about exim in wiki.d.o > > while there is always a postfix solution. I personally usually go with > > the default and thus using exim. But well, if it comes to tricky > > details I always need to fall back to the longish exim docs while the > > short solution is available for postfix in wiki.d.o. > > That's the next chapter in the great MTA war which has been won by > postfix. As somebody who has been working on Exim in the 2000 years (I > am still on the team but haven't done anything useful to the package > for 15 years), I of course must say that Exim is the better MTA; but it > is way harder to use. > > I tend to use the metaphor that Postfix is the menu of a nice restaurant > run by professionals, offering much that you might want to eat, while > Exim is the fully equipped kitchen with a storage full of the best > ingredients, but you need to cook yourself. Summarized, if you find > something on the restaurant's menu that feels your need, order that > dish from the Postfix menu, and if not, go to the kitchen and cook your > own Exim menu. > > And of cours, Postfix's architecture is more modern while Exim still is > a monolithic, suid root blob, and Postfix also is more suitable for > sending out bulk mail since it is way better parallelized tham Exim is > (exim's disadvantage in this regard doesn't show as blatantly on a very > busy system with a full queue). For the record (as the only active maintainer of postfix), I am super happy that postfix is NOT the default MTA. There are enough bug reports as it is. One additional point that I have not seen mentioned is the cognitive load associated with team maintenance. Almost all the packages are team maintained and that's great for things where we have general consensus on how to go about things (like Python packages, where most of my work is), but having multiple maintainers also then requires coordination and resolution of disagreements. For postfix, I prefer that I don't really have to deal with that. If something's broken (in a violates policy, breaks things for the user kind of way), I don't mind NMUs if I'm not paying attention (that does happen sometimes), but the original maintainer of postfix (lamont) made some opinionated choices about the package that I think it's not practical to undo now and I am glad I don't have to argue with people about that (much). Scott K signature.asc Description: This is a digitally signed message part.
