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

[Scott Kitterman]

On Wednesday, April 02, 2014 18:07:44 Harald Sitter wrote:
...
snip the stuff before the options - although I note that KDE upstream 
developers seem to rarely tag fixes to bugs in bugzilla in comparison to what's 
actually fixed, so just looking at the bugzilla probably significantly 
underestimates the bug fixing.
> ~~~~ 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

It seems like these two options can be worked in parallel.  Make the final push 
for packaging/testing and then push it in if ready and SRU if not.  The work 
is the same, it's just how fast it's done that determines which option we end 
up with.

> # 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

If there are known RC bugs (really RC) that have fixes available, we should 
push them even if we're trying to go for 4.13 final in order to reduce the pain 
if it doesn't make it.  In some cases is may make sense to cherrypick specific 
patches and not go all the way to git HEAD.  I recall doing this with success 
with PIM stuff for raring.

> # 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.

This would take enough work that it would mean a decision not to land 4.13 
before release.
> 
> # 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.

There are a variety of reasons why this would be bad.  I'd much rather release 
with the RC and SRU a week later.  Once 4.13.1 is out the amount of post-
install upgrading a user has to do won't be significantly different than if the 
RC is on the install media or the final.

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

Since KDE config file downgrades are at your own risk, this seems like it'd put 
the user base that installed pre-release at significant risk of issues that 
would be unsupported by upstream.

I suspect you can tell where I think we should go, but here it anyway:

Push for 4.13.0 in the release, but release with the RC + cherrypicks for 
serious defect correction if it's not ready.

Scott K

P.S.  Thanks Harald for the excellent analysis.