Re: RFC: Merge Request documenting a contributor-initiated orphaning process in the Developers Reference

--57hwdissoulp5cq2
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: RFC: Merge Request documenting a contributor-initiated orphaning
 process in the Developers Reference
MIME-Version: 1.0

Hi,

(a bit late to the party, nowadays LLMs are the thing to discuss)

On Wed, Jul 01, 2026 at 10:30:15AM +0200, Andreas Tille wrote:
>=20
> Following the recent discussion about packages that appear to lack
> active maintenance, I have prepared a Merge Request against the
> Developers Reference that attempts to document a possible
> contributor-initiated orphaning workflow.
>=20
> The proposal is intended as an optional workflow for contributors who
> encounter packages that appear to lack active maintenance but who do not
> wish to become the package's long-term maintainer themselves.
>=20
> It complements the existing orphaning and salvaging procedures by
> providing a documented workflow for contributors willing to investigate
> a package's maintenance status and prepare the necessary QA action.
>=20
> Compared to the original discussion, I have tried to incorporate the
> feedback received on debian-devel by:
>=20
>  * making the workflow package-centric rather than maintainer-centric

I think this is very helpful for the person doing the work, reading the
MIA procedure on dev-ref it seems a lot of work for someone trying to
improve one package. Specially for new contributors who are serching RC
bugs or some specific lintian tags to work on and might encouter one of
these packages.

My take is maintainer-centric action should be handled by the MIA team,
though I think this process could include some usertags for the MIA team
to track. The reasoning is a maintainer who has 2 different packages on
this workflow, probably is MIA and worth investigating.

>  * treating the listed criteria as non-exhaustive indicators rather than
>    mandatory requirements
>  * making the opportunities for the Maintainer and Uploaders to object
>    explicit
>=20
> I would appreciate review of both the proposed workflow and whether the
> Developers Reference is the appropriate place to document it.
>=20
> The Merge Request is available here:
>=20
>   https://salsa.debian.org/debian/developers-reference/-/merge_requests/85
>=20
> Comments and suggestions are welcome.

I think this proposal is very useful and probably comes from your work
in Bug of the Day and the effort to migrate a lot of packages to salsa.

I'll keep an eye to track packages that would fit this workflow, but it
seems a sensible proposal to ease the burden on contributors wanting to
update a package and the MIA team.

By the way, I believe the MR text should be on [email protected], so
here it goes:

> This MR should be the basis for a more focussed discussion on a new
> process.  It was suggested on debian-devel list at
> https://lists.debian.org/debian-devel/2026/06/msg00086.html which was a
> precisition of the original mail of the whole thread that started at
> https://lists.debian.org/debian-devel/2026/06/msg00038.html
>=20
> It avoids mixing the Debian Commons team into a process where this team
> was not designed for, clarifies the process with more precise
> suggestions and give clear motivation why the process is helpful
> covering cases that are not yet addressed by other processes in Debian.
>=20
> I understood the main argument on the mailing list against the proposal
> was "Do we really need another process" and I gave reason why I think it
> is the case.  Besides this those who do not want to use the process are
> free to ignore it (as well as people do not really need to use the
> Package Salvage procedure or similar things)

Also saw a mail saying the MIA team is working on a new workflow for the
MIA process, so we can also take that as input or get this discussion
going on upcoming MiniDebConfs or DebConf so it gets merged.

Cheers,
Charles

--57hwdissoulp5cq2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEECgzx8d8+AINglLHJt4M9ggJ8mQsFAmppaicACgkQt4M9ggJ8
mQuRgQ/8C4JbjYtZxMXnU/q03HF+0xQFTQfuoKeOy/L1VO75ZRqxruNRCsPfefCz
WRjXTolAocdeJLAJXWYcru23rpqru3Pnj4ox52OK4NJZtUJvMME1DXCKJcJ3YjvA
XMA/ieX3aI7OoN/SidEowv4GGd2aPZ5jLFXixjDqQIn3JM8Kmx3taraREmfVocq9
QbCrsBsR9pJ9UGm6p6x46zdW5AxHL10gRMJHl7YSLyXHtG6c0CogCK7x6bpoRv/4
d/dEbxTaoRggvWBA06vjJku6iu8SwceGLL3CHC3i67CB7V/6o2P86K3PWVC7wZYA
+gYWy1McYMis64eLD/kTraT4ynbIYfWisbS+1MeuiesQogrCEe0KwTTczDjmrJ9d
XD20X3cmjkdi0HCnSotGMM9ZbRzJHSiVk65HYT76niBtGptqnBjkngd0kx7JyCPG
UUH5WQttcwiKIpXeMeeohpW99P+80eaDsDZ7NHouzxDh6Qy4C1MOxtgdgvGUkyYR
kTCsSUuWS61yKcVwNlAxysq2mAkdidVQCt0LA5KR8ad1+HRYrQF92RNxTc3yO6eT
PPZ/Z+aWSoD+aKXJSrXTYSYjDdGyIxXvwBfi5jY5f8zJH87ehfyqnFgKeq9QmoCA
17zMTCY5ZpZ7XGXB9AegJkKkkywp4oPUbiSI/544CMGItiMRa2c=
=wrol
-----END PGP SIGNATURE-----

--57hwdissoulp5cq2--