Hi,

for some time I've been uploading packages with Maintainer set to a
mailing list and no Uploaders field.  In cases where some package kind
of fit within a team, but noone cares specifically about that individual
package, I feel it's better than setting Maintainer to the Debian QA
Group, which policy currently says is required, since the team will get
bug mail, and any updates to the package will probably come from the
team anyway.  So I'd like to see this requirement relaxed.

Cheers,
Julien

Hi,

Noooooooooooo!

Every package *must* have at least one named *person*. If it doesn't
have a named person, it's orphaned.

If you don't care about the package enough to maintain it, orphan it so
that someone else can or otherwise request its removal.

An archive full of packages that are notionally maintained by a team but
really no one is paying any attention to is a horrifying thought to me.

Thanks,
Iain.

Hi,

So I've had a quick chat with jcristau about this in #debian-doc. Here
is my proposal:

Instead of allowing there to be no named person for packages, allow
packages to be orphaned but without the changing of the Maintainer field
if it was previously maintained within a team.

An O bug is still filed on the package, but the Maintainer field remains
unchanged (the decision of whether or not to change it is left to the
person making the upload, the team may want rid of the package).

Any package that has no named person in the Maintainer field or
Uploaders field should be considered orphaned and a free candidate for
someone to come along and file an ITA.

The existing team in the Maintainer field of orphaned packages does not
give an obligation for the adopter to maintain the package within that
team, but until it is adopted the team will still recieve bug
notifications, etc. and is likely to be more knowledgable on the package
than the QA team in general.

Thanks,
Iain.

Do you realize that upload of such package will count as an NMU ?

Puzzled,

I'm honestly not sure what difference calling it NMU, team upload or QA
upload makes.

Cheers,
Julien

NMU are handled specially by various tools.
For once, NMUs do no close bugs.

Cheers,

Such as?
They have closed bugs for, err, 10 years now:
https://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

Cheers,
Julien

Not for lintian, if it doesn't have a NMU version and has "Team
upload." as the first changelog line.
(Since version 2.4.2 from 2010.)


Cheers,
gregor

Hi,

I don't think that this requirement makes sense. They can be rightfully annoyed
but it doesn't make sense to keep an outdated Uploaders field just to
please people so that they can mail people who no longer care about the
package.

If you need to find out someone who has some interest in the package, you
can always check who uploaded it last (or in the last X months).

IMO the hard requirement comes more from the fact that we don't like package
with no maintainer... those are effectively orphaned and should be up for
adoption by other maintainers.

Yes, I believe that this is the correct approach.

No, we should stop filing O bugs.  Instead we have just come up with a
nice definition of an orphaned package, it's called the
no-human-maintainer lintian tag:
https://lintian.debian.org/tags/no-human-maintainers.

We can stop the busy work of filing O bugs and point people who wants to
adopt packages to that page.

Yes, they should be open for adoption (as part of the team ideally, except
when the team was the QA team), 0-day NMU, etc.

While there's no obligation, we should not encourage people to take such
packages out of team maintainance. Having a team fallback is always better
than not having one.

Cheers,

https://lintian.debian.org/tags/no-human-maintainers.html

* Julien Cristau <jcristau@debian.org> [160708 15:31]:

I also want to see this. It makes lots of sense, especially for
teams maintaining very large numbers of packages. Honestly, the
individual package does not carry heavy weight in some of those
teams. At the same time, many packages carry old Uploaders,
including names of people that have long been known to be MIA, and
are kept there only to avoid setting an empty Uploaders field.

These packages are clearly not not-maintained (teams care about
them), so orphaning or assinging to Debian QA Group would make no
sense whatsoever. (Also, as far as I'm aware, the large teams are
all very open for anybody to join.)

Am Freitag, den 08.07.2016, 17:36 +0200 schrieb Christian Hofstaedtler:

Mmm, In theory you're right. However in practice see also some
downsides. For at least some teams it is not very clear who is member
of it and on especially smaller teams it is sometimes quite unclear if
the team exists at all. 
Especially in such it will then be lots harder to actually detect an
orphaned package and this might even deter some person taking over the
package. 

Which makes this information invisible to people outside of the team. 

YMMV. That requires a hell of discipline in the team. 
There are many teams that take quite great care about the packages, but
others do not so well (or even existing only on paper anymore). 

From my short time as MIA member I can tell it is already hard enough
to find persons being MIA; to track complete teams will be lot harder.
(
e.g the question who is actually a team member is sometimes hard to
answer from outside)

IMHO if the team commits to maintain that package it shouldn't be too much strain to add an explict carer too, is it? 
adoption. That information would be harder to retrieve. 
However wnpp could be used as a tool here: Why not advertise 
using a RFA and telling there that the team has open positions?

Maybe we should dicsuss this on -devel to get more other views and
arguments too?

* Tobias Frost <tobi@debian.org> [160715 21:03]:
[..]
- for the larger teams - meaningless.

But who would that be?

I do not think "adoption" is the right word here; in Debian context
it somehow implies that the package is orphaned and sees no
maintenance.

*shrug*. In pkg-ruby-extras, that wnpp bug would be very generic:
"please join and work on all packages that you can find" ...

Best,

wrapper around debchange(1) which allows us to do team uploads without
having "Team upload." be the first line of the changelog.  We select new
upstream versions based on snapshots compiled by an outside group.[1]
We upgrade tens of packages to new upstream releases at a time, and
upload them all together (for some time, Clint Adams has done these mass
uploads).  For us, having some random names in the Uploaders: field can
do nothing other than confuse newcomers to the team.

I suspect that we cannot get consensus on this bug.  Many people share
Iain's sentiment, but the issue continues to arise in many contributor's
Debian work.  So it might be advisable to refer to tech-ctte.

Before doing that, at the risk of achieving nothing, I'd like to suggest
another wording:

    ... if the Maintainer control field names a group of people and a
    shared email address, the Uploaders field must be present and must
    contain at least one human with their personal email address.  An
    exception is made for packaging teams which state clearly on their
    homepage, documentation or team policy that all packages are taken
    care of by every team member collectively.

Possibly too bureaucratic, but might allay some of the concerns that
Tobi raised: barely-established teams aren't likely to have a team
homepage/documentation/policy document.

[1]  https://www.stackage.org/

