On 2019-06-09 Nikos Mavrogiannopoulos <[email protected]> wrote: > On Sat, 2019-06-08 at 11:29 +0200, Andreas Metzler wrote: [...] > > I am now wondering on what to do with this bug for the next Debian > > stable release ("buster"). > > * We are unlikely to upgrade to 3.6.8 since buster is already frozen.
> What is blocking the upgrade to 3.6.8? Is there some further change to > do in the development rules so that debian can follow the stable > branch? Hello Nikos, the rules [1] for updates for the soon-to-be-released "buster" are very tight, every update is reviewed indiviually by an actual person. --------------- * targeted fixes for release critical bugs (i.e., bugs of severity critical, grave, and serious) in all packages; * fixes for severity: important bugs in packages of priority: optional, only when this can be done via unstable; * translation updates and documentation fixes that are included with fixes for the above criteria; [...] A targeted fix is one with only the minimum necessary changes to resolve a bug. --------------- (An important bug is defined as "a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.") A GnuTLS release on the stable branch OTOH can contain a lot more than that (essentially everything that does not break the API.). Looking at commits in 3.6.8 we find a lot of stuff that would not do for a Debian stable/frozen update. * beautification 8e28bb311ab33a1e7886e46af167311534070c39 * New features (e.g AES-XTS) * cleanup (344c77b755f68370a098b90ef2ce981b829dd534 handshake: remove unnecessary HSK_CRT_SENT flag) * Improvements for the test-suite I do not think that this is really solvable. GnuTLS and Debian release time are just not aligned and are not alignable. It is a matter of scale. - Debian cannot start doing bi-monthly stable releases including feature upgrades and GnuTLS would not improve if it switched to bi-annual releases (all new features happening in the unstable branch which was almost untested). > Having multiple gnutls versions in the major distributions with > diverse behaviors would make things not easy in terms of > interoperability for tls1.3 or any other future feature. I think that is unavoidable. If you can think of specific changes in 3.6.8 that you think I should cherry-pick I would be very grateful. Perhaps #720 (IDNA)? TIA, cu Andreas [1] https://release.debian.org/buster/freeze_policy.html -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
