Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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/

Re: Removing packages perhaps too aggressively?

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 >

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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 b

Re: Removing packages perhaps too aggressively?

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,

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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?

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;

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

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

Re: Removing packages perhaps too aggressively?

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 >

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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,

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

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

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

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,

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

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.

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

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.

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

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

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

* 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

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

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

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

* 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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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 p

Re: Removing packages perhaps too aggressively?

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 th

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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.

Re: Removing packages perhaps too aggressively?

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

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

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

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

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

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

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

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

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

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)

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

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

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

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

Re: Removing packages perhaps too aggressively?

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

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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

Re: Removing packages perhaps too aggressively?

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