"we replace exim with postfix as the default MTA",
Ahhhh, 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).
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 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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 486 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 136:43:45 |
| Calls: | 9,657 |
| Calls today: | 5 |
| Files: | 13,707 |
| Messages: | 6,167,060 |