Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

/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


On Mon, Aug 07, 2017 at 04:48:54PM +0300, Adrian Bunk wrote:
> 
> Approximate data based on grep'ing Packages[1]:
> - 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-de...@lists.alioth.debian.org
> 
> cu
> Adrian
> 
> [1] grep -Ei '^Maintainer.*(team|maintainer|lists.alioth.debian.org).*'

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Sat, Aug 05, 2017 at 04:29:34PM -0700, Russ Allbery wrote:
>...
> since teams are less likely to only have a single leaf package.

Approximate data based on grep'ing Packages[1]:
- 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-de...@lists.alioth.debian.org

cu
Adrian

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Andreas Tille]

On Sat, Aug 05, 2017 at 04:22:03PM -0400, gregor herrmann wrote:
> > So, if you want to count votes: I am working in teams (mainly Debian
> > Astro), and I would favour keeping it -- 
> 
> 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.)

As a member of Debian Med and Debian Science:  Please keep it
mandatory.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:
> On Fri, Aug 04, 2017 at 02:57:49PM -0700, Russ Allbery wrote:

>> but regardless of that discussion, machine-readable team information is
>> not something we have now.

> Policy says that Uploaders should list all co-maintainers.

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.

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Tobias Frost  writes:
> Am Donnerstag, den 03.08.2017, 11:58 -0700 schrieb Russ Allbery:

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

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

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.

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Sat, 05 Aug 2017 21:20:37 +0200, Ole Streicher wrote:

> > 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.
> So, if you want to count votes: I am working in teams (mainly Debian
> Astro), and I would favour keeping it -- 

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

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Ole Streicher]

gregor herrmann  writes:
> On Sat, 05 Aug 2017 21:39:40 +0300, Adrian Bunk wrote:
>
>> Regarding the first point, most large teams do have have the concept of 
>> package ownership inside the team. 
>
> 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.

So, if you want to count votes: I am working in teams (mainly Debian
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




signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Sat, 05 Aug 2017 21:39:40 +0300, Adrian Bunk wrote:

> Regarding the first point, most large teams do have have the concept of 
> package ownership inside the team. 

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.

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

- 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

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Sat, Aug 05, 2017 at 09:05:46PM +0300, Adrian Bunk wrote:
> > I think using the uploaders: field to guess who's a team member is just a
> > work-around / an estimate, as we have nothing better.
> It is the official place to list co-maintainers.

you keep repeating this but its still broken by design.

> > ;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.
> 
> 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.
 
then it's time to fix this and not hold on to a band-aid solution which causes
grief.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Sat, Aug 05, 2017 at 03:28:57PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > > 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?
> > 
> > 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.
>  
> I think using the uploaders: field to guess who's a team member is just a
> work-around / an estimate, as we have nothing better.

It is the official place to list co-maintainers.

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

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.

> cheers,
>   Holger

cu
Adrian

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > 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?
> 
> 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.
 
I think using the uploaders: field to guess who's a team member is just a
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.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Sat, Aug 05, 2017 at 02:15:16PM +0500, Andrey Rahmatullin wrote:
>...
> Besides, while it doesn't imply you shouldn't make an upload that only
> changes the maintainer (unlike 5.9.5. Adopting a package), I think it's
> the usual practice to not make such upload.

For people who are orphaning their own packages it is relatively common.

Many tools work based on the O: bug and it is also required for 
coordinating who will adopt a package, so that is clearly the
important part. But the BTS forwards emails based on Maintainer.

cu
Adrian

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 02:57:49PM -0700, Russ Allbery wrote:
>...
> but regardless of
> that discussion, machine-readable team information is not something we
> have now.

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.

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

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

-- 

   "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

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Andrey Rahmatullin]

On Sat, Aug 05, 2017 at 11:01:41AM +0200, Bill Allombert wrote:
> > > Nowadays orphaning is done by reuploading the package with the
> > > maintainer set to the QA group rather than using a O: wnpp bug.
> > Huh?
> 
> See:
> https://www.debian.org/doc/manuals/developers-reference/ch05.html#orphaning
Sure.
"You should set the package maintainer to Debian QA Group
 and submit a bug report against the pseudo
package wnpp. The bug report should be titled O: package -- short
description indicating that the package is now orphaned."
Besides, while it doesn't imply you shouldn't make an upload that only
changes the maintainer (unlike 5.9.5. Adopting a package), I think it's
the usual practice to not make such upload.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Bill Allombert]

