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 _______________________________________________ Kde-testing mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-testing