The problem is that the majority of such documentation is outdated and
obsolete to the point of being useless.
Most team start big and then slowly falter until they are reduced to
a single member (because it is easy to distribute work but hard to
distribute responsibility).

So yes at any time they are a number of active, hard-working team, but there
also a larger number of phantom team that used to be active, but whose
packages are still maintained in Debian. It is important they carry some
valid information about the effective maintainers.

Cheers,

Hello Bill,

The problem is that the information in Uploaders is no more likely to be
up-to-date than the team homepage/policy/docs.  And it's positively
misleading to have some names in Uploaders who haven't worked on the
package in ages.  So I don't see how my proposal introduces any new
problems; it's an improvement because it removes a source of confusion.

You should double-check how many teams already have a homepage in the
Debian wiki, such a homepage is not uncommon even for small teams.

cu
Adrian

Information in the control files can be fixed by any uploaders/NMUers much
more easily than information on a website, so control file tend to be
more current. Also they cannot go off-line while unattended websites do
sometimes.

Cheers,

whereas every upload triggers a lintian warning unless the uploader is
listed as such (and unless explicitly circumvented by flagged the upload
as an NMU or an upload by a not-regularly-uploading team member).


 - Jonas

What are the advantages of the Uploaders field over debian/changelog?
I can see some tooling issues, but nothing insurmountable (see
e.g. who-uploads from devscripts). There are also some advantages for
relying on changelog: e.g. it reveals packages only uploaded via NMUs
with the last X months/years, and of course the changelog is typically
even more up to date than the Uploaders field.

Hello,

Here is an updated diff for this bug, against the docbook version of
the policy manual.

I've also included a purely informative change which emphasises that
packages that are team maintained in name only should be orphaned
properly, with their maintainer field set to the QA team.  This is
already current best practice, but it's worth emphasising, because one
might fail to orphan a package on the grounds that "someone else on the
team might fix it", which is not true of a lot of teams.

This purely informative change came out of a discussion at DebCamp with
h01ger, gregoa and David Bremner.  We are CCing -devel because we want
to determine if there remains, in 2017, a consensus that we should not
drop this requirement.  We think that recent objections in the bug are
about implementation details, rather than a concern to retain humans in
the uploaders field.

diff --git a/policy.xml b/policy.xml
index 3daa532..4731507 100644
--- a/policy.xml
+++ b/policy.xml
@@ -1128,13 +1128,6 @@
         described in <xref linkend="s-f-Maintainer"/>.
       </para>
       <para>
-        If the maintainer of the package is a team of people with a shared
-        email address, the <literal>Uploaders</literal> control field must
-        be present and must contain at least one human with their personal
-        email address.  See <xref linkend="s-f-Uploaders"/> for the syntax
-        of that field.
-      </para>
-      <para>
         An orphaned package is one with no current maintainer.  Orphaned
         packages should have their <literal>Maintainer</literal> control
         field set to <literal>Debian QA Group
@@ -1149,6 +1142,12 @@
           </para>
         </footnote>
       </para>
+      <para>
+        This includes packages with a group of people or team in the
+        <literal>Maintainer</literal> control field.  They should be
+        orphaned if the team is not actively maintaining the package.
+      </para>
+
     </section>

     <section id="s-descriptions">
@@ -3448,13 +3447,6 @@ endif</programlisting>
           Maintainer field, and multiple entries must be comma separated.
         </para>
         <para>
-          This is normally an optional field, but if the
-          <literal>Maintainer</literal> control field names a group of
-          people and a shared email address, the
-          <literal>Uploaders</literal> field must be present and must
-          contain at least one human with their personal email address.
-        </para>
-        <para>
           The Uploaders field in <filename>debian/control</filename> can
           be folded.
         </para>

You are omitting the case of a team which get reduced to a single
member, in which case the package need not be orphaned. Yet it is
important the fact is mentionned in the package.

Cheers,

Bill Allombert <ballombe@debian.org> writes:

I don't think I understand the objection.  Sean's proposed wording seems
fine for that case -- it just says that the package should be orphaned if
the team is not maintaining it, which shouldn't depend on the size of the
team.

Am 2. August 2017 23:48:15 MESZ schrieb Sean Whitton <spwhitton@spwhitton.name>:

(Please appologize the brevity, I don't have the time needed to word that
properly)

Well, I still think that not having a human explicitly named as in charge of
the package is not good and will cause more damage than it will bring
benefits.
(Disclaimer: My view is biased with my actitivies in the MIA team)

Some remarks / questions I do not see adressed:
- If you have not a name on some task human nature tends toward that nonone
feels responsible at all. Like the German (fun) expansion of TEAM: Toll, Ein
Anderer Machts (Great, someone else it taking care)
- MANY team homepages are not updated or do not even exist. I think before
droping the requirement to have human uploaders this needs to be fixed by
policy and it must be RC(?) bug if the team homepage is
outdated/absent/inaccurate. The infomation about the teams *must* be in a way
that it can be easily found/parsed.
- There is currently no way to map a person to a team or to map a team to a
list of members -- if you need accurary. This is especially true for teams
that are smaller. - - When someon is going e.g MIA, we need to know which
teams are involved to trigger them.
- Not in all teams it is working tha everyone is looking at every package.
During the lipng transistion I filed many bugs on team-managed packages which
were never answered
- We have already the problem about "partially MIA" -- people holding several
pacakgages but neglecting several of them. Currently we have no real measures
of taking care of the neglected one, MIA team wise. This will be amplified
when there is no human responsible person named.

The patch also remove the requirement to list individual email of the
maintainers. That is what I am objecting to.

When a team is reduced to a single individual, it is no more a team, yet
the package is still maintained and need not be orphaned.

Cheers,

This would not be "a purely informative change".

Your suggested wording has the potential to create a HUGE amount of tensions.

I could name a lot of team-maintained packages where a team member
uploads a new upstream version every 1-2 years and noone ever bothers
to handle incoming bugs.[1]

If policy does not provide a definition of "actively maintaining",
it would be a reasonable interpretation to consider a package with
no upload or visible activity in new open bugs during the past
6 or 12 months as not actively maintained.

If policy states that such packages "should be orphaned" without
describing a proper process, it is a valid reading that everyone can do
this without trying to contact the team prior to orphaning the package.

