Neon/FoundingPlan: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
Line 1: Line 1:
{{Warning|2=Important|1=This is a draft}}
{{Warning|2=Important|1=This is a draft}}


== What we plan that Neon will be and why it will be so. ==
[[File:kde-neon.png|right]]
[[File:kde-neon.png|right]]
== What we plan that Neon will be and why it will be so. ==
October 2015
October 2015



Revision as of 17:39, 5 October 2015

Important

This is a draft


What we plan that Neon will be and why it will be so.

October 2015

Neon provides an easy and elegant way for people to test the latest from KDE, or use the latest releases of KDE Software.

KDE is a community making the best in end-user ready software, but it can be hard to install the latest versions. We rely upon Linux distribution companies and communities to package, compile and make our software available which they do an excellent job of. However they use release schedules which are not aligned to KDE's, they don't provide packages from Git and often not from Betas so there's no way to test the forthcoming releases and the packages can be late compared to KDE's releases. Once a user has installed a distro there is often no easy way to get updates of KDE packages such as a new release of Plasma, it typically involves adding an extra archive that the user needs to search out. Because of the competing demands of distributions the third party libraries and software is often a different version from that which KDE software works best with. And of course they take away KDE's branding, often adding their own branding to the software and driving away users and contributors and donors who might be best served directly from KDE.

We are a team of KDE fans who would like to try improving this situation and would like to work with KDE to do it.

We'll use Ubuntu as a base for Neon. Ubuntu provides a stable release with 2 years of security updates and if necessary hardware backports, this allows Neon to concentrate on the rolling KDE updates we care about. We have a lot of previous experience in Kubuntu to give us the starting technology and knowledge needed to make this available; the existing Neon/Kubuntu CI images are based on Ubuntu. Where KDE needs a newer version of software that is available it is likely available elsewhere for Ubuntu to be easily backported in the Neon archives. Increasingly the Ubuntu archives do not have the necessary version of a piece of software needed by KDE, in which case we will add it to the Neon archives. We will remove Ubuntu branding as much as possible to be good citizens with their trademark. Packages in Ubuntu "Must allow modification and distribution of modified copies under the same licence" and we will make use of these free software licences granted to Ubuntu by upstream projects such as KDE.

We love Linux distributions and recognise they will always be the main method of distributing KDE's software. Neon won't get special treatment from the rest of KDE by virtue of being a KDE project and it certainly won't be the KDE distribution. Other projects which release software packages for Linux may well join KDE as there are already project which release software packages for Windows and Mac.

Neon will make available KDE software from latest stable releases, latest unstable releases and from Git. Our default selection of software will include a fully functional desktop set up using Plasma and other KDE software where there is a viable option from KDE. For third party software which can be made to integrate with Plasma we will have versions including this integration.

Who's it for?

The user profiles for Neon are:

  • KDE contributors who want the latest libraries and tools available to work with
  • KDE testers who want to check the latest releases
  • KDE fans who admire our work, want to use it and watch it evolve and occasionally comment on forums or report problems

What's to be made available?

  • Mirrors of the Debian pkg-kde packaging with Neon branches for anyone in KDE to contribute to
  • Where a distribution specific piece of software is needed we will make a KDE program to work with this, in the style of for example Kubuntu Driver Control Modules. We will always look for a non-distribution piece of software first.
  • A continuous integration system to build packages for amd64 from these branches from KDE unstable and stable branches
  • The same set up to build packages from these branches from KDE unstable and stable released tars
  • A .deb archive of packages of KDE software built by the continuous integration systems with channels for git/release stable/unstable
  • ISO installable images using these packages released in time with major KDE software releases such as Plasma