Difference between revisions of "User:Usul/DevelopmentNG"

From Navit's Wiki
Jump to: navigation, search
(code review)
 
(2 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
==general==
 
==general==
If you look at [[user:Usul/Disburden cp15]], it's recommend to modularize our dev workflow as well.
+
If you look at [[user:Usul/Disburden cp15]], it's recommend to modularize our dev workflow as well. Please keep in mind, that this will be a process of months/years and not weeks!
 
*be indipendend from providers ->self hosted
 
*be indipendend from providers ->self hosted
 
*be able to replace single components without needing to switch everything -> single components
 
*be able to replace single components without needing to switch everything -> single components
Line 13: Line 13:
 
*GIT very popular, widely supported
 
*GIT very popular, widely supported
 
*git-flow enables easy seperation into 5 streams (stable, dev, feature, hotfix)
 
*git-flow enables easy seperation into 5 streams (stable, dev, feature, hotfix)
 
==build server==
 
Currently we use our own solution http://download.navit-project.org
 
*package building
 
*no support for multiple dev flows
 
*no triggering for post actions (tests, benchmarking, ...)
 
**ctest
 
  
 
==translating==
 
==translating==
Line 26: Line 19:
  
 
==code review==
 
==code review==
 +
We need to review code before submitting it to our mainline dev branch. This ensures that formating, coding style and docs relect our standards and that it will be possible to build the branch
 
*normalize code quality before merging to mainline
 
*normalize code quality before merging to mainline
 
*minimize load for the reviewer (make it confortable, fast communication, ...)
 
*minimize load for the reviewer (make it confortable, fast communication, ...)
 +
*[http://code.google.com/p/gerrit/ Gerrit]
 +
*[http://gitlab.org/ GITlab]
 +
*[http://phabricator.org Phabricator]
  
 
==issue tracking==
 
==issue tracking==
Line 33: Line 30:
 
*trac itself isn't very intuitive, focused  
 
*trac itself isn't very intuitive, focused  
 
**roadmap planing isn't well embedded
 
**roadmap planing isn't well embedded
 +
 +
==build server==
 +
Currently we use our own solution http://download.navit-project.org
 +
*package building
 +
*no support for multiple dev flows
 +
*no triggering for post actions (tests, benchmarking, ...)
 +
**ctest
  
 
[[Category:Development]]
 
[[Category:Development]]
 
[[Category:Community]]
 
[[Category:Community]]
 
[[Category:Ideas]]
 
[[Category:Ideas]]

Latest revision as of 08:27, 7 June 2013

Navit dev process.svg

general[edit]

If you look at user:Usul/Disburden cp15, it's recommend to modularize our dev workflow as well. Please keep in mind, that this will be a process of months/years and not weeks!

  • be indipendend from providers ->self hosted
  • be able to replace single components without needing to switch everything -> single components
    • sf.net is currently exactly the opposite (people expect we use the internal bugtracker, mailinglist, ... there, even if we currently use only the SVN)
  • but portals enable the components to work closely together
  • Components should offer PostgreSQL backend, SSO via custom OpenID (our wiki)

VCS[edit]

  • use a DVCS -> offline commits, support staging, allow sharing unstable code
  • GIT very popular, widely supported
  • git-flow enables easy seperation into 5 streams (stable, dev, feature, hotfix)

translating[edit]

  • is it only on translating, or does I18n cover here further resources?
  • Translatewiki has already some OSM context

code review[edit]

We need to review code before submitting it to our mainline dev branch. This ensures that formating, coding style and docs relect our standards and that it will be possible to build the branch

  • normalize code quality before merging to mainline
  • minimize load for the reviewer (make it confortable, fast communication, ...)
  • Gerrit
  • GITlab
  • Phabricator

issue tracking[edit]

  • our trac is spammend and unamanage
  • trac itself isn't very intuitive, focused
    • roadmap planing isn't well embedded

build server[edit]

Currently we use our own solution http://download.navit-project.org

  • package building
  • no support for multiple dev flows
  • no triggering for post actions (tests, benchmarking, ...)
    • ctest