Le Tue, Apr 09, 2024 at 12:18:02AM +0200, Johannes Schauer Marin Rodrigues a écrit : > we need both. Domain specific knowledge is clearly very important and I'm not > trying to argue against it. But doing packaging in a way such that it becomes > easy for others to contribute is *also* every important. As the maintainer of > a > package with expert knowledge of it you might think that there is nothing to > do > but you while you are the expert for that package, you might not be the expert > on topics like cross building, reproducible builds, multiarch, build profiles, > merged-/usr, build hardening and many other topics which span the whole > distribution. There are people who are heavily invested in these topics and > who > will want to touch very many packages to fix things. It should be made easy > for > them to make these contributions without them bit-rotting as a patch in the > BTS > for months or years. I'm not saying that *you* let these contributions > bit-rot. > This is meant as a general argument for making it easier to make large-scale > changes to packages. Diversity in our packaging styles and strong package > ownership sometimes work contrary to issues affecting very many packages > across > our distro.
These contributions always need to be carefull reviewed before being accepted. As likely as not, they are either slightly incorrect or introducing subtle breakages in some case the submitter did not envision. This is where an expert maintainer is most needed. People heavily invested in some topic tend to forget the packages has other users, and often fix the symptom instead of fixing the problem. When a change leads to a RC bug a month or three after having be part of a package, fixing the problem falls on the maintainer and not on the change author. Even correct changes can trigger latent bugs in software. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
