31,028
edits
Tag: 2017 source edit |
Tag: 2017 source edit |
||
| Line 42: | Line 42: | ||
Let's have a look a this point: | Let's have a look a this point: | ||
Dolibarr has an integration rate to integrate modifications of code (we call this "'''Pull Requests'''" or "'''PR'''") of around 95% (Calculation done from PR processed vs PR suggested by developers on GitHub). 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 between 30 and 85% on other projects of equivalent size (Odoo: 30%, ERPNext 85%, measured in 2022, so after 20 years of existence). | Dolibarr has an integration rate to integrate modifications of code (we call this "'''Pull Requests'''" or "'''PR'''") of around 95% (Calculation done from PR processed vs PR suggested by developers on GitHub). 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 between 30% and 85% on other projects of equivalent size (Odoo: 30%, ERPNext 85%, measured in 2022, so after 20 years of existence). | ||
So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase that 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: | So what is blocking the integration of more features today is the instability that each feature merge generates, and the stabilization phase that 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: | ||