Re: Removing packages perhaps too aggressively?

[Vincent Lefevre]

On 2018-05-29 15:35:24 +0200, Steve Cotton wrote:
> On Tue, May 29, 2018 at 03:03:11PM +0200, Vincent Lefevre wrote:
> > On 2018-05-23 09:46:09 +0800, Paul Wise wrote:
> > > Depends on obsolete WebKit version (fixed in experimental):
> > > 
> > > https://tracker.debian.org/pkg/gnucash
> > > https://tracker.debian.org/news/859896/gnucash-removed-from-testing/
> > > https://bugs.debian.org/790204
> > 
> > This bug was closed 4 months ago.
> 
> Fixed in experimental, but still open on the version in unstable.

But the bug status is closed. In particular, it is no longer shown
by the tracker:

  https://tracker.debian.org/pkg/gnucash

If one clicks on the number in the "RC" line, one just gets #893077,
which is a different bug.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Removing packages perhaps too aggressively?

[Ian Campbell]

On Tue, 2018-05-29 at 15:00 +0200, Vincent Lefevre wrote:
> On 2018-05-22 15:19:50 +0500, Andrey Rahmatullin wrote:
> > On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote:
> > > Just stumbled over some removals:
> > > 
> > > GnuCash removed from testing in August 2017
> > > FreeCad removed from testing in October 2017
> > > 
> > > no sign of any effort to readd them in sight ...
> > 
> > Maybe you are looking in a wrong place.
> > Last gnucash upload was in April.
> 
> But still not in testing:

Nonetheless, "being worked on in unstable/experimental" is nowhere near
the same as "no sign of any effort to readd them in sight", which was
the original claim.

Ian.

Re: Removing packages perhaps too aggressively?

[Steve Cotton]

On Tue, May 29, 2018 at 03:03:11PM +0200, Vincent Lefevre wrote:
> On 2018-05-23 09:46:09 +0800, Paul Wise wrote:
> > Depends on obsolete WebKit version (fixed in experimental):
> > 
> > https://tracker.debian.org/pkg/gnucash
> > https://tracker.debian.org/news/859896/gnucash-removed-from-testing/
> > https://bugs.debian.org/790204
> 
> This bug was closed 4 months ago.

Fixed in experimental, but still open on the version in unstable.

BR,
Steve

Re: Removing packages perhaps too aggressively?

[Vincent Lefevre]

On 2018-05-23 09:46:09 +0800, Paul Wise wrote:
> On Tue, May 22, 2018 at 5:43 PM, Heinz Repp wrote:
> 
> > GnuCash removed from testing in August 2017
> 
> Depends on obsolete WebKit version (fixed in experimental):
> 
> https://tracker.debian.org/pkg/gnucash
> https://tracker.debian.org/news/859896/gnucash-removed-from-testing/
> https://bugs.debian.org/790204

This bug was closed 4 months ago.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Removing packages perhaps too aggressively?

[Vincent Lefevre]

On 2018-05-22 15:19:50 +0500, Andrey Rahmatullin wrote:
> On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote:
> > Just stumbled over some removals:
> > 
> > GnuCash removed from testing in August 2017
> > FreeCad removed from testing in October 2017
> > 
> > no sign of any effort to readd them in sight ...
> Maybe you are looking in a wrong place.
> Last gnucash upload was in April.

But still not in testing:

$ apt-show-versions -a gnucash
gnucash:amd64 1:2.6.19-1 install ok installed
gnucash:amd64 1:2.6.15-1 stable   ftp.fr.debian.org
No stable-updates version
No testing version
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Removing packages perhaps too aggressively?

[Paul Wise]

On Tue, May 22, 2018 at 5:43 PM, Heinz Repp wrote:

> GnuCash removed from testing in August 2017

Depends on obsolete WebKit version (fixed in experimental):

https://tracker.debian.org/pkg/gnucash
https://tracker.debian.org/news/859896/gnucash-removed-from-testing/
https://bugs.debian.org/790204

> FreeCad removed from testing in October 2017

https://tracker.debian.org/pkg/freecad
https://tracker.debian.org/news/881598/freecad-removed-from-testing/
https://bugs.debian.org/784512

> no sign of any effort to readd them in sight ...

This is incorrect:

gnucash 3.0 looks like it will return to testing at some point.

FreeCAD upstream is porting to Qt5 via PySide2:

https://forum.freecadweb.org/viewtopic.php?t=14999

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Removing packages perhaps too aggressively?

[Andrey Rahmatullin]

On Tue, May 22, 2018 at 11:43:31AM +0200, Heinz Repp wrote:
> Just stumbled over some removals:
> 
> GnuCash removed from testing in August 2017
> FreeCad removed from testing in October 2017
> 
> no sign of any effort to readd them in sight ...
Maybe you are looking in a wrong place.
Last gnucash upload was in April.

> The point here is "interested maintainer". I concur it would have been
> easy to bring them back, but it did not happen.
It's easy to make guesses, it's harder to do the actual work. But you can
easily improve your guesses by researching the reasons packages are
removed from testing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Heinz Repp]

Just stumbled over some removals:

GnuCash removed from testing in August 2017
FreeCad removed from testing in October 2017

no sign of any effort to readd them in sight ...

> Debian is meant to be a high-quality operating system, not a collection
> of packages that we keep around in case they come in useful one day.

Those packages above are useful today, they even mark the most advanced
programs in their respective domain

> If a removed package later turns out to be useful or desirable, we have
> plenty of opportunities for an interested maintainer to bring it back,
> and a couple of ways (archive.debian.org, snapshot.debian.org) for a
> user to install it locally.

The point here is "interested maintainer". I concur it would have been
easy to bring them back, but it did not happen.

Depleting the next stable release from highly productive packages seems
not the most sensible approach to me ...

jm2c

Heinz

Re: Removing packages perhaps too aggressively?

[Colin Watson]

On Sun, Feb 04, 2018 at 03:22:13PM +0200, Adrian Bunk wrote:
> On Sat, Feb 03, 2018 at 05:57:26PM +, Colin Watson wrote:
> > I think at the moment the "affects" field in a bug's metadata doesn't
> > cause the maintainer of the affected packages to be copied on mail to
> > the bug, but it could probably reasonably be changed to do so,
> > eliminating the occasional problem where one of a package's maintainers
> > doesn't even realise that the RM bug was filed because they weren't
> > copied on it; again, only if the BTS has that metadata.
> 
> If someone file an RM bug against a package without the consent of the 
> maintainer and without Cc'ing the maintainer when submitting the RM bug,
> then the problem is the person who submitted the RM bug.

I see no reason to be absolutist about this.  It's possible to improve
things in more than one place.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Removing packages perhaps too aggressively?

[Adrian Bunk]

On Sat, Feb 03, 2018 at 02:01:38AM -0500, Scott Kitterman wrote:
> On Saturday, February 03, 2018 08:20:02 AM Adrian Bunk wrote:
>...
> > 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.

I am not talking about introducing packages to Debian, I am talking
about keeping packages that Debian is already providing to users as 
part of the current stable.

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

QA-maintained orphaned packages are *a lot* better maintained than 
NMU-maintained packages that have a "maintainer".

E.g. when I find an easy to fix FTBFS in an orphaned package I can
just make a QA upload right away instead of submitting a bug report.

For any other issue no matter how important or trivial anyone
can also make a QA upload of an orphaned package immediately.

And there are plenty of people reading the bug emails for orphaned 
packages, fixing many reported issues quickly.

For an NMU there has to be a good reason for doing an NMU,
and NMUs should contain only necessary changes.

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

I am just pointing out the problem that we are currently forcing
a maintainer to shame herself/himself when orphaning a package,
while executing zero-reason RM requests quickly and silent.

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

All is solvable for DSA as user.

A normal user doesn't have any chance to have such own metapackages
included in Debian.

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

Chances are this will either result in no answer,
public maintainer shaming, or both.

Like in the case at hand of a zero-reason RM, where it would be 
appropriate to Cc the mailing list of the affected port when
asking the maintainer.

> 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

Re: Removing packages perhaps too aggressively?

[Adrian Bunk]

On Sat, Feb 03, 2018 at 05:57:26PM +, Colin Watson wrote:
> On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote:
> > On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote:
> > > It'd probably make sense to use
> > > https://www.debian.org/Bugs/server-control#affects for this.
> > 
> > How would that help?
> 
> It would at least make it possible to see the pending action that's
> relevant to the package in its BTS view, even if you perhaps only see it
> too late.  Better than nothing.  Many times I've looked at bugs on a
> package that I'm trying to fix in passing, and not noticed that it had a
> removal bug either pending or recently processed.  If the BTS doesn't
> have that metadata, it can't do anything useful with it.

The place that contains all such data (including RM bugs)
for a package is tracker.debian.org.

It also contains many other information that could be relevant for
you in that case, for example it shows when the package is orphaned or 
when there is an open RFS request (that might already fix your problem).

Duplicating tracker in the BTS doesn't sound like a good approach to me.

> I think at the moment the "affects" field in a bug's metadata doesn't
> cause the maintainer of the affected packages to be copied on mail to
> the bug, but it could probably reasonably be changed to do so,
> eliminating the occasional problem where one of a package's maintainers
> doesn't even realise that the RM bug was filed because they weren't
> copied on it; again, only if the BTS has that metadata.

If someone file an RM bug against a package without the consent of the 
maintainer and without Cc'ing the maintainer when submitting the RM bug,
then the problem is the person who submitted the RM bug.

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: Removing packages perhaps too aggressively?

[Wouter Verhelst]

On Sat, Feb 03, 2018 at 11:07:37PM +0100, Adam Borowski wrote:
> On Sat, Feb 03, 2018 at 06:04:42PM +0100, Bernd Zeimetz wrote:
> > and/or open an rc bug
> 
> This sounds like an abuse to me.

Why would it be? You're always allowed to open a bug with "serious"
severity under the "in the opinion of the maintainer, this bug is
problematic enough to warrant RC-ness" definition. I've occasionally
used that to prevent a package of mine from migrating to testing for a
few days, even though there wasn't anything RC-wrong with it as such.

"I don't think this package is as useful anymore as it once was, and we
should get rid of it" sounds like a perfectly valid use of the "serious"
severity to me.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Removing packages perhaps too aggressively?

[Wouter Verhelst]

