[Koha-devel] Koha-3.0.2 Stable release

[MJ Ray]

LAURENT Henri-Damien <henridamien at koha-fr.org> wrote:
> MJ Ray a écrit :
> > 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.

If *anyone* is using "enhancement" on bugzilla for cosmetic bugfixes,
please stop it. If you spot anyone using it like that, please point
out that improving some readability or display should be as type
"trivial" or "minor" depending on how unreadable it was before.

Please keep enhancement for enhancements, else it's very confusing and
hard to QA, as well as harder for people to use the new
sponsorship-tracking marking for new work. That meaning is written on
both bugs.koha.org and wiki.koha.org in their bug reporting help
pages.

> 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.

Thanks.  Tidying up like that would be helpful.  I only checked 3.0.2
because maybe some of them were integrated in 3.0.1 and regressed or
something like that - checking in detail needed more time than I had.

> >> The next release scheduled in July will include features which are now 
> >> in master but not ported yet to stable [...]
> >   
> > 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. [...]

It sounds like there are already defacto forks to cope with.  I'll be
working on merging my co-op's fork this summer, but I'm really
surprised that an RM has a private fork too.  If 3.0 is going unstable
again, then I'll have to continue our fork because I don't want to
expose our customers to that.  Forking is no fun and takes a lot of
time which could be better spent on other koha work, so this saddens
me greatly.

I don't really understand "Liblime has worked on that branch as stable
branch" - what happened?

> 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. [...]

To be clear, I don't think any bias is intentional or deliberate.  I
think it just happened.  It's not really surprising, because people
who work together tend to work in more similar ways.  I feel it would
help the project to address and minimise it as much as we can.  If
someone's a RM, they get first suggestion rights on how to do that, I
think.  If they don't care, we can probably invent something.

> 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.

Yes, it would have been good, but how much should we expect to manage
the release manager?  I'm not sure if koha-maintenance was announced,
or if the impending release was announced, so it's not obvious whether
a patch was not taken, or just not taken yet.

Other than a few, I doubt the bugs were that serious, but I think it
would be good to pick this "low hanging fruit" in a release.

[...]
> 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.

Personally, I feel the way to make sure is to regard the bug tracker
as the primary source.  The list is a nice feed of updates and great
for eyeballs, but it's rather a tsunami of code that seems a bit
overwhelming for RMs and hard to manage.  Opening git trees is also
possible, but there's some stuff in my stable tree which isn't ready
for upstream IMO - the subset emailed and put in the bug tracker is
safer.

How do others want to track bugfixes?

Hope that helps,
-- 
MJ Ray (slef).  LMS developer and supporter for a small, friendly
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237