On Sat, Aug 05, 2017 at 01:55:01AM +0500, Andrey Rahmatullin wrote:
> On Fri, Aug 04, 2017 at 10:46:19PM +0200, Bill Allombert wrote:
> > On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > > An O: bug means that it is confirmed that the package is orphaned, and
> > > > gives permission to everyone to adopt the package immediately.
> > > 
> > > 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 
> > 
> > Nowadays orphaning is done by reuploading the package with the
> > maintainer set to the QA group rather than using a O: wnpp bug.
> Huh?

See:
https://www.debian.org/doc/manuals/developers-reference/ch05.html#orphaning

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 02:10:41PM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
>...
> > 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.
> 
> Because maintaining such a field increases the burden on teams for 
> little to no benefit.

It does not bring benefit to you personally.

It is quite useful elsewhere.

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

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

> On Fri, 04 Aug 2017, Bill Allombert wrote:
> > Nowadays orphaning is done by reuploading the package with the
> > maintainer set to the QA group rather than using a O: wnpp bug.
> 
> Good point.

Bill was giving alternative facts.

cu
Adrian

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 06:20:31PM -0700, Sean Whitton wrote:
> Hello,
> 
> On Fri, Aug 04 2017, Adrian Bunk wrote:
> 
> > Autogenerating Uploaders like GNOME does [1] would be an alternative
> > approach.
> >
> > [1]
> > https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/
> 
> 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?

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am Freitag, den 04.08.2017, 22:46 +0200 schrieb Bill Allombert:
> On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > An O: bug means that it is confirmed that the package is
> > > orphaned, and
> > > gives permission to everyone to adopt the package immediately.
> > 
> > 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 
> 
> Nowadays orphaning is done by reuploading the package with the
> maintainer set to the QA group rather than using a O: wnpp bug.

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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

Hello,

On Fri, Aug 04 2017, Adrian Bunk wrote:

> Autogenerating Uploaders like GNOME does [1] would be an alternative
> approach.
>
> [1]
> https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/

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?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:

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

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.

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> 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.

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.

> There is no Intent-To-Orphan bug.

Not currently, but one can be created.

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

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.

On Fri, 04 Aug 2017, Bill Allombert wrote:
> Nowadays orphaning is done by reuploading the package with the
> maintainer set to the QA group rather than using a O: wnpp bug.

Good point.

-- 
Don Armstrong  https://www.donarmstrong.com

The smallest quantity of bread that can be sliced and toasted has yet
to be experimentally determined. In the quantum limit we must
necessarily encounter fundamental toast particles which the author
will unflinchingly designate here as "croutons".
 -- Cser, Jim. Nanotechnology and the Physical Limits of Toastability.
AIR 1:3, June, 1995.

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Andrey Rahmatullin]

On Fri, Aug 04, 2017 at 10:46:19PM +0200, Bill Allombert wrote:
> On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > > An O: bug means that it is confirmed that the package is orphaned, and
> > > gives permission to everyone to adopt the package immediately.
> > 
> > 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 
> 
> Nowadays orphaning is done by reuploading the package with the
> maintainer set to the QA group rather than using a O: wnpp bug.
Huh?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Bill Allombert]

On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> > An O: bug means that it is confirmed that the package is orphaned, and
> > gives permission to everyone to adopt the package immediately.
> 
> 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 

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

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 11:59:40AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
>...
> > Uploaders is not the only option for doing that, but any change should
> > include provising more reliable information - not less reliable
> > information.
> 
> 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.

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.

> > An O: bug means that it is confirmed that the package is orphaned, and
> > gives permission to everyone to adopt the package immediately.
> 
> So just file an an Intent-To-Orphan bug. [This why I suggested to file
> the bug against the package, and not against wnpp.]
>...

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> And it would not work when the latest maintainer upload was by a team
> member who retired or was declared MIA earlier.

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.

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

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.

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

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 

-- 
Don Armstrong  https://www.donarmstrong.com