On Sat, Feb 03, 2018 at 01:25:14AM +0100, Adam Borowski wrote:
> On Sat, Feb 03, 2018 at 12:39:57AM +0100, Wouter Verhelst wrote:
> > On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote:
> > > If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right?
> > 
> > This doesn't compute.
> > 
> > A package can be orphaned and still perfectly functional; a package can
> > be orphaned and RC-buggy. A package cannot, however, be RC-buggy and in
> > a "still works" state. If it's genuinely RC buggy, then by definition it
> > no longer works properly or it's causing problems.
> 
> Copyright problems don't make the package any less useful.

That would be the "causing problems" part. Legally we may not be able to
redistribute it if there are copyright problems.

> > If it's RC buggy because the environment changed and it's now holding
> > back a transition or some such, then it's actively causing problems and
> > should be fixed or removed.
> 
> > If it's RC buggy because it broke and now crashes on startup, then it,
> > well, broke and should be fixed or removed.
> 
> What if it crashes on startup only with systemd?  This currently means the
> majority of users, but doesn't make the package any less useful for me.

That sounds like an "important" bug to me, then. If the bug indeed does
not occur with other init systems, that means the package is not totally
useless.

> > If it's RC buggy because someone had a bad case of "my use case is the
> > most important one in the world and this package should be fixed NOW",
> > then, well, fix the severity (it can be "important" without being RC
> > buggy) and it can remain.
> 
> What if it FTBFSes on s390x?  What if it may cause serious data loss on ext2
> with a split /var setup?

If the package is not likely to be useful on s390x, then ask for the
removal of just the s390x binaries, and downgrade the bug severity. The
other example seems somewhat contrived and unlikely; I doubt such things
are actually a problem in practice.

> > But if a package is RC buggy, then it is *broken*, and should either be
> > removed or fixed. You don't need to take over maintenance of a package,
> > but if you think it's important enough to be retained in the archive,
> > ensuring that it at least doesn't have any RC bugs anymore shouldn't be
> > too much to ask. If you can't do that, then it's perfectly normal for it
> > to be removed.
[limited time]

I understand all that, and it does make sense. But Debian as a whole has
a limited amount of time for everything, and it makes sense to not get
distracted by things that nobody's interested in.

If you care about an orphaned package, and there's an RC bug, it doesn't
hurt you to say "I want to fix this bug so the package can migrate
again, but I don't have the time right now". That should be enough to
ensure people don't file removal bugs on it.

Finally, a removal isn't a way of saying "this package has no purpose
being in Debian". It's just a way of saying "we're sorry we couldn't fix
this package, but it seems unlikely". If you care enough, you can always
take the last version of the package, fix it, and reupload it. There's
no real reason why it wouldn't get through NEW.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Removing packages perhaps too aggressively?

[Adam Borowski]

On Sat, Feb 03, 2018 at 06:04:42PM +0100, Bernd Zeimetz wrote:
> We don't need yet another process, if you want to get rid of a package
> you can open an RFA bug or orphan it

Orphaned packages tend to be maintained better than many of those which have
an alleged maintainer.  The O status shouldn't be taken as a step towards
removal.

Conversely, an active maintainer may have doubts wrt h{is,er} work is
actually of benefit to anyone.

> and/or open an rc bug

This sounds like an abuse to me.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Removing packages perhaps too aggressively?

[Bill Blough]

On Sat, Feb 03, 2018 at 02:01:38AM -0500, Scott Kitterman wrote:
> On Saturday, February 03, 2018 08:20:02 AM Adrian Bunk wrote:
> > 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?

I can't speak as to Adrian's intent, but from my perspective it's not
about shaming, but about awareness.

On more than one occasion, packages that I use have (from my perspective) just
disappeared from unstable without warning.  After some investigation, I
discover that they were removed months ago (with no RFH, RFA, or O bugs
filed).  Had I been aware of an issue prior to the packages being
removed, there's a good chance I would have stepped up and either
offered assistance or taken over maintenance (as circumstances dictated).

I can't realistically follow every single package I use - the amount of
email traffic would be unmanageable.  But I read the WNPP email every single
week and always consider if there's something I can/should act on.

So while adding RMs to WNPP (or something similar) may not be the
perfect solution, I think it would go a long way to solving this issue
for a lot of people.

Just my 2 cents.

Bill

Re: Removing packages perhaps too aggressively?

[Colin Watson]

On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote:
> On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote:
> > It'd probably make sense to use
> > https://www.debian.org/Bugs/server-control#affects for this.
> 
> How would that help?

It would at least make it possible to see the pending action that's
relevant to the package in its BTS view, even if you perhaps only see it
too late.  Better than nothing.  Many times I've looked at bugs on a
package that I'm trying to fix in passing, and not noticed that it had a
removal bug either pending or recently processed.  If the BTS doesn't
have that metadata, it can't do anything useful with it.

I think at the moment the "affects" field in a bug's metadata doesn't
cause the maintainer of the affected packages to be copied on mail to
the bug, but it could probably reasonably be changed to do so,
eliminating the occasional problem where one of a package's maintainers
doesn't even realise that the RM bug was filed because they weren't
copied on it; again, only if the BTS has that metadata.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Removing packages perhaps too aggressively?

[Bernd Zeimetz]

On 02/01/2018 01:53 PM, Ian Jackson wrote:
> Scott Kitterman writes ("Re: Removing packages perhaps too aggressively?"):
>> 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 agree with your 2nd point but if we introduce an ITR process, then
> it would make sense for ftp team members to check that the process
> looked like it had been followed.

We don't need yet another process, if you want to get rid of a package
you can open an RFA bug or orphan it and/or open an rc bug, so it won't
be part of the next stable release unless somebody takes care of it.
And then ask for removal.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

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 

Re: Removing packages perhaps too aggressively?

[Adrian Bunk]

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

Re: Removing packages perhaps too aggressively?

[Adrian Bunk]

On Fri, Feb 02, 2018 at 01:48:52PM -0500, Michael Stone wrote:
>...
> And we've all learned a lot more about secure coding in the past 20 years.
>...

Who is "we all"?

I'd guess the majority of new packages in Debian were not written
by people who have learned anything about secure coding.

It is very rare that a removed package ever had a CVE.

On a more general note, my personal impression is that the quality 
of the average package ITP'ed into Debian today is lower than the 
quality of the average package that was added to Debian 20 years ago.

The typical minimum bar has shifted from "student who has already
studied a few years Computer Science" to "15yo with GitHub account".

Better not think of security (or any other kind of sw quality)
when looking at new software in some of our blends.

And then there are the > 1k Node.js packages that are part of Debian.

> Mike Stone

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: Removing packages perhaps too aggressively?

[Michael Stone]

On Sat, Feb 03, 2018 at 01:25:14AM +0100, Adam Borowski wrote:

I have only a limited amount of tuits.  The package works fine for me, an


Then don't remove it from your machine. Problem solved.

Mike Stone

Re: Removing packages perhaps too aggressively?

[Adam Borowski]

On Sat, Feb 03, 2018 at 12:39:57AM +0100, Wouter Verhelst wrote:
> On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote:
> > If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right?
> 
> This doesn't compute.
> 
> A package can be orphaned and still perfectly functional; a package can
> be orphaned and RC-buggy. A package cannot, however, be RC-buggy and in
> a "still works" state. If it's genuinely RC buggy, then by definition it
> no longer works properly or it's causing problems.

Copyright problems don't make the package any less useful.

> If it's RC buggy because the environment changed and it's now holding
> back a transition or some such, then it's actively causing problems and
> should be fixed or removed.

> If it's RC buggy because it broke and now crashes on startup, then it,
> well, broke and should be fixed or removed.

What if it crashes on startup only with systemd?  This currently means the
majority of users, but doesn't make the package any less useful for me.
 
> If it's RC buggy because someone had a bad case of "my use case is the
> most important one in the world and this package should be fixed NOW",
> then, well, fix the severity (it can be "important" without being RC
> buggy) and it can remain.

What if it FTBFSes on s390x?  What if it may cause serious data loss on ext2
with a split /var setup?

> But if a package is RC buggy, then it is *broken*, and should either be
> removed or fixed. You don't need to take over maintenance of a package,
> but if you think it's important enough to be retained in the archive,
> ensuring that it at least doesn't have any RC bugs anymore shouldn't be
> too much to ask. If you can't do that, then it's perfectly normal for it
> to be removed.

I have only a limited amount of tuits.  The package works fine for me, an
unrelated problem with it -- or perhaps, a library for iCrap it transitively
depends on -- is not an immediate problem that affects me.

As the release freeze nears, I'd probably get off my butt and at least work
around the problem to get the package back in testing, but I'd grumble while
doing so.  I'm also a DD, which most users are not -- their means of getting
a package they need into shape are limited.

I do look at packages that don't affect me (I for one usually look at
orphaned stuff), but I'm not going to fix something written in PHP, Go or
Cobol even if it's a dependency of something I need -- unless perhaps just
before release, at a cost of effort that would be a lot lesser for someone
else who actually knows that language or package.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Removing packages perhaps too aggressively?

[Wouter Verhelst]

On Fri, Feb 02, 2018 at 12:23:51AM +0100, Adam Borowski wrote:
> If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right?

This doesn't compute.

A package can be orphaned and still perfectly functional; a package can
be orphaned and RC-buggy. A package cannot, however, be RC-buggy and in
a "still works" state. If it's genuinely RC buggy, then by definition it
no longer works properly or it's causing problems.

If it's RC buggy because the environment changed and it's now holding
back a transition or some such, then it's actively causing problems and
should be fixed or removed.

If it's RC buggy because it broke and now crashes on startup, then it,
well, broke and should be fixed or removed.

If it's RC buggy because someone had a bad case of "my use case is the
most important one in the world and this package should be fixed NOW",
then, well, fix the severity (it can be "important" without being RC
buggy) and it can remain.

But if a package is RC buggy, then it is *broken*, and should either be
removed or fixed. You don't need to take over maintenance of a package,
but if you think it's important enough to be retained in the archive,
ensuring that it at least doesn't have any RC bugs anymore shouldn't be
too much to ask. If you can't do that, then it's perfectly normal for it
to be removed.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

On February 2, 2018 9:21:48 PM UTC, Don Armstrong  wrote:
>On Wed, 31 Jan 2018, Scott Kitterman wrote:
>> So far, every time this comes up, there's no actual volunteer to
>> invest the time to update the removals page to make this reasonable
>to
>> do in practice.
>
>Would the last-modified time from the BTS be sufficient and/or useful?
>[Or the reported time?]

I think we're going to use last modified.

Scott K

Re: Removing packages perhaps too aggressively?

[Don Armstrong]

On Wed, 31 Jan 2018, Scott Kitterman wrote:
> So far, every time this comes up, there's no actual volunteer to
> invest the time to update the removals page to make this reasonable to
> do in practice.

