Changes

Jump to: navigation, search

3.2 Roadmap

2,206 bytes added, 16:58, 27 February 2009
no edit summary
* end of March 2009: decision of the final 3.2 Roadmap (this document). Every main goal and database change needs at minimum one developer and one reviewer.
* June 2009: database changes finished and merged back in trunk
* November 2009: main goals finished (if started in another branch, it is merged back in trunk)
* Beginning of 2010: Release
Changes to the way developers handle the workflow. This will be decided by the core developers in the near future.
* Required A required minimum pylint score? of 9. This would require all present code to at least obtain this score?''Developer to write this policy:'' ?* Every main goal and database change needs at minimum one developer and one reviewer. We need to avoid situations as with 3.0/3.1 where large code changes where left only partially finished. If the developer drops out, the reviewer can or take over and fix things up, or revert the changes. If there are two developers then it suffices both are also reviewers.* svn branches for all large changes that requires multiple checking over a period of time during which the code will be broken (eg database changes and large refractoring). It is mainly up to the developers to do this or not, but this should make it clear how main goals? Can everybody with commit rights make changes can be added to the codebase without disrupting development of other people for a branch or only adminslong period (which should be avoided). See commands eg [http://matforge.org/fipy/browser/trunk/documentation/ADMINISTRATA.txt here]. ''Developer to write this policy:'' ? * Decision on the definition of the different parts of GRAMPS. What do we allow as plugins, views, gramplets, ... ? How do we offer the user a non-confusing image of what GRAMPS is? This starts in version 3.1 with not distributing some parts of GRAMPS that are present in the subversion repository. ''Developer to write this policy:'' bmcage* Decision on a tool for adding API documentation to GRAMPS source code. The aim would be to work out the infrastructure to make this possible, and guidelines to the GRAMPS developers. Note that GRAMPS contains some support already, but as since the last version nobody seems to bother this means the present guidelines are or not known, or the syntax not liked, or ... See [http://www.gramps-project.org/bugs/view.php?id=2691 feature request]. ''Developer to write this policy:'' ?
==Dependency upgrades==
For 3.2:
* change to PyGTK 2.12. Reason: Move away from libglade to GtkBuilder. Info: [http://www.micahcarrick.com/05-30-2008/gtk-builder-libglade-faq.html], example: [http://www.micahcarrick.com/01-01-2008/gtk-glade-tutorial-part-3.html]. ''Developers'': ? - ''Reviewers'': ?
* change to python 2.6. Reason: preparing for a move to python 3.0. For this we need the support that python 2.6 offers. That is, people should start to run GRAMPS with:
python -3 gramps.py
: which will print out depreciation warnings for all syntax that is not compatible with Python 3.0. The goal is then to clean up all Python 3.0 depreciation warnings using the new functionality that python 2.6 offers for this. There is no need to have this finished before 3.2 though. ''Developers'': All
==Database backend changes==
Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here. Database changes should be started in subversion branches if disruptive (see commands eg [http://matforge.org/fipy/browser/trunk/documentation/ADMINISTRATA.txt here]).
Suggestions:
==Main goals==
This section lists main goals developers want to achieve with GRAMPS 3.2. Main goals should be started in subversion branches if the user wants to collaborate or use version management (consider svn-git if needed) (see commands eg [http://matforge.org/fipy/browser/trunk/documentation/ADMINISTRATA.txt here])
* '''File Organization (GEPS 008)''': bug tracker:[http://www.gramps-project.org/bugs/view.php?id=2622]. ''Developers'': ? - ''Reviewers'': ?
==Minor goals==
This section lists minor goals developers want to achieve. Changes to plugins are normally minor goals !! Minor goals can be done by one developers alone.Partially finished 3.1 features might be completed in 3.2 and backported to a 3.1.x version if there is support for this in the communitity.  
* '''Fully functional GeoView''': bug tracker: TODO. GeoView has some way to go to be on the level needed to allow inclusion in GRAMPS. ''Developers'': ?
* '''Remove memory leaks present in glade loading code'''. bug tracker: [http://www.gramps-project.org/bugs/view.php?id=2616]- these changes might be backported to 3.1 depending on the code size. ''Developers'': ?

Navigation menu