[Pkg-javascript-devel] Bug#980291: Bug#980294: libjs-jquery-flot: breaking API change

[Xavier]

Le 19/01/2021 à 11:11, Jonas Smedegaard a écrit :
> Quoting Xavier (2021-01-18 22:16:30)
>> Le 18/01/2021 à 18:47, Pirate Praveen a écrit :
>>>
>>> On Mon, Jan 18, 2021 at 2:28 pm, Antonio Terceiro 
>>> <terceiro at debian.org> wrote:
>>>> But the fact is that all the other reverse dependencies that used 
>>>> any plugin now need to be changed accordingly. Otherwise we can 
>>>> just wait for their chart features to break in subtle ways in the 
>>>> face of users.
>>>
>>> Not specific to this bug, but in general, we need to be a lot more 
>>> careful and slow when updating node modules that also has libjs-* 
>>> since we don't really have automated tests for them. For, node only 
>>> parts we have tests most of the time, though not all packages have 
>>> tests. So we have to be generally slow down on any major version 
>>> update.
>>
>> Maintaining an unsupported version means taking the risk to be unable 
>> to backport a security fix during stable life and LTS (we already have 
>> many examples).
> 
> Yes, and by letting a package into testing with no RC bugs filed, we 
> signal to consumers of the package that we take that risk.
> 
> 
>> _Before freeze_, I prefer having updated libraries, take the risk to
>> break sometime something, and patch reverse dependencies (with an
>> upstream PR when useful): breaking a little testing/unstable is not a
>> drama.
> 
> Breaking a little in testing/unstable is generally expected, yes.
> 
> Except close to freeze, where breakage _is_ a drama!
> 
> The time of freeze is not the time to stop break things.
> 
> The time of freeze is the time nothing can be broken.
> 
> As a consequence, the closer to the freeze the more cautious we need to 
> be to avoid breaking things.  Libraries can break things in consuming 
> libraries and applications as well, so need more caution, earlier.
> 
>> But we are a team, if the team prefer to take the security risk,
>> then OK, I'll stop updating any libjs-* package (and stop tearing my
>> hair to patch obsolete packages when a CVE exists).
> 
> Debian is making a release. Not the JavaScript team, and not you.
> 
> Debian care *both* about security and breakage.
> 
> Close to freeze, we shall not stop doing security assessments.  Instead, 
> we shall involve the release team and the security team more in our 
> security assessments, by sharing release-concerning bugs with them, and 
> have them help decide how to deal with the dilemma of risking breakage 
> or tolerating security risks.
> 
> First step in that is to _continue_ to file RC bugs.  Then contact the 
> release team suggesting them how those bugs can be solved by them making 
> freeze exceptions, or alternatively having them make an exception for 
> that specific RC bug.
> 
>> Anyway, we entered freeze, it's not time to update anything not 
>> needed,
> 
> Not true: When entered freeze any larger update needs explicit accept 
> from the release team.

Notes:
 * I'm not the author of the breakage, I did no source update on this
   package (just fixed node-uglify problem)
 * The breakage came before soft-freeze
 * I just tried to fix RC bug since nobody took care of it

Bye