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. 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?
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: What is the point of RFA? Was: Re: proposal: ITR
On Fri, Feb 2, 2018 at 7:23 AM, Jeremy Bicha wrote: > What is the point of RFA? > > I mean why don't you just Orphan it and continue to maintain it with > QA uploads until a volunteer wants to adopt it? I wasn't around when RFA was invented, but: You might want to have choose amongst the potential adopters who gets it. With your name still attached to the package, it shows up in more places so you are more likely to notice issues with it, RC bugs etc. -- bye, pabs https://wiki.debian.org/PaulWise
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 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: Mass bug filing for the removal of freetype-config and freetype.m4
On Thu, Feb 1, 2018 at 7:07 PM, Hugh McMaster wrote: > This is a Debian-specific change. Will you be asking upstream to remove it too? -- bye, pabs https://wiki.debian.org/PaulWise
Work-needing packages report for Feb 2, 2018
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1158 (new: 2) Total number of packages offered up for adoption: 167 (new: 7) Total number of packages requested help for: 50 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: haskell98-report (#888723), orphaned 3 days ago Description: The Haskell 98 Language and Libraries Revised Report & addenda Reverse Depends: haskell-doc Installations reported by Popcon: 381 Bug Report URL: http://bugs.debian.org/888723 libmbim (#888680), orphaned 4 days ago Description: MBIM protocol support Reverse Depends: libmbim-glib-dev libmbim-proxy libmbim-utils libqmi-glib5 libqmi-utils modemmanager Installations reported by Popcon: 94989 Bug Report URL: http://bugs.debian.org/888680 1156 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: doxygen (#888580), offered 5 days ago Description: Documentation system for C, C++, Java, Python and other languages Reverse Depends: doxygen-dbg doxygen-gui doxygen-latex doxyqml eclipse-eclox python-breathe python3-breathe Installations reported by Popcon: 8302 Bug Report URL: http://bugs.debian.org/888580 python-adal (#889082), offered today Description: Azure Active Directory Authentication Library for Python 2.x Reverse Depends: azure-cli Installations reported by Popcon: 10 Bug Report URL: http://bugs.debian.org/889082 python-applicationinsights (#889083), offered today Description: Azure Application Insights API for Python 2.x Reverse Depends: azure-cli Installations reported by Popcon: 12 Bug Report URL: http://bugs.debian.org/889083 python-azure (#889084), offered today Description: Microsoft Azure SDK for Python 2.x Reverse Depends: azure-cli python-azure-storage python3-azure-storage Installations reported by Popcon: 27 Bug Report URL: http://bugs.debian.org/889084 python-azure-devtools (#889085), offered today Description: Microsoft Azure Development Tools for Python 2.x Installations reported by Popcon: 4 Bug Report URL: http://bugs.debian.org/889085 ruby-haikunator (#889095), offered today Description: Heroku-like random name generator Reverse Depends: vagrant-azure Installations reported by Popcon: 16 Bug Report URL: http://bugs.debian.org/889095 ruby-timeliness (#889094), offered today Description: Fast date/time parser gem for Ruby Reverse Depends: ruby-ms-rest Installations reported by Popcon: 14 Bug Report URL: http://bugs.debian.org/889094 160 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 428 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 1095 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2321 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 668 Bug Report URL: http://bugs.debian.org/642906 broadcom-sta (#886599), requested 24 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 2030 Bug Report URL: http://bugs.debian.org/886599 cargo (#860116), requested 296 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 569 Bug Report URL: http://bugs.debian.org/860116 cups (#532097), requested 3162 days ago Description: Common UNIX Printing System Reverse Depends: ayatana-indicator-printers bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd (69 more omitted) Installations reported by Popcon: 181280 Bug Report URL: http://bugs.debian.org/532097 cyrus-sasl2 (#799864), requested 862 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper claws-mail-archiver-plugin (123 more omitted) Installations reported by Popcon: 203569 Bug
What is the point of RFA? Was: Re: proposal: ITR
On Thu, Feb 1, 2018 at 5:46 PM, 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. What is the point of RFA? I mean why don't you just Orphan it and continue to maintain it with QA uploads until a volunteer wants to adopt it? See this for reference: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#orphaning Thanks, Jeremy Bicha
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 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?
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?
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?)
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)
Mass bug filing for the removal of freetype-config and freetype.m4
Hi everyone, I intend to do a mass bug filing against all packages that use freetype-config and/or freetype.m4, as these APIs will be removed from libfreetype6-dev in the next maintainer release. This is a Debian-specific change. Freetype-config has been considered deprecated for several years [1]. Although it is suitable for compiling for the native architecture (i.e. host = build), it cannot handle cross-compiling. See, for example [1], [2] and [3]. Freetype-config also acts as a wrapper for pkg-config, if that package is installed. However, as explained in [2] and [3], this does not help with cross-compiling, because "pkg-config must be qualified with the GNU triplet of the package architecture" in order to output the correct library paths. I asked for freetype-config to be removed in [4] to allow libfreetype6-dev to become Multi-Arch: same. Five months later, I compromised and patched freetype-config to remove the hard-coded libdir paths causing the multi-arch file conflict. A separate change (build-depending on pkg-config) fixed [5], but caused additional bugs when libfreetype6-dev is installed for foreign architectures only (see [2] and [3]). In these bugs, freetype-config was calling pkg-config for the native architecture. Following discussions in [3] and further investigation, the decision was made to remove freetype-config and freetype.m4 to better support multi-arch usage. With this in mind, I removed freetype-config and built all reverse build-dependencies. I have also searched codesearch.debian.net for use of AC_CHECK_FT2 in configure.ac and configure.in. (Thanks to Simon McVittie for the suggestion.) A list of affected source packages is attached. 36 packages FTBFS without freetype-config. Another 25 compile, but warn that freetype was not detected. 26 of the 61 packages already use pkg-config to detect other libraries, so updating those packages to detect freetype2 using pkg-config is straightforward. The proposed wording for the bug reports reads: Dear Maintainer, The next release of libfreetype6-dev will *not* ship freetype-config or or freetype2.m4. This is a Debian-specific change. Please use pkg-config to detect the freetype2 headers and libraries. If this bug is not resolved prior to the release of the next version of libfreetype6-dev, your package may FTBFS. Thank you I realise removing freetype-config may not be popular. However, the long-term benefits will outweigh any short-term inconvenience. -- Hugh McMaster [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642354 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871470 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886461 [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870618 [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885324List of packages affected by the removal of freetype-config: D Haley 3depict (U) Debian Science Maintainers 3depict Barry deFreese adonthell (U) Debian Games Team adonthell Robert Luberda afterstep Barry deFreese asc (U) Bartosz Fenski asc (U) Debian Games Team asc Markus Koschany asc (U) Sam Hocevar asc (U) Barry deFreese brutalchess (U) Debian Games Team brutalchess Vincent Legout brutalchess (U) Debian OCaml Maintainers camlimages Mehdi Dogguy camlimages (U) Ralf Treinen camlimages (U) Debian Games Team cube2font Martin Erik Werner cube2font (U) Debian QA Group dia Marc Leeman dvdauthor OHURA Makoto dvi2ps Varun Hiremath dvipng Barry deFreese fenix-plugins (U) Debian Games Team fenix-plugins Miriam Ruiz fenix-plugins (U) Peter Pentchev fenix-plugins (U) Michele Martone fim Rafael Laboissiere fim (U) Aaron M. Ucko fltk1.1 Debian Games Team foobillardplus Markus Koschany foobillardplus (U) Sam Hocevar ftgl Jaimos Skriletz fvwm Giacomo Catenazzi g15composer Ari Pollak gimp Jordi Mallach gimp (U) Debian GNUstep maintainers gnustep-back Eric Heintzmann gnustep-back (U) Gürkan Myczko gnustep-back (U) Yavor Doganov gnustep-back (U) Laszlo Boszormenyi (GCS) graphicsmagick Colin Watson grub2 (U) Felix Zielcke grub2 (U) GRUB Maintainers grub2 Ian Campbell grub2 (U) Jordi Mallach grub2 (U) Debian Multimedia Maintainers inkscape Matteo F. Vescovi inkscape (U) Mattia Rizzolo inkscape (U) Dominique Dumont lcdproc Giacomo Catenazzi libg15render Harshula Jayasuriya libotf Debian SDL packages maintainers libsdl-sge Manuel A. Fernandez Montecelo libsdl-sge (U) Debian SDL packages maintainers libsdl2-ttf Manuel A. Fernandez Montecelo libsdl2-ttf (U) Debian QA Group libwmf Debian freesmartphone.org Team literki Timo Jyrinki literki (U) Harshula Jayasuriya m17n-lib Bas Couwenberg mapnik (U) David Paleino mapnik (U) Debian
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 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?
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?
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
Bug#889075: ITP: qt5-engines-kvantum -- SVG-based theme engine for Qt5
Package: wnpp Severity: wishlist Owner: Alf Gaida * Package name: qt5-engines-kvantum Version : 10.5 Upstream Author : Pedram Pourang * URL : https://github.com/tsujan/Kvantum * License : GPL-3.0+ Programming Lang: C++, etc Description : SVG-based theme engine for Qt5 Kvantum (by Pedram Pourang, a.k.a. Tsu Jan tsujan2...@gmail.com) is an SVG-based theme engine for Qt4/Qt5, KDE and LXQt, with an emphasis on elegance, usability and practicality. LXQt Team want to maintain it.
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 "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?)
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?)
* 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?)
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?)
* 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
Bug#889054: ITP: pytest-astropy -- Metapackage to resolve pytest dependencies for Astropy
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-devel@lists.debian.org * Package name: pytest-astropy Version : 0.2.1 Upstream Author : Thomas Robitaille * URL : https://github.com/astropy/pytest-astropy * License : BSD-3-Clause Programming Lang: Python Description : Pytest dependencies for Astropy & Co. This is a meta-package that pulls in the dependencies that are used by `astropy` and some `affiliated packages` for testing. It can also be used for testing packages that are not affiliated with the Astropy project. It is a new build dependency of astropy 3.0. I will maintain it within the Debian Astro team. Best regards Ole
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 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?
On February 1, 2018 12:53:40 PM UTC, 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.
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?
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 JacksonThese 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?
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?
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?
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?
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?
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?
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?)
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?
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?
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?)
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?)
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&user=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?)
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
