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 > > <[email protected]> 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 assesments. 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 relase 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. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
