On Fri, Feb 02, 2018 at 12:17:14PM -0500, Scott Kitterman wrote: > On Friday, February 02, 2018 06:30:28 PM Adrian Bunk wrote: > > On Wed, Jan 31, 2018 at 11:18:28PM -0500, Scott Kitterman wrote: > > > On Thursday, February 01, 2018 11:56:21 AM Paul Wise wrote: > > > > On Thu, Feb 1, 2018 at 3:14 AM, Andrej Shadura wrote: > > > > > For example > > > > > > > > Here is another example of a low-quality RM bug; removal at request of > > > > the maintainer, with no reason stated. > > > > > > > > https://bugs.debian.org/887554 > > > > > > > > As a result of this, DSA has to resort to stretch or snapshot.d.o for > > > > out-of-band access to our s390x machines. > > > > > > As the FTP team member that processed that removal, I can tell you I think > > > it's perfectly fine. I don't think the FTP team should be in the business > > > of second guessing maintainers that say their packages should be removed. > > I don't think it should be the sole decision of the maintainer to get > > a package removed. > > > > Like in the case at hand: > > Last maintainer upload was in 2014. > > Maintainer does nothing (including no action on a "new upstream release" > > bug from a user in 2014). > > Maintainer files RM bug in 2018. > > > > Why does the maintainer have the sole decision here? > > The package would have been in a better state had it > > been a QA-maintained orphaned package since 2014. > > Sometimes the maintainer is wrong, but someone has to decide. There are > approximately two choices for who decides: > > 1. Maintainer, who knows about the package. > 2. FTP team member, who does not. > > I guess, in theory, there's a third choice of some committee that reviews > these requests before they are referred to the FTP team for action, but I > think it would be a horrible idea.
Noone talks about a committee, this is about a pre-removal grace period where people can raise objections. testing removals have a grace period, which gives me and others a chance to fix issues. Do you have any suggestion better than "ITP immediately followed by orphaning" for packages I consider useful but don't want to maintain myself long-time? Note that as sad as it is, the QA maintainance of orphaned packages is better than the (non)maintainance of a huge part of our packages that officially have a maintainer - keeping my name in the maintainer field would be worse than having the QA team there. > There are packages that do fine as QA maintained and there are others that > really should not be in Debian unless someone is watching over them. I have > asked for packages that I maintained to be removed for that reason. I think > the maintainer is the best one to make this call. A human problem is that it is quick and painless to submit a zero-reason RM request. It is much harder for many people to orphan a package, part of the reason is that this feels like admitting that she/he has not done a proper job. Making RM requests as visible as orphaned packages (e.g. in a weekly debian-devel post) would help here. > > > If it's important, someone who cares enough should re-introduce the > > > package. > > This works nicely, assuming the user who needs the package is a DD and > > notices immediately. > > > > For normal users who are not following unstable the situation > > is less rosy. > > > > And if a normal user would notice immediately, what could he/she do? > > Even an RFP to get a perfectly working package re-added just like it > > was before the removal has close to zero chance of being acted on. > > I agree that it's not a general solution. I was referring to this specific > case. > > I also think it's difficult for people who don't routinely process rm > requests > to appreciate how rare a controversial removal is. It almost never happens > (in the context of the large number of requests that get processed). > Statistically this is virtually a non-problem. If you have a 0.1% probability of being killed by a car every day you cycle to work, would you call that "virtually a non-problem" or "life expectancy reduced to 4 more years"? There is also not much time for a removal to become controversial in a way that you would notice. Only a tiny fraction of our users are using unstable. In this specific case it was DSA, and they were using the package from unstable. That's a rare exception. If users notice that a package important for them is no longer in Debian, they will typically notice when it is no longer in a new stable release. At that point there should be a removal reason better than "maintainer who hadn't maintained the package for years suddenly decided to have it removed". > Scott K 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