I'm just following the guidelines for SRU here, which make me think this isn't exactly suitable for SRU without a proper exception from the TB. For example, there are some changes that aren't quite bugfixes in my mind:
So, for Trusty, it feels to me like the best would be to wait and see what the TB thinks. I don't think it would be worthwhile to open a bug report for each one of them separately.
As for the Utopic changes; there is would be useful to have a specific bug for avoiding TLSv1.2 -- this is because we can then verify each bug separately, and track regressions. I agree the likelihood of regression is low, but it's nonetheless the procedure that we should follow, unless you'd rather also wait for the TB to statute on a micro-release exception.
Daniel,
Your email to the Technical Board appears to have been received: https:/ /lists. ubuntu. com/archives/ technical- board/2015- February/ 002080. html
I'm just following the guidelines for SRU here, which make me think this isn't exactly suitable for SRU without a proper exception from the TB. For example, there are some changes that aren't quite bugfixes in my mind:
resip/stack: additional OpenSSL cleanup fn - reordered functions to match order used in this post: http:// openssl. 6102.n7. nabble. com/Cleanup- procedure- missing- some-calls- td37441. html
resip/stack: Added accessor for TransactionUser FIFO so to obtain stats
rutil: accept case insensitive log level strings
So, for Trusty, it feels to me like the best would be to wait and see what the TB thinks. I don't think it would be worthwhile to open a bug report for each one of them separately.
As for the Utopic changes; there is would be useful to have a specific bug for avoiding TLSv1.2 -- this is because we can then verify each bug separately, and track regressions. I agree the likelihood of regression is low, but it's nonetheless the procedure that we should follow, unless you'd rather also wait for the TB to statute on a micro-release exception.