Changes

Jump to: navigation, search

3.2 Roadmap

3,489 bytes added, 04:03, 13 December 2009
pylint policy is complete
[[Category:Developers/General]][[Category:Developers/Roadmap]]
 
This page collects possibilities for the 3.2 version of GRAMPS
Changes to the way developers handle the workflow. This will be decided by the core developers in the near future.
* A required minimum pylint score of 9. This would require all present code to at least obtain this score? ''Developer to write this policy:'' ?Brian M.** ''Status: done ([[Developer_Policies#Coding_style]])''
* 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 changes can be added to the codebase without disrupting development of other people for a long 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. First scribles: [[GEPS 012: Ecosystem_definition]]
* 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:'' ?
* Developers must follow guidelines described in [[Howto: Contribute to GRAMPS]]
==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 keep python 2.65 compatibility, while preparing for python 3.x. Reason: preparing for a At the moment there are no features of the 2.6/7 versionGRAMPS needs that require python 2.5 support to be dropped. Version3.2 will however be the last GRAMPS version on python 2.x, with thenext version of GRAMPS (3.3) being python 3.x only. For that reason,the move to python 3.0needs to be prepared. 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, while still providing fallback for python2.5 (usingeg __future__ module and try, except blocks).Should somebody come forward with an important improvement thatrequires python2.6, or if removing the warnings of python -3 isimpossible with backward python2.5 compatibility present, keepingpython2.5 compatibility can be dropped after talking it through on thedevel list. In other words, support for python2.5 should not bedropped without giving it a try first. ''Developers'': All* it appears there is a drive to use enchant for spell checking. There The API is no need better than gtkspell and has a python interface. We should investigate if we should not move entirely to have this finished before 3package and deprecate gtkspell. At a minimum we will look into adding enchant as a possible spell checking backend to GRAMPS, using it when installed.2 thoughPackagers could then choose to let GRAMPS depend on enchant or gtkspell (part of gnome-extras now). ''Developers'': AllBenny, ''Status'': enchant is working
==Database backend changes==
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]. Although this goal is disruptive it will be done in trunk due to its inherent nature. ''Developers'': ? Brian M. - ''Reviewers'': ?
* '''Import Export Merge (GEPS 009)''': bug tracker:[http://www.gramps-project.org/bugs/view.php?id=2623]. ''Developers'': ? - ''Reviewers'': ?
* '''Beter API documentation''': bug tracker:[http://www.gramps-project.org/bugs/view.php?id=2691]. ''Developers'': ? - ''Reviewers'': ?- ''Status'': Sphinx with RestructuredText is chosen, see [http://www.gramps-project.org/docs]* '''rework PageView classes''': bug tracker: TODO[http://www.gramps-project.org/bugs/view.php?id=3275]. Aim would be to split PageView and classes to it's own subdirectory, allow views to be plugins, have PersonView derive from the same classes as the other views instead of a custom class, have history in all listviews (as it was intended originally, code is half finished now), allow organized views in source/place like in present person view. ''Developers'': bmcage , nick hall - ''Reviewers'': ?, ''Status'': Integration* '''Class and method naming''': bug tracker: TODO. Class and method names in Gramps do not follow object oriented conventions. Class names should be nouns and method names should be verbs. ''Developers'': gburto01 - ''Reviewers'': Brian M.* '''Registering of plugins (GEPS 014)''': bug tracker: [http://www.gramps-project.org/bugs/view.php?id=3292], Plugins should not load on startup but when needed. This reduces start up time, but more importantly makes a CLI gramps more lean. ''Developers'': bmcage, doug, ''Satus'': Finished* '''Clever database connect of GUI''': bug tracker: [http://www.gramps-project.org/bugs/view.php?id=1277] GUI must update or close itself when change to db happens outside it's control. A generic signal management object should be made that GUI can build upon. ''Developers'': bmcage - ''Status'': Finished* '''Third-Party Plugin Reorganization (GEPS 005)''' - due to changes in the plugin subsystem, third-party add-ons need to be revised. This involves a New Plugin Manager for getting new plugins (new tab in plugin dialog?), a new SVN repository, and version numbering. See [[GEPS 005: Enhanced Plugin Interface]] ''Developers'': Doug B. ''Status'': under development.
==Minor goals==
* '''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'': gburto01
* '''GEDCOM import error/warnings report'''. bug tracker: todo - provide a report of GEDCOM errors and warnings after import to show the user what information has not been imported. ''Developers'': gburto01
* '''New HTML output of reports'''. bug tracker: todo - deprecate html templates and move to the new backend structure constructed for markup notes and pdf/cairo output, based on libhtml. At the same time this brings markup notes to html output. ''Developers'': bmcage ''Status'': finished
* '''Markup notes in narrated web and ODF'''. ''Developers'': Rob, Serge, ''Status'': finished
* '''First version of Gramps on-line webapp''': A multi-user, collaboration-focused version of Gramps. Based on Django Python web framework tools. See [[GEPS 013: GRAMPS Webapp]]. ''Developers'': Doug B. and Kathy M.
* '''Rewrite of Configure subsystem and .ini file format''': Old system was derived from gconf, and was unnecessarily complicated. New system is straightforward and more flexible. ''Developers'': Doug B. ''Status'': complete, but still being revised.
54
edits

Navigation menu