Would the last-modified time from the BTS be sufficient and/or useful?
[Or the reported time?]

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

If it jams, force it. If it breaks, it needed replacing anyway.
 -- Lowery's Law

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Adam Borowski]

On Fri, Feb 02, 2018 at 08:54:37AM +0100, Christoph Biedl wrote:
> Thomas Goirand wrote...
> 
> > We already have RFA, where maintainers are asking for adoption. I fail
> > to see how a different type of bug will trigger a quicker adoption. An
> > ITR is going to (unfortunately) achieve the exact same thing as an RFA,
> > which in most cases is ... no much.
> 
> I disagree. The messages are ...
> 
> RFA: If somebody wishes to take over, please get in touch.
> O: If you want to take over, it's yours.
> ITR: Somebody take over, otherwise the package will be gone soon.

That would be redundant, merely a yet another stage that's not really
needed.

RFA/O are about whether there's someone willing to do the work, without
a message about the package being useful or not.

ITR (or an usertag) would be a query if the package is useful, with no
statement about whether you're willing to do the work or not.

Ie, there's no "somebody take over", as you may be okay with keeping the
package -- you no longer need it yourself, but can continue maintaining it,
as long as there are actual users who care.

> So for me the anger is mostly about the silence and the (sometimes)
> haste of an RM. I was glad if RMs had to follow a certain procedure
> which boils down to notifying more places and giving a grace period of,
> say, two weeks. Which is what in my understanding an ITR would do. If
> you just don't want to introduce a new name for this augmented RM, be my
> guest.

I wouldn't want to spam the FTP team with a thousand of RMs they're not
supposed to handle yet.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Removing packages perhaps too aggressively?

[Adam Borowski]

On Fri, Feb 02, 2018 at 06:44:36PM +0200, Adrian Bunk wrote:
> Example:
> 
> Subject: RM: hello -- RoM; obsolete
> Control: affects -1 src:hello
> 
> For the few days or hours between the RM bug being filed and the
> package actually being removed, this would show up at
>   https://bugs.debian.org/src:hello
> 
> The chances of someone looking at this specific BTS page during the
> short amount of time between it showing up there and the actual
> removal are close to zero.

> BTW: And then the next problem would be that the ftp team tends
>  to ignore non-maintainer objections in RM bugs and removes
>  the package anyway.

As the FTP team is the single most important one in Debian, and also quite
overworked, I'd refrain from anything that makes their workflow more
tedious.  If they have to read every bug over and over to check if it's good
to be acted on, it'd waste a lot of their time.

Thus, it's good to keep RMs as something that can be acted on immediately.

That's why I proposed to have the burden of that "unripe RM" state carried
by wnpp.  There are other good proposals, like an usertagged bug on the
package itself -- all that matters is a way to query these in bulk, to get a
list you can automatically compare to what you have on your system[s], etc.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Removing packages perhaps too aggressively?

[Michael Stone]

On Fri, Feb 02, 2018 at 06:39:32PM +0200, Adrian Bunk wrote:

Typically a removed package is not in a much worse shape when it got
removed compared to when it was first shipped in a stable release.[1]

At that point the actual question is why we did allow the package
to be ITP'ed into Debian at all.


Well, in a lot of cases better alternatives have come along, or it 
wasn't originally clear which alternatives would live and which would 
wither away. And we've all learned a lot more about secure coding in the 
past 20 years.


I do wish it was easier for users to find out why a package was removed, 
and that it was more common for the removal log to list alternatives.


Mike Stone

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

On Friday, February 02, 2018 06:44:36 PM Adrian Bunk wrote:
> On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote:
> > On Fri, Feb 02, 2018 at 12:00:58AM +0100, Wouter Verhelst wrote:
> > > Currently, RM bugs are filed against ftp.debian.org.
> > > 
> > > It might make sense to have them filed against ftp.debian.org *and* the
> > > package to be removed, instead. That way, people who care about the
> > > package are more likely to see that it is about to be removed, and can
> > > take corrective action if they don't want to have that happen?
> > 
> > It'd probably make sense to use
> > https://www.debian.org/Bugs/server-control#affects for this.
> 
> How would that help?
> 
> Example:
> 
> Subject: RM: hello -- RoM; obsolete
> Control: affects -1 src:hello
> 
> For the few days or hours between the RM bug being filed and the
> package actually being removed, this would show up at
>   https://bugs.debian.org/src:hello
> 
> The chances of someone looking at this specific BTS page during the
> short amount of time between it showing up there and the actual
> removal are close to zero.

I think we are going to modify the pending removals page to indicate which 
requests are recent or have recent activity on the bug.  I think that will put 
at least a little cushion in.  As the FTP team member processing most of the 
rm bugs recently, what I mostly want is to have to touch the bug once.  Once 
there's a visual indication it should be left to ripen for now, I'll be glad 
to do that.
 
> BTW: And then the next problem would be that the ftp team tends
>  to ignore non-maintainer objections in RM bugs and removes
>  the package anyway.

If in the maintainer's opinion it's better to remove the package than to leave 
it in the archive unmaintained, I think this is generally appropriate (see my 
previous mentions about not thinking FTP team should second guess 
maintainers).  The one exception is if a non-maintainer objects to a removal 
and the objection includes them saying they will take over maintenance.  Of 
course that almost never happens.

Scott K

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

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.

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.

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

Scott K

Re: Removing packages perhaps too aggressively?

[Adrian Bunk]

On Fri, Feb 02, 2018 at 02:29:49AM +, Colin Watson wrote:
> On Fri, Feb 02, 2018 at 12:00:58AM +0100, Wouter Verhelst wrote:
> > Currently, RM bugs are filed against ftp.debian.org.
> > 
> > It might make sense to have them filed against ftp.debian.org *and* the
> > package to be removed, instead. That way, people who care about the
> > package are more likely to see that it is about to be removed, and can
> > take corrective action if they don't want to have that happen?
> 
> It'd probably make sense to use
> https://www.debian.org/Bugs/server-control#affects for this.

How would that help?

Example:

Subject: RM: hello -- RoM; obsolete
Control: affects -1 src:hello

For the few days or hours between the RM bug being filed and the
package actually being removed, this would show up at
  https://bugs.debian.org/src:hello

The chances of someone looking at this specific BTS page during the
short amount of time between it showing up there and the actual
removal are close to zero.

cu
Adrian

BTW: And then the next problem would be that the ftp team tends
 to ignore non-maintainer objections in RM bugs and removes
 the package anyway.

-- 

   "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: Removing packages perhaps too aggressively?

[Adrian Bunk]

On Wed, Jan 31, 2018 at 10:40:19PM +0100, Michael Biebl wrote:
> 
> I think we should remove cruft more aggressively then we currently do.

I think it would be bad to move even more to a revolving door 
situation where we are adding packages to a stable release only
to remove them in the next stable release.

For users it is a problem when packages they use disappear in a new
stable release.

> We are much too lenient with what we ship in our stable releases.

But RM is the wrong side to attack this problem.

Typically a removed package is not in a much worse shape when it got 
removed compared to when it was first shipped in a stable release.[1]

At that point the actual question is why we did allow the package
to be ITP'ed into Debian at all.

cu
Adrian

[1] from a user perspective

-- 

   "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: Removing packages perhaps too aggressively?

[Adrian Bunk]

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.

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

> 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

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Gert Wollny]

Am Freitag, den 02.02.2018, 09:32 +0100 schrieb Thomas Goirand:
[...]

> O: Package is unmaintained, hurry or the package is in danger to be
> removed.

I risk to differ, if this were so, we wouldn't have +700 packages that
have the QA team as maintainer, and quite a few have a five or even
six-figure popcorn. 

Orphaning a package does not imply an intent to remove the package and
apparently quite a number of packages don't need much maintainance
apart from a binary rebuild once in a while.

> If you introduce ITR, then RFA will become meaningless. Let's not do
> that and improve the RM bug procedure as you suggest below.

Anyway, I also think that an extra ITR is not needed, but the RMs
should be more visible if they don't just relate to cruft. For instance
for packages that are not RC buggy or have other important reasons to
be removed and are not yet orphaned it would be nice if the package
would be orphaned before removal is requested to give others the
opportunity to take over, maybe in this case with a tag "removal
pending if not adopted within X weeks". 

[...]

My 2 cents, 
Gert

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Thomas Goirand]

On 02/02/2018 08:54 AM, Christoph Biedl wrote:
> Thomas Goirand wrote...
> 
>> We already have RFA, where maintainers are asking for adoption. I fail
>> to see how a different type of bug will trigger a quicker adoption. An
>> ITR is going to (unfortunately) achieve the exact same thing as an RFA,
>> which in most cases is ... no much.
> 
> I disagree. The messages are ...
> 
> RFA: If somebody wishes to take over, please get in touch.
> O: If you want to take over, it's yours.
> ITR: Somebody take over, otherwise the package will be gone soon.

My reading is a way more radical. To me:

RFA: Please adopt it, I lost interest and the package is bit-rotting.
I'm doing the bare minimal work.

O: Package is unmaintained, hurry or the package is in danger to be removed.

ITR: No meaning, see "O:" that already covers it...

If you introduce ITR, then RFA will become meaningless. Let's not do
that and improve the RM bug procedure as you suggest below.

> Assuming the ITR gets a broader audience than the RM, like d-d and the
> packages's qa address: It's a sign of high urgency

Orphaning is already a sign of urgency, since it means there's no
maintainer anymore. We don't need anything else.

> While RFA/O mostly show
> up in the weekly WNPP report, and while I read this, packages of my
> interest usually trigger a feeling of: While I could take some of those,
> looking at my time budget, I should rather not. And hopefully somebody
> else will jump in.

Having ITR wont change the fact you have other priorities (ie: to be
read as "no time for it", as this is the same thing).

> I was glad if RMs had to follow a certain procedure
> which boils down to notifying more places and giving a grace period of,
> say, two weeks.

There's many reasons why a RM can take place, sometimes it's not at all
about stopping maintenance. For example, I was maintaining
python-pyldap, which was a fork of python-ldap, but it got merged back,
so pyldap had no meaning anymore as soon as ldap was in version >= 3. In
such case, RM as quick as possible is the way to go.

However, in the case we're discussing (ie: lost of interest by the
current maintainer), I agree we could add a mandatory delay, probably by
adding some kind of field in reportbug.

> If you just don't want to introduce a new name for this augmented RM, be my
> guest.

Definitively, IMO it should be kept within the boundaries of the RM bug.
That's the thing we could improve to avoid RM-ing packages too fast, and
advertise when a package is being removed.

Cheers,

Thomas Goirand (zigo)

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Christoph Biedl]

Thomas Goirand wrote...

> We already have RFA, where maintainers are asking for adoption. I fail
> to see how a different type of bug will trigger a quicker adoption. An
> ITR is going to (unfortunately) achieve the exact same thing as an RFA,
> which in most cases is ... no much.

I disagree. The messages are ...

RFA: If somebody wishes to take over, please get in touch.
O: If you want to take over, it's yours.
ITR: Somebody take over, otherwise the package will be gone soon.

> See this one (of mine) as an example:
> https://bugs.debian.org/880416
>
> it's just bit-rotting. I've told a few people vaguely interested in the
> package that I will RoM it soon. No action so far. I'm quite sure the
> only path is to actually remove the package. Someone may then pick it up
> because of the removal, but IMO that process can only be speed up by
> actually removing the package faster, not slower. Adding an ITR wont help.

Changing this to ITR would tell "This is your last chance".

Assuming the ITR gets a broader audience than the RM, like d-d and the
packages's qa address: It's a sign of high urgency, and anybody who is
even remotely interested should stand up *now*. While RFA/O mostly show
up in the weekly WNPP report, and while I read this, packages of my
interest usually trigger a feeling of: While I could take some of those,
looking at my time budget, I should rather not. And hopefully somebody
else will jump in.

Actually removing the package in the silent way it happens right now
carries a high risk the next release will ship without it, as users of
stable will not notice until the next dist-upgrade.

So for me the anger is mostly about the silence and the (sometimes)
haste of an RM. I was glad if RMs had to follow a certain procedure
which boils down to notifying more places and giving a grace period of,
say, two weeks. Which is what in my understanding an ITR would do. If
you just don't want to introduce a new name for this augmented RM, be my
guest.

Christoph


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Colin Watson]

On Fri, Feb 02, 2018 at 12:00:58AM +0100, Wouter Verhelst wrote:
> Currently, RM bugs are filed against ftp.debian.org.
> 
> It might make sense to have them filed against ftp.debian.org *and* the
> package to be removed, instead. That way, people who care about the
> package are more likely to see that it is about to be removed, and can
> take corrective action if they don't want to have that happen?

It'd probably make sense to use
https://www.debian.org/Bugs/server-control#affects for this.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Removing packages perhaps too aggressively?

[Paul Wise]

On Fri, Feb 2, 2018 at 2:26 AM, peter green wrote:

> On that note one thing that doesn't seem to be easy/well documented is how
> to go about finding the bugs that affected a package at the time of it's
> removal. If I go to the bugs page for the package and select "archived and
> unarchived" I see a bunch of resolved bugs but other than opening them up
> individually I don't see a good way to tell the difference between ones that
> were actually fixed and ones that were open at the time of the removal.

The ones that need to be reopened are closed with a version ending in +rm.
This is documented in the developers reference section I mentioned.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Removing packages perhaps too aggressively?

[Adam Borowski]

On Thu, Feb 01, 2018 at 09:24:05PM +0100, Abou Al Montacir wrote:
> On Thu, 2018-02-01 at 12:23 +0200, Lars Wirzenius wrote:
> > I disagree, I'm afraid. As a user, the speed in which we do removals
> > from testing or unstable shouldn't matter to you. What matters is that
> > the software you need is in the stable release. For that, you need to
> > know that something is not going to be in the next stable release,
> > with enough time for you to request it to be included if it matters to
> > you.
> > 
> > (I think we need ways of helping users to do that, but it's orthogonal
> > to how fast we remove things from testing.)
> I do agree with the statements above. However I think that by decreasing the
> speed of removal, packages get more chance to be fixed, but I'll not bet on
> this.

I'd say we want to _increase_ the speed of removals.  Less cruft is good: if
a package is in hopeless state, shipping it is a disservice to the users.

However, a package being orphaned doesn't make it a lot less functional: an
user who's a DD or contributor, will fix it the moment it gets problematic
for his particular use case -- and conversely, no one gives flying carnal
knowledge about "a file in the testsuite has bad license" or "might cause
data loss on unclean shutdown on ext2 in an unusual configuration".
If it's orphaned+RC-buggy but it Works For Me™, it's good to stay, right?

Thus, mere orphaning doesn't seem to be a good marker, especially for non-DD
users.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

On February 1, 2018 8:24:05 PM UTC, Abou Al Montacir  
wrote:
>On Thu, 2018-02-01 at 12:23 +0200, Lars Wirzenius wrote:
>> On Thu, 2018-02-01 at 11:10 +0100, Abou Al Montacir wrote:
>> > In general I agree with this as a DD, but when I wear my user hat I
>don't.
>> 
>> I disagree, I'm afraid. As a user, the speed in which we do removals
>> from testing or unstable shouldn't matter to you. What matters is
>that
>> the software you need is in the stable release. For that, you need to
>> know that something is not going to be in the next stable release,
>> with enough time for you to request it to be included if it matters
>to
>> you.
>> 
>> (I think we need ways of helping users to do that, but it's
>orthogonal
>> to how fast we remove things from testing.)
>I do agree with the statements above. However I think that by
>decreasing the
>speed of removal, packages get more chance to be fixed, but I'll not
>bet on
>this.

In my experience, it's very rare that it helps.  Here's a current example that 
I'm about to go ahead and remove after an extended period of no response:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870987

Scott K

Re: Removing packages perhaps too aggressively?

[Wouter Verhelst]

On Thu, Feb 01, 2018 at 09:45:55AM +0100, Andrej Shadura wrote:
> On 01/02/18 09:40, Ansgar Burchardt wrote:
> > Why would filing a third RC bug (the "proposed-RM") and waiting one
> > month more change anything?  Why would someone turn up to fix them now?
> 
> Why not? I *was* already doing just that, but with an RM bug filed
> elsewhere, I was unable to know it's about to be removed. I would have
> reacted and closed it before the package's got removed.

Currently, RM bugs are filed against ftp.debian.org.

It might make sense to have them filed against ftp.debian.org *and* the
package to be removed, instead. That way, people who care about the
package are more likely to see that it is about to be removed, and can
take corrective action if they don't want to have that happen?

I don't think a package that is orphaned, has long-standing RC bugs
against it, and hasn't been in a released version of Debian for a long
time requires much consideration before being removed, however. Those
are cruft, and we should get rid of them...

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Thomas Goirand]

On 02/01/2018 01:12 AM, Adam Borowski wrote:
> One issue: on a small screen, crap font and no glasses, "ITR" looks similar
> to "ITP", an alternate acronym could be better.
> 
> Meow.

Hi,

I very much appreciate your intent here, which is for sure, to make
Debian nicer and more welcoming. However, my guts are telling me this is
counter-productive. Let me share.

We already have RFA, where maintainers are asking for adoption. I fail
to see how a different type of bug will trigger a quicker adoption. An
ITR is going to (unfortunately) achieve the exact same thing as an RFA,
which in most cases is ... no much.

See this one (of mine) as an example:
https://bugs.debian.org/880416

it's just bit-rotting. I've told a few people vaguely interested in the
package that I will RoM it soon. No action so far. I'm quite sure the
only path is to actually remove the package. Someone may then pick it up
because of the removal, but IMO that process can only be speed up by
actually removing the package faster, not slower. Adding an ITR wont help.

Actually, let me RoM the package right away now... done! See #889099.
Let's see if someone complains now. If this happens (which I expect), it
will prove my point: the issue we're having isn't the lack of ITR, but
the fact that nobody acts on RFAs. If it doesn't happen, then it means I
could (and should) have file the RoM bug earlier. In both cases,
removing the package earlier from the archive was the best thing to do.

Cheers,

Thomas Goirand (zigo)

Re: Removing packages perhaps too aggressively?

[Mattia Rizzolo]

On Thu, Feb 01, 2018 at 09:42:13PM +0100, Ansgar Burchardt wrote:
> peter green writes:
> >> If you do reintroduce it, please note the extra steps (reopening bugs
> >> in particular)
> > On that note one thing that doesn't seem to be easy/well documented is
> > how to go about finding the bugs that affected a package at the time
> > of it's removal. If I go to the bugs page for the package and select
> > "archived and unarchived" I see a bunch of resolved bugs but other
> > than opening them up individually I don't see a good way to tell the
> > difference between ones that were actually fixed and ones that were
> > open at the time of the removal.
> 
> dak logs which bug reports is closed when a source package was removed:
> see the "Also-Bugs" field in https://ftp-master.debian.org/removals.822
> (for the current year; removals-.822 or removals-full.822 are also
> available).

Also, bugs cloed by dak rm are closed with a version of 1.2.3-1+rm (with
1.2.3-1 the version of the source removed, I believe the highest when
multiple versions of the same source were removed at the same time).  So
you query for bugs closed with a version containing '+rm'.
This is documented in devref.


DAK removal logs are usually more parsable, of course.  :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Ansgar Burchardt]

peter green writes:
>> If you do reintroduce it, please note the extra steps (reopening bugs
>> in particular)
> On that note one thing that doesn't seem to be easy/well documented is
> how to go about finding the bugs that affected a package at the time
> of it's removal. If I go to the bugs page for the package and select
> "archived and unarchived" I see a bunch of resolved bugs but other
> than opening them up individually I don't see a good way to tell the
> difference between ones that were actually fixed and ones that were
> open at the time of the removal.

dak logs which bug reports is closed when a source package was removed:
see the "Also-Bugs" field in https://ftp-master.debian.org/removals.822
(for the current year; removals-.822 or removals-full.822 are also
available).

Note that sometimes[1] the bugs are not closed by dak and end up getting
closed in a different way.

Ansgar

  [1] IIRC when removing >1 source package at the same time

Re: Removing packages perhaps too aggressively?

[Abou Al Montacir]

On Thu, 2018-02-01 at 12:23 +0200, Lars Wirzenius wrote:
> On Thu, 2018-02-01 at 11:10 +0100, Abou Al Montacir wrote:
> > In general I agree with this as a DD, but when I wear my user hat I don't.
> 
> I disagree, I'm afraid. As a user, the speed in which we do removals
> from testing or unstable shouldn't matter to you. What matters is that
> the software you need is in the stable release. For that, you need to
> know that something is not going to be in the next stable release,
> with enough time for you to request it to be included if it matters to
> you.
> 
> (I think we need ways of helping users to do that, but it's orthogonal
> to how fast we remove things from testing.)
I do agree with the statements above. However I think that by decreasing the
speed of removal, packages get more chance to be fixed, but I'll not bet on
this.
-- 
Cheers,
Abou Al Montacir

