14:00:50 <ashimema> #startmeeting Development IRC meeting 29 January 2020
14:00:50 <huginn> Meeting started Wed Jan 29 14:00:50 2020 UTC.  The chair is ashimema. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:50 <huginn> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:50 <huginn> The meeting name has been set to 'development_irc_meeting_29_january_2020'
14:00:57 <ashimema> #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_29_January_2020 Agenda
14:01:03 <ashimema> #topic Introductions
14:01:12 <ashimema> #info please use "#info" in front of your introduction to have it show up in the automatic minutes
14:01:13 <oleonard> #info Owen Leonard, Athens County Public Libraries, Ohio, USA
14:01:22 <marcelr> #info Marcel de Rooy Rijksmuseum
14:01:26 <ashimema> #info Martin Renvoize, PTFS Europe
14:02:09 <thd> #info Thomas Dukleth, Agogme, New York City
14:02:26 <Joubu> #info Jonathan Druart
14:02:35 <Joubu> qa_team?
14:02:35 <wahanui> i guess qa_team is cait Joubu marcelr kohaputti josef_moravec tcohen kidclamp khall
14:02:39 <Joubu> rmaints?
14:02:39 <wahanui> i guess rmaints is talljoy, lucas, hayley
14:02:53 <tcohen> #info Tomas Cohen Arazi, Theke Solutions
14:02:54 <kidclamp> #info Nick Clemens, ByWater Solutions
14:02:56 <kohaputti> #info Joonas Kylmälä
14:03:38 <cait> oh
14:03:39 <cait> sorry
14:03:44 <cait> #info Katrin Fischer, BSZ, Germany
14:04:49 <ashimema> Moving along..
14:04:59 <ashimema> #topic Announcements
14:05:28 <ashimema> We need to reschedule the GBSD day as I ran out of time to organise it :(
14:06:06 <cait> don't beat yourself up, let's set a new date
14:06:08 <ashimema> any volunteers to throw a wiki page together and send out a mail to organise one?
14:06:17 <cait> marseille is coming up end of march, some time before that would be nice
14:06:57 <ashimema> how much warning do people actually need.. 1 week, 2 weeks enough?
14:07:17 <ashimema> thinking next thurs/fri or the following week if we want to give more notice
14:07:18 <cait> 2 weeks might be enough
14:07:33 <kohaputti> 2 weeks to maximise amount of participants
14:07:58 <cait> clear your schedule at work :)
14:08:06 <fridolin> good morning all
14:08:27 <ashimema> how about 13/14th Feb then?
14:08:28 <fridolin> just to say that I will be less on Koha for 3 month
14:08:45 <fridolin> good luck to you, long live the community
14:08:59 * fridolin is flying next week to Madagascar
14:08:59 <kohaputti> 14th sounds nice
14:09:12 <fridolin> see you on WattsApp
14:09:25 <oleonard> Send lots of photos fridolin!
14:09:31 <ashimema> +1
14:09:39 <Joubu> Enjoy fridolin :)
14:09:54 <Joubu> 13/14 ok for me as well
14:10:04 <fridolin> I will ;) and he will learn Perl programming with math and french ;)
14:10:14 <cait> fridolin: save travels and all the best
14:10:39 <ashimema> ok.. lets organise GBSD for the 14th
14:10:56 <ashimema> #info GBSD rescheduled for the 14th February
14:11:31 <ashimema> #info Fridolin will be taking a break from Koha for a few months. He wishes us all the best and will be back :)
14:11:52 <ashimema> #topic Update from the RM
14:12:54 <ashimema> #info The master branch is moving along nicely at the moment with lots having been pushed over the past couple of weeks.  Thanks go out the QA team who are diligently working through bugs.
14:13:37 <ashimema> #info I am paying close attention to some of the refactoring bugs that are currently making their way through SO/QA and I look forward to pushing them soon.
14:13:43 <ashimema> #topic Updates from the RMaints
14:13:50 <ashimema> rmaints?
14:13:51 <wahanui> it has been said that rmaints is talljoy, lucas, hayley
14:13:54 <ashimema> do we have any here today?
14:15:30 <kidclamp> i think early for most of them :-)
14:15:44 <ashimema> fair enough..
14:16:43 <ashimema> #info 19.11.02, 19.05.07 and 18.11.13 were all released since the last meeting
14:17:29 <ashimema> #topic Updates from the QA team
14:17:30 <ashimema> cait
14:17:56 <cait> not much more to say than ashimema did already
14:18:16 <cait> #info Queues are super full - please all balance your patch writing with sign-offs and QA a bit more!
14:18:34 <cait> we are almost touching 100 in Needs QA atm
14:18:44 <cait> and the hackfest is coming closer...
14:19:07 <kohaputti> cait, on the good side most of those 100 are features and not bugs
14:19:22 <ashimema> indeed
14:19:26 <Joubu> [or write bugfixes]
14:19:34 <cait> #info Stilll over 100 major and critical  - we need people working on those, retesting, confirming, fixing etc.
14:19:47 <marcelr> this number is not saying that much
14:19:54 <marcelr> includes failed qa etc
14:19:55 <ashimema> though there are 5 majors in the queue.. I'm sure we should be able to knock them off
14:20:09 <cait> yep, but maybe failed qa needs work too? :)
14:20:15 <cait> not only adressing the QA team here, i should say
14:20:22 <marcelr> in that list they make me ignore the number
14:20:28 <cait> testing/confirming can be done by anyone especially
14:20:43 <ashimema> indeed
14:20:57 <kohaputti> could we recruit more qa?
14:21:03 <cait> kohaputti: always keen to
14:21:21 <cait> i think adding someone would not require much... finding the volunteers is the hard bit :)
14:21:22 <Joubu> we are more lacking testers than QA I'd say
14:21:29 <marcelr> kohaputti: thats not always the answer
14:21:40 <cait> we need both i'd say
14:21:42 <marcelr> you need good people
14:22:00 <cait> i am just highlighting a development here - the numbers are much higher which usually indicates longer waiting times too
14:22:54 <cait> we had QA around 30 pretty constantly a while ago - but in general bug activity is quite high right now (which is good :) )
14:23:10 <cait> anyway, I think i shoudl stop here :)
14:23:17 <marcelr> 30 is pretty low btw
14:23:30 <cait> yeah, that was a good number, harder to get lower
14:24:12 <ashimema> It would be nice to add one or two more to the team for next cycle.. so keep a look out for people who you think may be capable and willing..
14:24:45 <ashimema> qa team tends to be 'by invite', though if someone wants to volunteer out of the blue it all goes to a vote anyways so we can assess
14:25:17 <cait> it's not formally by invite... it just happeens people seem to need a bit of a push
14:25:19 <ashimema> we have a few great people doing signoff lots at the moment.. David Nind, and Andrew Fuerste-Henry have been storming ahead on that front..
14:25:27 <ashimema> indeed
14:25:32 <cait> yeah davidnind++ again :)
14:25:39 <cait> andrew too, but not here i think
14:26:21 <ashimema> but existing members of the team shouldn't be backwards in coming forwards if you feel there's someone out there who would be a good addition
14:26:29 <ashimema> gamification.. remember the leader boards https://dashboard.koha-community.org/
14:26:33 <marcelr> if you remove active signoffers, you have a problem at the other queue
14:26:41 <cait> it's true
14:26:48 <ashimema> very true
14:26:58 <cait> but qa can still signoff
14:26:58 * oleonard agrees that signoffs have been more needed than QA lately
14:27:04 <cait> so we can balance that
14:27:42 <ashimema> ok.. moving on
14:27:45 <ashimema> #topic General development discussion
14:27:59 <ashimema> We didn't get through all the votes last meeting
14:28:14 <cait> it was a lot at once... and acq
14:28:56 <ashimema> #topic RFC /subscriptions endpoint
14:29:11 <ashimema> #link https://wiki.koha-community.org/wiki/Subscriptions_endpoint_RFC /subscriptions
14:29:29 <marcelr> noting that it wasnt on the agenda?
14:30:02 <ashimema> #info There are stll allot of blanks in the mappings table, so rather than vote this week I suggest we all try to find time to take a look at it before the next meeting and help fill in those fields.
14:30:45 <ashimema> I cloned them accross from last meetings agenda just as the meeting started marcelr
14:31:09 <thd> unfinished business from the previous meeting
14:31:11 <ashimema> #topic RFC /suggestions endpoint
14:32:31 <ashimema> er..
14:32:42 <ashimema> whats the difference between suggestion_date and date_created?
14:35:09 <ashimema> all very quiet
14:35:23 <marcelr> suggestion_date is rather vague
14:35:32 <marcelr> especially if it gets updated or so
14:35:47 <kohaputti> date contains timestamp
14:36:07 <kohaputti> it is the last time the suggestion row was updated
14:36:23 <Joubu> 3041   `date` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,  -- date and time the suggestion was updated
14:36:33 <kohaputti> so date_created is a really bad name
14:36:34 <Joubu> 3028   `suggesteddate` date NOT NULL, -- date the suggestion was submitted
14:36:45 <kohaputti> date_updated would be better
14:36:53 <ashimema> so it's not 'date_created' at all
14:36:54 <Joubu> date => updated_on
14:37:01 <ashimema> agreed
14:37:41 <thd> date_created as opposed to creation_date is inconsistent with other dates as something_date .  We should either have date_something or something_date if it is easy enough to be consistent.
14:38:15 <kohaputti> Joubu, updated_on is used elsewhere?
14:38:34 <kohaputti> just checked
14:38:45 <kohaputti> it is used on other endpoints, so let's use updated_on here also
14:38:55 <marcelr> created_on and updated_on are used
14:39:00 <Joubu> it was not a suggestion, just saying what it does
14:39:04 <ashimema> we discussed the date vs date last meeting.. I think we came to the conclusion we should try to be consistently *_date
14:39:15 <Joubu> in the rest api we use *_date
14:39:27 <cait> sorry had to step out for a sec
14:39:28 <thd> Yes.
14:39:36 <marcelr> updated_date is not so nice btw
14:40:08 <cait> ashimema: not against people checking - but I tried my best to fill blanks
14:40:25 <kohaputti> we have the patrons endpoint using updated_on
14:40:25 <thd> update_date may be nicer for that case.
14:40:28 <Joubu> it should be 'timestamp' I think
14:40:37 <kohaputti> Joubu, timestamp of what
14:40:42 <kohaputti> Joubu, not clear for me
14:40:43 <cait> for suggestions (sorry, slow reading back)
14:40:52 <ashimema> we have `updated_by` and `updated_on` in a few places elsewhere in the API.. so that seems sane enough to me
14:40:53 <Joubu> item already has "timestamp"
14:41:26 <cait> but it's not hte same is it?
14:41:30 <cait> date created and updated?
14:42:14 <kohaputti> cait, it is not the same
14:42:16 <ashimema> ack.. we do indeed also have 'timestamp' in a bunch of places
14:42:31 <Joubu> 883   `timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, -- date and time this item was last altered
14:42:35 <Joubu> it's exactly the same
14:42:40 <thd> The fact that it has been previously done in some way does not mean that we should be stuck with what we did previously.  We may want to revisit previous usage for consistency on a reasonable principle.
14:42:49 <ashimema> I don't like 'timestamp' on it's own as it's not clear whether it's an initial create or an update that's being recorded
14:43:13 <cait> if it#s both
14:43:21 <cait> timestamp seems not so bad
14:43:21 <marcelr> does _date also mean datetime ?
14:43:30 <cait> we have places where update/create are 2 things
14:43:32 <marcelr> or do we differentiate that?
14:44:35 <cait> good question
14:44:41 <cait> i think we have not been cehcking all the others so far
14:44:53 * ashimema thinks we should really always store timestamp and then reduce to date only if/when we want to..
14:45:19 <ashimema> we really need to add some guidlines for these rather than voting on them per endpoint
14:45:58 <cait> there was some discussion ont hat last time
14:46:02 <cait> date_ vs. _date
14:46:12 <marcelr> or trust one dedicated and consitent person to do that for us ;)
14:46:17 <marcelr> consistent
14:46:20 <cait> and also using _id - when we actually store an id
14:46:21 <ashimema> and we sebtled on *_date I believe.. but didn't record it
14:46:34 <Joubu> I think we should have the whole thing/view and vote in one go
14:47:10 <cait> i think the only place where we need a decision is date date_created creaton_date updated_on
14:47:27 <cait> then we coudl say the last column counts
14:47:27 <thd> Even if we have only a date and not a time for some source a hypothetical time might be attached as 12.00.00 .
14:47:48 <cait> thd: i don't think we do or should do that
14:47:59 <marcelr> i think we should store datetimes
14:48:05 <cait> +1
14:48:10 <marcelr> and show date in presentation perhaps
14:48:24 <cait> reducing is easy, but we shoudl stay 'true'
14:48:33 <ashimema> yup
14:48:41 <ashimema> that's what I suggested
14:49:00 <cait> but back to this one
14:49:05 <cait> we have verified that it's not creation only
14:49:09 <cait> so the first 2 are out
14:49:22 <cait> and we have established that we like using _date if it's a date.. but it's a datetime
14:49:23 <thd> If we do not always have dates as date times then we should distinguish between them.
14:50:15 <marcelr> what about created_date and modified_date ?
14:50:29 <marcelr> to prevent updated_date
14:50:33 <cait> heh
14:50:48 <cait> what did we do on items?
14:51:01 <ashimema> `ed` on `ion`
14:51:02 <cait> hm items has timestamp
14:51:26 <ashimema> creation_date, modification_date
14:51:46 <marcelr> sounds nicer
14:51:47 <cait> looks like bilbio doesn't have anything
14:51:56 <marcelr> no it should
14:52:20 <cait> holds has timestamp too
14:52:25 <cait> i think stay consistent for now
14:52:26 <cait> timestamp
14:52:37 <marcelr> biblio has a timestamp yes
14:52:45 <ashimema> there are updated_on littered around too cait
14:52:57 <ashimema> there is no 'stay consistent' yet because we are inconsistent
14:53:08 <ashimema> hense me feeling we need to write a guideline properly first..
14:53:12 <cait> yes
14:53:19 <cait> but sometimes that's just updated_on
14:53:20 <ashimema> then work on making them all consisntent
14:53:20 <cait> like borrowers
14:53:22 <cait> they have both
14:53:54 <thd> ashimema++ #guidelines
14:54:03 <cait> my feeling is we shoudl not hold this up forever for one small decision
14:54:06 <cait> we can still fix that
14:54:18 <cait> have tomas continue... and then go in and fix according to guidelines at hackfest
14:54:24 <marcelr> guidelines first, fixes later on
14:54:35 <marcelr> tomas can proceed
14:54:37 <cait> 1.5+ months is a lot in a cycle
14:54:43 <cait> and those have been held up already
14:55:00 <ashimema> right.. I think so we don't run out of time we should schedule a guideline for next meeting and not vote this week
14:55:02 <kohaputti> cait, but we cannot fix this without breaking backwards compatibility?
14:55:03 <cait> changing timestamp to something else in oen cylce is not hard
14:55:05 <thd> Certainly we do not come to understand what guidelines should be without struggling with the questions in a real world context.
14:55:15 <cait> i am saying fix according to guielines within this cycle
14:55:23 <cait> and maybe not backport before we have done that
14:55:30 <ashimema> well likewise.. but I don't feel it is being held up.. code is being written and we have time still in the cycle to correct the terms as per a guidline once the guidline it done
14:55:41 <cait> exactly
14:55:48 <tcohen> code is being written, that's correct
14:56:16 <tcohen> the sooner we sort things the better, but we passed the mappings on the development, we will remap if required
14:56:38 <tcohen> [off] sorry, grabbed by another meeting
14:56:57 <cait> i am not sure if discussiong things biweekly here is so helpful too - because people don't do homework on this
14:57:05 <cait> the rfc are open for commenting
14:57:12 <ashimema> indeed
14:57:14 <cait> we have had no additional comments added in the last 2 weeks
14:57:15 <tcohen> maybe
14:57:19 <cait> i feel it's unfiar to hold things up now
14:57:31 <ashimema> lets move on
14:57:34 <tcohen> we could have things moving on, and have a period of time in which people can counter propose
14:57:48 <tcohen> during the cycle
14:58:49 <cait> vote to vote?
14:59:06 <marcelr> communicate important decisions or guidelines on the dev list ?
14:59:27 <Joubu> wording will not block development anyway, it's a matter of 5min to adjust the patches to a new word
14:59:42 <cait> Joubu: yeah, but stuff doesn't get pushed before vote
14:59:43 <ashimema> indeed, that's my point
14:59:49 <marcelr> Joubu we can rename 12 times an hour
14:59:57 <Joubu> stuff is not developped :)
15:00:23 <Joubu> marcelr: I am sure we can do more, it's 5 for the first one, but then we will automate that
15:00:26 <thd> I do not see much lack of homework but it may be difficult to elicit proper engaged interactive discussion of nomenclature in this context outside of something as real time as an IRC meeting.
15:01:28 <marcelr> i agree that doing this on a meeting is not very productive
15:01:55 <tcohen> lets skip this, and we will think of a better workflow for this guidelines
15:02:03 * oleonard leaves for another meeting, test 22880!
15:02:05 <tcohen> I will think about it
15:02:33 <tcohen> development is not held by this, the only problem is if things didn't get pushed/integrated because of this
15:02:38 <tcohen> but such is not the case
15:03:01 <tcohen> so, lets move on and I will propose something in the lines of what marcelr said about announcing things on the lise
15:03:03 <tcohen> list
15:03:21 <ashimema> #info votes are not holding up development and as such will be postponed untill we have written clear guidlines for the contentious field names (date vs date and timestamp vs date consistency)
15:03:31 <Joubu> we also need to be consistent, that's certainly the most important bit
15:03:34 <ashimema> #topic Moving on with Bug 22407
15:03:34 <huginn> 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22407 enhancement, P5 - low, ---, koha-bugs, NEW , OMNIBUS: Use DBIC relations to fetch related object rather than searching for the object
15:04:08 <ashimema> was this tcohen or Joubu that raised it?
15:04:17 <Joubu> was not you?
15:04:25 <tcohen> it was all of us
15:04:29 <marcelr> my agenda didnt contain this point too?
15:04:44 <Joubu> marcelr: refresh
15:04:53 <marcelr> i would suggest to copy stuff from the previous meeting directly after that one
15:05:00 <marcelr> and not just before starting
15:06:01 <Joubu> ashimema: is there a "replace them all" plan, or it only applies for the new ones?
15:06:44 <Joubu> ie. are all the related an exhaustive list?
15:06:44 <ashimema> I think that's the question.. I feel like we should plan to replace them all
15:06:56 <marcelr> i would agree with the principle but it might be a major refactor ?
15:07:07 <Joubu> it's not
15:07:11 <marcelr> ok
15:07:13 <Joubu> should be quite easy
15:07:16 <marcelr> even better
15:07:45 <marcelr> at least dont allow new ones to come up again
15:07:52 <marcelr> qa tools?
15:08:08 <Joubu> I do not think it will be possible to write such rule
15:08:23 <marcelr> hoped you could
15:08:54 <ashimema> indeed.. I tried to work out if it was possible but failed
15:09:11 <marcelr> yeah it does not sound easy
15:09:27 <Joubu> but easy to eyeball :)
15:09:29 <ashimema> OK, I'm happy to work with someone on a bug to catch outstanding cases..
15:09:39 <ashimema> I do tend to catch them in new code as QA or Push time
15:09:40 <Joubu> I will too
15:09:54 <marcelr> add a guideline too
15:10:07 <ashimema> the guideline already exists I believe
15:10:23 <ashimema> PERL15
15:11:11 <marcelr> it is a bit hidden in the examples
15:11:56 <ashimema> feel free to reword it.. I think we voted on it months ago and didn't come up with better
15:12:35 <Joubu> moving on then?
15:12:42 <ashimema> yeah.
15:12:48 <marcelr> ok i will spend 5 mins on rewording ;)
15:13:23 <ashimema> #info We will clarify the wording of PERL15 (perhaps even splitting it out into it's own guidline) for Koha::Object relationships
15:13:30 <ashimema> #topic Review of coding guidelines
15:13:49 <ashimema> #topic PERL27: Return values consistency. If a method returns a list, and there are no items, it should return [] (empty list). If it is a scalar, undef.
15:14:11 <marcelr> do we mean to write return undef; ?
15:14:16 <marcelr> this is not recommended
15:14:30 <ashimema> remind me where this came from
15:15:07 <marcelr> ProhibitExplicitReturnUndef in best practices
15:15:27 <marcelr> and obivously [] is not empty list but ()
15:15:52 <marcelr> but a return; in list context does the same ?
15:16:00 * ashimema reaches for the book
15:16:03 <Joubu> where does come from PERL27? what was the context?
15:16:13 <marcelr> who submitted it?
15:16:16 <ashimema> indeed.. that's what I want to know
15:16:21 <ashimema> where's the context..
15:16:43 <ashimema> in my opinion it should reply in caller context
15:16:50 <marcelr> as a reference https://perlmaven.com/how-to-return-undef-from-a-function
15:17:30 <tcohen> PERL27
15:17:35 <tcohen> I think it was me
15:17:42 <marcelr> lol
15:17:56 <marcelr> never do that again tcohen ;)
15:18:08 <tcohen> the problem is I'm not on the meeting
15:18:09 <tcohen> haha
15:18:31 <tcohen> we are building a framework for simplifying retireval of data for rendering on the API
15:19:02 <tcohen> and we need conventions so we can nicely prefetch related stuffs, and there will be a need for consistency on function call results
15:19:37 <tcohen> that one, was a trivial one, so we don't need to check for defined on the result, and just pass the result to the rendering party
15:20:10 <tcohen> the OpenAPI plugin will reject things that are supposed to be lists and are undef instead
15:20:18 <tcohen> so, to avoid manual handling I proposed a guideline
15:21:16 <Joubu> for the next meeting, could you provide existing examples, good and wrong?
15:21:19 <marcelr> so it needs a bit more context
15:21:27 <ashimema> +1
15:21:57 <tcohen> to be honest, I planned to explain it on the previoius meeting
15:22:09 <tcohen> and didn't notice there was a meeting today
15:22:11 <tcohen> sorry for that
15:22:12 * Joubu vote yes for rule MEETING01 "Provide a new item with context and example, as well as a full guideline" :D
15:22:30 <tcohen> +1
15:22:36 <marcelr> +1
15:22:52 <tcohen> dont_do_things_too_fast++
15:23:02 <ashimema> haha
15:23:13 <ashimema> shall we move on again then
15:23:37 <ashimema> #topic Reinforce good commit messages guideline
15:23:45 <Joubu> that was me
15:23:48 <ashimema> #link https://wiki.koha-community.org/wiki/Commit_messages#Examples Guidline
15:23:51 <marcelr> note the diff between bug and enhancement here
15:23:53 <ashimema> it was indeed
15:24:05 <Joubu> I tried to enforce this rule when I was RM. And we voted the guideline. The rule is no longer enforced
15:24:18 <Joubu> I'd like to know if we should get back to that or not
15:24:31 <tcohen> You don't always follow it :-P
15:24:37 <Joubu> like: do not c/p the bug title in the commit message, that's 2 different things
15:24:46 <tcohen> yeah, I hate that
15:24:58 <Joubu> I had to raise it because kohaputti FQA one of my patches for that reason :)
15:25:23 <marcelr> ah
15:25:33 <marcelr> selective reinforcement
15:25:41 <Joubu> it should be done at QA level and RM, not necessarily FQA
15:26:01 <ashimema> agreed I think
15:26:05 <kohaputti> I vote  to definitely enforce it
15:26:12 <ashimema> I do sometimes clean up commit messages on push.. though I'm inconsistent
15:26:12 <marcelr> it is always hard to fail a patch for title only
15:26:14 <thd> Have we recently passing patches which match examples of the worst commit messages?
15:26:24 <Joubu> and FQA if author stick to their bad habbits ;)
15:26:34 <Joubu> yes, a lot
15:26:35 <tcohen> I agree with Joubu
15:26:41 <ashimema> me too
15:26:49 <kohaputti> It is just one time to fail the patch, the author should learn for the next times
15:26:59 <Joubu> so email to koha-devel ?
15:27:07 <marcelr> exception for new authors perhaps
15:27:07 <tcohen> use social skills and don't be too hard on people, unless they keep their wrong habbit
15:27:12 <thd> Joubu++
15:27:27 <marcelr> new authors are allowed to do a lot
15:27:35 <tcohen> when I was RM, I fixed them on push too
15:27:40 <Joubu> but only the first time ;)
15:27:45 <marcelr> right
15:28:05 <ashimema> having a quick scan of the commitlog we're not straying too far from it all that often
15:28:30 <kohaputti> as a qa person I have no idea how many times this person has made non-descriptive patches, so quick fail or no fail is better in my opinion
15:28:40 <ashimema> so, enforcement at QA level isn't terrible.. but equally use a bit of judgement and generally opt on the side of 'be nice'..
15:28:55 <marcelr> so actually there is no problem?
15:28:56 <Joubu> #action Joubu will send an email to the list to remind devs about good/bad commit messages
15:29:09 <ashimema> I would never FQA a bug on just the title without having looked at the rest of the code first.. I would usually fix it for them and bring it up as a point that they should learn from my change
15:29:29 <marcelr> you always change my titles lol
15:29:36 <ashimema> a reminder is good now and then.. so that would be great Joubu
15:30:05 <thd> Without checking I presumed that the issue was more about excessive reference to bug report discussion in commit comments where irrespective of the simplicity of making a simple in comment description.
15:30:40 <kohaputti> for me the issue with non-descriptive commits is I have to use more time to understand the patch
15:30:55 <kohaputti> I don't want to reverse engineer the patch
15:31:25 <marcelr> that is also about more comment in the code
15:32:03 * ashimema is really struggling to find a bad one going through master
15:32:06 <marcelr> but leaving scope here
15:32:30 <Joubu> "Column Configuration for pay-fines-table does not hide Account Type properly"
15:32:37 <Joubu> it's the bug, not what does the patch
15:33:44 <Joubu> the following sequence of patch does not tell what the patchset does:
15:33:46 <Joubu> 24478: Add `EnablePointOfSale` system preference
15:33:54 <Joubu> 24478: Use `EnablePointOfSale` preference
15:33:59 <Joubu> 24478: Fix sequence in sysprefs.sql and add missing comma
15:34:08 <ashimema> to me.. the really bad ones are 'Address comment #42' and  'follow-up'
15:35:03 <marcelr> {QA follow-up) Some changes
15:36:03 <Joubu> I think we are done :)
15:36:06 <marcelr> yeah
15:36:11 <ashimema> I'm confused.. are you highlighting 24478 as bad or good..
15:36:17 <Joubu> bad
15:36:26 <kohaputti> for me those 24478 ones are really clear
15:36:29 <marcelr> Fix sequence in sysprefs.sql and add missing comma is not that bad
15:36:48 <ashimema> how would you have worded them?
15:36:50 <marcelr> it describe what you do
15:36:52 <Joubu> The main patch is "Use `EnablePointOfSale` preference"
15:37:12 <kohaputti> Joubu, read the body if you wanna know more details why it is used
15:37:13 <Joubu> Add a global switch to turn POS off
15:37:26 <kohaputti> body is for more explanation
15:37:35 <ashimema> what.. for all three patches you would use that single title?
15:37:44 <ashimema> or you would submit it as one bigger patch
15:37:47 <marcelr> Introduce pref X to allow enabling or disabling
15:38:12 <marcelr> Use pref X is a bit cryptic
15:38:28 * ashimema is looking at this as constructive criticism.. I like :)
15:38:39 <ashimema> fair
15:39:00 <ashimema> I tend to break down bugs into small commits to ease rebasing and backporting personally..
15:39:08 <marcelr> which is great
15:39:21 <marcelr> it is just about the title
15:39:21 <Joubu> I do not understand that one: "Dobbie is a free elf"
15:39:23 <Joubu> what did you mean?
15:39:25 <Joubu> ;)
15:39:38 <Joubu> next meeting?
15:39:38 <wahanui> next meeting is https://wiki.koha-community.org/wiki/Next_IRC_meetings
15:39:43 <kohaputti> ashimema, here it would have been better to make use of the syspref in the same patch it is introduced
15:39:43 <marcelr> your latest patch, Joubu ?
15:39:50 <ashimema> ok.. I think we can probably move on.
15:39:52 <ashimema> lol
15:39:54 <ashimema> 'Guess the RM'
15:39:59 <marcelr> ashimema++
15:40:12 <ashimema> #topic Set time of next meeting
15:40:20 <ashimema> same schedule as ever..
15:40:30 <Joubu> kohaputti: no, 1 patch for the new pref is good
15:40:45 <ashimema> so, 5th
15:40:48 <Joubu> you can spot omission easily
15:41:02 <kohaputti> Joubu, not for reading a story or reverting feature
15:41:19 <Joubu> it does not happen often
15:41:19 <kohaputti> Joubu, what omission you are talking about?
15:41:26 <ashimema> what time shall we make it..
15:41:40 <Joubu> add a pref is: atomicupdate, sysprefs.sql, pref.inc
15:41:44 <kohaputti> anything fine for me
15:42:06 <thd> That is one week?
15:42:15 <ashimema> 2pm or 8pm UTC is the usual switch
15:42:17 <marcelr> no it should be two weeks
15:42:35 <ashimema> oops
15:42:49 <ashimema> you're right.. i read the wrong line
15:42:51 <marcelr> it always toggles, good for NZ bad for Europe
15:42:55 <ashimema> 12th.. but that's also a general meeting on the 12th
15:43:08 <marcelr> the general should be on the 5th ?
15:43:12 <ashimema> 8pm on the 12th is the general meeting..
15:43:55 <Joubu> 1 or 3 weeks then
15:43:58 <ashimema> how about 11th 8pm
15:44:08 <thd> We have been on a second week of month or so pattern for general meetings recently.
15:44:09 <ashimema> so same time as general meeting, but a day early
15:44:51 <ashimema> or..
15:44:57 <Joubu> we need to resync, otherwise you will have the same problem next month
15:45:19 <marcelr> do we want 1 or 2 dev meetings a month ?
15:45:28 <Joubu> every 2 weeks
15:45:31 <marcelr> ok 2
15:45:58 <marcelr> second tuesday fourth wednesday ?
15:46:31 <Joubu> I would pick Wed 19th
15:46:39 <ashimema> I'm thinking 5th.. to keep the ball rolling on getting those API guidelines done and bringing us back to the off week for general meeting.
15:46:45 <ashimema> it can be a nice short one with just a vote on that guidline I'll draft this afternoon
15:46:46 <Joubu> or 5 yes
15:46:54 <marcelr> 5th and 19th and sticking to first and third
15:47:20 <ashimema> also.. 5th gives us another week to remind GBSD on 14th :)
15:47:20 <marcelr> twice a month means every 2 or 3 weeks
15:47:51 <thd> Yes, months are not evenly divided by weeks.
15:47:54 <Joubu> that's why I answered you 1 every 2 weeks
15:48:03 <marcelr> Joubu that could be confusing too
15:48:07 <Joubu> endmeeeeeting
15:48:10 <marcelr> heh
15:48:21 <ashimema> #info Next meeting: 5 February 2020, 20 UTC
15:48:41 <ashimema> #endmeeting