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

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)



Ole Streicher <olebole@debian.org> (2016-12-20):
> This is for sure. Cyril just states that he rather would love to remove
> the blends completely, and this is something I am arguing against.

No, I said this was the default action, until I have looked at proposed
changes, and assessed what to do with them.


Current state in the archive is a no-go. It's been the case for too many
releases already, and it's been reported as such from the very beginning.

Proposed implementation hasn't reached the master branch, let alone the
archive; and current commit messages contain interrogations AFAICT from a
quick look at the IRC notifications earlier today.

That's not something I want to see rushed into stretch just because
nobody worked on the no-go situation for months, despite early warnings.

> That Phils solution is a great compromise, is out of question. IMO it
> would help much if d-i would help here a bit instead of just trying to
> play a veto game.

It's not about veto-ing. It's about not believing it's OK to push/rush
invasive changes whenever one feels like it. The freeze is here for a
reason. Back a few years, we've had to change d-i a lot during the
freeze because almost nobody worked on it for quite a while. (We even went
as far as not starting the freeze until an Alpha was actually released, if
memory serves.)

We've been having (in)frequent d-i releases for two release cycles now,
and there have been plenty of chances to determine and implement a “great
compromise”. Several weeks or months after the gradual freeze has started
is way too late by my count.

Hence my current heuristics.


KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: