31,029
edits
Category:RoadMap: Difference between revisions
Jump to navigation
Jump to search
m
→Roadmap calendar
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 32: | Line 32: | ||
*etc... | *etc... | ||
</div> | </div> | ||
Why 2 releases per year : | |||
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 (called Pull Requests) and the stability. | |||
Let's have a look a this point: | |||
Dolibarr has a PR (Pull Request) integration rate of 95% today (PR processed vs PR suggested by developers). Hoping to have more merged PRs (so more features), and therefore to have a rate of 98% for example is clearly utopian especially when we know that the merge rate is rather 50% on other projects of equivalent size (example Odoo: 30%, but 85 % for ERPNext, measured in 2022). | |||
So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase which is necessary to “digest” a Pull Request for evolution. This time and workload to stabilize integrated developments is exponential with the number of integrated PRs, thus: | |||
* If we release 2 times less often (so 1 every year), the time and efforts to “stabilize” is multiplied by 4. | |||
* Seen another way, for an identical result in terms of evolution, the workload 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. | |||
Today the integration of new PRs is currently deliberately slowed down 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 developments 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). | |||
A merger can replace himself because it is a task that requires strong technical knowledge, history and anticipatory vision of course, but little mobilization. | |||
On the other hand, where the project is at risk is the lack of FDK (because it relies on a smaller team and it is an activity which requires a large investment of work). This is where the “bus factor” is located on a community project: on the FDK (I’ll let you see the definition of Bus Factor on Wikipedia). The idea of releasing more often (reminder: making a version stable is exponential to the amount of evolution of this version) is the solution taken by many projects to make stabilization easier, to the point of pushing the system into "rolling" release, monthly, or weekly by some. | |||
For Dolibarr, a monthly or even quarterly pace is unfortunately too fast because it is necessary to give the community time to analyze and comment on each PR due to the community mode of the project (which is not done in an unconstrained scheduled proprietary projet). | |||
In short, if you have ideas for increasing the number of “FDKs”, or encouraging actors to convert from business developers to FDKs, it is welcome, because this is the bottleneck and where the project is at risk (the problem is that business developer sells their production to customers so we have a large amount of such contributions, but not the FDKs). If we find a “trick” to motivate actors to take on this role in support of the handful of existing FDKs, Dolibarr project will be taken on another dimension… | |||
=Branch and Source control management= | =Branch and Source control management= | ||