Tobias Frost <tobi@debian.org> writes:

On Tue, Feb 17, 2026 at 11:34:31PM +0100, Simon Josefsson wrote:

It seems there is some support to make Uploaders optional, so I made a
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

I think the key point from the MIA perspective is that our workflow is person-centric.

Thanks for explaining!

We usually start using that informatin when we've determined that
specific person became inactive or unreachable, and then need to
determine which packages might be affected. Upload history helps to see
past activity, but it does not reliably answer the question "which
packages do we need to look at because this person was involved?"

Why not? I think commit and upload history is a good indicator.
Commit and upload history seems to me be the real indicator of where
actually work happens (or not happens). Isn't this information
available in UDD or some similar resource?

in other words, 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. In practice, that would mean teams would need to notice emeritus/removed
cases themselves and act accordingly. For DMs and DCs, we do not even
have comparable notifications.

The Uploaders field is not perfect, but it provides a simple and
queryable mapping from person to packages, which is exactly what we need
when starting to clean up after a missing person.

I don't understand this part. What is the cleaning up action you are
thinking of? Is it removing the MIA person from the Uploaders: fields?
What else is there to do when someone disappears?
Making the field optional and allow not putting humans in it seems like
it may save everyone time to have to keep track of MIA's and removing
their name from a control field.
/Simon

--
tobi