signature.asc
Description: This is a digitally signed message part

Re: Removing packages perhaps too aggressively?

[peter green]

If you do reintroduce it, please note the extra steps (reopening bugs
in particular)

On that note one thing that doesn't seem to be easy/well documented is how to go about 
finding the bugs that affected a package at the time of it's removal. If I go to the bugs 
page for the package and select "archived and unarchived" I see a bunch of 
resolved bugs but other than opening them up individually I don't see a good way to tell 
the difference between ones that were actually fixed and ones that were open at the time 
of the removal.

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Philipp Kern]

On 2018-02-01 15:03, Scott Kitterman wrote:

I agree that the FTP team should not second guess the maintainer's
removal request.  However, with or without a new ITR process, I think
it
would be justified (and good practice) for the FTP team to start
requiring the maintainer to record in the bug the reasoning behind the
removal.  This appears to be common, but not universal, practice when
filing ROMs, but making it mandatory and enforced by the FTP team does
not seem out of line.  This has nothing to do with second guessing; it
is about openness to the rest of the Debian community (esp users who
are
wondering why their favorite niche package didn't make it into the 
next

release).  And as stated elsewhere in this thread, it will help a
prospective new maintainer know whether reintroducing the package will
be worth the effort.


While I agree that would be best, I don't think it's the primary
purpose of an rm bug.  It doesn't take an FTP team member to ping the
maintainer to ask why, cc the bug.

If this concerns people, they can ask for more information.


Except that there is no requirement anymore to actually answer the 
question. The bug has been acted upon and closed.


Kind regards
Philipp Kern

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Marvin Renich]

* Scott Kitterman  [180201 09:04]:
> On February 1, 2018 1:47:17 PM UTC, Marvin Renich  wrote:
> >I agree that the FTP team should not second guess the maintainer's
> >removal request.  However, with or without a new ITR process, I think
> >it would be justified (and good practice) for the FTP team to start
> >requiring the maintainer to record in the bug the reasoning behind
> >the removal.
> 
> While I agree that would be best, I don't think it's the primary
> purpose of an rm bug.  It doesn't take an FTP team member to ping the
> maintainer to ask why, cc the bug.

I think the RM bug should include both what is being requested (removal)
and why.  I think the two are closely related enough that they should
share the title of "primary purpose".

However, I know that you and the rest of the FTP team do a tremendous
amount of work (thank you very much!), so I will concede that this is
one item that should be the responsibility of the bug filer and doesn't
need to be on your plate.

> If this concerns people, they can ask for more information.

True, but that happens after the fact, and sometimes time has a way of
helping information to get lost.

...Marvin

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Scott Kitterman]

On February 1, 2018 1:47:17 PM UTC, Marvin Renich  wrote:
>* Mattia Rizzolo  [180201 03:26]:
>> I seriously doubt ITRs or somesuch would help, you wouldn't notice
>them
>> anyway.
>> If you can parse a list of ITRs you can equally easy parse a list of
>> packages with open RC bugs with next to the same effect.
>
>I disagree.  As a user, if I see RC bugs on a package, I have no idea
>what work is or isn't being done by the maintainer or others to address
>those bugs.  However, if the maintainer (or someone close to the
>package) files an ITR, I now know that this is my last chance to speak
>up.  With something similar to apt-listchanges that notifies me when I
>do aptitude update that a package I have installed will be removed
>soon,
>I have an opportunity to react.  Something similar for RC bugs would
>not
>serve the same purpose (though it might be very useful for someone
>looking for ways to contribute to Debian:  "There are RC bugs on these
>packages that you use; would you like to help out?").
>
>> RoQA packages without RC bugs is very rare (and I don't like them
>> myself), and ROM shouldn't be second guessed anyway (as an ftpteam
>> member stated).
>
>I agree that the FTP team should not second guess the maintainer's
>removal request.  However, with or without a new ITR process, I think
>it
>would be justified (and good practice) for the FTP team to start
>requiring the maintainer to record in the bug the reasoning behind the
>removal.  This appears to be common, but not universal, practice when
>filing ROMs, but making it mandatory and enforced by the FTP team does
>not seem out of line.  This has nothing to do with second guessing; it
>is about openness to the rest of the Debian community (esp users who
>are
>wondering why their favorite niche package didn't make it into the next
>release).  And as stated elsewhere in this thread, it will help a
>prospective new maintainer know whether reintroducing the package will
>be worth the effort.

While I agree that would be best, I don't think it's the primary purpose of an 
rm bug.  It doesn't take an FTP team member to ping the maintainer to ask why, 
cc the bug.

If this concerns people, they can ask for more information.

Scott K

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Marvin Renich]

* Mattia Rizzolo  [180201 03:26]:
> I seriously doubt ITRs or somesuch would help, you wouldn't notice them
> anyway.
> If you can parse a list of ITRs you can equally easy parse a list of
> packages with open RC bugs with next to the same effect.

I disagree.  As a user, if I see RC bugs on a package, I have no idea
what work is or isn't being done by the maintainer or others to address
those bugs.  However, if the maintainer (or someone close to the
package) files an ITR, I now know that this is my last chance to speak
up.  With something similar to apt-listchanges that notifies me when I
do aptitude update that a package I have installed will be removed soon,
I have an opportunity to react.  Something similar for RC bugs would not
serve the same purpose (though it might be very useful for someone
looking for ways to contribute to Debian:  "There are RC bugs on these
packages that you use; would you like to help out?").

> RoQA packages without RC bugs is very rare (and I don't like them
> myself), and ROM shouldn't be second guessed anyway (as an ftpteam
> member stated).

I agree that the FTP team should not second guess the maintainer's
removal request.  However, with or without a new ITR process, I think it
would be justified (and good practice) for the FTP team to start
requiring the maintainer to record in the bug the reasoning behind the
removal.  This appears to be common, but not universal, practice when
filing ROMs, but making it mandatory and enforced by the FTP team does
not seem out of line.  This has nothing to do with second guessing; it
is about openness to the rest of the Debian community (esp users who are
wondering why their favorite niche package didn't make it into the next
release).  And as stated elsewhere in this thread, it will help a
prospective new maintainer know whether reintroducing the package will
be worth the effort.

...Marvin

Re: Removing packages perhaps too aggressively?

[Steve Cotton]

On Thu, Feb 01, 2018 at 11:10:43AM +0100, Andrej Shadura wrote:
> > On 01/02/18 09:45, Andrej Shadura wrote:
> >> On 01/02/18 09:40, Ansgar Burchardt wrote:
> >>> So there was plenty of time to fix them.
> >>>
> >>> Why would filing a third RC bug (the "proposed-RM") and waiting one
> >>> month more change anything?  Why would someone turn up to fix them now?
> >>
> >> Why not? I *was* already doing just that, but with an RM bug filed
> >> elsewhere, I was unable to know it's about to be removed. I would have
> >> reacted and closed it before the package's got removed.

But #871004 wasn't filed elsewhere - it spent a month as a non-RC bug
against Hyde itself.

> I hope you're not going to suggest I subscribe to bug reports for each
> and every package I value so that I don't miss a potential removal notice?

The rc-alert tool in devscripts fits in this gap, it gives a list of
all open RC bugs against locally-installed packages, and the output
can be diffed with a VCS to see which bugs are newly added to the RC
list.

It wouldn't have spotted #871004, but having a policy of filing
"should this be removed?" bugs as RC would solve that. IMHO, it was
correct that the mass-bug-filing including #871004 wasn't RC, because
it would just lengthen the list of RC bugs against packages that
already have an RC bug.

Steve

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

