On 24/11/16 16:37, Adrian Bunk wrote:
> On Thu, Nov 24, 2016 at 02:45:26PM +0100, Ondřej Surý wrote:
>> On Thu, Nov 24, 2016, at 13:39, Philipp Kern wrote:
>>> So if you, as an upstream maintainer, have a change that is needed for
>>> compatibility with changes in network APIs and the change is reviewable
>>> by humans, a stable update could be possible. It's still on a
>>> case-by-case basis, so you would need to ask and the Release Team cannot
>>> approve what they do not know about.
>>
>> There are more cases where Debian stable is getting new upstream
>> releases.
>> It's mostly to keep up with the security (MySQL, PHP),
>> ...
>
> These are long-term supported upstream stable branches.
>
> Debian cannot just sacrifice stability by throwing the latest upstream
> release of some random packages into stable.
>
> And rewarding an upstream not able or willing to provide stability would
> also set the incentive the wrong way.
>
"not able or willing to provide stability" is rather broad.
I agree that for compilers and scripting languages a lot of stability is
essential.
For networked services, it is different.
Debian has already been carrying updated versions of Firefox and
Chromium in stable including bundled dependencies too. Maybe we need to
have an objective way of deciding which other projects genuinely deserve
the same treatment.
> If it is likely that some packages cannot be supported until the end of
> the (non-LTS) lifetime of stretch in mid/end-2020, then please file RC
> bugs to keep these packages out of stretch.
>
An RC bug against libmusicbrainz5-1 would impact packages that are in
the default desktop.
$ apt-cache rdepends --recurse --no-suggests --no-recommends \
libmusicbrainz5-1
