On Sun, Feb 16, 2025 at 05:29:26PM +0100, Chris Hofstaedtler wrote: > On Sun, Feb 16, 2025 at 05:18:39PM +0100, наб wrote: > > Quoting the relevant: > > > It is recommended to choose between one of the two following schemes: > > > 2. Put the mailing list address in the Maintainer field. > > > In the Uploaders field, put the team members who care for the package. > > > > In the packages salvaged into the salvage team we have a choice between: > [..] > > 3. Maintainer: salvage team > > > [..] > > 3 is a better fit for what I term dead-end packages > > (ones that truly no-one cares about, with no upstream, > > or no maintainer, or no utility, or otherwise 0 forward motion; > > and with little potential to generate bugs except 1 FTBFS/decade). > > This is most of the salvage team packages. > > Why are what you call "dead-end packages" "salvaged" at all? I seem > to recall that the salvaging process is for packages you actually > want to maintain. Because a more aggressive RM RoQA policy got me yelled at last time for making work for the ftpmasters, so I stopped arguing for RMs and do Andreas' preferred methodology of salvaging everything.
Doing this allows packages that tend to be in a functionally-orphaned state to be team-maintained in the long term. This satisfies the salvage criteria as I see them and I have an equal interest in every weird ancient FTBFS these packages generate. This also sets up the packages to be RM ROMed when they do fizzle out. But, consolation. > If the packages are "dead", RM them. > Not doing so is a big disservice to the project. I thought so too, yeah. Best,
signature.asc
Description: PGP signature