Policies/Application Lifecycle: Difference between revisions

    From KDE TechBase
    (Contact blurb)
    (tidy ups, wikiification. tom rocks!)
    Line 7: Line 7:




    === First stage: the start. ===
    === Stage 1: The start ===
    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 /trunk/playground folder in the repository where everyone is free to commit his own application. You can request a SVN account at sysadmin and after that you can import your project in the subfolder of your choice.
    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 his own application. You can request a SVN account at sysadmin 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.
    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.
    Line 14: Line 14:
    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.  
    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.  


    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 /tag/unmaintained/[3|4]/ (/tags/unmaintained/3/ for KDE3 and /tags/unmaintained/4/ for KDE4 based 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.
    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.


    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 /tag/unmaintained/[3|4]/.
    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/}}.


    This also applies to the currently no longer used /trunk/kdenonbeta area.
    This also applies to the currently no longer used /trunk/kdenonbeta area.


    === Second stage: stable ===
    === Stage 2: Stable ===
    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.  
    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 there might it might be possibile to be released together with the KDE main modules. But at this moment this is not possible.
    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 there might it might be possibile 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:  
    Whatever you choose, there are some rules to follow before you are allowed to move to either location:  
    * there should be user documentation in the form a docbook
    * There should be user documentation in the form a docbook
    * there should be developers documentation in the form of apidox for librararies you can check this at [http://www.englishbreakfastnetwork.org/ ebn]
    * There should be developers documentation in the form of apidox for librararies you can check this at [http://www.englishbreakfastnetwork.org/ ebn]
    * there should be no krazy issues reported, again, you can check that 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.
    * 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
    * 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 completely translatable
    * Your application should be [[Development/Tutorials/Localization/i18n|completely translatable]].


    When you decide you want to move to this second stage, you move your application to /trunk/kdereview. Then you sent an announcement to '''[email protected]''' that you have done that, address above issues and make clear where you want to move to (which kde main module or extragear).Extragear only requires general approval on kde-core-devel, while going into, for instance, kdepim requires approval from the kdepim community who manage that module.
    When you decide you want to move to this second stage, you move your application to {{path|/trunk/kdereview}}. Then you sent an announcement to '''[email protected]''' that you have done that, address above issues and make clear where you want to move to (which kde main module or extragear). Extragear only requires general approval on kde-core-devel, while going into, for instance, kdepim requires approval from the kdepim community who manage that module.


    Then the two weeks review period starts. In those two weeks people can object to your proposal or request additional changes. When there are no objections after the two week period, you are allowed to move your application to the place you decided to go. If your intention is to move to a main module you must get approval from the module maintainer(s) who manages that module.
    Then the two weeks review period starts. In those two weeks people can object to your proposal or request additional changes. When there are no objections after the two week period, you are allowed to move your application to the place you decided to go. If your intention is to move to a main module you must get approval from the module maintainer(s) who manages that module.
    Line 40: Line 40:
    In no case kdereview can be a permanent place to develop your application.
    In no case kdereview can be a permanent place to develop your application.


    === Third stage: the end ===
    === 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 /trunk/unmaintained/[3|4]/ area as every application in the KDE main modules and in extragear needs to have a maintainer to stay there.
    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 ===
    === 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 David Faure ('''[email protected]''') or Tom Albers ('''[email protected]''') to move them. Send a simple mail with the information required to do the move, for example: 'move /playground/somewhere/someapp to /kdereview/someapp'.
    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 David Faure ('''[email protected]''') or Tom Albers ('''[email protected]''') 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.
    If you want to help out with these kinds of moves, please send a mail! You are welcome to help out.


    === Contact ===
    === Contact ===
    If you need any help regarding this, please contact Tom Albers ('''[email protected]''')
    If you need any help regarding this, please contact Tom Albers ('''[email protected]''')

    Revision as of 21:45, 6 March 2007

    When you want to start a new 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.

    In a diagram it all comes down to:



    Stage 1: The start

    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 /trunk/playground folder in the repository where everyone is free to commit his own application. You can request a SVN account at sysadmin 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.

    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.

    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 /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.

    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 /tag/unmaintained/N/.

    This also applies to the currently no longer used /trunk/kdenonbeta area.

    Stage 2: Stable

    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 there might it might be possibile 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:

    • There should be user documentation in the form a docbook
    • There should be developers documentation in the form of apidox for librararies you can check this at ebn
    • There should be no krazy code checker issues reported. Again, you can check that at ebn. There is also a 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 completely translatable.

    When you decide you want to move to this second stage, you move your application to /trunk/kdereview. Then you sent an announcement to [email protected] that you have done that, address above issues and make clear where you want to move to (which kde main module or extragear). Extragear only requires general approval on kde-core-devel, while going into, for instance, kdepim requires approval from the kdepim community who manage that module.

    Then the two weeks review period starts. In those two weeks people can object to your proposal or request additional changes. When there are no objections after the two week period, you are allowed to move your application to the place you decided to go. If your intention is to move to a main module you must get approval from the module maintainer(s) who manages that module.

    If there are changes requested, you can make them while in kdereview. But only as long as you are working on those issues. If you decide to let it rest for a month for example, you should move it back to playground. When the requested changes are completed, announce it again to kde-core-devel and wait for one week for objections.

    In no case kdereview can 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 /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 David Faure ([email protected]) or Tom Albers ([email protected]) to move them. Send a simple mail with the information required to do the move, for example: 'move /playground/somewhere/someapp to /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])