© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
Thanks again for actively working on this! I'd certainly like Robie to take a look at this upload as he was the one originally involved in handling the SRU. But a few of my second-opinion cents here.
With my SRU hat on, it's very difficult handling such huge new upstream release updates to our stable series. I do have some questions before I can actually formulate my own opinion here:
The issues mentioned to be caused by the 'buggy' version do seem to be high-impact, but from what I understand the application is still usable - is that correct? Because if it's not and the current issues are simply making the package unusable, that is certainly a different story. Many of our strict SRU rules are simply to guard from regressions. But in cases where the experience is anyway 'regressed', we can be a bit less strict for the good of everyone.
Looking at the source, it looks to me that there is quite a lot of unit-tests defined - are those being run during build time? How does the test coverage story for mixxx look like? Do all bugfixed/features come with unit-testing always?
Finally, if we decide to include this SRU in our stable series, the manual testing story will have to be improved. This is a lot of changes and just the tests mentioned in the [Test Case] currently are not enough in my opinion to verify if the upload is good to be released. First thing I'd recommend is: the upload links to 4 other bugs (as seen in the bug description here), so what I'd like seeing is getting all 4 of those updated for SRU purposed (i.e. adding all the needed information as per the SRU template [1]). Each of those would have to be verified separately anyway. Also, I'd propose adding some general-usage test cases to the Test Case here. Something to make sure that the application is still working.
[1] https:/