The terrorist's job is to terrorize the people, to interfere with
freedom in such a way that disrupts ordinary life and commerce. With
due respect, it is clear that the above referenced governmental
agencies are aiding the terrorists' objective.
 -- Gary Fielder in Gary Fielder vs Janet Napolitano et al.

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Fri, Aug 04, 2017 at 08:25:57AM -0700, Don Armstrong wrote:
> On Fri, 04 Aug 2017, Adrian Bunk wrote:
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> >
> > Think of it as a 3 step process:
> 
> [...]
> 
> > 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  Uploaders list" bug.
> 
> [...]
> 
> > 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.
> 
> MIA could find #3 by looking for all packages where the maintainer is
> the most recent uploader, and no other individual has recently uploaded
> the package. This would work even if Uploaders: lists people who are not
> MIA but have stopped being involved in the team.

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.

> If there was any question, filing an O: bug against the package and
> marking it affects wnpp should notify the team who can close the O: bug
> if the package is still being maintained.

This is a HORRIBLE suggestion.

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

-- 

   "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

Re: Bug#798476: Returning to the requirement that Uploaders: contain humans

[Don Armstrong]

On Fri, 04 Aug 2017, Adrian Bunk wrote:
> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.
>
> Think of it as a 3 step process:

[...]

> 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  Uploaders list" bug.

[...]

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

MIA could find #3 by looking for all packages where the maintainer is
the most recent uploader, and no other individual has recently uploaded
the package. This would work even if Uploaders: lists people who are not
MIA but have stopped being involved in the team.

If there was any question, filing an O: bug against the package and
marking it affects wnpp should notify the team who can close the O: bug
if the package is still being maintained.


-- 
Don Armstrong  https://www.donarmstrong.com

With one simple pill
we cured unhappiness
and art
 -- a softer world #437
http://www.asofterworld.com/index.php?id=437

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:
> On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
>> Adrian Bunk  writes:

>>> Regressing on being able to orphan all packages of a known-MIA/retired
>>> maintainer would be very bad.

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

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

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.

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

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

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
> 
> 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).

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.

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

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.

> > You are assuming that the team has a non-zero number of active members
> > left after a member becomes MIA.
>
> 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.

cu
Adrian

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
> 
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > 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?
> > 
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> > 
> > These "Updating the  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.
> 
> 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.

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.

> Cheers,
> gregor 

cu
Adrian

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Adrian Bunk  writes:

> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.

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

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

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

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.

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

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.

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:11:07PM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> 
> > 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.
> 
> 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.
>...

Regressing on being able to orphan all packages of a known-MIA/retired
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  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.

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

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:

> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > 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?
> 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?bug-rev=on;include=severity:minor;include=tags:pending;maint=pkg-perl-maintain...@lists.alioth.debian.org#_2_5_5
> 
> These "Updating the  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.

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 

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>...
> 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?
>...

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

These "Updating the  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.

> Cheers,
> gregor

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Clint Adams]

On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> 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 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.

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Holger Levsen]

On Thu, Aug 03, 2017 at 06:04:17PM -0400, gregor herrmann wrote:
> On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:
> […]
> Thanks for putting my thoughts (again!) into better words than I ever
> could!

+1
  
> > (I am entirely in favor of giving the MIA team more actual power.)
> (Me too. And, tangential to this discussion but still: maybe also to
> packaging teams, like for salvaging un(der)-maintained packages.)

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.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> > 
> > This would not be "a purely informative change".
> > 
> > Your suggested wording has the potential to create a HUGE amount of 
> > tensions.
> 
> You're right.  After sending my patch I realised that it contains the
> 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?
>...

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

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:

> I wonder whether we are framing this in the right way anyway. There
> are two orthogonal questions in my mind:
>  - is a specific person MIA?
>  - is a package still maintained?

Ack, separating these questions makes sense to me.
 
> 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.

Right, I think that's the situation that the proponents of this
change have in mind.
 
> 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. […] 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.

Here I disagree: This database would just shift the outdated
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?
 
> 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. 

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

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[gregor herrmann]

On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:

> Tobias Frost  writes:
> > 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.
> I'm dubious about this assertion and would like to dig into it a bit more.

[…]

Thanks for putting my thoughts (again!) into better words than I ever
could!
 
> (I am entirely in favor of giving the MIA team more actual power.)

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


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 of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Christian Seiler]

On 08/03/2017 08:58 PM, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
>> 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.
> 
> 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.

I wonder whether we are framing this in the right way anyway. There
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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Tobias Frost  writes:

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

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.

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

We already have a way of contacting the team: the address in the
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.

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

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.

