2.1. MIA teamsnip
4. in case of no answer, the MIA team will make one manual attempt
to reach the person, indicating that failing to get a response on
that, the person's packages (if any) will be orphaned
On Wed Feb 4, 2026 at 5:38 PM GMT, Andreas Tille wrote:
2.1. MIA teamsnip
4. in case of no answer, the MIA team will make one manual attempt
to reach the person, indicating that failing to get a response on
that, the person's packages (if any) will be orphaned
I'm a big fan of packages being team maintained by default.
However, an ostensibly team-maintained package which is de-facto only actually maintained by one developer, will languish if that developer is
MIA, and would not be caught by the above step.
So as the ratio of team-maintained packages increases, the gain achieved
by orphaning directly-maintained packages as part of the MIA process
goes down.
Has anyone got any plans to try and identify and track such packages?
On Wed Feb 4, 2026 at 5:38 PM GMT, Andreas Tille wrote:Agreed.
2.1. MIA teamsnip
4. in case of no answer, the MIA team will make one manual attempt
to reach the person, indicating that failing to get a response on
that, the person's packages (if any) will be orphaned
I'm a big fan of packages being team maintained by default.
However, an ostensibly team-maintained package which is de-facto only actually maintained by one developer, will languish if that developer is MIA, and would not be caught by the above step.
So as the ratio of team-maintained packages increases, the gain achieved
by orphaning directly-maintained packages as part of the MIA process
goes down.
Has anyone got any plans to try and identify and track such packages?But why would that matter? Presumably if there are serious problems
But why would that matter? Presumably if there are serious problems
with a team-maintained-but-really-one-person-doing-the-work-package,
when that person goes missing, anyone else from the team can step in and
fix it? And if nobody else from the team takes responsibility, it is a >team-wide problem that MIA probably cannot resolve.
Or are you thinking of finding out which maintainers just stopped
working and the packages doesn't have any serious problem, but several >versions behind? In well-working teams, I would think that someone else >would just step in and feel at liberty of updating the package at some
point. This approach works well in the Go team, in my perception.
Perhaps a tool that finds a top-list of the "worst" version laggers in
Debian would improve this? That is, sort the set of packages which has
been behind upstream's latest release for the longest time.
On Thu, Feb 05, 2026 at 04:14:15PM +0100, Simon Josefsson wrote:Do you (or anyone else) update the Uploaders field? In what way?
But why would that matter? Presumably if there are serious problems
with a team-maintained-but-really-one-person-doing-the-work-package,
when that person goes missing, anyone else from the team can step in and >>fix it? And if nobody else from the team takes responsibility, it is a >>team-wide problem that MIA probably cannot resolve.
Or are you thinking of finding out which maintainers just stopped
working and the packages doesn't have any serious problem, but several >>versions behind? In well-working teams, I would think that someone else >>would just step in and feel at liberty of updating the package at some >>point. This approach works well in the Go team, in my perception.
We have a lot of such cases in the Python team. I think generally
speaking we function reasonably well as a team, but there's a huge
pile of stuff to do and only so many hours in the day. I do quite
often find that the alleged Uploader is somebody who last touched the
package in 2016 or something like that. Updating the package once we
notice this isn't normally a huge problem, but it does mean that
things will probably have been lagging behind for some time until
somebody notices.
I wonder if UDD stores upstream release events, which is necessary toPerhaps a tool that finds a top-list of the "worst" version laggers in >>Debian would improve this? That is, sort the set of packages which has >>been behind upstream's latest release for the longest time.
I wouldn't be 100% confident that something like this doesn't exist
somewhere - sufficiently clever filters in UDD, say - but if it does
then I've missed it and I would find it helpful.
Do you (or anyone else) update the Uploaders field? In what way?
On Thu, Feb 05, 2026 at 06:22:13PM +0100, Simon Josefsson wrote:
Do you (or anyone else) update the Uploaders field? In what way?
I feel like I probably should in some way, but at the moment I basically don't unless I particularly feel inclined to take over primary
maintenance of that particular package.
On Thu, Feb 5, 2026, at 7:21 PM, Colin Watson wrote:So if this is the de-facto situation for Python, Go and Rust team, I
On Thu, Feb 05, 2026 at 06:22:13PM +0100, Simon Josefsson wrote:
Do you (or anyone else) update the Uploaders field? In what way?
I feel like I probably should in some way, but at the moment I basically
don't unless I particularly feel inclined to take over primary
maintenance of that particular package.
The effective practice in the Rust team also matches this.
Uploaders usually contains whoever first packaged a particular crate,
and potentially people who expressed a particular interest in it after,
if they bothered (enough) to add themselves.
To pick a random example - rust-cargo's last non-team upload by someobdy
in Uploaders was in 2021, the 27(!) uploads after were "Team uploads"
(with all but one marked as such). I guess I should add myself to
Uploaders with the next one ;) for rust-libc it's very similar (26 uploads since the last non-team-upload in 2021). Many crate packages might only
have a single upload by the Uploader (the first one to NEW).
It seems to me that the Uploaders: fields doesn't really reflect anyIt depends on the team. In the Games Team, I tend to add myself in Uploaders for any package I care about enough to sponser uploads. So any non-DD contributor
relevant information, or at least none that is kept up to date.
So if this is the de-facto situation for Python, Go and Rust team, I
wonder if we shouldn't make the 'Uploaders:' field optional to allow
team Maintainer: fields without any particular Uploaders: fields.
..Do you (or anyone else) update the Uploaders field? In what way?
I feel like I probably should in some way, but at the moment I basically >> don't unless I particularly feel inclined to take over primary
maintenance of that particular package.
It seems to me that the Uploaders: fields doesn't really reflect any
relevant information, or at least none that is kept up to date.
Is there any reason we couldn't make this change to policy?
On the contrary, I would actually ask you to consider using it moreI've never used this page but as it seems to contain random packages I
often. For example you have done all golang-go.crypto uploads in
(nearly) the past year, but you didn't add yourself as Uploader, so
the package does not show up at >https://udd.debian.org/dmd/?jas%40debian.org#todo
and/or you don't get copies of bug reports filed against it.Do you think people in Uploaders get those? How?
Also feel free to clean up the Uploaders listIt's easy to say "feel free" but I don't think it's actually allowed to do that.
from people who haven't been active for several years.
Well, I see now that it's possible to hide sponsored uploads and NMUs so I think it's not as bad.On the contrary, I would actually ask you to consider using it more
often. For example you have done all golang-go.crypto uploads in
(nearly) the past year, but you didn't add yourself as Uploader, so
the package does not show up at >>https://udd.debian.org/dmd/?jas%40debian.org#todo
I've never used this page but as it seems to contain random packages I
don't maintain, it doesn't seem to be a priority to start using it and >modify metadata of packages for that.
Fabian Grnbichler <debian@fabian.gruenbichler.email> writes:Also the Debian Perl Group.
So if this is the de-facto situation for Python, Go and Rust team,
IHahaha!
wonder if we shouldn't make the 'Uploaders:' field optional to allow
team Maintainer: fields without any particular Uploaders: fields.
It seems to me that the Uploaders: fields doesn't really reflect anyI completely agree, and if you'r going to try and change this, I will
relevant information, or at least none that is kept up to date.
Is there any reason we couldn't make this change to policy?
Hi!Do Policy say anything which suggest that? What I find is this:
..Do you (or anyone else) update the Uploaders field? In what way?
I feel like I probably should in some way, but at the moment I basically >> >> don't unless I particularly feel inclined to take over primary
maintenance of that particular package.
It seems to me that the Uploaders: fields doesn't really reflect any
relevant information, or at least none that is kept up to date.
Is there any reason we couldn't make this change to policy?
I use the Uploaders field like described in the Policy, and add myself
as Uploader on packages where I am willing to take responsibility like
others describe above. Please don't change the meaning or remove the Uploaders field.
On the contrary, I would actually ask you to consider using it more
often. For example you have done all golang-go.crypto uploads in
(nearly) the past year, but you didn't add yourself as Uploader
As they are currently defined, I believe dropping Maintainer/Uploader
fields from the debian policy manual is the simplest improvement.
Or at least make them optional.
I am increasingly inclined to remove the requirement that Uploaders be present for team-maintained packages, though.As someone who uses the Uploaders field both inside and outside of teams,
Sure, it?s going to make it hard to spot team-"unmaintained" packages
(packages hosted by a team, but actually orphaned), but it?s notlike
these are easy to spot with the current setup.
objections on the grounds that they needed someone specific to contact if >there was a problem with a package.
On Thu, 05 Feb 2026 22:58:22 +0100, Simon Josefsson wrote:
Fabian Gr?nbichler <debian@fabian.gruenbichler.email> writes:
So if this is the de-facto situation for Python, Go and Rust team,
Also the Debian Perl Group.
I
wonder if we shouldn't make the 'Uploaders:' field optional to allow
team Maintainer: fields without any particular Uploaders: fields.
Hahaha!
I guess I should explain why I'm bursting out in laughter: Yes of course we should, and I've argued this several times in the past, and it was always
was shot down by vocal people who are not involved in any of this team maintenance stuff.
It seems to me that the Uploaders: fields doesn't really reflect any relevant information, or at least none that is kept up to date.
Is there any reason we couldn't make this change to policy?
I completely agree, and if you'r going to try and change this, I will
(again) support this position.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
I am increasingly inclined to remove the requirement that Uploaders be present for team-maintained packages, though. My vague recollection isNo, it was the MIA team who were opposed to us making that change,
that the last time this came up, the FTP team raised the primary
objections on the grounds that they needed someone specific to contact if there was a problem with a package. But I'm not sure this still makes
sense (this was many years ago), and the correct contact point for nearly
all purposes I can think of is indeed the team.
I am increasingly inclined to remove the requirement that Uploaders be present for team-maintained packages, though. My vague recollection is
that the last time this came up, the FTP team raised the primary
objections on the grounds that they needed someone specific to contact if there was a problem with a package. But I'm not sure this still makes
sense (this was many years ago), and the correct contact point for nearly all purposes I can think of is indeed the team.
No, it was the MIA team who were opposed to us making that change,
nothing to do with the FTP team. Their workflow would have been broken
by the change and they weren't happy with the alternatives.
Hi Sean,
Am Sun, Feb 08, 2026 at 12:54:41PM +0000 schrieb Sean Whitton:
I am increasingly inclined to remove the requirement that Uploaders be
present for team-maintained packages, though. My vague recollection is
that the last time this came up, the FTP team raised the primary
objections on the grounds that they needed someone specific to contact if >> > there was a problem with a package. But I'm not sure this still makes
sense (this was many years ago), and the correct contact point for nearly >> > all purposes I can think of is indeed the team.
No, it was the MIA team who were opposed to us making that change,
nothing to do with the FTP team. Their workflow would have been broken
by the change and they weren't happy with the alternatives.
Can we review this opinion with the (remaining) MIA team (in CC) in the
light of the proposed (changed) workflow?
Hi Sean,
Am Sun, Feb 08, 2026 at 12:54:41PM +0000 schrieb Sean Whitton:
No, it was the MIA team who were opposed to us making that change,
nothing to do with the FTP team. Their workflow would have been broken
by the change and they weren't happy with the alternatives.
Can we review this opinion with the (remaining) MIA team (in CC) in the
light of the proposed (changed) workflow?
The uploader information remains very valuble. A key problem is that
there often no information on who is part of a team, assseing if a team
is functioning well is often hard, whether all (to us unknown) team
members are already gone -- if the team is actually still teaming?
Teams a very hard to assess for the MIA team. I wrote (smaller) teams
emails as part of MIA work but often did not received any response.
Being able to adress a *human* is IMHO much more promising of getting
results - as often they feel more resonsible for their package - than
talking to a team.
Hunting information about no longer active persons is already taking a
lot of energy and time. Any additional friction in accessing accurate information will increases that burden.
The contact point problem remains, of course. Personally, I'd love for packaging teams to publish a list of individual people who are points of contact, but I realize that's just one more thing to keep up to date.
(the below is generalizing teams a lot.
There are teams that are
very well organized and we've never had issues with; We've
got agreements with some teams how to handle their retirement cases and
that worked well; but those teams are usually not sources of concerns
for the MIA team; usually those agreements are in the line of "don't
file bugs, send us a mail that someone went missing and we'll use our automation to update the Uploaders file".)
The uploader information remains very valuble. A key problem is that
there often no information on who is part of a team, assseing if a team is functioning well is often hard, whether all (to us unknown) team members
are already gone -- if the team is actually still teaming?
Teams a very hard to assess for the MIA team. I wrote (smaller) teams
emails as part of MIA work but often did not received any response.
Being able to adress a *human* is IMHO much more promising of getting
results - as often they feel more resonsible for their package - than
talking to a team.
Hunting information about no longer active persons is already taking a
lot of energy and time. Any additional friction in accessing accurate information will increases that burden.
On the other hand, please don't keep everyone in the Uploaders field,
limit them to only those actually working on the package; please do some Uploaders-Field-Hygene from time to time. For example, if you do an
ITS, and the maintainer didn't response, it is IMHO fine to remove
them by default instead of keeping them; (as this can easily be undone
at any time and could also be communicated this way to the former
maintainer and/or checked with them beforehand, with the default to
removal when there is no answer from them within some reasonable time)
Luckily there were disussions in Brest to reform the process to a more automated way, and we've got an rough idea how it could look like.
But we'd need eventually someone to rehack on nm.d.o to make that
happen.
But the process is on-purpose not automated end-to-end, if just
helps to filter out the "false-positives", for my lack of better words
atm. After the automation finished, there will still be humand needing
to look through information manually, where likely we'll need above information readily available too.
That's last paragraph is orthogonal
to team and uploaders, of course, as it likely won't cover teams as as outlined above we don't really have the information to track teams.
As a side note: contributors who neither maintain packages nor list themselves in Uploaders are basically invisible as there will be no
trigger for us to investigate.
Being invisible can be a problem as those people still have access to
all of our infrastructure, part of the MIA mission is to keep Debian
safe from misusing lingering accounts.
Maybe the automation needs to be different, like an regular membership
ping? (like done in the past for DMs)?
- undetected, unmaintained packages, reviving those packges
We are also lucky that we now have the ITS procedure as helps to transit ownership to interested people more easily, this often reduces the
immediate need to have action on a maintainer. As this was a topic in
the recent past, I think the MIA teams stanca still is that orphaning packages is last-resort, when everything fails. Orphaning packages will
not automatically attract new interested maintainers, nor make them maintained again. OTOH if you orphaning too careless, you might alienate
the person.
Maybe we should more often also ask ourselfes if some packages should
indeed be retired instead of being tried to revived;
($people, including
/me have done so in the past with a RC bug saying, "hey respond to this
bug, or I'm gonna RM this package in 3 months" on really carefully
manally selected packages that likely noone will miss.
Tobias Frost <tobi@debian.org> writes:Thanks, Tobi, for sharing these details of your work.
The uploader information remains very valuble. A key problem is that
there often no information on who is part of a team, assseing if a team
is functioning well is often hard, whether all (to us unknown) team
members are already gone -- if the team is actually still teaming?
Teams a very hard to assess for the MIA team. I wrote (smaller) teams
emails as part of MIA work but often did not received any response.
Being able to adress a *human* is IMHO much more promising of getting
results - as often they feel more resonsible for their package - than
talking to a team.
Hunting information about no longer active persons is already taking a
lot of energy and time. Any additional friction in accessing accurate
information will increases that burden.
It sounds like this is the root of the issue for you: You rely on
Uploaders to have a sense of who is still active in Debian as part of a packaging team, and you also use it to find a human contact point to ask about status.
Also, presumably you're pretty busy and may not have the time to develop
new tools.
Is there perhaps something others can do to help you with other sources of data? The first thing that occurred to me when reading this is that in a world where team maintenance is increasingly happening on Salsa, Salsa activity might be a better metric for project activity than uploads or presence in Uploaders. That would also capture people who do a lot of
merge requests and reviews but don't prepare final uploads. I have no idea how common that is, but it seems at least plausible.
Maybe there's some way for someone else to help you pull that data from
Salsa and add it as an input to your process? And then teams that work in Salsa and can provide that activity information could drop the Uploaders field because they're providing you with better information?
The contact point problem remains, of course. Personally, I'd love for packaging teams to publish a list of individual people who are points of contact, but I realize that's just one more thing to keep up to date.
Le Sat, Feb 14, 2026 at 09:20:56AM -0800, Russ Allbery a crit :IIUC you are copying a non-human name from Maintainers to Uploaders,
The contact point problem remains, of course. Personally, I'd love for
packaging teams to publish a list of individual people who are points of
contact, but I realize that's just one more thing to keep up to date.
I think that in the teams where I participate, it makes sense to have no Uploader field in packages where nobody wants to have them in their developers
dasboard (as opposed to the teams dasboard).
But if that is putting too much pressure on other teams, maybe I will
propose to just add this to our routine update scripts:
grep -q '^Uploaders:' debian/control ||
cme modify dpkg-control "source Uploaders=\"$(dpkg-parsechangelog -S Maintainer)\""
And leave it to the team members to remove themselves from the Uploader field in the VCS whenever they want.
Am Sat, Feb 14, 2026 at 03:46:25PM +0100 schrieb Tobias Frost:[...]
Do you mean to say, that you would welcome treating only very wellThere are teams that are
very well organized and we've never had issues with; We've
got agreements with some teams how to handle their retirement cases and that worked well; but those teams are usually not sources of concerns
for the MIA team; usually those agreements are in the line of "don't
file bugs, send us a mail that someone went missing and we'll use our automation to update the Uploaders file".)
I would very much welcome this becoming the default way of dealing with
such situations.
Charles Plessy [16/Feb 7:19pm +09] wrote:My mistake, you're copying it from d/changelog, which is an interesting
Le Sat, Feb 14, 2026 at 09:20:56AM -0800, Russ Allbery a crit :
The contact point problem remains, of course. Personally, I'd love for
packaging teams to publish a list of individual people who are points of >>> contact, but I realize that's just one more thing to keep up to date.
I think that in the teams where I participate, it makes sense to have no
Uploader field in packages where nobody wants to have them in their developers
dasboard (as opposed to the teams dasboard).
But if that is putting too much pressure on other teams, maybe I will
propose to just add this to our routine update scripts:
grep -q '^Uploaders:' debian/control ||
cme modify dpkg-control "source Uploaders=\"$(dpkg-parsechangelog -S Maintainer)\""
And leave it to the team members to remove themselves from the Uploader field
in the VCS whenever they want.
IIUC you are copying a non-human name from Maintainers to Uploaders,
which would violate a Policy "must" and thus be an RC bug. That's the
whole thing we're discussing here.
But if that is putting too much pressure on other teams, maybe I will
propose to just add this to our routine update scripts:
grep -q '^Uploaders:' debian/control ||
cme modify dpkg-control "source Uploaders=\"$(dpkg-parsechangelog -S Maintainer)\""
And leave it to the team members to remove themselves from the Uploader field
in the VCS whenever they want.
I would very much welcome this becoming the default way of dealing with such situations.
Do you mean to say, that you would welcome treating only very well
organized teams as teams in Debian?
But if that is putting too much pressure on other teams, maybe I will
propose to just add this to our routine update scripts:
grep -q '^Uploaders:' debian/control ||
cme modify dpkg-control "source Uploaders=\"$(dpkg-parsechangelog -S Maintainer)\""
And leave it to the team members to remove themselves from the Uploader field
in the VCS whenever they want.
I've read your suggestion on Matrix and I might have misinterpreted your >intention, thus trying to clarify. Is your intention to simply have
another instance who actually uploaded this specific package version?
Am Tue, Feb 17, 2026 at 10:36:18AM +0100 schrieb Jonas Smedegaard:Sorry, but I still don't get it. Or possibly you don't. Since I am too
I would very much welcome this becoming the default way of dealing with such situations.
Do you mean to say, that you would welcome treating only very well organized teams as teams in Debian?
No, that is not what I meant.
My statement was about the procedure, not about redefining which teams qualify as teams. Where a team has a working agreement and responds
reliably, I would welcome using that as the default handling.
In fact, I have had good experiences writing to team addresses and
receiving a response from a person. That suggests that pinging teams can
work well in practice.
If packages without Uploaders turn out to be problematic, we could adoptThat's what's happening in the Debian Perl Group (in practice, I
a simple r-pkg-team rule: the next person who uploads Uploaderless
packages becomes the Uploader by default, using something like the
one?liner above.
Still, I think making the Uploader field optional is the cleanerAck.
long?term solution, especially since this kind of metadata can be
maintained outside the archive.
Hi,
just to support a random of the supportive mails: Many Blends teams I
know are using Uploaders field in a similar way as described in this
thread. Making it optional would really help.
I know several cases where original Uploaders vanished while the team is keeping up the maintenance. Its just a mental thing to decide: Is it
OK to reflect reality or will this hurt the person who originally spent
some time into it if the name is removed after X years of no commit.
Kind regards
Andreas.
Am Sat, Feb 07, 2026 at 02:01:37AM +0100 schrieb gregor herrmann:
On Thu, 05 Feb 2026 22:58:22 +0100, Simon Josefsson wrote:
Fabian Grnbichler <debian@fabian.gruenbichler.email> writes:
So if this is the de-facto situation for Python, Go and Rust team,
Also the Debian Perl Group.
I
wonder if we shouldn't make the 'Uploaders:' field optional to allow
team Maintainer: fields without any particular Uploaders: fields.
Hahaha!
I guess I should explain why I'm bursting out in laughter: Yes of course we >> should, and I've argued this several times in the past, and it was always
was shot down by vocal people who are not involved in any of this team
maintenance stuff.
It seems to me that the Uploaders: fields doesn't really reflect any
relevant information, or at least none that is kept up to date.
Is there any reason we couldn't make this change to policy?
I completely agree, and if you'r going to try and change this, I will
(again) support this position.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
If packages without Uploaders turn out to be problematic, we could adopt^^^^^^^^^^^^^^^^^^^^
a simple r-pkg-team rule: the next person who uploads Uploaderless
packages becomes the Uploader by default, using something like the
one?liner above.
This doesn?t increase anyone?s workload; it just preserves the status
quo and avoids unnecessary noise.
Still, I think making the Uploader field optional is the cleaner
long?term solution, especially since this kind of metadata can be
maintained outside the archive.
Hi Tobias,
thank you for sharing your experience. Its highly appreciated.
Am Sat, Feb 14, 2026 at 03:46:25PM +0100 schrieb Tobias Frost:
(the below is generalizing teams a lot.
I fully agree that any generalization is inherently weak and that teams
in Debian work in very different ways.
There are teams that are
very well organized and we've never had issues with; We've
got agreements with some teams how to handle their retirement cases and that worked well; but those teams are usually not sources of concerns
for the MIA team; usually those agreements are in the line of "don't
file bugs, send us a mail that someone went missing and we'll use our automation to update the Uploaders file".)
I would very much welcome this becoming the default way of dealing with
such situations.
The uploader information remains very valuble. A key problem is that
there often no information on who is part of a team, assseing if a team is functioning well is often hard, whether all (to us unknown) team members are already gone -- if the team is actually still teaming?
Teams a very hard to assess for the MIA team. I wrote (smaller) teams emails as part of MIA work but often did not received any response.
Being able to adress a *human* is IMHO much more promising of getting results - as often they feel more resonsible for their package - than talking to a team.
I could imagine that the changelog author of any upload marked as a
"Team upload" could be considered a team member.
Hunting information about no longer active persons is already taking a
lot of energy and time. Any additional friction in accessing accurate information will increases that burden.
I fully acknowledge that identifying inactive contributors already
consumes a significant amount of time and energy. Any additional
friction in accessing reliable information will inevitably add to that burden.
That said, I would greatly appreciate a pointer to any code implementing
the "The proposed process will be as follows:" section referenced here: https://salsa.debian.org/debconf-team/public/data/dc25/-/raw/main/etherpad/txt/232-mia-team-interal-meeting.txt#L30-50
Despite my repeated questions about whether the implementation has
started, I have not received any response. Even a short reply - either a
link to the implementation or a clear "not yet" - would be helpful.
At this point, I consider the lack of response a blocker to making
progress towards a future process that is less draining in terms of time
and energy.
On the other hand, please don't keep everyone in the Uploaders field,
limit them to only those actually working on the package; please do some Uploaders-Field-Hygene from time to time. For example, if you do an
ITS, and the maintainer didn't response, it is IMHO fine to remove
them by default instead of keeping them; (as this can easily be undone
at any time and could also be communicated this way to the former maintainer and/or checked with them beforehand, with the default to
removal when there is no answer from them within some reasonable time)
Shouldn't such a default removal of a former Maintainer be documented in
the Developer's Reference[1]? If this is considered good practice, it
would be helpful to make it explicit and visible rather than relying on implicit conventions.
Luckily there were disussions in Brest to reform the process to a more automated way, and we've got an rough idea how it could look like.
But we'd need eventually someone to rehack on nm.d.o to make that
happen.
Is there any concrete progress on this? Is someone currently working on
it, or is this still at the idea stage?
But the process is on-purpose not automated end-to-end, if just
helps to filter out the "false-positives", for my lack of better words
atm. After the automation finished, there will still be humand needing
to look through information manually, where likely we'll need above information readily available too.
Could you (or someone else from the MIA team) provide concrete examples
where the proposed automated process would be sufficiently error-prone
that manual intervention is clearly required?
I am not arguing against human review per se. However, it would help the discussion to better understand the specific scenarios in which
automation is expected to fail, and what kinds of risks we are trying to mitigate by keeping this part manual.
That's last paragraph is orthogonal
to team and uploaders, of course, as it likely won't cover teams as as outlined above we don't really have the information to track teams.
As a side note: contributors who neither maintain packages nor list themselves in Uploaders are basically invisible as there will be no
trigger for us to investigate.
Being invisible can be a problem as those people still have access to
all of our infrastructure, part of the MIA mission is to keep Debian
safe from misusing lingering accounts.
What about introducing an automated safeguard on Salsa: for example, downgrading an account to 'Guest' in all projects if it has not pushed
any commits for a defined period of time (for instance, two years)?
GitLab provides a feature to "Automatically deactivate dormant
users"[2]. This seems like a reasonable way to reduce the risk
associated with lingering accounts, while still allowing the person to
regain access easily if they return.
Such a mechanism could complement the MIA work by reducing the attack
surface without requiring manual investigation in every individual case.
Maybe the automation needs to be different, like an regular membership ping? (like done in the past for DMs)?
- undetected, unmaintained packages, reviving those packges
We are also lucky that we now have the ITS procedure as helps to transit ownership to interested people more easily, this often reduces the immediate need to have action on a maintainer. As this was a topic in
the recent past, I think the MIA teams stanca still is that orphaning packages is last-resort, when everything fails. Orphaning packages will
not automatically attract new interested maintainers, nor make them maintained again. OTOH if you orphaning too careless, you might alienate the person.
I am strongly convinced that, in addition to the current procedures, we
need a clearly defined orphaning process. While I fully agree that
orphaning a package will not automatically attract new maintainers, it
at least makes the status of the package explicit. Clarity has value in itself. An explicitly orphaned package signals that it currently lacks responsible maintenance and allows us to act accordingly.
In particular, it may simplify decisions about removal if it turns out
there is no compelling reason to keep the package in Debian. We already
have a considerable number of effectively unmaintained packages. I
consider it problematic that we often avoid formally declaring them as orphaned.
I would very much welcome others joining me in defining a transparent and predictable process for orphaning packages.
Maybe we should more often also ask ourselfes if some packages should indeed be retired instead of being tried to revived;
+1
($people, including
/me have done so in the past with a RC bug saying, "hey respond to this bug, or I'm gonna RM this package in 3 months" on really carefully
manally selected packages that likely noone will miss.
Helmut has automated this process, and it works well for packages with long-standing RC bugs. That is definitely helpful and a step forward.
However, we also have packages without RC bugs that are effectively unmaintained. The absence of RC bugs does not necessarily mean that a
package is actively maintained or reviewed.
In my view, such packages can still represent an attack surface within
the archive. Leaving them in an unclear maintenance state for extended periods is therefore not only an organizational issue, but potentially a security concern as well.
Kind regards
Andreas.
[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package
item 3.
[2] https://docs.gitlab.com/administration/moderate_users/#automatically-deactivate-dormant-users
--
https://fam-tille.de
Am Tue, Feb 17, 2026 at 11:06:09PM +0900 schrieb Charles Plessy:Or as a "Team upload"?
If packages without Uploaders turn out to be problematic, we could adopt^^^^^^^^^^^^^^^^^^^^
a simple r-pkg-team rule: the next person who uploads Uploaderless
packages becomes the Uploader by default, using something like theAs a team member of this team I support this *conditional* setting
one?liner above.
(= *if* Uploaders is empty *then* set it to the current Uploader).
Perhaps this automatism should be avoided if the Upload is explicitly
marked as NMU.
It seems there is some support to make Uploaders optional, so I made aI think the key point from the MIA perspective is that our workflow is person-centric.
patch to move this into the realm of actionable:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798476#462
Has there been any strong opinions to not make that change?
I see valid arguments about this diluting the ability to find real
humans behind a package, but I think this can reasonable (and more accurately) be resolved by deferring to debian/changelog fields and/or
the PTS history on who made uploads. Making the field optional does not forbid anyone to continue using it for what they believe it is useful
for. It just makes it possible for people to stop using the field when
they don't feel it provides value
/Simon
Andreas Tille <andreas@an3as.eu> writes:
Hi,
just to support a random of the supportive mails: Many Blends teams I
know are using Uploaders field in a similar way as described in this thread. Making it optional would really help.
I know several cases where original Uploaders vanished while the team is keeping up the maintenance. Its just a mental thing to decide: Is it
OK to reflect reality or will this hurt the person who originally spent some time into it if the name is removed after X years of no commit.
Kind regards
Andreas.
Am Sat, Feb 07, 2026 at 02:01:37AM +0100 schrieb gregor herrmann:
On Thu, 05 Feb 2026 22:58:22 +0100, Simon Josefsson wrote:
Fabian Grnbichler <debian@fabian.gruenbichler.email> writes:
So if this is the de-facto situation for Python, Go and Rust team,
Also the Debian Perl Group.
I
wonder if we shouldn't make the 'Uploaders:' field optional to allow
team Maintainer: fields without any particular Uploaders: fields.
Hahaha!
I guess I should explain why I'm bursting out in laughter: Yes of course we
should, and I've argued this several times in the past, and it was always >> was shot down by vocal people who are not involved in any of this team
maintenance stuff.
It seems to me that the Uploaders: fields doesn't really reflect any
relevant information, or at least none that is kept up to date.
Is there any reason we couldn't make this change to policy?
I completely agree, and if you'r going to try and change this, I will
(again) support this position.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
the information in the Uploaders field is less about determining activity and more about enabling action once inactivity has been established.
If team membership is not clearly documented, we cannot easily determine which team should be contacted when someone goes missing.
Do you have some concrete query in mind that you could share with me, which would tell (quickly and with accuracy) that someone stopped working on a package and we need to tell someone, e.g a team?
this is the whole point of making the Uploader field optional. When absent, it
means that every team member is equally in chage for the packag
Hi,No. It means the team is in charge.
this is the whole point of making the Uploader field optional. When absent, it
means that every team member is equally in chage for the packag
Ah no, please not! At least not with what I understand as "in charge of".
Let's say someone joins the Python packaging team, and uploads a
package without an Uplaoders entry. Now I am in charge of this
package.
What does this entail? Do I constantly have to monitor upstream? Do I, personally, get all the maintainer duties? And everyone else in theNo. The package is a shared responsibility, which is my perception of
team as well?
That won't work. I don't want all maintainer duties for all theHuh? What's the point of having team-maintained packages at all with
thousands of packages under the Python team, and if "everyone" is in
charge, then noone is in charge. Instead, if noone cares enough to put
on the "in charge" hat, the package should be dropped from the team.
I may have missed essential parts of the discussion, but as I see it,I don't think anyone has suggested your semantics, or that it follows
making the Uoploaders field optional, with the semantics described
above, would *ensure* that all team maintained packages fly under the
radar, contrary to what it should do.
tWhat does this entail? Do I constantly have to monitor upstream? Do I,
personally, get all the maintainer duties? And everyone else in the
team as well?
No. The package is a shared responsibility, which is my perception of
the point of doing team-maintained package in the first place. If you
don't want shared responsibility, then why team-maintain something?
That won't work. I don't want all maintainer duties for all the
thousands of packages under the Python team, and if "everyone" is in
charge, then noone is in charge. Instead, if noone cares enough to pu
on the "in charge" hat, the package should be dropped from the team.
Huh? What's the point of having team-maintained packages at all with
that perspective? Maybe it helps to think about this differently, and >consider that it is possible to not have a single-maintainer strong
ownership model of package maintainance.
Dominik George <natureshadow@debian.org> writes:How can I assess, as a concerned Debian developer, whether everybody or somebody or nobody in a team are responsible for the package?
this is the whole point of making the Uploader field optional.What does this entail? Do I constantly have to monitor upstream? Do
When absent, it means that every team member is equally in chage
for the packag
I, personally, get all the maintainer duties? And everyone else in
the team as well?
No. The package is a shared responsibility, which is my perception
of the point of doing team-maintained package in the first place. If
you don't want shared responsibility, then why team-maintain
something?
It is fine for people to have the single-maintainer model and stillWhat do you mean by "do what they want"? Isn't it those arguing for
be able to do what they want. Nobody has suggested to remove the
Uploaders field. Only to make it optional, for those who prefer
another way.
If explicit person -> package associations become optional, individual >inactivity within teams would no longer be a project-level concern. MIA
could then no longer operate under its current model, as one of the >structured signals linking individuals to packages would not be
consistently available. While other heuristics may still exist, they
are not equivalent to an explicit and declared association, and are >operationally much more expensive.
[dropping a pile of cc'ed addresses]+1
Quoting Simon Josefsson (2026-02-20 14:50:28)
Dominik George <natureshadow@debian.org> writes:
this is the whole point of making the Uploader field optional.What does this entail? Do I constantly have to monitor upstream? Do
When absent, it means that every team member is equally in chage
for the packag
I, personally, get all the maintainer duties? And everyone else in
the team as well?
No. The package is a shared responsibility, which is my perception
of the point of doing team-maintained package in the first place. If
you don't want shared responsibility, then why team-maintain
something?
How can I assess, as a concerned Debian developer, whether everybody or somebody or nobody in a team are responsible for the package?
If the answer is "ask the team" then why is the Uploaders field ever relevant? I mean, the MIA team and anyone else concerned about a
package can always "just ask" - why should we need to declare ahead of
time what individuals take responsibility for, when we play loose with
teams?
I was only referring to "use an Uploaders" field here. Nobody hasIt is fine for people to have the single-maintainer model and still
be able to do what they want. Nobody has suggested to remove the
Uploaders field. Only to make it optional, for those who prefer
another way.
What do you mean by "do what they want"? Isn't it those arguing for
making the Uploaders field optional for team-maintained packages that
wants to "do what they want"? In what ways can maintainers of single-maintainer packages "do what they want"?
As this thread shows, there are differing interpretations of what "team responsibility" entails in practice. This suggests the change is notI think you are right.
merely a metadata adjustment, but a shift in expectations about accountability and recovery.
In practice, many packages - even within established teams - areAnd even further, I think the shift of expectations is already deployed
effectively driven by one or a few individuals. When responsibility is
purely collective, inactivity can become less visible, particularly in smaller or less structured teams where attempts to contact the team may
not result in any response.
I now realize that the MIA workflow is not particulary aligned with how
the Go team operates, but I don't see any problem here: the go team
tries to take care of all golang-* packages, so there is no problem with someone just disappearing from the go team. Which seems to have
happened a couple of times in the past. I don't think the MIA team need
to worry a lot about golang-* packages for a MIA person. There is just nothing to do in that case, except possibly remove someone from
Uploaders (which argues for making it optional).
I guess I'm still not sure I understand why Salsa activity isn't even
better than presence in Uploaders or recent uploads to the archive for MIA team purposes, though. If someone is active in Salsa (committing changes
to packages, merging MRs, etc.), then they're not MIA, no? (They could
still be neglecting other duties, but IIRC the MIA team doesn't really
handle that case, only people who have stopped contributing entirely.)
Simon and you are describing the two different models of "teamHuh? What's the point of having team-maintained packages at all withI think you are confusing ownership with responsibility. "Ownership"
that perspective? Maybe it helps to think about this differently, and >>consider that it is possible to not have a single-maintainer strong >>ownership model of package maintainance.
would mean that I don't want others to touch my package. That does,
as you said, not make sense in team maintenance.
"Responsibility", or "being in charge", means that someone pledged
to take on maintainer responsibilities, like keeping the package
updated regularly, ensuring it transitions to testing, etc. ? i.e.,
regular tasks that do not arise from external communication.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 119:29:10 |
| Calls: | 125 |
| Calls today: | 125 |
| Files: | 489 |
| D/L today: |
859 files (365M bytes) |
| Messages: | 76,550 |
| Posted today: | 26 |