Re: Bug#798476: Returning to the requirement that Uploaders: contain humans
- Date: Fri, 4 Aug 2017 12:37:53 +0300
- From: Adrian Bunk <bunk@xxxxxxxxxx>
- Subject: Re: Bug#798476: Returning to the requirement that Uploaders: contain humans
On Thu, Aug 03, 2017 at 06:48:27PM -0700, Russ Allbery wrote:
> 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.
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.
> 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.
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".
> > 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.
> 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.
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.
> >> 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.
> > This would create both longer bitrot for packages and more work for
> > an already overworked team.
> 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.
Declaring someone is MIA is the result of a half-year process.
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
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.
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed