On Saturday, February 03, 2018 08:20:02 AM Adrian Bunk wrote: > 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.
My point is: who decides. Raising objections absent actually doing work isn't particularly helpful. I did already mention that we plan to change the removals page to indicate which rm bugs have recent activity so we can give them a pass, so it's safe to stop asking for the FTP team do that. It's in the plan. > 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? Yes. Don't introduce them into Debian. Every package introduced causes work for volunteers. If you don't think it's worth having in stable eventually, then I don't think it belongs in Debian. If you know you aren't going to take care of it, it's an imposition on the rest of the project that's impolite at best. > 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. Could be. I've seen plenty of packages that are really maintained by NMU, but I don't think that's germane. There was a rm bug filed in the last day or two about a package where the web service it connected to no longer worked with the package due to API changes and the maintainer said he was not able to keep up with the package anymore. That kind of package is pointless in the archive without someone to watch over it. Some unmaintained packages are fine as QA maintained and some aren't as I already said. > > 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. So your in favor of shaming DDs to improve their behavior? > > > > 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"? This is a slightly different type of problem. Removals are eminently reversible. > There is also not much time for a removal to become controversial > in a way that you would notice. Somewhere in this thread someone managed to whine about removal of a package that had already missed multiple releases. > 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 their metapackage were in the archive, it would have shown up as problematic. > 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". I agree (and already said), that would be better and anyone who cares is welcome to ask the maintainer why they thought it should be removed and document it. Of course one way to get longer to between when the rm is filed and when the removal is done is long, rambling, 80% pointless d-devel threads like this. I've been spending the time I would be doing FTP team work this week writing d-devel emails instead. Scott K
