Re: Bug#798476: Returning to the requirement that Uploaders: contain humans
- Date: Thu, 03 Aug 2017 19:52:10 +0200
- From: Tobias Frost <tobi@xxxxxxxxxx>
- Subject: Re: Bug#798476: Returning to the requirement that Uploaders: contain humans
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
> 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
> 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
> > - 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
> 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
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.