31,029
edits
Category:RoadMap: Difference between revisions
Jump to navigation
Jump to search
m
→Why 2 releases per year
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 47: | Line 47: | ||
Today the integration of new PRs is currently deliberately slowed down (this does not prevent Dolibarr from being one of the opensource projects with a highest pace of integrated PR), in order to be able to digest the integrated PRs. Indeed, the bottleneck is mainly in the number of contributors who “correct and stabilize” the integrated PRs. Let's recall the figures, evaluated during a former devcamp: On Dolibarr, for 1 PR of integrated evolution, you need to obtain approximately 2 PR of stabilization fix (2022 evaluation made on Odoo: 2.5, on erpnext: 7). | Today the integration of new PRs is currently deliberately slowed down (this does not prevent Dolibarr from being one of the opensource projects with a highest pace of integrated PR), in order to be able to digest the integrated PRs. Indeed, the bottleneck is mainly in the number of contributors who “correct and stabilize” the integrated PRs. Let's recall the figures, evaluated during a former devcamp: On Dolibarr, for 1 PR of integrated evolution, you need to obtain approximately 2 PR of stabilization fix (2022 evaluation made on Odoo: 2.5, on erpnext: 7). | ||
However, today the number of | However, today the number of enhancement proposed (and which are integrated) is greater than the number of fixes or stabilizations (standardization, security, etc.) proposed while it should be 1 PR out of 3 only to be at the balance (3 = 1 for feature + 2 for stabilization). | ||
In short, there is no understaffing on the merge (in fact the workload when you know the app well is quite low) but we will always have an understaffing on the '''Fixers''', '''Debuggers''' and '''Technical Debt Killers''' that I would call with the initials, the "'''FDK'''s" for the following (FDKs are those who work, mainly during a beta phase, to make the application stable and/or coherent, correct regressions, but also during the dev phases to reduce technical debt for example). | In short, there is no understaffing on the merge (in fact the workload when you know the app well is quite low) but we will always have an understaffing on the '''Fixers''', '''Debuggers''' and '''Technical Debt Killers''' that I would call with the initials, the "'''FDK'''s" for the following (FDKs are those who work, mainly during a beta phase, to make the application stable and/or coherent, correct regressions, but also during the dev phases to reduce technical debt for example). | ||