Testing minor releases

[Markus]

Instead of Project Neon which is tied to a specific distribution someone with 
the proper knowledge should rather do a "KDE:/Testing" repo in OBS. OBS has 
the advantage that it can not only build for openSUSE but also Arch, Fedora, 
Ubuntu, Debian, Mandriva,... (the cross-distro version of Unity is made 
available this way for multiple distros).

Considering that the Active folks use OBS for Mer anyway and want to make 
Plasma Active almost a rolling release, such a repo would help them as well.


Am Mittwoch, 13. Februar 2013, 12:21:14 schrieb David Edmundson:
> 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