> This is not the point I wanted to make: In my experience if there is NOT
> a name tacked to an task, the likelyhood of noone will feel responsible
> and the task not done is very high.

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.

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

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

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am Donnerstag, den 03.08.2017, 12:44 -0400 schrieb Sean Whitton:
> Hello Tobias,
> 
> Thank you for writing about this bug from the MIA team's perspective,
> which is very relevant to resolving this.
> 
> On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> > 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)
> 
> In most teams, this happens anyway -- I would take this as an
> argument
> against team maintenance more generally.
> 
> > - 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.
> 
> For teams on alioth, would you find the list of team members on the
> alioth project insufficient?

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

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

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. 

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

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 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
> 
> Right, but having some random team members listed in Uploaders:
> doesn't help.

This is not the point I wanted to make: In my experience if there is
NOT a name tacked to an task, the likelyhood of noone will feel
responsible and the task not done is very high. 

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

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.

-- 
tobi 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

Hello Tobias,

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

On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> 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)

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

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

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.

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

Right, but having some random team members listed in Uploaders: doesn't help.

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

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.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> Please be more thoughtful about the consequences of such changes to policy.
> 
> This would not be "a purely informative change".
> 
> Your suggested wording has the potential to create a HUGE amount of tensions.

You're right.  After sending my patch I realised that it contains the
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?

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

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Bill Allombert  writes:

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

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?

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

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.

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 12:30:11PM +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> > On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > > Bill Allombert  writes:
> > > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> > > 
> > > >> 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.
> > > 
> > > > 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.
> > > 
> > > 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.
> > 
> > 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.
> 
> 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.

Re-reading, I might understand what caused the misunderstanding:

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > Bill Allombert  writes:
> > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> > 
> > >> 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.
> > 
> > > 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.
> > 
> > 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.
> 
> 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.

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.

> Cheers,

cu
Adrian

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Adrian Bunk]

On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>...
> 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.
>...
> @@ -1149,6 +1142,12 @@
>
>  
>
> +  
> +This includes packages with a group of people or team in the
> +Maintainer control field.  They should be
> +orphaned if the team is not actively maintaining the package.
> +  
> +
>  
>  
>  
>...

Please be more thoughtful about the consequences of such changes to policy.

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

-- 

   "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

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Bill Allombert]

On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> Bill Allombert  writes:
> > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> 
> >> 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.
> 
> > 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.
> 
> 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.

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,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Tobias Frost]

Am 2. August 2017 23:48:15 MESZ schrieb Sean Whitton :
>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 .
>   
>   
>-If the maintainer of the package is a team of people with a
>shared
>-email address, the Uploaders control field
>must
>-be present and must contain at least one human with their
>personal
>-email address.  See  for the
>syntax
>-of that field.
>-  
>-  
>   An orphaned package is one with no current maintainer.  Orphaned
>   packages should have their Maintainer control
> field set to Debian QA Group
>@@ -1149,6 +1142,12 @@
>   
> 
>   
>+  
>+This includes packages with a group of people or team in the
>+Maintainer control field.  They should be
>+orphaned if the team is not actively maintaining the package.
>+  
>+
> 
> 
> 
>@@ -3448,13 +3447,6 @@ endif
>Maintainer field, and multiple entries must be comma separated.
> 
> 
>-  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.
>-
>-
> The Uploaders field in debian/control can
>   be folded.
> 

Dear all,

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

--
tobi

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Russ Allbery]

Bill Allombert  writes:
> On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:

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

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

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.

-- 
Russ Allbery (r...@debian.org)   

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Bill Allombert]

On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> 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.

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. 

Imagine a large red swirl here. 

Bug#798476: Returning to the requirement that Uploaders: contain humans

[Sean Whitton]

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 .
   
   
-If the maintainer of the package is a team of people with a shared
-email address, the Uploaders control field must
-be present and must contain at least one human with their personal
-email address.  See  for the syntax
-of that field.
-  
-  
 An orphaned package is one with no current maintainer.  Orphaned
 packages should have their Maintainer control
 field set to Debian QA Group
@@ -1149,6 +1142,12 @@
   
 
   
+  
+This includes packages with a group of people or team in the
+Maintainer control field.  They should be
+orphaned if the team is not actively maintaining the package.
+  
+
 
 
 
@@ -3448,13 +3447,6 @@ endif
   Maintainer field, and multiple entries must be comma separated.
 
 
-  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.
-
-
   The Uploaders field in debian/control can
   be folded.
 

-- 
Sean Whitton


signature.asc
Description: PGP signature