On February 1, 2018 12:53:40 PM UTC, Ian Jackson 
<ijack...@chiark.greenend.org.uk> wrote:
>Scott Kitterman writes ("Re: Removing packages perhaps too
>aggressively?"):
>> 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 agree with your 2nd point but if we introduce an ITR process, then
>it would make sense for ftp team members to check that the process
>looked like it had been followed.

I don't think such a process should be mandatory.  Only a very small percentage 
of rm requests are even potentially problematic.

Let's not create more bureaucratic overhead that will create more work for 
everyone to 'solve' a problem that is extremely rare.

Scott K

Re: Removing packages perhaps too aggressively?

[Ian Jackson]

Scott Kitterman writes ("Re: Removing packages perhaps too aggressively?"):
> 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 agree with your 2nd point but if we introduce an ITR process, then
it would make sense for ftp team members to check that the process
looked like it had been followed.

Ian.


-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Removing packages perhaps too aggressively?

[Paul Wise]

On Thu, Feb 1, 2018 at 5:18 PM, Philipp Kern wrote:

> Oh wow, I didn't realize x3270 got removed. :(
...
> I agree that you shouldn't second-guess, but I think you can at least
> enforce some comment to be present. As someone who now ponders to
> re-introduce the package I have zero context as well as to why the
> package got removed and if it's sensible to re-introduce it in the first
> place.

I was told that there are several reasons for the removal, but wasn't
told what they were.

If you do reintroduce it, please note the extra steps (reopening bugs
in particular) and that it belongs in main instead of non-free:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs
https://bugs.debian.org/848103

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Removing packages perhaps too aggressively?

[Lars Wirzenius]

On Thu, 2018-02-01 at 11:10 +0100, Abou Al Montacir wrote:
> In general I agree with this as a DD, but when I wear my user hat I don't.

I disagree, I'm afraid. As a user, the speed in which we do removals
from testing or unstable shouldn't matter to you. What matters is that
the software you need is in the stable release. For that, you need to
know that something is not going to be in the next stable release,
with enough time for you to request it to be included if it matters to
you.

(I think we need ways of helping users to do that, but it's orthogonal
to how fast we remove things from testing.)


signature.asc
Description: This is a digitally signed message part

Re: Removing packages perhaps too aggressively?

[Abou Al Montacir]

On Wed, 2018-01-31 at 23:00 +, Scott Kitterman wrote:
> On January 31, 2018 10:34:28 PM UTC, Michael Biebl 
> wrote:
> > Am 31.01.2018 um 22:49 schrieb Don Armstrong:
> > > On Wed, 31 Jan 2018, Abou Al Montacir wrote:
> > > > Me too likes to extend the removal notice for few weeks/months.
> > > > Especially removal from testing when outside freeze periods.
> > > 
> > > Packages removed from testing outside of the freeze can be easily
> > > re-added to testing once the underlying RC bugs are fixed. So RMs
> > 
> > should
> > > continue to remove early, and remove often. [When this has happened
> > 
> > with
> > > my packages (see lilypond), it's resulted in more people helping with
> > > the maintenance of them, and brought some issues to a wider
> > 
> > audience.]
> > 
> > I agree. Removals from testing should have no artifical delay. Removals
> > from the archive (i.e. unstable), a two or four week courtesy delay
> > seems ok to me, giving the person listed in Maintainers a chance to
> > reply, seems ok.
> 
> So far, every time this comes up, there's no actual volunteer to invest the
> time to update the removals page to make this reasonable to do in practice.
> 
> I think some normal delay is reasonable, but it needs to be integrated into
> the pending removals page so the FTP team member processing removals gets an
> indication the request is new.
In general I agree with this as a DD, but when I wear my user hat I don't.It
happened multiple times that I need to install a package that is not widely used
(last one I remember was spyder, a Python editor) and it was not in stable,
because of FTBFS caused by other packages update! I was obliged to take it from
sid and "update" some libs from "unstable" to make my "stable" system install
it. This is not user friendly.
Of course here I'm not discussing the pertinence of FTBFS bugs, but saying that
sometimes some packages get removed as collateral damage of igration of othe
ones especially if the package maintainer does not react because busy.
I think this kind of case need to be discussed and the situation improved, but I
don't have a strong mind about what to do with it.
-- 
Cheers,
Abou Al Montacir

signature.asc
Description: This is a digitally signed message part

Re: Removing packages perhaps too aggressively?

[Emilio Pozuelo Monfort]

On 01/02/18 09:45, Andrej Shadura wrote:
> On 01/02/18 09:40, Ansgar Burchardt wrote:
>> Andrej Shadura writes:
>>> On 31/01/18 21:01, Jeremy Bicha wrote:
> Here you go, there's #871004 for you. Missed jessie, stretch,
> not in testing, no uploads since the beginning of 2017.

 I don't think you'll get much sympathy for a package being removed
 from unstable when it hasn't shipped with a Debian release since
 Wheezy, and has continuously been out of Testing for 3.5 years.
>>>
>>> True, it hasn't. But if you look a little bit closer, you'll see both RC
>>> bugs it had were quite trivial to fix: two sourceless files (would be
>>> fixed by linking them to the packaged versions instead), and an failed
>>> attempt to download a build-dep (actually, fixed by an NMU while fixing
>>> another bug, just never marked as done).
>>
>> So there was plenty of time to fix them.
>>
>> Why would filing a third RC bug (the "proposed-RM") and waiting one
>> month more change anything?  Why would someone turn up to fix them now?
> 
> Why not? I *was* already doing just that, but with an RM bug filed
> elsewhere, I was unable to know it's about to be removed. I would have
> reacted and closed it before the package's got removed.

Doesn't the PTS^Wtracker service already do that? I.e. notify when an RM bug is
opened. At least it warns on the web interface, and I think I have seen email
notifications about it too. So you only need to subscribe to those packages that
interest you.

Cheers,
Emilio

Re: Removing packages perhaps too aggressively?

[Philipp Kern]

On 01.02.2018 05:18, 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.
> 
> If it's important, someone who cares enough should re-introduce the package.

Oh wow, I didn't realize x3270 got removed. :(

As a user I'd be deeply disappointed by that removal bug because it has
zero context. I do feel like there should be at least some. It's fine to
say "RoM, dead upstream". But to provide literally no reason is not.

I agree that you shouldn't second-guess, but I think you can at least
enforce some comment to be present. As someone who now ponders to
re-introduce the package I have zero context as well as to why the
package got removed and if it's sensible to re-introduce it in the first
place.

(Note that nothing here is intended to assign some kind of personal blame.)

Kind regards
Philipp Kern

Re: Removing packages perhaps too aggressively?

[Ansgar Burchardt]

Andrej Shadura writes:
> On 01/02/18 09:40, Ansgar Burchardt wrote:
>> Andrej Shadura writes:
>>> On 31/01/18 21:01, Jeremy Bicha wrote:
> Here you go, there's #871004 for you. Missed jessie, stretch,
> not in testing, no uploads since the beginning of 2017.

 I don't think you'll get much sympathy for a package being removed
 from unstable when it hasn't shipped with a Debian release since
 Wheezy, and has continuously been out of Testing for 3.5 years.
>>>
>>> True, it hasn't. But if you look a little bit closer, you'll see both RC
>>> bugs it had were quite trivial to fix: two sourceless files (would be
>>> fixed by linking them to the packaged versions instead), and an failed
>>> attempt to download a build-dep (actually, fixed by an NMU while fixing
>>> another bug, just never marked as done).
>> 
>> So there was plenty of time to fix them.
>> 
>> Why would filing a third RC bug (the "proposed-RM") and waiting one
>> month more change anything?  Why would someone turn up to fix them now?
>
> Why not? I *was* already doing just that, but with an RM bug filed
> elsewhere, I was unable to know it's about to be removed. I would have
> reacted and closed it before the package's got removed.

Packages that have open RC bugs are always at risk to get removed
eventually.  That is why the bug is release critical.

Especially when there is no activity at all on the bugs for an extended
period of time (or no activity ever as was the case here).  And when
they already missed getting included in a stable release or two.

Ansgar

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Lars Wirzenius]

On Thu, 2018-02-01 at 08:37 +0100, Christoph Biedl wrote:
> Adam Borowski wrote...
> 
> > Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".
> 
> Sounds like a very good idea. For me, I could automatically parse these
> and check against the list of packages installed on my systems, or are
> used to build packages (thanks for .buildinfo files) outside the archive.
> 
> > After filing the ITR, if no one objects in a period time, the bug would be
> > retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP"
> > written on them.  Such a period could be:
> > * (if we decide to CC ITRs to d-devel): short: a week?
> > * otherwise: long: 6 months?
> 
> The short period, but not *that* short. I'd expect any reaction will be
> pretty soon but allow people to be offline for a week. In the situation
> where removal is obviously the right thing to do, waiting months is
> mostly horror.


When the cost of making a mistake is high, it pays to spend a lot of
effort to avoid making them. If the cost of removing a package from
testing or unstable is high, we should put in a lot of effort to not
removing packages unless we're really sure it's worth it. Taking
longer to remove packages, to learn of negative effects such removal
would have, is such an effort.

On the other hand, there's also a cost to spending a lot of effort to
avoid mistakes. Being very careful at all times, and doing things more
slowly, tends to slow down development, sometimes by quite a lot. Case
in point: Debian used to be fairly careful about removing packages
from testing, but in the past couple of release cycles, removal from
testing has had a low threshold, and it's been my impression that this
has helped us do better releases with less pain.

The reason that has worked is that the cost of making a mistake when
removing from testing is low. If a package is removed due to having RC
bugs, fixing those bugs will let the package back into testing fairly
quickly, and automatically.

Removing a package from unstable has a somewhat higher cost, but it
seems to me that it it's still fairly low. Thus I would advocate
keeping the time-until-removal fairly short. In other words, a week 
should be OK.

signature.asc
Description: This is a digitally signed message part

Re: Removing packages perhaps too aggressively?

[Ansgar Burchardt]

Andrej Shadura writes:
> On 31/01/18 21:01, Jeremy Bicha wrote:
>>> Here you go, there's #871004 for you. Missed jessie, stretch,
>>> not in testing, no uploads since the beginning of 2017.
>> 
>> I don't think you'll get much sympathy for a package being removed
>> from unstable when it hasn't shipped with a Debian release since
>> Wheezy, and has continuously been out of Testing for 3.5 years.
>
> True, it hasn't. But if you look a little bit closer, you'll see both RC
> bugs it had were quite trivial to fix: two sourceless files (would be
> fixed by linking them to the packaged versions instead), and an failed
> attempt to download a build-dep (actually, fixed by an NMU while fixing
> another bug, just never marked as done).

So there was plenty of time to fix them.

Why would filing a third RC bug (the "proposed-RM") and waiting one
month more change anything?  Why would someone turn up to fix them now?

Ansgar

Re: Removing packages perhaps too aggressively?

[Simon McVittie]

On Thu, 01 Feb 2018 at 08:50:05 +0100, Andrej Shadura wrote:
> > I don't think you'll get much sympathy for a package being removed
> > from unstable when it hasn't shipped with a Debian release since
> > Wheezy, and has continuously been out of Testing for 3.5 years.
> 
> True, it hasn't. But if you look a little bit closer, you'll see both RC
> bugs it had were quite trivial to fix

I'm sure they are - *many* RC bugs are trivial to fix. That doesn't
necessarily make them the best use of our limiting resource: volunteer
time/attention/motivation. If I could spend an hour fixing trivial RC
bugs in undermaintained packages with few users (and trying to work out
how to smoke-test the result to make sure I'm not uploading something
fundamentally broken, which is usually the more time-consuming part),
or alternatively I could spend 10 minutes proposing their removal
and spend the rest of the hour fixing non-RC bugs in widely-relied-on
packages like dbus or GNOME, I suspect the latter is going to have a
larger impact on the quality of Debian.

If you disagree (different people have different priorities), there are
plenty of unmaintained or undermaintained packages you could pick up.

smcv

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Mattia Rizzolo]

On Thu, Feb 01, 2018 at 08:16:31AM +, Simon McVittie wrote:
> So for example "RM: RoQA; unmaintained upstream, orphaned, low popcon"
> (but with no actually known RC bugs) would go via an ITR bug, but
> removals for long-standing RC bugs would usually be immediate? That
> sounds fair, and is similar to common practice with "should this package
> be removed?" bugs.

Except that apparently the OP is complaining about removing a package
with RC bugs open for 3+ years with nobody caring enough to notice them
and *triaging* (as apparently one was even already fixed…) them.

I seriously doubt ITRs or somesuch would help, you wouldn't notice them
anyway.
If you can parse a list of ITRs you can equally easy parse a list of
packages with open RC bugs with next to the same effect.


RoQA packages without RC bugs is very rare (and I don't like them
myself), and ROM shouldn't be second guessed anyway (as an ftpteam
member stated).



(btw, many removals requested by Moritz Muehlenhoff are marked RoQA but
really are RoST (but did that acronym disapper from the list?!), and
that covers a bunch of of the "orphaned pkg removed despite no rc bug")

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Simon McVittie]

On Thu, 01 Feb 2018 at 01:12:21 +0100, Adam Borowski wrote:
> Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".

This sounds like a formalization of the "foo: should this package be
removed?" bugs that some people already use[1]. I was wondering whether
to suggest formalizing those in devref or something.

