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