[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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

Reply to: