Salut, back when we decided to try to land 4.13 no final decision was made on whether to actually go for the final (which pretty much implies getting it all packaged and uploaded in one day - and hope it works) or whether to ship with 4.13 rc and SRU the final.
it's about time we made a decision on this topic. I discussed this earlier a bit with people. Towards the end of this mail you can find the five options that present themselves currently. They are ordered by my personal preference, but (hopefully) objectively inform abut what each option means. Please have a look at the options and decide which one seems most reasonable. Since they all evolve around the quality of 4.13.0 vs. the quality of 4.13 rc the following data may come in handy: (bare in mind that the raw queries are subject to false positives because bug tracking software...., includes !sc software as well as reports that did not have a version assigned) fixed bugs reported since rc1 tagging (counting 3 legit ones): http://goo.gl/b2C8HT bugs reported since rc1 tagging (counting 42 legit ones): http://goo.gl/e1xE1e crasheroo in the past month (nothing apparently caused by KDE, all the spam about kwallet is entirely someone else's fault): http://goo.gl/7jKAOe Interpretation lazy people: - there don't seem to be any major crashers active (other than the kwallet thing which was caused by a patch) - there are still quite some bugs possibly affecting the release candidate - given fix amount right now we might be able to expect another 3 documented bug fixes (or more, or less, there isn't really anything conclusive about this :P) Remarks: - Please bare in mind that translations as of 4.12.95 are still broken, so fixing those without upstream tarballs would be "fun" and require yet more tooling to be written. Personal opinion: while the final-sneak option is the probably most stressful one, it will most likely provide the best exerpience, plus if the bugzilla query is only remotely useful there is still quite some fixes that could go into 4.13.0. all in all a whole-sale approach seems most sensible. at least we have the tooling for this already :) ~~~~ options ~~~~ # final-sneak 4.13.0 is packaged and uploaded on tagging day (this works around KDE's release embargo - needs approval I guess - happens just before final freeze). needs: tagging to happen in time; packages to actually build; packaging to not need changes byond the regular changlog and dep bump; someone to have time to actually push it through in the time given; complete testing offers: 4.13.0 from the very beginning of the 14.04 life cycle # final-sru 4.13.0 is packaged and uploaded to PPA, pushed via regular SC SRU process after release. needs: PPA testing (i.e. people to actually test it); limited testing offers: 4.13 rc to be in the archive and potentially have known or unknown defects # final-selective-cherrypeak-sneak 4.13 rc is to be shipped in 14.04 final, packages with serious defects get their entire diff from rc to git HEAD imported as a patch into the package. needs: need to know about there being the defects to begin with; coordination with upstream; limited testing offers: prevention of releasing with known defects simply because they were not in the rc # final-sru-continuous-cherrypeak-sneak All of the above. 14.04 releases with a heavily patched 4.13 rc (up to the point where we would not want to add patches anymore, which is either close to or even after 4.13.0). All packages would get their respective upstream git changes imported as patches. needs: tooling to actually do that; a machine with resonably sized disk space and bandwith; complete testing offers: same as final-sneak but less stressful landing and control over when we stop to import changes. # nuke Get the release pushed back by a week. needs: approval and/or someone to roll ISO (having a separate release from the rest of buntu would be a first, it's not exactly well known territory) offers: less stressful landing, more time for testing. (sixth for completness' sake) # revert Revert back to 4.12.x ~~~~ HS -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