/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 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
`-

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, Feb 19, 2026 at 08:55:26AM +0100, Simon Josefsson wrote:

Tobias Frost <tobi@debian.org> writes:

On Tue, Feb 17, 2026 at 11:34:31PM +0100, Simon Josefsson wrote:

It seems there is some support to make Uploaders optional, so I made a
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

I think the key point from the MIA perspective is that our workflow is person-centric.

Thanks for explaining!

We usually start using that informatin when we've determined that
specific person became inactive or unreachable, and then need to
determine which packages might be affected. Upload history helps to see past activity, but it does not reliably answer the question "which
packages do we need to look at because this person was involved?"

Why not? I think commit and upload history is a good indicator.

Commit and upload history seems to me be the real indicator of where
actually work happens (or not happens). Isn't this information
available in UDD or some similar resource?

Activity data is certainly useful to assess where work has happened. The question from the MIA perspective is slightly different: once a person
has been determined inactive, how do we obtain a reliable and complete
list of packages that may require follow-up action because of that
person?s involvement?
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? What other resources do you think could help?

in other words, 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. In practice, that would mean teams would need to notice emeritus/removed
cases themselves and act accordingly. For DMs and DCs, we do not even
have comparable notifications.

The Uploaders field is not perfect, but it provides a simple and
queryable mapping from person to packages, which is exactly what we need when starting to clean up after a missing person.

I don't understand this part. What is the cleaning up action you are thinking of? Is it removing the MIA person from the Uploaders: fields?

What else is there to do when someone disappears?

Orphaning and asking to remove persons from the uploader is possibly the
effect that has the most visibliy to the project.
Removal from Uploaders is only one possible action, and I'd say the
current goto mean to effectivly acilitating maintainership transitions
(e.g. orphaning, helping identify new maintainers, or contacting
relevant teams), and coordinating with other teams where project
resources are affected.?
For that, we need a person -> package mapping that is predictable and queryable once inactivity has been established.
? usually people start missing people because of neglegted packages and
then trigger us. I expect when Uploader is no longer widely used,
people will also less likely to ping us.
(The ?MIA 2.0? process would make MIA work independent of triggers,
but we are operating with the old process)

Making the field optional and allow not putting humans in it seems like
it may save everyone time to have to keep track of MIA's and removing
their name from a control field.

It may reduce metadata maintenance for maintainers, yes.
From the MIA side, however, that cost does not disappear, it shifts.
Instead of updating a structured field at the time of change, we would
need to reconstruct person -> package relationships later from activity
data when cleanup is required.
Maintaining the Uploaders field is comparatively cheap and distributed:
it is updated when work is already happening. Reconstructing
associations after someone has disappeared is necessarily centralized, heuristic, and more time-consuming.
The DPL recently described inactivity as a structural challenge for
Debian, particularly the lack of lightweight and reliable ways to make
changes in availability visible. Explicit and queryable person ->
package associations are one of the few structured signals we currently
have at the package level.
The more systematic inactivity workflow discussed at DebConf
(I've nicknamed it "MIA 2.0" earlier) outlines a possible activity-based
model, but it remains conceptual and is not operational today.
Until such a replacement exists in practice, removing explicit
associations would not merely simplify a control field; it would change
how inactivity is handled, without a defined alternative.
MIA 2.0 will still include "cleanup" steps, but these become less
critical for the project if we move toward an activity-based model,
supported by complementary processes such as easier ways to orphan or
take over packages that may be neglected. Maybe, once such a system is
in place, it could even allow us to drop the Uploaders field?�
--
tobi
� "?" because honstely I can't tell at the moment, too many loose ends.


--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, Feb 20, 2026 at 08:50:55AM +0900, Charles Plessy wrote:

Le Thu, Feb 19, 2026 at 07:31:44AM +0100, Tobias Frost a ?crit :

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.

Le Thu, Feb 19, 2026 at 10:41:51PM +0100, Tobias Frost a ?crit :

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?

Hi Tobias,

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 package, and that when
one member of the team leaves or becomes inactive, nobody changes for that package.

So if a team-maintained package without an Uploader field is not effectively maintained, it can be salvaged/orphaned/hijacked by any DD exactly as if it was not team-maintained ?

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Tobias Frost wrote:

Activity data is certainly useful to assess where work has happened. The question from the MIA perspective is slightly different: once a person
has been determined inactive, how do we obtain a reliable and complete
list of packages that may require follow-up action because of that
person?s involvement?

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? What other resources do you think could help?

I haven't a concrete query, but it seems to me that you can't expect
to obtain that list *from packages only*.

Generally speaking, a person is involved in maintaining a package if:
1) that person is explicitly listed as either Maintainer or Uploader; or
2) the package is team-maintained *and* that person is a member of that tea
m.
In the second case, querying the package can tell you what the team
is, but can't tell you who its members are.

Trying to solve that by (ab)using the Uploader field is the wrong
approach, because it singles out individual members of the team as
"the persons responsible for the package". That may not reflect the
way the team actually works, goes against the very concept of team-maintainership, and doesn't actually solve the problem, because
if a team member goes MIA who wasn't listed as uploader, this package
wouldn't appear in the "reliable and complete list" that you're aiming
at.

The right solution is to have a canonical place within the project
where the list of members of every team is stored and kept up-to-date.
It is definitely not duplicating that information in every package. I
don't know whether that already exists.

Gerardo

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hi,

Trying to solve that by (ab)using the Uploader field is the wrong
approach, because it singles out individual members of the team as
"the persons responsible for the package". That may not reflect the
way the team actually works, goes against the very concept of team-maintainership, and doesn't actually solve the problem, because
if a team member goes MIA who wasn't listed as uploader, this package wouldn't appear in the "reliable and complete list" that you're aiming
at.

IMHO, that's how teams *should* work: For every package, someone (at
least one person) is listed as the responsible person.

I am currently in this very situation with some of my team-maintained packages. I am listed as the Uploader (the only one), but want to get
rid of these packages. What I did is ask in the team (either on the
mailing lsit or directly the people who are also lsited in recent
changelog entries) whether they want to take over that role. I will then update the Uploaders on all packages where I find someone new, and
orphan all packages where I don't.

And I think while it's a bit effortful, it's absolutely the right way.

I don't think it's against team maintenance. The difference between
Uplaoders and Maintainers is the nuance of responsibility: If I
team-maintain a package, I agree that everyone else in the time may at
any time touch my package, as long as they do in accordance with any
team policies. I still remain responsible, and if I don't agree with how
the team helps maintaining the package and can't find consensus, I can
either move it out of the team, or move myself out of the team.

The right solution is to have a canonical place within the project
where the list of members of every team is stored and kept up-to-date.
It is definitely not duplicating that information in every package. I
don't know whether that already exists.

How should that work?

It would require all teams to use a central mailing list infrastructure
as well. tracker does have tools for maintaining semi-official team
lists and mailing lists, but not everyone uses it, and there is no
technical way to determine whether a package is team-maintained or not
by looking at Maintainers. We'd either need a new field in d/control to
encode that fact, or prescribe a unique e-mail domain for team mailing
lists.


In conclusion, I think the Uplaoders field right now works exactly as I
think it should.

-nik


--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Tobias Frost <tobi@debian.org> writes:

We usually start using that informatin when we've determined that
specific person became inactive or unreachable, and then need to
determine which packages might be affected. Upload history helps to see
past activity, but it does not reliably answer the question "which
packages do we need to look at because this person was involved?"

Why not? I think commit and upload history is a good indicator.

Commit and upload history seems to me be the real indicator of where
actually work happens (or not happens). Isn't this information
available in UDD or some similar resource?

Activity data is certainly useful to assess where work has happened. The question from the MIA perspective is slightly different: once a person
has been determined inactive, how do we obtain a reliable and complete
list of packages that may require follow-up action because of that
person?s involvement?

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? What other resources do you think could help?

I think I'm missing some piece of the context here, because in my mind
the logic is simple:
- MIA team get some indication that a person may be MIA, and then
actually confirm that the person stopped working X months ago or
similar (which could involve a couple of round-trips of personal
e-mails).
- Review everything the MIA person has actually done. For packaging
work, the complete list of commits & uploads is a sufficient, isn't
it? For non-packaging work I wouldn't know where to look.
- Take action on the review, notifying relevant teams and/or orphan
packages that doesn't have any remaining owner.
How do the Uploaders field help you?
I know little about this and do not feel particulary qualified to
comment on the MIA team workflow. If it works for the MIA team and
critically depends on the Uploaders field, then I wouldn't want to
challenge your workflow. Then it becomes the job of the rest of the
project to evaluate if the cost of requiring the Uploaders field
outweight the advantages of having the MIA team use their current
workflow. Maybe discussing a new MIA workflow, not based on Uploaders,
will help here, and you can evaluate if that new workflow would be
better or worse than your current setup.

in other words, 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. In
practice, that would mean teams would need to notice emeritus/removed
cases themselves and act accordingly. For DMs and DCs, we do not even
have comparable notifications.

The Uploaders field is not perfect, but it provides a simple and
queryable mapping from person to packages, which is exactly what we need >> > when starting to clean up after a missing person.

I don't understand this part. What is the cleaning up action you are
thinking of? Is it removing the MIA person from the Uploaders: fields?

What else is there to do when someone disappears?

Orphaning and asking to remove persons from the uploader is possibly the effect that has the most visibliy to the project.

If the package is team-maintained and doesn't have a Uploaders field, no
new upload will be necessary.
If the person is in the Uploaders field, removing them would be good,
but this is just extra work if the team takes care of the package
properly. That work may be saved by making Uploaders optional.
Orphaning a package when the person is in Maintainer will still be
necessary though, but I think that is unrelated to the Uploaders field.

From the MIA side, however, that cost does not disappear, it shifts.
Instead of updating a structured field at the time of change, we would
need to reconstruct person -> package relationships later from activity
data when cleanup is required.

Right. I'd argue that you need that anyway.

Maintaining the Uploaders field is comparatively cheap and distributed:
it is updated when work is already happening.

Here I disagree, and this is the reason for all of this.
I believe having a required Uploaders field is a really costly matter,
both technically (there is no consensus on how to update the field, see
the feedback from various teams in Debian that aren't really using this
field for anything but initial packager) and socially (it perpetuate the single-maintainer ownership model where others are not encouraged or
feel entitled to touch a package).

Explicit and queryable person -> package associations are one of the
few structured signals we currently have at the package level.

Hmm. Could someone design a UDD query that give you that association,
but based on commit & uploader activity instead?
I think such an association would be more accurate than looking at
Uploaders fields.
You seem to be coming back to the person->package association as an
important part, and while I believe this is a social mistake -- let's team-maintain all packages instead -- I understand this association is
needed if you start from a single-person maintainer assumption.

The more systematic inactivity workflow discussed at DebConf
(I've nicknamed it "MIA 2.0" earlier) outlines a possible activity-based model, but it remains conceptual and is not operational today.

Interesting, do you have a URL?
/Simon


--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, Feb 20, 2026 at 01:40:01PM +0100, Simon Josefsson wrote:

The more systematic inactivity workflow discussed at DebConf
(I've nicknamed it "MIA 2.0" earlier) outlines a possible activity-based model, but it remains conceptual and is not operational today.

Interesting, do you have a URL?

https://salsa.debian.org/debconf-team/public/data/dc25/-/raw/main/etherpad/txt/232-mia-team-interal-meeting.txt

/Simon

--- PyGate Linux v1.5.11
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Dominik George wrote:

The right solution is to have a canonical place within the project
where the list of members of every team is stored and kept up-to-date.
It is definitely not duplicating that information in every package. I
don't know whether that already exists.

How should that work?

It could be a wiki page, a database table, whatever is deemed more
useful (the wiki page would probably be better for humans, the
database for programs).
Every team would be responsible of keeping the list of its members up
to date. It doesn't seem a heavy task.

there is no technical way to determine whether a package is team-maintained or not by looking at Maintainers

Isn't there? I was assuming that if a package is team-maintained, the Maintainers field contains the team's name.
Are you concerned that one might not be able to distinguish whether a
name identifies a team or a human? Even if that could be a real
concern (I don't know whether there is any Debian contributor called
John Team, Team Smith, or anything like that), having all the team
names stored in a canonical place would solve it: if and only if the
name matches that list, then it's a team.

Gerardo

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)