And it does not even help with the problem Tobias raised:

When a maintainer retires or is declared MIA by the MIA team according
to the MIA process, how can you *find* all teams and team-maintained
packages where this maintainer was the only or last active team member
when there is no Uploaders: field?

This information could be moved from the Uploaders: field to
a database, but then this database has to exist and maintaining
the information there has to be mandatory when no Uploaders: field
is present.

Another option would be to keep the Uploaders: requirement,
but make it more clear that autogenerating is permitted.

The GNOME team already generates Uploaders: as the intersection
of current team members and people who did the latest 10 uploads
of a package.

cu
Adrian

[1] a few people are IMHO just bad maintainers, but in the common
    case there is simply too much work for too few people in a
    volunteer project and new team members are always welcome

Your objection does not make sense.

The change Sean is proposing is intended to make providing the
information about team members in Uploaders: optional.

If are not objecting to removing the information about who is in a team,
you cannot suggest that anything should be done based on the no longer
existing information about the number of team members.

cu
Adrian

This bug is about making providing the information about team members
in Uploaders: optional.

That's the core point discussed.

The part you were referring to is an attempt from Sean to address some
problems caused by this change. This is not a standalone proposal.

If Uploaders: stays mandatory, we do not need new rules for orphaning
team maintained packages that compensate for the no longer available
information about team membership.

cu
Adrian

How do you express "X is no longer a member of the team maintaining
package foo" in a way that all tooling understands it?

There is also the opposite problem of team members in Uploaders: who are
actively working on the package in the git repository, but only one team
member does the actual uploads.

If you still can't see insurmountable tooling issues, please try to
write such a tool. As testcase, try to find the active members of
the Debian Lintian Maintainers from the lintian debian/changelog

cu
Adrian

Bill Allombert <ballombe@debian.org> writes:

Oh, okay, I see that, but I'm not sure why.  What is the purpose of
listing those email addresses that you want to preserve?

It still is a team even when it's one individual.  I don't know why you
would say that it's not.  A team can certainly contain just one person.

I'm confused about how this is at all related to listing individual email
addresses, and I don't understand why you think this would result in a
package being orphaned.

word "should", which is a magic word in policy, imposing a normative
requirement.  This was not intended.

My intended meaning: it is already best practice that *other team
members* should orphan a package if they know that no-one in the team is
actively taking care of it *according to their judgement of 'actively'*.

Would you agree that this is already established best practice?

I'll reply to this when replying to Tobias' remarks.

Hello Tobias,

Thank you for writing about this bug from the MIA team's perspective,
which is very relevant to resolving this.

In most teams, this happens anyway -- I would take this as an argument
against team maintenance more generally.

For teams on alioth, would you find the list of team members on the
alioth project insufficient?

I agree this doesn't help with teams that do not use alioth but are
based around a mailing list.

As Adrian said, it's not clear what an alternative to Uploaders would
be for this purpose.  But I'm not sure that Uploaders is much use,
either, because in so many teams it's simply not kept up-to-date.


Could you explain further how this would amplify the problem?  I agree
that this is a serious problem, but I don't see how this change would
amplify it.

Am Donnerstag, den 03.08.2017, 12:44 -0400 schrieb Sean Whitton:

The lists on alioth are hardly accurate. Also, as you say:

This and in combination that team information is not in an defined
location makes it quite hard to find useful, accurate information.
Not mentioning that there is no way to do an lookup in which teams
someone is; so there is no way to trigger them to act when e.g someone
has left the project and did not clean up after them.

Some time ago I did some spring cleaning going over DDs that have
retired but still in the Maintainer/Uploader fields: There were quite a
 lot "team maintained" packages where the team did not recognize that
the (sole) Uploader wasn't there anymore and the packages were
bitrotting. Without the Uploader field there would have been excactly
zero change to find those packages and get them back into maintainance
again.

Removing the requirement won't help here either; It would just mask
this fact and makes it harder for other parties to detect this.

I think the "how can I contact somone on the team" could be fixed, like
(brainstomring) e.g by a Team-Contact field in d/control with an human
contact and formalizing requirements on a Team so that they are allowed
to drop the Uploaders -- if they fulfill this requirements. One
requirement could be e.g  that the team has a site on the Wiki and we
need some central place to record the team members and a mandatory
enrollment process (like the yearly team member ping that the perl team
does, AFAIK)
NOT a name tacked to an task, the likelyhood of noone will feel
responsible and the task not done is very high.

Relates to the "if there is no name attached to a task" thing explained
above. 
Also mind that we really do not have processes at hand to handle those
situations. The MIA team has already now no actual power on "partially
MIA" situations, but in the past it often helped to write a nice mail.
If I write to the anonymity of a team mailing list, I guess those mails
will be more easily ignored.

Quoting Russ Allbery (2017-08-03 11:41:12)

Do the MIA team also track MIA teams?

My concern is that packages without maintainers may go unnoticed when
none of its previously active maintainers were tracked individually.

For such detection of abandonment we need not track _all_ active
maintainers, but at least one - as individual.


 - Jonas

Jonas Smedegaard <jonas@jones.dk> writes:

Or track MIA teams, which in a lot of ways is a much easier problem, and
seems like a worthwhile problem to solve anyway.

I don't feel like dropping the Uploaders field for team-maintained
packages if the team so chooses will make MIA tracking substantially
harder, or will make orphaned package tracking substantially harder.

Tobias Frost <tobi@debian.org> writes:

I'm dubious about this assertion and would like to dig into it a bit more.

The way we hopefully would find bitrotting packages is that they are,
well, bitrotting.  This is based on lack of uploads, open bugs, old Policy
versions, incomplete transitions, and in serious cases, missing from
stable releases.  While we can *also* find bitrotting packages via the MIA
process, it shouldn't be our primary or even a major way of finding them
since it's entirely possible for someone to be quite active in Debian
while still neglecting some of their packages.

Keeping around uploader information that we know gets constantly out of
date and is kind of irritating to maintain, plus results in noise for team
members that they don't want, just so that we can detect packages that
aren't being worked on feels like putting the cart before the horse.  It's
pretty obvious *from the package* if a package isn't being worked on.  And
detection based on uploaders isn't even accurate: there are teams that use
semi-automated tools and sprints and mass uploads to maintain tons of
packages, and listing themselves as Uploaders on everything they touch is
just extra work and doesn't carry any useful meaning.

