Hi MJ, MJ Ray a écrit :

As you know, I'm a statistician, so I hope koha-devel don't mind asking about a few of the release statistics:

Given the "does not include new features" comment, why were the enhancements included? (particularly bugs 988, 1578, 3081)

At the moment, enhancement on bugzilla is used for two purpose : - brand New and tough features - Not so severe bugs, but improve some readability or display, or feature in a way. those "enhancements" you tell about are of the second type.

Why were 15 PATCH-Sent rel_3_0 non-enhancement bug fixes available in bugs.koha.org not included? (bugs 1837, 2151, 2415, 2543, 2555, 2747, 2769, 2777, 2785, 2792, 2805, 2809, 2982, 3064, 3067, 3165, 3166, 3241, 3261)

Thanks for the list. I shall have to detail those in order to see if they have been pushed into master, and when, since they may already have been integrated in 3.0.1 see bug 2777 for instance which should be already integrated, or if they are 3.0 only and have been sent as such.

Working from bugs.koha.org reports generator, it seems 36 biblibre bugfixes were included in this release, but only 15 liblime ones and very few from the other development companies. The last 3 months of patch submissions to rel_3_0 bugs look like 37 biblibre, 25 liblime and 19 from other companies.

So in short, biblibre has almost 100% fix inclusion rate this release, liblime has 60% inclusion and the other companies were wasting their time submitting patches for 3.0.2. What steps can we take to rebalance whose patches get into release 3.0.3? What does the RM want to see from non-biblibre patch-senders that biblibre ones give?

...

The next release scheduled in July will include features which are now in master but not ported yet to stable [...]

Please can we make those new features available as contribs, rather than trying to introduce new features during a stable series?

In general, "new features" and "stable release" are contradictory ideas, unless those features come as side-effects of bugfixes. YES I agree that stable release SHOULD NOT, as a general rule take in new features. And NO, It is not possible, unless we make a new branch, to leave them as contribs. Considering that Liblime has worked on that branch as stable branch, we NEED a way to make reconciliation. And quite quick, since if we donot reconcile, then we will have a defacto fork to cope with when we come to testing 3.2 features. I feel that the above shows that there are still bugfixes to include. I suspect including new features in 3.0 will also make the 3.2 RM more difficult.

I have been discussing with Galen on that purpose and I donot think it would really harden his task to make reconciliation between 3.0 and 3.2. I think that it can make it easier on the contrary. Again, Master branch was considered as stable branch by LibLime, so we have to upgrade stable branch to master so that we can then have a clear path to feature integration. Thanks for those statistics. To explain my way to do : As a general rule, I cherry picked what was pushed in master. If only 60% LL bug fixes are integrated, it is because either I included a patch that took into the commit the bugfix for that, or the bug fixed was not a bug but an enhancement. BibLibre has only sent bug fixes or has not created bugs for enhancement. It was also for me quite easier to test whether BibLibre had all the patches integrated in the stable branch, since, I had access to the Biblibrarian stable branch so I could easily rebase one branch onto an other back and forth. I am quite sorry if you think I could be biased in integration. And I realise that interesting patches have not made their way into the release. So I apologize to you commiters that have not get your patch integrated although they are good for all. It is owed to the way I did the job. Surely, if I could have READ access to stable branches of ppl outside BibLibre and LL HEAD repository, the process would even be safer and clearer for any commiter. It would then require to be more cautious about conflicts, which I have made my best to be. But wouldnot it be a shame if the master repository would not benefit from those patches ? Since, if they are bug fix, then it may affect also master branch. On the other hand, koha-maintenance was exposed 2 weeks before the release was announced, and some testers have sent patches for it which made their way into the tree. If somebody had seen that his patch was not taken, and thought that it should be, simply resending the patch directly would have been a good reminder for me. I want here only to detail my process so that you can be fully aware of how things got done and since you spotted some problems which I cannot deny and acknowledge myself that these should be solved. Problem boils down to how to make sure that the patch sent to the list are processed at some point would they be rejected or pushed or squashed or applied then edited ? This has been my crux from the very beginning of my involvement in Koha git management. And even having direct read access to git branches would not be enough. Since it would not publicise the status of patches sent to the list. It could be a step forward though. Since we could then compare git trees, see which commits made their way in. If this solution suits you, then we could have a wiki page where we could add git web or git repositories to compare and rebase from those. Or I could also send some public key to ppl so that you could keep that repository private and still, allow me to add remote on it. If someone has a better suggestion, please speak aloud. -- Henri-Damien LAURENT BibLibre Release maintainer 3.0