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 35: | Line 35: | ||
==Why 2 releases per year== | ==Why 2 releases per year ? The limitation of FDK ? == | ||
The most important point we must think about when we decide the frequency of a release are the productivity of features we try to reach and the stability. | The most important point we must think about when we decide the frequency of a release are the productivity of features we try to reach and the stability. | ||
| Line 46: | Line 46: | ||
* Seen another way, for an identical result in terms of evolution in the same time, the workload for developers is multiplied by 2. | * Seen another way, for an identical result in terms of evolution in the same time, the workload for developers is multiplied by 2. | ||
* Or again, to an identical result in terms of evolution and an identical workload, the quality of stabilization is divided by 2 by releasing 2 times less often. | * Or again, to an identical result in terms of evolution and an identical workload, the quality of stabilization is divided by 2 by releasing 2 times less often. | ||
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 | 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 enhancement proposed (and which are integrated) is greater than the number of fixes or | However, today the number of enhancement proposed (and which are integrated) is greater than the number of fixes or stabilization (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 | In short, there is no under-staffing on the merge (in fact the workload when you know the app well is quite low) but we will always have an under-staffing 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 development phases to reduce technical debt for example). | ||
The merger can be replaced because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but a little mobilization compared to size of the project (2 half days per week). | The merger can be replaced because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but a little mobilization compared to size of the project (2 half days per week). | ||