Tobias Frost <t...@debian.org> 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) <http://www.eyrie.org/~eagle/>