Currently, when the MIA team finds someone who is no longer active, teams
have to go do a bunch of work to strip their name out of uploader fields.
That work doesn't really make Debian any better; it's just bookkeeping.
When the team has other ways of knowing the health of their packages, I'd
like to let them not do this bookkeeping.
Maintainer field.  I feel like we're inventing extra complexity without a
good motivating reason for it.  If no one replies to mail to that address,
I'm dubious you're going to get much more of an (actually useful) reply to
mailing individuals either.

This feels like way more bureaucratic structure than Debian needs.  What
specific problem in Debian are you trying to solve with this sort of
formal org chart maintenance?  I think this is quickly going to get out of
date, and it's not particularly compatible with structures like the Perl
team, which has tons of members doing varying amounts of work based on
their available time and energy and knowledge.

And yet I can name counter-examples, such as the Perl team who maintain
hundreds of packages as a team effort and do not look out for *only* the
packages they personally care about.

Packaging teams that aren't doing a great job of maintaining their
packages will continue to not do a great job of maintaining their packages
whether or not they're listed as uploaders.  We already have other tools
for finding packages that aren't well-maintained.  I can see the argument
for keeping uploaders if it gave people some motivation to work on those
packages, but in practice (and I say this as someone who has been a member
of a ton of packaging teams), the uploaders changes quickly become just a
minor bit of bureaucratic housekeeping that I do once and then never look
at again, and I stopped looking at my package list on qa.debian.org
because it became useless due to all the team noise.  So I don't think
this is achieving what you intend to achieve.

I agree that this is a problem, but this is a problem regardless, and we
will need to address this regardless.  I don't think it's closely related.

(I am entirely in favor of giving the MIA team more actual power.)

are two orthogonal questions in my mind:

 - is a specific person MIA?

 - is a package still maintained?

