Difference between revisions of "5.1 Roadmap"
(→Pull requests for significant changes) |
(→Schedule) |
||
(9 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
+ | {{man note|This is a guide only.|Because of the nature of a volunteer-driven project, it isn't possible to say with any certainty what will happen in the next release.}} | ||
+ | |||
This page collects possibilities for the 5.1 version of Gramps | This page collects possibilities for the 5.1 version of Gramps | ||
Line 12: | Line 14: | ||
| 01 Jun 2019 || String freeze. | | 01 Jun 2019 || String freeze. | ||
|- | |- | ||
− | | | + | | ?? Jun 2019 || Final release. |
|- | |- | ||
|} | |} | ||
Line 30: | Line 32: | ||
* https://opensource.guide/leadership-and-governance | * https://opensource.guide/leadership-and-governance | ||
− | + | ====Decision:==== | |
We will continue with the benevolent dictator model. The Architect will define the project's strategic direction and have the final say in decisions. However, if a contributor regards a decision as unfair or contrary to the projects goals, an appeal can be made to the Administrator. | We will continue with the benevolent dictator model. The Architect will define the project's strategic direction and have the final say in decisions. However, if a contributor regards a decision as unfair or contrary to the projects goals, an appeal can be made to the Administrator. | ||
Line 47: | Line 49: | ||
When should they be merged? | When should they be merged? | ||
− | + | ====Decision:==== | |
We will continue with the current process and also extend it to the addons-source repository. | We will continue with the current process and also extend it to the addons-source repository. | ||
Line 66: | Line 68: | ||
How long should a PR remain open for reviews, comments and testing before merging? | How long should a PR remain open for reviews, comments and testing before merging? | ||
− | + | ====Decision:==== | |
Almost all changes should now be made through pull requests. The following are exceptions: | Almost all changes should now be made through pull requests. The following are exceptions: | ||
Line 87: | Line 89: | ||
==Database model changes== | ==Database model changes== | ||
Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here. | Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Major goals== | ==Major goals== | ||
This section lists main goals developers want to achieve. Major goals should be started in a GEPS branch. Major goals require a developer and a reviewer. | This section lists main goals developers want to achieve. Major goals should be started in a GEPS branch. Major goals require a developer and a reviewer. | ||
− | * | + | * ✔ '''[[GEPS 044: Replace Deprecated Gtk.UIManager|GEPS044]] Rewrite UIManager code to avoid using deprecated methods''' |
− | |||
− | |||
− | |||
==Minor goals== | ==Minor goals== | ||
Line 122: | Line 100: | ||
Suggestions: | Suggestions: | ||
− | * | + | * ✔ Change default database backend to SQLite for all users [https://sourceforge.net/p/gramps/mailman/message/36148493/][https://github.com/gramps-project/gramps/pull/827 PR#827] |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Rejected | + | ==Rejected Changes== |
* '''Add citations and attributes to notes''' Sources on notes previously rejected. [https://sourceforge.net/p/gramps/mailman/message/28754193/] | * '''Add citations and attributes to notes''' Sources on notes previously rejected. [https://sourceforge.net/p/gramps/mailman/message/28754193/] |
Latest revision as of 00:17, 16 June 2019
This is a guide only. Because of the nature of a volunteer-driven project, it isn't possible to say with any certainty what will happen in the next release. |
This page collects possibilities for the 5.1 version of Gramps
Contents
Schedule
31 Dec 2018 | Agree final roadmap (this document). |
15 Apr 2019 | All major features should be merged into master. |
15 May 2019 | Feature freeze. |
01 Jun 2019 | String freeze. |
?? Jun 2019 | Final release. |
Policy changes
Project governance
At present, we use a benevolent dictator model. The BD defines the project's strategic direction and has the final say in decisions. Do we wish to change this?
Do we want to introduce a voting process for significant changes? If so, who gets a vote?
Perhaps we should introduce a committee to make decisions?
The following web pages are worth reading:
- http://oss-watch.ac.uk/resources/governancemodels
- https://opensource.guide/leadership-and-governance
Decision:
We will continue with the benevolent dictator model. The Architect will define the project's strategic direction and have the final say in decisions. However, if a contributor regards a decision as unfair or contrary to the projects goals, an appeal can be made to the Administrator.
The current Architect and Administrator are listed on the wiki Team page:
Procedures for branch merging
Currently the core gramps50 branch is occasionally merged into master. This process seems to have been a success, but we need to review it.
Do we want to extend it to the addons repositories?
Who should merge the branches?
When should they be merged?
Decision:
We will continue with the current process and also extend it to the addons-source repository.
Branches should be merged before they diverge significantly, but no exact timing was agreed.
Paul Culley will co-ordinate this task. Other developers are more than welcome to help out.
Pull requests for significant changes
Always using pull requests for most changes has been proposed previously and rejected [1], but we can discuss it again.
What changes should require a pull request?
Who should be allowed to merge a PR?
Should the submitter be allowed to merge the PR?
How long should a PR remain open for reviews, comments and testing before merging?
Decision:
Almost all changes should now be made through pull requests. The following are exceptions:
- Making a release
- Branch merging
- Updates to translations
- Updates in release directories
- Emergency fixes
Bug fixes in maintenance branches should be left open for at least 7 days for comments. After that, if no objections have been raised, any developer is allowed to merge the PR including the author. The developer merging the PR should test it first. Code reviews are encouraged. Any contributor can easier express approval or concern by reacting to the initial comment with either a thumbs-up or thumbs-down emoji.
New features in the master branch should be left open for at least 14 days for comments.
Dependency upgrades
- Python 3.5.x[2] (as 3.3.x reached end of life status on 2017-09-29.)
- Gtk 3.12.x EmailIt looks like we should just move from 3.10 to 3.12 then. Nick. (3.10.x reached end of life status on 2014-05-12.)
Database model changes
Are there features that require database change? This should happen in the beginning of the development cycle. List your requirements here.
Major goals
This section lists main goals developers want to achieve. Major goals should be started in a GEPS branch. Major goals require a developer and a reviewer.
- ✔ GEPS044 Rewrite UIManager code to avoid using deprecated methods
Minor goals
This section lists minor goals developers want to achieve. Minor goals can be done by one developer alone.
Suggestions: