4.13.0 or 4.13 rc (that is the question - no, really, it is)

Harald Sitter apachelogger at ubuntu.com
Wed Apr 2 16:07:44 UTC 2014


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):

bugs reported since rc1 tagging (counting 42 legit ones):

crasheroo in the past month (nothing apparently caused by KDE, all the
spam about kwallet is entirely someone else's fault):

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)

- 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

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

offers: less stressful landing, more time for testing.

(sixth for completness' sake)
# revert
Revert back to 4.12.x



More information about the kubuntu-devel mailing list