There is not necessarily a direct relation between both questions.
Take for example a person who someone in this thread called
"partially MIA" (I don't like that term btw.): they still actively
maintain a bunch of packages, but have dropped the ball on another
package.

On the other hand you could have a package that has
Maintainer: some team and Uploaders: some person, where "some
person" is actually MIA, but the rest of the team is still actively
maintaining the package.

The main problem I see with Uploaders: is that it's often not really
up to date. So I do think that it might be a good idea to track the
people who are responsible for a package outside of the package
itself in some kind of central database that is not tied to package
uploads. This could also make it easy to query that database. On the
other hand I would not want to maintain a team membership list for
this purpose, but track by package, because while there are small
teams where everyone is responsible for every single package, there
are also larger teams where not everyone cares about every single
package that the team maintains. So I don't think the Uploaders:
field in a package is useless, I just think the current way of
storing that information is not the best way to do so. But until
such a central database is ready for usage, I don't think it would
be wise to drop Uploaders: at the moment, because otherwise that
information can't be tracked at all.

To help with the question of whether a package is still being
actively maintained, let me frame it in this way: I think it is
not completely unreasonable to say that _most_ packages will be
updated at least once every 12 months in sid or experimental. (The
precise number is subject to bikeshedding.) Of course that's not
true for every package, there are some packages which don't require
updates that often. So what one could do is the following: a
package is considered to be actively maintained if a maintainer (or
team) upload has happened in the last 12 months. (NMUs don't count.)
If that is not the case, after 12 months an email is automatically
sent to the maintainer/uploaders to ask whether they are still
actively maintaining the package. They then have 3 months to respond
by either uploading a new version to sid or experimental, or
replying to that email that "yes, the package is still being
actively maintained, there was just no reason to update it recently".
Then there could be a clear way of determining what packages are
candidates for orphanning (while the email + reply logic should be
automatic, the orphanning should only be done after a human looks
that over). Obviously the precise amount of time can be bikeshedded,
but I do believe that the general concept is something sensible.
Becuase if one is indeed actively maintaining a package, then they
should be able to reply to an email every year or so. (Especially
if just doing "reply" + "send" is sufficient, like with mailing
list confirmations.)

Just to throw some ideas out there.

Regards,
Christian

Am Donnerstag, den 03.08.2017, 14:50 -0400 schrieb Jonas Smedegaard:

Yes, we also track teams.

However, Tracking teams is quite hard and much more time consuming as
information about the teams are not easy retrieveable, and you run
easily in the situation of "partial MIA". Teams with active members --
but activity not within the team or just on a subset of packages.

(But we're actually getting only very seldom requests about teams)

[…]

Thanks for putting my thoughts (again!) into better words than I ever
could!

(Me too. And, tangential to this discussion but still: maybe also to
packaging teams, like for salvaging un(der)-maintained packages.)


Cheers,
gregor

On Thu, 03 Aug 2017 21:25:32 +0200, Christian Seiler wrote:

Thanks for your long and elaborate email.
Unfortunately I find myself disagreeing with your two main points:

Ack, separating these questions makes sense to me.

Right, I think that's the situation that the proponents of this
change have in mind.
information to another place; and more generally: I fail to see which
problem it solves.

I guess this is the general difference in perception we have in this
discussion: Some people start from the idea of "responsibility of a
human for a team package" while others are happy and have good
experiences in teams where all (or enough) members take
responsibility for the team packages and feel that a "dedicated human
responsible" doesn't make sense in their workflow.

What I don't understand in the point of view of the "keep Uploaders"
proponents: What does this information, whether correct or not,
actually give others? Are they going to email or phone these persons
privately when emails to the BTS or the maintainer/team list are
ignored? And what happens if they ignore these communications as
well?

I'm sorry but this feels like loads of paperwork for active teams
with tons of package which might not need an upload each $months.

I mean, in the worst case we could script the replies to the pings but
I'd rather not go there :)


Cheers,
gregor

That completely misses the problem.

If the team has remaining members, and one of these members knows that
no-one in the team is actively taking care of a package, then what
happens afterwards is obvious.

Finding unmaintained packages is the hard part.

In a bigger team maintaining 500 packages it is a non-trivial amount of
extra work searching for packages no-one inside the team is actively
taking care of.

In a small team with 2 members maintaining 1 package, what you write
obviously cannot work when the last team member becomes MIA.

With Uploaders you are able to see when all uploaders are retired/MIA,
either inside the team or from outside when the team has no active
members left.

cu
Adrian

+1

agreed as well.

Then, Tobias has a point, knowing which team members uploaded a package is
useful. So I have a simple proposal to achieve that: make tracker.d.o
show the last 10 uploaders for a given package (based on UDD), just like it
parses the Uploaders: field from the packages now.

And probably some pages where all uploading team members of given teams are
shown.

I agree.  This information is useless, and even if it's not, the source
package is entirely the wrong place for it.  Let's get rid of the
Uploaders field entirely.

https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintainers@lists.alioth.debian.org#_2_5_5

These "Updating the <package> Uploaders list" bugs.

When the MIA team has determined that a person is MIA,[1]
it can send bugs informing all packages where that person
is listed in Uploaders that the person is no longer active.

For small teams (e.g. 2 people in a team maintaining 1 package)
this is also a way for seeing when 0 team members are left who
are still active in Debian.

cu
Adrian

[1] or retired, all this is about what happens after it has been
    determined that a person is no longer active in Debian

Ok, that's a good example:

So, when we (pkg-perl) get such a list of bug reports (or, which is
less work, a single mail from the MIA team about XY being inactive)
what happens is that
- we probably know that already (but it's still good to have the
  offical confirmation)
- we remove them from Uploaders in git
- nothing else changes: the package will be uploaded when there's any
  reason for it (new release, bugfix) as before when XY was still
  mentioned in Uploaders

Dropping the Uploaders field would mean that we save the work (which
can be quite tedious when we have to add the right bug numbers to the
right packages' changelog entry) without any other changes to the
maintenance of the package.


Cheers,
gregor

maintainer would be very bad.

Think of it as a 3 step process:
1. a bitrotting package indicates a potentially MIA maintainer
2. the maintainer agrees to orphaning all packages, or after several
   failed contact attempts the MIA team declares that the maintainer is MIA
3. for every package where the maintainer is in Maintainer or Uploaders
   the MIA team either orphans the package, or informs team or
   co-maintainers through an "Updating the <package> Uploaders list" bug.

Just by going through bugs, I compiled during the past 10 months a list
of currently 250 (sic) names of people listed in Maintainer or Uploaders
of packages in unstable where I suspect the person might be MIA.

Automating this part would not be a problem, the intersection of
"in Maintainer or Uploaders of a package in unstable" and
"no email to a Debian list or the BTS in the past 12 months"
should give approximately a superset of my list.

Step 2 is actually a lot of work.

The part where removing the Uploaders: requirement could cause
regressions is step 3.

Give for a person a complete list of all packages where this person was
active" - if we regress on this, it means that packages will continue to
bitrot in cases where they can currently be orphaned.

You are assuming that the team notices without the current notifications
from the MIA team that a team member is no longer active in Debian.

You are assuming that the team has a non-zero number of active members
left after a member becomes MIA.

cu
Adrian

Adrian Bunk <bunk@debian.org> writes:

I agree, but that's not directly relevant here, since we're talking about
team-maintained packages.  The whole *point* of team maintenance is that
there's no reason to orphan a package just because one team member went
away.  If that weren't the case, the package is, *by definition*, not
team-maintained (or the team itself is MIA, which is a different issue as
discussed below).

I'm really not.  I'm pointing out that for a lot of teams, that literally
*does not matter at all*.  Absolutely nothing changes about the
maintenance status of many team-maintained packages if the person who last
worked on that package disappears.

Teams often don't notice that someone is MIA because *it doesn't matter*
for their workflow; they're happy to have people come and go.

No, I'm not -- as I pointed out in a separate message, this is a problem
worth solving, but this is an MIA team problem that I think is best
tackled from that angle.  If all of a team's packages are bitrotting, then
the team's packages should be orphaned just like we do with an MIA single
maintainer.

But then the information who is currently part of pkg-perl is needed in
machine-readable form and displayed by tools like DDPO and tracker for:
1. being able to inform a team that a member is MIA and inform the team, and
2. being able to detect when the last team member is MIA

Policy equally applies to packages where point 2 is far more likely to
happen than for pkg-perl.

Autogenerating Uploaders like GNOME does [1] would be an alternative
approach.

cu
Adrian

[1] https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/

Your definition is completely detached from the reality in Debian.

Many (likely the majority) of teams in Debian have not more
than 1 active member.

When all members of a team are confirmed to be MIA/retired,
this should result in an orphaning of all packages maintained
by the team.

This would create both longer bitrot for packages and more work for
an already overworked team.

cu
Adrian

Adrian Bunk <bunk@debian.org> writes:

Then when that one member disappears, that team becomes MIA, which is
something that would need to be detected by an MIA process for teams,
which I agree should exist, but which I think is detectable via other
mechanisms than Uploaders.  One approach as Holger points out: look for
packages where all the recent uploads have been by the MIA member, which
doesn't require the Uploaders field at all.

I stand by my statement that as long as the team *does* have more than one
member, not having to change anything abot package maintenance when one
team member disappears is kind of the whole point of having team
maintenance.  If the team is not providing that, it feels like there's not
much point in having a team, although I guess it could be aspirational.

One of the whole points of this discussion is that this "members of a
team" concept is not well-defined in Debian and is probably not something
that we *can* make well-defined in Debian.  Or, more to the point, *want*
to make well-defined.

Why?  I don't see how this follows; in fact, I believe the exact opposite.
The current work that the MIA team does to track down Uploaders that
mention MIA people on team-maintained packages and file a bunch of bugs to
have them removed is work that they *don't* have to do in this model.
Instead, just treat the team like another maintainer and look at whether
that maintainer's packages are being maintained and whether that team is
active and orphan packages if they aren't.

Am Donnerstag, den 03.08.2017, 23:09 +0000 schrieb Clint Adams:
major information source to determine if someone is MIA -- before
sending the fist mail.
With only teams in the Maintainer field and no other source of
information to get that information easily, the MIA team will go
defunct or it will make the work by magnitues harder.

And as the fallacy is keeping showing up repeatily in other answers:
The perl team is extraoridnary. They are very well organized and there
it works. But the mayority of teams is not the perl team.

Have to go for $DAYJOB now.

As I already tried to explain, this is an easy part that could be
automated. The half-year MIA process that follows is the bottleneck,
and wasting slots on teams would make the bottleneck even worse.

This is how you imagine how teams should work, not a description of the
actual reality in Debian.

As an example, we do have teams that define in their policy the
semantics for "person in Maintainer, team in Uploaders".

It is interesting how you manage to argue both based on a very specific
definition of teams you have in mind, and based on declaring that all
this is not well-defined and that we neither can nor want to define it.

What is needed is a machine-readable mapping between teams and their members.

Mandatory Uploaders gives a good-enough approximation of that.

Removing that without replacement would be a regression.

Declaring someone is MIA is the result of a half-year process.[1]

Doing a MIA process for a team many years (and several releases)
after it has been confirmed that all team members are MIA would
both lower the quality of Debian and create additional work.

You are trying to push the solution of making Uploaders optional
for teams, marginalizing any new problems it might cause.

Let's go back from trying to push a solution to discussing the problems
that should be solved, and the problems different potential solutions
might cause.

I do understand that for teams whose policy states that every team
member maintains every package and that maintain many packages it
is not convenient to manually update uploaders. Is this the one
problem that should be solved, or are there other problems that
should be solved here?

An alternative option of maintaining machine-readable information
about team member in a different place outside the packages would
fix the problem of losing information about team membership.

Or the low-change option of documenting that the already used way of
autogenerating the Uploaders list based on information stored in one
core package of the team is a valid option - this allows teams with many
packages to get rid of the problem of having to update this information
manually in every single package.

cu
Adrian

[1] https://wiki.debian.org/qa.debian.org/MIATeam

Hi,

as a more radical change one could also ask the question where to
maintain the maintainer information.  Currently we handle this in the
source package via the Maintainer and Uploaders field, and via team
memberships.

This has several limitations: for teams, Uploaders will often be
useless (you don't want to list all team members in every team-
maintained package).  The Maintainer field only really applies to
Debian, in derivatives someone else should be contacted.  In stable
releases, the field can often be outdated (it records who maintained
the package some time ago, not who currently maintains it).

So I have been wondering several times whether we should move the
maintainer information elsewhere.  For example, tracker.d.o could be
extended to record maintainer information.  It could also understand
the concept of "teams" listing team members and whom to send mails
about individual packages.

For legacy purposes, the Maintainer field would then list ${source}@tra
cker.d.o and the Uploaders field could be removed.

This would also address the fact that various bits of our
infrastructure don't know about Uploaders (like bugs.d.o only
contacting the Maintainer).

Ansgar

This has been planned by the distro-tracker folks for many years,
there is even a DEP about it:

http://dep.debian.net/deps/dep2/

And it would not work when the latest maintainer upload was by a team
member who retired or was declared MIA earlier.

There are also other situations where a mapping between teams and
all members of the team can be very useful.

Uploaders is not the only option for doing that, but any change
should include provising more reliable information - not less
reliable information.

An O: bug means that it is confirmed that the package is orphaned,
and gives permission to everyone to adopt the package immediately.

cu
Adrian

That can be found out by recursing until you find a non-MIA individual
who has uploaded since the previous stable release, or something like
that.

In practice, Uploaders often only includes people who have ever uploaded
the package, not everyone who is on (or still on) the team. I you'll
have better luck with a who-uploads equivalent.

So just file an an Intent-To-Orphan bug. [This why I suggested to file
the bug against the package, and not against wnpp.]

In N days, the bug can be filed against

In practice, Uploaders often includes active team members who work
in git, but one specific team member does all the uploads.

I already gave the lintian package as an example for that.

And in the other direction what you describe would leave no way for
a person to make it visible that he has left the team.

There is no Intent-To-Orphan bug.

And whenever possible the process should work by first confirming
that a person or team is MIA, and then orphan everything that was
maintained by that person or team.

In a more general note, I am a bit puzzled that it is so controversial
that machine-readable team membership information is important and
should continue to be available.

cu
Adrian

Nowadays orphaning is done by reuploading the package with the
maintainer set to the QA group rather than using a O: wnpp bug.

Cheers,

It is rarely my experience that people leave teams in clean, definitive
breaks. If they did, packages wouldn't have to be orphaned by the QA
group. Maintainers would take care of that themselves.

Not currently, but one can be created.

Because maintaining such a field increases the burden on teams for
little to no benefit. I know I haven't bothered to be sure that the
Uploaders field in any of my packages only contains people who are
currently actively involved in maintaining that particular packages.

Good point.

Adrian Bunk <bunk@debian.org> writes:

One of the major points of disagreement in this thread is that you think
this information is currently available and useful, and other people (such
as myself) think that your understanding of Uploaders has little
relationship to how the field is currently used in the archive.

I'm dubious that it's worth the effort to maintain this, but regardless of
that discussion, machine-readable team information is not something we
have now.  We instead have a partial record of some people who have
previously worked on the package, without much information about whether
they're currently working on the package.  It's marginally more useful
than the debian/changelog entries, but only marginally.

Hi,

Ansgar Burchardt wrote:

This would make me pretty happy, for what it's worth.

Thanks,
Jonathan

Package: tracker.debian.org
Severity: wishlist

Such a feature would move this discussion forward, so I'm submitting it
as a feature request.

I think that the logic in who-uploads(1) is probably insufficient;
parsing d/changelog would catch people actually /contributing/ to the
package, not just those who signed the uploads.

Hello,

I don't understand this suggestion.  If it can be automatically
generated, just generate it when you need it -- why store it in the
source package?

Am Freitag, den 04.08.2017, 22:46 +0200 schrieb Bill Allombert:

NO. Simply NO. 
That behaviour would be really rude.

Am Freitag, den 04.08.2017, 12:10 +0200 schrieb Ansgar Burchardt:
not required that everyone how ever touched the package needs to be
Uploader. 
(somewhat related #630578.)

As this is often brought as argument to remove Uploaders: why doe the
teams think that they need to update Uploaders on every upload?

This would be best. Having the information in some database, which is
also much more easy to retrieve programmatically a good dataset.

Yes. But please not drop Uploaders first and then implement this e.g
database.

Am Freitag, den 04.08.2017, 01:58 +0300 schrieb Adrian Bunk:

Which, by the way, is already a hard problem on its own.

Am Donnerstag, den 03.08.2017, 11:58 -0700 schrieb Russ Allbery:

No, because with a $TEAM you have to expand it to $TEAM_MEMBERS and
check them individually.

What cannot be automatically generated is the other side of the
intersection:
https://sources.debian.net/src/gnome-pkg-tools/0.19.9/pkg-gnome.team/

And you cannot automatically generate whom the team considers as members.

This is policy specific to a team, where some team members might only
work in git (see the lintian example) and others might have left the
team recently.

cu
Adrian

It does not bring benefit to you personally.

It is quite useful elsewhere.

Whom you officially list as co-maintainers of your packages is your
decision.

Bill was giving alternative facts.

cu
Adrian

Policy says that Uploaders should list all co-maintainers.

Who is considered a co-maintainer is determined by team policy or the
other maintainers.

Uploaders is machine-readable.

True, but the situation is actually better than for the Maintainer field.

There is a very popular (not team-maintained) package where the person
in Maintainer is still reachable by email but hasn't uploaded since 2014,
and the last 80 uploads were made by the people in Uploaders.

For fringe leaf packages, it is perfectly possible that we might
have people in Maintainer who died 10 years ago.

And disappearing uploaders in team maintained packages can be much
easier solved than disappearing Maintainers in not co-maintained
packages: The team can drop an Uploader without a 6 month MIA process.

cu
Adrian

I assume you are thinking of parsing the [ name ] syntax used by many teams.

Note that a prerequisite for such debian/changelog parsing would
be that policy sets strict syntax and semantics requirements.

Examples:

Some teams use different syntax.
I did already state in the policy bug that extracting this information
from the lintian changelog is my challenge to everyone who thinks that
that this could be extracted from current debian/changelog.

This can only work if policy states that that the established practice
of many people using this syntax also for patch submitters is no longer
permitted.

cu
Adrian

Adrian Bunk:

The syntax used in lintian's changelog is relatively unique to my
knowledge; if by changing it we can actually have this proposal work,
then let me know and I will raise that internally in the lintian team.

Thanks,
~Niels

Hello,

Yes.

No, we do not need to block such a feature that would work for 90% of
packages until we have a policy about the [ name ] syntax.  It can begin
as a useful heuristic.

How do you get that it would work 90% of package ?
Using [] for non-team members is very common.

Cheers,

for getting the _uploaders_ it's not even required to parse those fields, as
each upload has one uploader which is semantically strict defined already.

work-around / an estimate, as we have nothing better. Yet it's very often
inaccurate as eg src:debian-edu shows, which at least I don't keep accurate
as I dont want to remove people unneccessarily (can be seen as stepping on
their toes), have added people who will not upload (because currently this
field is indeed abused to generate team member metadata) and sometimes
people were even added even though they don't want to belong to the team.

;tl;dr: I think we need a better system to manage team membership in Debian.
(Ab)using the uploaders: field gives an estimate or datapoint today, but we
have other means to gather this data.

Policy says that Uploaders contains the _co-maintainers_.

And that also matches what most teams do.

cu
Adrian

It is the official place to list co-maintainers.

No, we do not have currently any other means to gather who is considered
a team member by a team.

And that's the problem.

cu
Adrian

you keep repeating this but its still broken by design.

then it's time to fix this and not hold on to a band-aid solution which causes
grief.

One thing that is worth discussing here:

For how many teams would it bring real benefits if they no longer
have to maintain team membership information in every source packages?

My guesstimate is that these might perhaps be 5 teams.

Why is my guestimate so low?

It only brings real benefits for teams:
1. that do not have a concept of package ownership inside the team, and
2. that maintain many packages.

Regarding the second point, there clearly is a real amount of work
removing a person from the Uploaders of hundreds of packages.
But when a team maintains only 5 packages this is no longer a problem.

Regarding the first point, most large teams do have have the concept of
package ownership inside the team. Sometimes with well-defined semantics
regarding the differences between putting the team in Maintainer and the
human in Uploaders, or putting the human in Maintainer and the team in
Uploaders. For these teams it is no question that Uploaders is useful.

A reason why "generate Uploaders based on team member information
stored in a core package of the team" sounds like a reasonable solution
to me is that I think a solution is required only for a handful large
teams.

cu
Adrian

Maybe, maybe not.
So far I've seen mostly voices from people working in teams in this
thread who are in favour of dropping the required Uploaders field.

- Team membership is easily available for teams which use Alioth. [0]
- Does this suggestion mean we should put 140 people in Uploaders? [0]
  And/or sync Alioth project membership to a package regularly?

[0] https://alioth.debian.org/projects/pkg-perl/


Cheers,
gregor

Perfectly fine, thanks for adding your point of view.

(And just to be sure: The proposal is not to forbid or drop the
field, just to make it optional instead of required for teams, so
each team would be free to keep it and use it according to their
policy and needs.)


Cheers,
gregor

gregor herrmann <gregoa@debian.org> writes:
Astro), and I would favour keeping it -- exactly for the reasons Adrian
wrote: In Debian Astro, most packages are practically maintained by
a single person, who should also feel responsible. Team maintenance at
this stage gives the possibility to contribute to the git repository,
and to ease "NMU"s. d/changelog is not the proper solution, since it
contains the person who did the last upload, independent of whether it
was a team upload or a take-over. And incrementally investigating
d/changelog to find the last non-team-upload (which also may be done by
mistake) does not sound very smart.

There is the concept of "people feeling responsible for a
team-maintained package" which is not identical to the team itself. This
difference should be documented, and since it is the same kind of
information as the original Maintainer: field, I see no reason to put it
into a different place.

Best regards

Ole

Tobias Frost <tobi@sviech.de> writes:

Well, as I've already said, I don't agree with this approach for finding
MIA teams.  I'm not sure if you disagree for reasons you're not saying, or
if you just didn't see that message, or if I missed another message from
you explaining why you disagree.

Anyway, I truly don't understand why you can't determine MIA teams based
on whether their packages are maintained.  Team-maintained packages not
being uploaded translates into the team being MIA (regardless of the MIA
status of individual members).  I think it's in a lot of respects much
more straightforward than MIA maintainers, since you don't have to worry
about voting and other maintainer privileges and access.  And with most
teams there will be fewer edge cases where there are legitimate reasons
for all of their packages to have just not needed an upload, since teams
are less likely to only have a single leaf package.

Adrian Bunk <bunk@debian.org> writes:

Your understanding of Policy is incorrect.  (This is one of the few topics
in this thread where I can put on my Policy Editor hat and say that this
isn't just a matter of opinion.)

Policy says that all co-maintainers *who are not included in the
Maintainer* field should be listed in Uploaders, which obviously means
that team members do not have to be listed there since they're included in
the Maintainer field.

The only reason why anyone gets added to Uploaders from a Policy
perspective for a team-maintained package is the statement under
discussion here:

    This is normally an optional field, but if the Maintainer control
    field names a group of people and a shared email address, the
    Uploaders field must be present and must contain at least one human
    with their personal email address.

*At least one human.*  Not everyone on the team.  And note how this
specifically talks about how the Maintainer field can represent a *group*
of people.

Team membership information does not exist in a machine-readable form
right now.  You have misunderstood the meaning of Uploaders and it is
leading you to draw a bunch of other erroneous conclusions.

mandatory.

Kind regards

      Andreas.

- 466 teams maintaining packages in unstable
- 8 is the median number of packages maintained by a team
- 73 teams maintaining a single package

A package with 500 LOC might have an own team:
https://qa.debian.org/developer.php?email=hostname-devel@lists.alioth.debian.org

cu
Adrian

[1] grep -Ei '^Maintainer.*(team|maintainer|lists.alioth.debian.org).*'

Hello,
tracker.debian.org. As Paul already pointed out, I started a
DEP on this a long time ago (altough it's broader in scope):
http://dep.debian.net/deps/dep2/

While storing the maintainer information in tracker is far from being
done, I actually worked on various steps to make it possible to have
a generic maintainer address like "<source>@packages.debian.org" (like I
ensured that the packages.debian.org email aliases do not include
packages.debian.org email addresses to avoid loops [1]).

I think the only missing step is some sort of logic to drop duplicate
emails that we would currently get through the tracker if we do not change
anything in dak or the BTS or other scripts that are currently mailing
both the maintainer and the tracker directly.

In the future, I would like to be able to also use “team+foo@tracker.debian.org“
so that it's automatically tagged as being part of the corresponding team
and so that the associated mails are sent to the team subscribers. But
here again we have quite some work to do.

FWIW, I just tried to use zim@packages.debian.org as maintainer for my zim
package, we will see if my analysis is right and if I only get a few
duplicates. We will have to fix lintian too because I just see this:

E: zim source: maintainer-address-causes-mail-loops-or-bounces Zim Package Maintainers <zim@packages.debian.org>

And the tag is not overridable and it's fatal for dak. Ansgar, do you
feel like disabling that auto-reject tag temporarily so that I can upload my
test package ?

Cheers,

[1] https://anonscm.debian.org/cgit/webwml/packages.git/commit/?h=debian-master&id=5f4f27920e996e521d32dfb5a9693a09348d18d5

/me just realized he made a stupid mistake by grep'ing Packages instead
of Sources.

Approximate data based on grep'ing Sources:
- 452 teams maintaining packages in unstable
- 3 is the median number of packages maintained by a team
- 155 teams maintaining a single package

Ansgar Burchardt writes ("Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)"):

Yes.

Indeed.

Yes.

I think this would all be brilliant.

Ian.

remember was during DebCamp/Conf17 in Montréal.

Ah, here we go: #798476


Cheers,
gregor, cc'ing the bug

tags 798476 patch
thanks

Hi!

Given discussion on debian-devel about relaxing the requirement for a
Uploaders: header and making this optional, I wanted to suggest a patch.

It is my personal opinion that things would be better without requiring
the Uploaders: field, but I have thought this was a opinionated belief
but the discussion on debian-devel suggests others share this.  Maybe
there are still strong opinions against this that I've missed, but at
least this patch allows a more focused discussion about how a change to
policy could actually look.

What do you think?

/Simon

Simon Josefsson <simon@josefsson.org> writes:

There's an ongoing discussion with the relevant Debian team who raised an
objection last time. I'd prefer to wait to act on this until that
discussion resolves.

I too don't really understand how Uploaders is really helping, but I'm not
the team doing the work and the team doing the work said that it is, so I
want to make sure they have an opportunity to explain. It's entirely
possible that I'm missing something important.

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

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?"

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.

Tobias Frost <tobi@debian.org> writes:

Thanks for explaining!

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?

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

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?

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)
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?²

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

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

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.

If a team member does not list themselves in the Uploaders field of of a
team-maintained package, then there is no need to notify the team that the
member is inactive.

With that point of view I still do not understand how making the Uploaders
field makes your work harder.  I do get the point that if an Uploader-optional
policy were abused, with people agressively removing the field, especially when
the package mainainer is not a formal team, it would be bad for you, but maybe
the solution is to carefully word the policy change to make it clear that
antisocial behaviour is not welcome?

Have a nice day,

Charles

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,

Tobias Frost <tobi@debian.org> writes:

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.

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.

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

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).

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.

Interesting, do you have a URL?

/Simon

Hi,

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 the team as well?

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 put on the "in charge" hat, the package should be dropped from the team.

Please also note that pretty much all the maintainer tooling assumes things to be that way – for example, my DDPO lists team packages I am responsible for, so I can check on them doing my maintainer duties on behalf of the team.

I may have missed essential parts of the discussion, but as I see it, 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.

So, how about put a clear definition of the Uploaders field in the policy instead, in regard of what the duties of the Uploaders are?

Dominik George <natureshadow@debian.org> writes:

No.  It means the team is in charge.

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?

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.

It 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.

I don't think anyone has suggested your semantics, or that it follows
from anything part of the Debian Policy or any other document.

/Simon

I think you are confusing ownership with responsibility.

"Ownership" 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.

In other words:

* a bug is opened -> anyone in the team should act
* security team contacts team -> anyone should act
* upstream contacts team -> anyone should act

All these are reasons for team maintenance.

But on top of that, there are *regular* tasks maintainers should do, like checking for new upstream versions, or in general, keeping an eye on the DDPO for anything that does not open a bug or trigger communication on its own. And *that's* where I see the relevance of the maintainer field.