They should probably be bugs against the package itself rather than wnpp
(like the "should be removed?" bugs are), or X-Debbugs-Cc'd to the
package's contact address and marked as "affects", or something, to give
the maintainer (and other subscribers) one last chance to respond.

[1] I thought the canonical usertag for these was
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=proposed-removal=debian-qa%40lists.debian.org
but that list looks much shorter than I expected it to be, so perhaps
I'm wrong (or perhaps the vast majority of proposed removals have
escalated to actual removals and so the bug got closed)

> As someone who watches the output of qa-rc a lot, most of the time I stare
> at the list, ponder "do I fix this? or would RoQA be better?", shrug and
> move on.  Instead, we could file hundreds of ITRs, wait, then bury the ftp
> folks under a pile of removal requests.

Regular attendees of #debian-uk bug squashing parties will recognise this
pattern already :-)

> However, ITRs wouldn't be mandatory: the majority of packages can be removed
> outright; you'd file an ITR only if you believe there's some controversy.

So for example "RM: RoQA; unmaintained upstream, orphaned, low popcon"
(but with no actually known RC bugs) would go via an ITR bug, but
removals for long-standing RC bugs would usually be immediate? That
sounds fair, and is similar to common practice with "should this package
be removed?" bugs.

smcv

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Ben Finney]

Adam Borowski  writes:

> One issue: on a small screen, crap font and no glasses, "ITR" looks similar
> to "ITP", an alternate acronym could be better.

