Policies/Application Lifecycle: Difference between revisions

From KDE Community Wiki
(link to coordinator overview)
(27 intermediate revisions by 15 users not shown)
Line 1: Line 1:
When you want to start a new application (or remove an old application), you want to know where you should place it in the Subversion repository. This document describes where to go in which stage of your application.
KDE is a friendly community which hosts hundreds of projects. Any project which follows the [https://manifesto.kde.org/ KDE manifesto] and [https://community.kde.org/KDE/Vision KDE Vision] is welcome to join us.


See [[#Stage 3: The end]] for instructions on how to deal with old, unmaintained applications.
The term "application" is used here to mean any project hosted in KDE Git and includes programming libraries and development tools but not typically infrastructure tools or projects with other end product outputs.


In a diagram it all comes down to:
[[File:App-lifecycle2.png|400px]]


= playground =
[https://projects.kde.org/api/v1/projects/playground playground] is a Git module for projects starting development
* You will need a Git write account which needs a referral from another KDE contributor, see [[Infrastructure/Get_a_Developer_Account|Get_a_Developer_Account]]
* You will need to to ask sysadmin to create a module
* Projects can start in scratch repos without asking for a repo, see [[Sysadmin/GitKdeOrgManual|Git KDE.org manual]]
* Projects can make alpha releases and can put them on [http://download.kde.org/unstable download.kde.org unstable]
* Projects can ask for translations for their master branch only


[[Image:svnguidelines.png]]
= Incubator =
Projects which started life outside of KDE are welcome to join us if you feel our community makes a good fit through the [https://community.kde.org/Incubator KDE Incubator]. A sponsor will guide you through the process and check your project complies with the needs of the KDE community


= kdereview =
Projects move into [https://projects.kde.org/api/v1/projects/kdereview kdereview] when they are ready to start making beta or stable releases. It allows for the KDE community to check over for minimum standards.
* You can move your project in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], see [https://cgit.kde.org/sysadmin/repo-metadata.git/tree/README.md repo-metadata README] or file a [http://sysadmin.kde.org/tickets Sysadmin ticket asking for the move]
* See the [[ReleasingSoftware|Sanity Checklist]] for some of the elements people will review
* E-mail [https://mail.kde.org/mailman/listinfo/kde-core-devel kde-core-devel] and other relevant mailing lists with details of your project and what the expected destination is for the repo
* Make fixes to issues people bring up or provide explanation why they are not (yet) fixed
* Wait at least two weeks in kdereview
* After two months in kdereview the repo should be moved back to playground or moved to unmaintained


=== Stage 1: The start ===
* See [[KDEReview]] page for current status of projects (feel free to help maintain this page and push reviews forwards)
The start of a new application can take place on a local disk, in a local repository or any other way. Another option is provided by KDE in the special {{path|/trunk/playground}} folder in the repository where everyone is free to commit ones own application. You can [[Contribute/Get_a_SVN_Account | request an SVN account]] and after that you can import your project in the subfolder of your choice.


It is not meant as a backup area, so you should not develop your application somewhere else and only sync the changes now and then to KDE's repository.
= Releasing =
Your project is now active and can make beta or stable releases. Find the best home for your project based on contents and release process wanted.
* After two weeks in kdereview you can move it in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], file a [http://sysadmin.kde.org/tickets Sysadmin ticket] if unsure.
* These projects should depend only on stable released software or software known it will get a stable release before the project does. It may use unstable or unreleased software only as an optional build dependency.
* Add your project to automated builds:
** Update [https://cgit.kde.org/kde-build-metadata.git/ kde-build-metadata] to add it to [https://kdesrc-build.kde.org/ kdesrc-build]
** Ping the KDE neon devs to help get it added to [https://build.neon.kde.org/ KDE neon builds]
** Ping the sysadmins to help get it added to [https://build.kde.org/ KDE CI]
* KDE Frameworks are programmer libraries
** They have [[Frameworks/Policies|strict quality requirements]]
** Get released monthly
** Ask on [https://mail.kde.org/mailman/listinfo/kde-frameworks-devel kde-frameworks-devel] if you want to be considered for inclusion
** Version numbers are made by release person, there are no stable branches
* Plasma is a cross device work environment where trust is put on the users' capacity to best define her own workflow and preferences.
** It is typically released 3 times a year
** Projects released as part of Plasma must fit well together and be a useful part of the user's work experience.
** They would not be useful to users of other desktops.
** Version numbers and stable branches are made by release person
** Ask on [https://mail.kde.org/mailman/listinfo/plasma-devel plasma-devel] for consideration of inclusion
* release service
** Released typically 3 times a year en-masse
** Includes a range of libraries, applications and developer tools
** External version numbers (projects often have their own internal version numbering scheme) and stable branches are made by release person
** Ask [https://mail.kde.org/mailman/listinfo/release-team release-team] for inclusion
* Self Released - Many projects take care of their own release process
** Also called Extragear
** They can use whatever version number scheme they want and can release in their own timeframe
** Use [https://cgit.kde.org/releaseme.git/ releaseme] to make releases, see [https://community.kde.org/ReleasingSoftware Releasing Software]


As soon as you start releasing your software and match the criteria for the next stage, you should consider moving your application folder to the next stage.  
= Unmaintained =
If a project is no longer useful you can move it to [https://projects.kde.org/api/v1/projects/unmaintained unmaintained].  It can move here from any stage in the lifecycle.


Because playground is something like an 'experimental' area, there is only a small amount of applications that make it to the next stage. To keep the playground area accessible and a bit organized, we have created a {{path|/tag/unmaintained/N}} (where 'N' is the KDE major version the application was written for; e.g. 4 for KDE4 applications). If you do not want to continue your application, move it to that place in the repository. If you do not know how, contact the current contactperson which is mentioned at the bottom of this document.
Consider suggesting to [[Gardening|KDE Gardening team]] to maintain it if there are still valid use cases.


Whenever an application has not received a commit for one complete year, you will be contacted via email to discuss if you want to continue the application or if it has died. In the latter case or when the email bounces, it will be moved to {{path|/tag/unmaintained/N/}}.
You can move your project in [https://cgit.kde.org/sysadmin/repo-metadata.git/ repo-metadata], see [https://cgit.kde.org/sysadmin/repo-metadata.git/tree/README.md repo-metadata README] or file a [http://sysadmin.kde.org/tickets Sysadmin ticket asking for the move]


=== Stage 2: Stable ===
Projects can move back to playground if they are picked up for maintenance again.
When you have made one of more releases and want to continue to develop it, the term 'playground' does no longer apply to you. That is the right time to move out of here. There are two options to move to: extragear and one of the KDE main modules. If you want to move to one of the KDE main modules, you will get released with KDE. That also means you have to respect that release schedule. The fact you want your program in KDE main modules is not enough and others have to agree is valuable to have it.
In extragear you are on your own. You make the releases whenever you want and you have to talk to the translators about your release schedule. In the future it might be possible to be released together with the KDE main modules. But at this moment this is not possible.


Whatever you choose, there are some rules to follow before you are allowed to move to either location:
= Translations =
* There should be user documentation in docbook format. If you need help, you can ask for help to the KDE Documentation team: [https://mail.kde.org/mailman/listinfo/kde-doc-english kde-doc-[email protected]].
All projects with user-visible strings must have translations.
* There should be developers documentation in the form of apidox for libraries you can check this at [http://www.englishbreakfastnetwork.org/ ebn]
* There should be no krazy code checker issues reported. Again, you can check that at [http://www.englishbreakfastnetwork.org/ ebn]. There is also a [[Development/Tutorials/Code_Checking|tutorial on using Krazy]] available here on TechBase.
* If possible, there should have been a basic usability review of your application. Usability people are hard to get, so this is not crucial.
* You should have checked for basic problems with a profiler. I hope we will get a tutorial on how to do this soon
* Your application should be [[Development/Tutorials/Localization/i18n|completely translatable]].  


When you decide you want to move to this second stage, move your application to {{path|/trunk/kdereview}} and announce the move on '''kde-core-[email protected]'''. In the announcement address the above issues and state where you want your application to move to (which KDE main module or extragear). Extragear only requires general approval on kde-core-devel. A main module requires approval from the community who manages that module (e.g. the kdepim module requires approval from the kdepim community).
Whenever moving projects between Git modules or when you make a new stable branch you must tell [https://mail.kde.org/mailman/listinfo/kde-i18n-doc kde-i18n-doc] mailing list to update the translation branches.


The move to kdereview starts a two week review period during which the community can object to your proposal or request additional changes. If there are no objections or requested changes after this two week period, you are allowed to move your application to the place you requested. If your intention is to move to a main module you must additionally get approval from the [[Projects/Release_Team#Module_Coordinators|module coordinator(s)]] who manage that module.
See [https://techbase.kde.org/Development/Tutorials/Localization/i18n i18n wiki pages].
 
If changes are requested, you can leave your application in kdereview while you are actively working on those issues. If you lack the time to work on the changes, move your application back to playground. Once the requested changes are completed, announce to kde-core-devel that you have completed the requested changes and wait for another week for objections.
 
Kdereview is only meant as a transitional place from playground to the main modules or extrager. In no case can kdereview be a permanent place to develop your application.
 
=== Stage 3: The end ===
Whenever you decide to stop developing the application and that leaves the application without developers, please announce that to kde-core-devel. If nobody stands up to take over maintainership within two weeks, the application has to be moved to the {{path|/trunk/unmaintained/N/}} area as every application in the KDE main modules and in extragear needs to have a maintainer to stay there.
 
=== Translations ===
For each move in subversion, the translation files of each language need to move as well. Because this requires a complete checkout of the l10n folder and some knowledge about the structure, you can ask the release-team ('''release-team@kde.org''') to move them. Send a simple mail with the information required to do the move, for example: 'move {{path|/playground/somewhere/someapp}} to {{path|/kdereview/someapp}}'.
If you want to help out with these kinds of moves, please send a mail! You are welcome to help out.
 
=== Contact ===
If you need any help regarding this, please contact Tom Albers ('''[email protected]''')
 
[[Category:Policies]]

Revision as of 12:34, 26 November 2019

KDE is a friendly community which hosts hundreds of projects. Any project which follows the KDE manifesto and KDE Vision is welcome to join us.

The term "application" is used here to mean any project hosted in KDE Git and includes programming libraries and development tools but not typically infrastructure tools or projects with other end product outputs.

playground

playground is a Git module for projects starting development

  • You will need a Git write account which needs a referral from another KDE contributor, see Get_a_Developer_Account
  • You will need to to ask sysadmin to create a module
  • Projects can start in scratch repos without asking for a repo, see Git KDE.org manual
  • Projects can make alpha releases and can put them on download.kde.org unstable
  • Projects can ask for translations for their master branch only

Incubator

Projects which started life outside of KDE are welcome to join us if you feel our community makes a good fit through the KDE Incubator. A sponsor will guide you through the process and check your project complies with the needs of the KDE community

kdereview

Projects move into kdereview when they are ready to start making beta or stable releases. It allows for the KDE community to check over for minimum standards.

  • You can move your project in repo-metadata, see repo-metadata README or file a Sysadmin ticket asking for the move
  • See the Sanity Checklist for some of the elements people will review
  • E-mail kde-core-devel and other relevant mailing lists with details of your project and what the expected destination is for the repo
  • Make fixes to issues people bring up or provide explanation why they are not (yet) fixed
  • Wait at least two weeks in kdereview
  • After two months in kdereview the repo should be moved back to playground or moved to unmaintained
  • See KDEReview page for current status of projects (feel free to help maintain this page and push reviews forwards)

Releasing

Your project is now active and can make beta or stable releases. Find the best home for your project based on contents and release process wanted.

  • After two weeks in kdereview you can move it in repo-metadata, file a Sysadmin ticket if unsure.
  • These projects should depend only on stable released software or software known it will get a stable release before the project does. It may use unstable or unreleased software only as an optional build dependency.
  • Add your project to automated builds:
  • KDE Frameworks are programmer libraries
  • Plasma is a cross device work environment where trust is put on the users' capacity to best define her own workflow and preferences.
    • It is typically released 3 times a year
    • Projects released as part of Plasma must fit well together and be a useful part of the user's work experience.
    • They would not be useful to users of other desktops.
    • Version numbers and stable branches are made by release person
    • Ask on plasma-devel for consideration of inclusion
  • release service
    • Released typically 3 times a year en-masse
    • Includes a range of libraries, applications and developer tools
    • External version numbers (projects often have their own internal version numbering scheme) and stable branches are made by release person
    • Ask release-team for inclusion
  • Self Released - Many projects take care of their own release process
    • Also called Extragear
    • They can use whatever version number scheme they want and can release in their own timeframe
    • Use releaseme to make releases, see Releasing Software

Unmaintained

If a project is no longer useful you can move it to unmaintained. It can move here from any stage in the lifecycle.

Consider suggesting to KDE Gardening team to maintain it if there are still valid use cases.

You can move your project in repo-metadata, see repo-metadata README or file a Sysadmin ticket asking for the move

Projects can move back to playground if they are picked up for maintenance again.

Translations

All projects with user-visible strings must have translations.

Whenever moving projects between Git modules or when you make a new stable branch you must tell kde-i18n-doc mailing list to update the translation branches.

See i18n wiki pages.