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