[Koha-devel] Koha-3.0.2 Stable release

[LAURENT Henri-Damien]

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