Testing minor releases

David Edmundson david at davidedmundson.co.uk
Wed Feb 13 12:21:14 UTC 2013


There is a current thread on the release team mailing list "Better testing
of tagged tars" during the massive email thread the topic of testing the
minor releases comes up. There is a supposed problem in KDE that we have
people running stable releases and we have people running the very latest
master code.
What we don't have is people running the latest code from the 4.10 branch
which makes the minor releases effectively untested when they are released.
This can introduce regressions and other problems.

In an effort to be proactive, I sent an email to Kubuntu-devel asking how
much effort it would be to make a "project neon" for stable branches. I got
a really detailed response back from Philip Muskovac from Kubuntu.

# with my Project Neon Maintainer Hat on: #
> === Short Version: ===
> Doable with a bit of work if it's useful
>


=== Long Version: ===
> What this would need at least:
> - another ~ 15-20GiB Repository to hold the packages.
>   (that's counting packages for 2 kubuntu releases)
> - new source code imports for all stable branches
> - new recipes for all of them.
> Creating the source code imports and the recipes isn't too much work
> considering one can script that.
> It could require forking some of the packaging branches, but that's not
> too much work either.
> Project Neon by itself is pretty low maintenance. It's mostly checking
> package dependencies every now and then and keeping up with the git
> transition and new components.
> The question here would be how many people would use this so it's worth
> the trouble to set it up and the additional load it would put on
> Launchpad's infrastructure.
> If this would really help the kde-quality team it could be done though
> with not too much work.



Questions:
  - How much is it actually a problem? Is there a way to quantify how many
regressions come in during minor releases?
  - How many user's do you think we could get?
  - Is it worth pushing for this as opposed to pushing for user's to run
latest master? Assuming we can really only put our effort in one direction.
  - Are there any other ways we can do this?

David Edmundson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-testing/attachments/20130213/0899ce48/attachment.html>


More information about the Kde-testing mailing list