RFI (Request for Interest)
RFU (Request for Users)
POLL (Participate Or Let's Lose this)

-- 
 \“Politics is not the art of the possible. It consists in |
  `\   choosing between the disastrous and the unpalatable.” —John |
_o__)Kenneth Galbraith, 1962-03-02 |
Ben Finney

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Christoph Biedl]

Adam Borowski wrote...

> Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".

Sounds like a very good idea. For me, I could automatically parse these
and check against the list of packages installed on my systems, or are
used to build packages (thanks for .buildinfo files) outside the archive.

> After filing the ITR, if no one objects in a period time, the bug would be
> retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP"
> written on them.  Such a period could be:
> * (if we decide to CC ITRs to d-devel): short: a week?
> * otherwise: long: 6 months?

The short period, but not *that* short. I'd expect any reaction will be
pretty soon but allow people to be offline for a week. In the situation
where removal is obviously the right thing to do, waiting months is
mostly horror.

> We could have an offshot of wnpp-alert notify you if a package you have
> installed has been ITRed.  Perhaps even this could be installed by default,
> so users in stable of obscure packages have a chance to act.

Certainly, packages to be removed from (old)stable in a point release
should go through that procedure aswell.

> However, ITRs wouldn't be mandatory: the majority of packages can be removed
> outright; you'd file an ITR only if you believe there's some controversy.

For this I'd prefer to have a guideline so this isn't entirely left to the
submitter's discretion. It boils down to "do no harm". So removing cruft
like NVIU certainly can do done straight ahead, while ROM/ROP/RoQA
should get some audience and time.

> One issue: on a small screen, crap font and no glasses, "ITR" looks similar
> to "ITP", an alternate acronym could be better.

Removal Intent for a Package? (jk)

Christoph


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Christoph Biedl]

Jeremy Bicha wrote...

> On Wed, Jan 31, 2018 at 3:03 PM, Christoph Biedl
>  wrote:
> > Or for example the xmem removal (#733668):
> 
> 4 years ago.

So?

> > And also give it some time, I'd suggest some two to four weeks.
> 
> I don't think we need to add an artificial delay for package removals
> that are approved by the package maintainer.

Certainly not. Last year there was a library that no longer had any
rdeps, so the maintainer decided to RM it. Too bad someone out there
develops software based on Debian. At least I learned rather soon,
thanks to some CI that started to report build failures for unresolvable
build dependencies.

Christoph


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

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.

If it's important, someone who cares enough should re-introduce the package.

Scott K

Re: Removing packages perhaps too aggressively?

[Paul Wise]

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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Holger Levsen]

On Thu, Feb 01, 2018 at 01:12:21AM +0100, Adam Borowski wrote:
> Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".
> It's pretty much the opposite of O:
[...]
> * by filing an ITR, you don't disclaim your commitment to the package (if
>   you're the maintainer, you may or may not be willing to continue working
>   on it) -- but instead, you declare doubt whether the package is still
>   needed.
[...]

I like this!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

proposal: ITR (was Re: Removing packages perhaps too aggressively?)

[Adam Borowski]

On Wed, Jan 31, 2018 at 08:14:31PM +0100, Andrej Shadura wrote:
> It has happened to me in the recent years quite a few times that a
> package which I was using has a RoQA bug filed against it, and the
> package's got removed at a very short notice.

For example, dasher was removed (by its maintainer!) because he believed no
one cares about it; the packages wasn't even orphaned.  No one monitors FTP
bugs, the ftpmasters acted swiftly, and the flamewar started only after the
removal was completed.

On the other hand, we have thousands of crap packages no one cares about,
in all three states of maintenance:
* orphaned
* nominally "maintained"
* with a maintainer who actually fixes bugs
yet no one removes them because we don't _know_ whether users would get
hurt, or merely move to an alternative.


Thus, I'd like to propose a new kind of wnpp bug: "Intent To Remove".
It's pretty much the opposite of O:
* if you orphan a package, you claim that you (or the old maintainer) don't
  have enough time, but you believe that Debian is better off with the
  package being kept in the archive
  (batched orphaning (such as by the MIA team) makes no statement for the
  latter part, but that still means no assessment rather than a negative
  one)
* by filing an ITR, you don't disclaim your commitment to the package (if
  you're the maintainer, you may or may not be willing to continue working
  on it) -- but instead, you declare doubt whether the package is still
  needed.

After filing the ITR, if no one objects in a period time, the bug would be
retitled to Ro{M,QA} and shoved towards those guys wearing hats with "FTP"
written on them.  Such a period could be:
* (if we decide to CC ITRs to d-devel): short: a week?
* otherwise: long: 6 months?
We could even have a mix of both of these: packages likely to evoke a
controversy could be discussed upon on d-devel then handled as soon as the
flamerwar abates, while QA spring cleaning would be quiet, massed, and
without haste.

We could have an offshot of wnpp-alert notify you if a package you have
installed has been ITRed.  Perhaps even this could be installed by default,
so users in stable of obscure packages have a chance to act.

As someone who watches the output of qa-rc a lot, most of the time I stare
at the list, ponder "do I fix this? or would RoQA be better?", shrug and
move on.  Instead, we could file hundreds of ITRs, wait, then bury the ftp
folks under a pile of removal requests.

However, ITRs wouldn't be mandatory: the majority of packages can be removed
outright; you'd file an ITR only if you believe there's some controversy.


So, let'd discuss!


One issue: on a small screen, crap font and no glasses, "ITR" looks similar
to "ITP", an alternate acronym could be better.

Meow.
-- 
⢀⣴⠾⠻⢶⣦⠀ The bill with 3 years prison for mentioning Polish concentration
⣾⠁⢰⠒⠀⣿⡁ camps is back.  What about KL Warschau (operating until 1956)?
⢿⡄⠘⠷⠚⠋⠀ Zgoda?  Łambinowice?  Most ex-German KLs?  If those were "soviet
⠈⠳⣄ puppets", Bereza Kartuska?  Sikorski's camps in UK (thanks Brits!)?

Re: Removing packages perhaps too aggressively?

[Simon McVittie]

On Wed, 31 Jan 2018 at 22:36:50 +, Holger Levsen wrote:
> On Wed, Jan 31, 2018 at 10:40:19PM +0100, Michael Biebl wrote:
> > I think we should remove cruft more aggressively then we currently do.
> > We are much too lenient with what we ship in our stable releases.
> 
> I agree, thanks. Re-adding stuff is easy.
> 
> (3 months before the freeze we should stop those cruft removals though, maybe
> even 6.)

The transition freeze might be a useful cutoff? After the transition
freeze, in theory unmaintained packages can't be causing trouble for
transitions (although of course uncoordinated transitions still happen,
unfortunately).

RM: RoQA bugs are often the result of BSPs trying to make the next stable
release releasable, and many BSPs happen shortly before or during the
freeze. I don't think it's a good idea to take that tool away entirely:
I've often looked at RC bugs during BSPs and thought "the fact that I'm
even looking at this package means it has wasted more volunteer time
than I can justify", and I can't be the only one.

Having a higher bar for removals close to or during freeze does make
sense, though: in particular, not removing packages just because
they're unmaintained/little-used/cruft, but only when they have
serious bugs or are specifically causing problems.

smcv

Re: Removing packages perhaps too aggressively?

[Simon McVittie]

On Wed, 31 Jan 2018 at 22:25:31 +0100, Andreas Ronnquist wrote:
> On Wed, 31 Jan 2018 20:14:31 +0100,
> Andrej Shadura wrote:
> >Should I've known someone's going to remove it, I would have adopted
> >it earlier.

If I understand the rules correctly, if a package is present in any
suite in the main Debian archive as hosted on ftp-master (so oldstable or
newer), removals are not particularly permanent: anything still present
in the database, in any suite, doesn't count as NEW. So removal of a
package from unstable doesn't need to be a barrier to adopting it.

You should be aware of what you're getting into, though... packages
aren't routinely or automatically removed just for being orphaned,
so if this one was removed, it's because someone noticed it. That's
reasonably well-correlated with having had release-critical bugs,
having caused trouble for a transition, or otherwise impeding someone
else's work.

You've probably heard the motto "if it isn't tested, it doesn't work"?
If a package doesn't have anything depending on it, isn't widely
installed, and doesn't have a maintainer who is looking after it (and
presumably using it at least occasionally), then it's likely that it
isn't being tested, which in turn means there's a significant probability
that someone who later decides they want to use it will discover that
it doesn't actually work any more (or that it works but has security
vulnerabilities). That seems like a disservice to our users.

Debian is meant to be a high-quality operating system, not a collection
of packages that we keep around in case they come in useful one day.
If a removed package later turns out to be useful or desirable, we have
plenty of opportunities for an interested maintainer to bring it back,
and a couple of ways (archive.debian.org, snapshot.debian.org) for a
user to install it locally.

Every package in the archive consumes resources. Mirror space and network
bandwidth are no big deal, we have plenty of those. Volunteer time and
attention are much more scarce, and we should value them accordingly.
Our users' attention is also a limited resource: when I'm looking for a
package that I can install to solve a particular problem, if there are
(say) two or three good implementations, I'd rather not spend time
looking through a dozen bad implementations to find them.

> >Today, hyde. [...] Missed jessie, stretch, not in testing

If this package was (as mentioned in the removal request) already in
unstable at the time of the jessie freeze (November 2014), then was
removed in mid 2017, then it had been potentially migrating to testing
for, conservatively, at least 2½ years. That's *plenty* of opportunities
to fix whatever release-critical bugs affected it and get it into testing.

> Isn't this rather publicly announced by the how-can-i-help program? I
> am running apt [...] I don't know if this isn't the case if you are
> using apt-get or aptitude though.

Anything that reads apt's DPkg::Post-Invoke configuration, including
apt-get and aptitude, will trigger how-can-i-help. (I mostly use
aptitude myself, and how-can-i-help definitely shows up there.)

smcv

Re: Removing packages perhaps too aggressively?

[Scott Kitterman]

On January 31, 2018 10:34:28 PM UTC, Michael Biebl  
wrote:
>Am 31.01.2018 um 22:49 schrieb Don Armstrong:
>> On Wed, 31 Jan 2018, Abou Al Montacir wrote:
>>> Me too likes to extend the removal notice for few weeks/months.
>>> Especially removal from testing when outside freeze periods.
>> 
>> Packages removed from testing outside of the freeze can be easily
>> re-added to testing once the underlying RC bugs are fixed. So RMs
>should
>> continue to remove early, and remove often. [When this has happened
>with
>> my packages (see lilypond), it's resulted in more people helping with
>> the maintenance of them, and brought some issues to a wider
>audience.]
>> 
>
>I agree. Removals from testing should have no artifical delay. Removals
>from the archive (i.e. unstable), a two or four week courtesy delay
>seems ok to me, giving the person listed in Maintainers a chance to
>reply, seems ok.

So far, every time this comes up, there's no actual volunteer to invest the 
time to update the removals page to make this reasonable to do in practice.

I think some normal delay is reasonable, but it needs to be integrated into the 
pending removals page so the FTP team member processing removals gets an 
indication the request is new.

 Scott K

Re: Removing packages perhaps too aggressively?

[Holger Levsen]

On Wed, Jan 31, 2018 at 10:40:19PM +0100, Michael Biebl wrote:
> I think we should remove cruft more aggressively then we currently do.
> We are much too lenient with what we ship in our stable releases.

I agree, thanks. Re-adding stuff is easy.

(3 months before the freeze we should stop those cruft removals though, maybe
even 6.)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Michael Biebl]

Am 31.01.2018 um 22:49 schrieb Don Armstrong:
> On Wed, 31 Jan 2018, Abou Al Montacir wrote:
>> Me too likes to extend the removal notice for few weeks/months.
>> Especially removal from testing when outside freeze periods.
> 
> Packages removed from testing outside of the freeze can be easily
> re-added to testing once the underlying RC bugs are fixed. So RMs should
> continue to remove early, and remove often. [When this has happened with
> my packages (see lilypond), it's resulted in more people helping with
> the maintenance of them, and brought some issues to a wider audience.]
> 

I agree. Removals from testing should have no artifical delay. Removals
from the archive (i.e. unstable), a two or four week courtesy delay
seems ok to me, giving the person listed in Maintainers a chance to
reply, seems ok.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Removing packages perhaps too aggressively?

[Don Armstrong]

On Wed, 31 Jan 2018, Abou Al Montacir wrote:
> Me too likes to extend the removal notice for few weeks/months.
> Especially removal from testing when outside freeze periods.

Packages removed from testing outside of the freeze can be easily
re-added to testing once the underlying RC bugs are fixed. So RMs should
continue to remove early, and remove often. [When this has happened with
my packages (see lilypond), it's resulted in more people helping with
the maintenance of them, and brought some issues to a wider audience.]

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

Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from. 
 -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_

Re: Removing packages perhaps too aggressively?

[Michael Biebl]

Am 31.01.2018 um 20:14 schrieb Andrej Shadura:
> Hi everyone,
> 
> It has happened to me in the recent years quite a few times that a
> package which I was using has a RoQA bug filed against it, and the
> package's got removed at a very short notice.
> 
> For example, in #616376, gbdfed was removed because "low popcon,
> orphaned". It took just one day to remove it, with no discussion at all.
> Orphaned is *not* a bug. Orphaned doesn't mean the package has no users.
> Maybe the package works for them just fine, and they're happy. Should
> I've known someone's going to remove it, I would have adopted it earlier.
> 
> Today, hyde. I worked on a new release of the package in July, leaving a
> couple of things to be polished when I find more time. Today, I needed
> to use the package, so I thought, oh, let me adopt and upload the
> package. Here you go, there's #871004 for you. Missed jessie, stretch,
> not in testing, no uploads since the beginning of 2017. Filed on 06 Aug
> 2017, removed 10 Sep 2017. Fair enough, the notice was on display for a
> whole month. In a place resembling a locked filing cabinet stuck in a
> disused lavatory with a sign on the door saying ‘Beware of the Leopard’.
> 
> Well, I'm a DD, so it's not a big deal for me to re-upload it, wait for
> a couple hundred years^W hours for it to go through NEW, but…
> Should we maybe give it *a bit* more visibility? Let RoQA bugs hang
> around for *at least* a month, maybe post notification emails every
> fortnight so that they can be noticed? Encourage newcomers to pick them
> up? Prodding DDs who's last reported bugs against the package to maybe
> pick it up?
> 
> Feel free to tell me I'm wrong and don't understand something, but if
> you do, please explain me how and why :)

I think we should remove cruft more aggressively then we currently do.
We are much too lenient with what we ship in our stable releases.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Removing packages perhaps too aggressively?

[Andreas Ronnquist]

On Wed, 31 Jan 2018 20:14:31 +0100,
Andrej Shadura wrote:

>Hi everyone,
>
>It has happened to me in the recent years quite a few times that a
>package which I was using has a RoQA bug filed against it, and the
>package's got removed at a very short notice.
>
>For example, in #616376, gbdfed was removed because "low popcon,
>orphaned". It took just one day to remove it, with no discussion at
>all. Orphaned is *not* a bug. Orphaned doesn't mean the package has no
>users. Maybe the package works for them just fine, and they're happy.
>Should I've known someone's going to remove it, I would have adopted
>it earlier.
>
>Today, hyde. I worked on a new release of the package in July, leaving
>a couple of things to be polished when I find more time. Today, I
>needed to use the package, so I thought, oh, let me adopt and upload
>the package. Here you go, there's #871004 for you. Missed jessie,
>stretch, not in testing, no uploads since the beginning of 2017. Filed
>on 06 Aug 2017, removed 10 Sep 2017. Fair enough, the notice was on
>display for a whole month. In a place resembling a locked filing
>cabinet stuck in a disused lavatory with a sign on the door saying
>‘Beware of the Leopard’.
>

Isn't this rather publicly announced by the how-can-i-help program? I
am running apt, and after each apt run I get a little report for
how-can-i-help if some of my installed packages are orphaned or in risk
of being removed.

I don't know if this isn't the case if you are using apt-get or
aptitude though.

-- Andreas Rönnquist
mailingli...@gusnan.se
andr...@ronnquist.net
gus...@debian.org

Re: Removing packages perhaps too aggressively?

[Abou Al Montacir]

On Wed, 2018-01-31 at 21:03 +0100, Christoph Biedl wrote:
> > It has happened to me in the recent years quite a few times that a
> 
> > package which I was using has a RoQA bug filed against it, and the
> 
> > package's got removed at a very short notice.
> 
> 
> 
> +1
> 
> 
> 
> You meant "RM"? Let me extend this to package removals in general since
> 
> I'm not to happy with the current situation, too.
+1
Me too likes to extend the removal notice for few weeks/months. Especially
removal from testing when outside freeze periods.
-- 
Cheers,
Abou Al Montacir

signature.asc
Description: This is a digitally signed message part

Re: Removing packages perhaps too aggressively?

[Jeremy Bicha]

On Wed, Jan 31, 2018 at 3:03 PM, Christoph Biedl
 wrote:
> Or for example the xmem removal (#733668):

4 years ago.

> More suggestions for the, say, manual removals (mostly ROM, ROP, RoQA):

> And also give it some time, I'd suggest some two to four weeks.

I don't think we need to add an artificial delay for package removals
that are approved by the package maintainer.

Thanks,
Jeremy Bicha

Re: Removing packages perhaps too aggressively?

[Christoph Biedl]

Andrej Shadura wrote...

> It has happened to me in the recent years quite a few times that a
> package which I was using has a RoQA bug filed against it, and the
> package's got removed at a very short notice.

+1

You meant "RM"? Let me extend this to package removals in general since
I'm not to happy with the current situation, too.

While certainly most RMs are obviously the right thing to do, every now
and then I get surprised by a removal - to find this has happened months
ago.

Then reading the related RM I saw a vague justifications like
"Alternatives exist" a bit too often. This is not helpful, I'd at least
expect a list of packages that are actually an alternative.

Or for example the xmem removal (#733668): It indeed failed to build
due to a libprocps transition but the fix was trivial. Also "shows
nothing" was a misunderstanding, xmem really shows nothing for the first
ten seconds.[1] 

Points like these might be brought up immediatly after the RM was filed,
but not a year later.

> Should we maybe give it *a bit* more visibility? Let RoQA bugs hang
> around for *at least* a month, maybe post notification emails every
> fortnight so that they can be noticed? Encourage newcomers to pick them
> up? Prodding DDs who's last reported bugs against the package to maybe
> pick it up?

At first, let's exclude auto-cruft and similar removals since I doubt
there was much dispute about these.

More suggestions for the, say, manual removals (mostly ROM, ROP, RoQA):
To make sure they get attention, send them to d-d as this happens for
ITPs, send them to @packages.qa.debian.org so all subscribers
of the package learn it's important to take action.

And also give it some time, I'd suggest some two to four weeks.

Christoph

[1] Don't get me wrong, resurrecting xmem is not a good idea today, the
program shows garbage, probably due to kernel changes.


signature.asc
Description: PGP signature

Re: Removing packages perhaps too aggressively?

[Jeremy Bicha]

On Wed, Jan 31, 2018 at 2:14 PM, Andrej Shadura  wrote:
> For example, in #616376, gbdfed was removed

This happened 7 years ago. Sorry :(

> Here you go, there's #871004 for you. Missed jessie, stretch,
> not in testing, no uploads since the beginning of 2017.

I don't think you'll get much sympathy for a package being removed
from unstable when it hasn't shipped with a Debian release since
Wheezy, and has continuously been out of Testing for 3.5 years.

Thanks,
Jeremy Bicha