07:01:34 #startmeeting Development IRC meeting 24 August 2016 07:01:34 Meeting started Wed Aug 24 07:01:34 2016 UTC. The chair is cait. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:01:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:01:34 The meeting name has been set to 'development_irc_meeting_24_august_2016' 07:01:37 #topic Introductions 07:01:37 #info wahanui, a bot that has become sentient 07:01:48 please introduce yourself with #info following wahanui's example 07:01:51 today's agenda is at 07:01:54 #link https://wiki.koha-community.org/wiki/Development_IRC_meeting_24_August_2016 07:02:08 #info Mirko Tietgen, Berlin, Germany 07:02:15 #info Katrin Fischer, BSZ, Germany 07:02:22 #info Nick Clemens, ByWater Solutions 07:02:36 hm 07:02:39 that's too easy 07:02:47 #info Jonathan Druart 07:03:06 Europe should be more awake :) 07:03:26 can we shake some more people awake? 07:03:53 #info Kyle M Hall, ByWater Solutions 07:04:11 hm ok 07:04:17 let's moveon, maybe we have some people oversleeping 07:04:29 #topic Announcements 07:04:37 any announcements? 07:05:15 maybe a quick question fromme 07:05:18 shoudl we try for another GBSD? 07:05:39 yes 07:05:41 i am not sure if people are still holidaying much everywhere 07:05:50 but mabe in 1-2 weeks 07:05:59 don't have time for gbsd but in general, yes 07:06:01 #info Tomas Cohen Arazi 07:06:04 yes 07:06:10 any preferences on a day? 07:06:14 can't hurt! 07:06:42 maybe friday 9th September? 07:06:43 maybe a friday? 07:06:50 I like Fridays 07:06:57 friday 07:07:09 can we agree on the one in 2 weeks? 07:07:17 :) 07:07:30 +1 07:07:45 +1 07:07:51 i think there is a caffeine hackathon in berlin that day ;) 07:08:05 hello 07:08:05 hey, reiveune 07:08:06 #agreed Friday, 9 September will be GBSD = Global Bug Squashing Day 07:08:19 #action cait to update wiki and send info about GBSD to the mailing list 07:08:25 moving on? 07:08:51 #topic Review of coding guidelines 07:08:55 no suggestions have been made 07:09:03 is there something people want to discuss? 07:09:37 i will take the quiet as a clue to move on 07:09:38 I would like to mention 07:09:40 ah 07:09:46 hie 07:10:01 I've been looking at REST-related patches the last couple days 07:10:27 and while not finished, there will be need for coding guidelines for the swagger files 07:10:44 #info tcohen is working on the REST-related patches and suggests adding coding guidelines for the swagger files 07:10:50 maybe this should be discussed on another meeting of course 07:10:53 can you detail a bit? 07:10:58 like give an example? 07:11:22 i'm abit asleep still 07:11:49 the original swagger file was about to get bigger and bigger 07:11:50 ok, so maybe we shoud just keep it in mind and add to next meeting? 07:12:05 tcohen: that's ok, I think kidclamp and I are too ; ) 07:12:15 and there are patches on the queue that propose splitting 07:12:22 the file into pieces 07:12:32 I like the schema they are proposing 07:12:44 but as there hasn't been much attention on them 07:12:51 bug 15126 07:12:52 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15126 enhancement, P5 - low, ---, julian.maurice, Pushed to Master , REST API: Use newer version of Swagger2 07:12:54 I'd like to promote it to a dev meeting 07:12:58 bug 16699 07:12:59 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16699 enhancement, P5 - low, ---, koha-bugs, Signed Off , Swagger: Split parameters and paths, and specify required permissions for resource 07:13:13 so people can give their opinions 07:13:29 maybe good to send to the mailing list too before the next meeting 07:13:35 so people get time to look into it 07:13:45 good idea, I can send that email 07:14:17 #action tcohen to send an email to the list about 'splitting the swagger files' - bug 16699 07:14:27 ok, let's move on - more REST 07:14:43 yeah, I need to REST :-P 07:15:22 #topic General development discussion 07:15:43 hope people are not grumpy with me - I added questions about 2 topics I have stumbled on/being thinking about 07:16:05 so the first is: Is the REST API optional or mandatory (when you install Koha) 07:16:15 triggered was this by kidclamp's patch on bug 8030 07:16:16 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 enhancement, P5 - low, ---, nick, Signed Off , Change pickup location of a hold from patron record 07:16:33 and the fact that it was not working for me - as my REST stuff doesn't appear to be configured correctly yet 07:16:57 is there a general consensus about this kind of patch that we shoudl be using the API in the GUI already? 07:17:11 and if we do that, is it production ready? (secure, installs nicely, etc)? 07:17:36 one thing i noticed is that mojo etc. is still optional in PerlDependencies.pm 07:17:57 the REST api code has been deployed into users' installs since it was introduced 07:18:37 the original patches enabled it only on tarball/git installs 07:18:56 because the package's apache configuration files hadn't been tweaked 07:19:32 * tcohen re-reads the questions 07:20:08 cait: what reasons could there be to keep it optional? 07:20:18 (as far as it is tested, secure etc) 07:20:28 if it doesn't install well out of the box - it's not documented to activate (woudl be one reason for me) 07:20:35 if it's not ready yet 07:20:44 becuase the patch from kidclamp will put it in the middle of Koha so people will stumble upon it if it doesn't work :) 07:20:49 #info Frédéric Demians 07:20:50 cait: imo it's ready and necessary 07:20:56 or if there are security concerns - like permission problems 07:21:00 with a few more tweaks 07:21:01 i am not against it - hope that's clear 07:21:06 i'd just like us to be on the same page 07:21:07 The problem we have is that it's not ready yet and we'd like to use it from Koha 07:21:11 and look out for potential problems in production use 07:21:27 like fixing PerlDependencies etc. 07:22:03 ok, 2 different opinions 07:22:14 Joubu: can you tell what's missing in your eyes right now? 07:22:34 FYI i have reverted bug 17030 from 16.05.03 for the debian package, because we lacked permission settings and it (if i got it right) allowed holds to be placed by everyone 07:22:35 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17030 enhancement, P5 - low, ---, tomascohen, Pushed to Stable , Configure the REST api on packages install 07:22:38 one more questio maybe woudl be about backporting REST API work to the stable releases atm 07:22:45 I have no idea, just repeating what I heard 07:22:52 if we say we will have it ready for 16.11 - but atm things are changing too much or so 07:23:00 but permission is a blocker 07:23:12 it's a mighty API.. which is cool, but also has me a little worried 07:23:19 :) 07:23:26 bug 14868 07:23:27 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 enhancement, P5 - low, ---, larit, Needs Signoff , REST API: Swagger2-driven permission checking 07:23:53 I have an idea of what is missing 07:24:02 some love :-D 07:24:07 tcohen: can you summarize? 07:24:12 ; ) 07:24:19 lol 07:24:21 a simple search for REST on BZ 07:24:35 hello 07:24:36 will show that people have invested lots of time in two things 07:25:16 1) create a good basis for defining endpoints and handling permissions seemlessly, using state-of-the-art technologies 07:25:36 I'm talking about having the API fully documented with a Swagger 2.0 spec 07:25:45 and the bug kidclamp mentioned 07:25:53 is the most important piece 07:25:56 IMO we need a list of people willing to be involved in the maintenance of the REST API 07:26:13 2) there are lots of bugs introducing new endpoints 07:26:32 #info lots of REST related patches on bugzilla, focusing mostly on 2 things: 1) permission handling and documentation, 2) adding new endpoints 07:26:45 from a first look, we can notice people are writing endpoints so the UI can be fully rendered using the REST api 07:27:11 "need a dropdown with the list of branches? here's an endpoint" 07:27:12 etc 07:27:15 api devs++ 07:27:47 the problem is we need people testing them - and we shoudl be careful about permissions/prefs taken into account/terminology :) 07:27:48 Joubu: why do we need a specific list for maintaining this above other things? 07:28:11 cait: I agree 07:28:20 kidclamp: i think he meant people dedicated to look after it 07:28:23 currently there are patches, but just few people are involved 07:28:27 the patches get stuck right now - not a lot of experts 07:28:46 I'd like to know who is going to write/test/qa these patches 07:29:02 and who will fix bugs 07:29:16 I don't feel ready to test/qa - I'd like to learn - either online sometime or maybe in marseille 07:29:18 somebody should do a dev intro in marseille 07:29:55 volunteers? :P 07:29:59 I'd like to clarify something 07:30:00 (I've asked the same question on the ML but did not get answer from the involved people) 07:30:30 most functionality comes from the Koha::* classes 07:30:51 the mighty REST api is just a layer on top of that 07:31:00 routing calls to the right classes 07:31:14 s/is/must be 07:31:16 agreed! 07:31:17 which now has a rudimentary permission layer 07:31:37 which is about to get steroids with bug 07:31:50 bug 14868 07:31:51 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 enhancement, P5 - low, ---, larit, Needs Signoff , REST API: Swagger2-driven permission checking 07:32:10 what the guys do in that patches 07:32:41 is letting us declare the needed permissions, on the swagger file 07:33:08 so the API now will also provide more documentation, and a permission check schema 07:33:12 that makes code simpler too 07:33:25 I think we definitely need a workshop on this 07:34:31 so for now we need people leading, but should be community maintainable without difficulty is what I hear tcohen 07:35:56 we need to make interested parties get involved 07:36:11 i'm not sure why they aren't 07:36:48 but I don't see the REST api as a complicated piece of code 07:37:27 maybe the V1.pm could get complicated with the permission checking layer 07:37:56 but look at this 07:37:57 http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=Koha/REST/V1/Patron.pm;h=2851308e7c34d78925972959438c28f4aa0782e8;hb=HEAD 07:38:16 if you remove the permission checking from that code 07:38:29 (because it is moved somewhere else by the mentioned patch) 07:38:43 you just have a couple calls to Koha::* libs 07:39:07 could it be a good idea to say no backports for now until we have sorted those base patches? 07:39:08 that is just lovely ; ) 07:39:11 even the permission check lines are… what you'd expect 07:39:46 I'd even say no push to master 07:40:28 hm why not? 07:40:30 um, how do you propose we handle it then Joubu? 07:40:51 I meant to push of patches using the REST API 07:41:01 no the patches of the REST API 07:41:44 Joubu: I understand now, you mean don't push new endpoint patches until we get these mechanics fixing patches in place, right? 07:41:49 block them with 14868, they all depend on that and can't be pushed until after 07:42:02 I agree we need some level of completeness before we make the decision to allow the REST to be used from the UI 07:42:27 I was thinking about bug 8030 (sorry kidclamp) 07:42:28 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8030 enhancement, P5 - low, ---, nick, Signed Off , Change pickup location of a hold from patron record 07:42:35 Joubu refers to patches that USE the endpoints 07:42:59 that was what I meant, make it depends on the necessary infrastrcuture bugs 07:43:38 yes, that's sensible 07:44:02 cool 07:44:12 tcohen: since you looked at the patch deeper than me, could you send an email to summarise the situation? 07:44:21 alright 07:44:28 #idea don't backport REST API patches atm, until infrastructure is sorted out 07:44:35 I think I already volunteered for that 07:45:23 #idea make new patches using REST in the GUI depend on the infrastructure bugs, especially bug 14868 07:45:24 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14868 enhancement, P5 - low, ---, larit, Needs Signoff , REST API: Swagger2-driven permission checking 07:45:39 * cait is glad about the discussion 07:45:42 I think only 16.05 has got the REST api on packages 07:46:07 and fredericd is aware of the issues that prevent it to be enabled by default 07:47:06 can i add another question? 07:47:20 if 14868 is not backported to 16.05 i think 17030 should be reverted 07:47:41 fredericd: what do you think? 07:47:44 I taked to fredericd yesterday about the pending bad fines bug 07:47:50 that's fredericd's call, but yes 07:47:51 he said maybe he could do an additional earlier release 07:47:54 once we got that in 07:48:03 we coudl also use it to fix that 07:48:41 I agree with drojf. 17030 should be reverted 07:48:54 From now, I will skip any REST related patch 07:50:21 fredericd: we could patch /holds too 07:50:40 but it seems the real solution is so close :-D 07:51:45 I wrote a POC for bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16815 07:51:46 04Bug 16815: critical, P5 - low, ---, julian.maurice, ASSIGNED , API routes to list, create, update, delete holds need permissions 07:53:13 Without modifying Apache conf, is it possible to exploit hold security flaw? 07:53:45 the /api endpoint shouldn't be available without tweaking the apache files 07:53:50 there is no way to reach the api if it's not in apache 07:53:50 hm with a package install probably? tcohen? 07:54:03 (i hope) 07:54:10 i thought it auto-activated 07:54:13 on 16.05? 07:54:26 cait: i reverted 17030 before i built the package. so no 07:54:28 reverting 7030 will fix that in 16.05 07:54:32 ah ok 07:54:37 bug 17030 07:54:38 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17030 enhancement, P5 - low, ---, tomascohen, Pushed to Stable , Configure the REST api on packages install 07:54:50 i thought that was in - so that's where i got confused 07:54:53 thanks to tcohen for pointing that out btw 07:55:08 tcohen++ 07:55:16 hi 07:56:27 hi eythian 07:56:32 ok, another question from me? :) 07:56:54 yes 07:57:06 one of the patches, i will find the bug in a moment, adds the ability to see your own checkouts/renew your own mateirals 07:57:10 this doesn't require any permission 07:57:20 so if the api is there, anyone can use it - without the library knowing 07:57:31 it gives me a bit of a headache to be honest - i'd like to know how others see it 07:57:40 sounds like an awful idea 07:57:58 that's my feeling, but so far i feel a bit lonely/paranoid .) 07:58:18 i'd like it better if you coud get for aexample an api key 07:58:21 that the library can revoke 07:58:22 cait: if I understand correctly 07:58:38 you mean that there's a bug proposing a REST endpoint, which implements it wrong? 07:58:42 bug 13895 07:58:43 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13895 new feature, P5 - low, ---, julian.maurice, Signed Off , Add API routes for checkouts retrieval and renewal 07:58:46 cait: it should require either 1) your login has the necessary permissions to view / modify checkouts or 2) the checkouts are your own ( for viewing ) 07:58:53 it requires a login 07:58:57 but you can't control use 07:59:14 it mimicks what you can do with an opac access 07:59:18 ah 07:59:23 not so awful then 07:59:37 if you can do it in the OPAC right now, there's no difference 07:59:38 but for me... API is a different level of complexitiy 08:00:27 there is also ths bit as part of the big patch: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54766 08:00:30 cait: why do you think that? Giving patrons the ability to access their data via the api is a *good* thing! 08:00:53 cait: suppose you have a button in the OPAC, which allows logged users to renew stuff 08:00:58 fully automated access... not seeing any hints the library might have added - maybe getting around limitations only implemented in the templates... 08:01:14 anyone can point the browser to the .pl with the right arguments 08:01:15 if they are only in the templates then that is a bug now 08:01:23 true 08:01:23 and renew their stuff without using 'our' button 08:01:26 if we want to have an API 08:01:35 or we can't have one :P 08:02:16 the API is just a way to organize things 08:02:19 if your patrons are bold enough to research and use the API directly you should get them signing off on bugs :-) 08:02:29 heh 08:02:29 hahaha 08:02:53 ok, so paranoid :) 08:03:06 we should have good logging facilities 08:03:10 even better, it means that Koha can be integrated into other apps 08:03:18 for example, we could have a special 'api' interface 08:03:18 other sofware seem to require something like an api key - so youwould know hwo uses your api 08:03:30 tcohen: good idea 08:03:30 folio will be so happy 08:03:32 :P 08:03:41 or, ebsco 08:03:58 or my customer's student's management system 08:04:08 drojf: good point, the api will make folio integration much simpler 08:04:28 * ashimema_ hints at OAUth 08:04:33 OAuth.. even 08:04:41 lol 08:04:41 that's it's entire reason for being 08:04:43 cait: the api-key stuff if for system<->system integration 08:05:01 right now, the API only implements cookie-based auth 08:05:33 * ashimema disappears again before he slates our api implementation ;) 08:05:46 I think cait in the end patrons shouldn't be able to do anything via API they can't do via the opac, so it shouldn't be any different 08:06:07 with the same restrictions 08:06:28 ok 08:06:39 i will log that :) 08:06:48 that's why it is important that people get involved 08:06:52 people that know Koha a lot 08:06:57 can I give another example 08:07:01 proper access control would take into account.. who's data your trying to chance, who's trying to change it and what application is doing the change on behalf of the person 08:07:06 tcohen: doing the workshop in marseille? :P 08:07:06 #info patrons will be able to use the REST API to do, what they can do in the OPAC, but not more 08:07:18 #chair drojf 08:07:19 Current chairs: cait drojf 08:07:21 phone 08:07:31 err i only had one coffee 08:07:43 i.e the cookie or token your using for authentication should include those three details 08:07:56 #chair tcohen 08:07:56 Current chairs: cait drojf tcohen 08:07:59 so for the koha case 08:08:06 cait: https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54767 08:08:08 the cookie you get when you log in to the opac says.. 08:08:28 I'm person X, using interface 'OPAC'. 08:08:50 (which defaults to limiting them to only chaning person x's data and limits them to opac only actions. 08:09:01 when you login to the staff client the cookie says 08:09:13 I'm Person X, Using interface 'Staff'.. 08:09:56 then any actions you undertake on Person Y may or may not be permissible because your aware of what person c is allowed to do under the 'staff' interface. 08:10:31 ashimema: we are missing the interface data I think 08:10:32 person x? :P 08:10:49 in the OAuth world.. your efectively just adding more 'interfaces' and letting the person involved choose what that interface is allowed to do on thier behalf with their login 08:10:51 i.e 08:11:19 Person X logs in to Koha, then grant Interface Z privileges to undate their username. 08:11:44 When person X then logs into Interface Z, the system knows that all Interface Z is allowed to do is change the username. 08:12:01 (or rather.. the system knows all that interface Z is allowed to do is change the username).. 08:12:11 the interface can optionally look that up or not.. 08:12:28 so a user would allow an android app to log in and show account details. like a twitter app or something 08:12:28 but form the api security perspective.. Interface Z will never be allowed to do more than change the username 08:12:29 ashimema: are you attending Marseille? 08:12:36 I am 08:12:47 though I still need to book my train and hotel 08:12:56 so the "workshop" thing is dealed with 08:12:58 :-P 08:13:07 ? 08:13:21 you need to talk about REST and Swagger 08:13:29 haha.. sure 08:13:30 *dealt* 08:13:45 cait: are you back? 08:13:45 * ashimema hints it's changed it's name lately.. it's no longer 'Swagger', it's 'OpenAPI'.. 08:14:04 yeha, I noticed yesterday 08:14:11 cool, nore confusion 08:14:13 more 08:14:29 are we done with REST discussion? 08:14:43 I want to clear cait's fears, and encourage her to get involved in reviewing some REST stuff 08:14:45 ooh.. 08:14:50 I didn't realise we were in a meeting.. 08:14:55 apologies for that diversion then ;) 08:15:02 ashimema: good contributions though 08:15:04 #info Martin Renvoize - PTFS Europe 08:15:07 lol 08:15:10 so I need to explain this https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54767 08:15:23 * ashimema should put meetings in the diary and set alarms.. lots of alarms 08:16:30 I need a couple hours of sleep 08:16:32 tcohen: do we wait or do you want to do it later maybe? 08:16:48 no idea how long she will be on the phone 08:17:02 * ashimema will read that lot probably late this evening.. too much to do today already :( 08:17:05 i just want to make a point 08:17:16 anyone can look at that 'swagger' file 08:17:31 and review permissions that are required for each endpoint/action 08:17:47 indeed they can 08:17:56 specially people like cait, that know Koha's business with lots of detail 08:17:57 that's a good thing in my opinion 08:18:15 there's no need to engage in the technical part of the problem 08:19:06 #info REST api permissions can be reviewed in file, see https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54767 08:19:23 so, our product owner can review it and with a simple reading and notice issues 08:19:34 the code of course should respect those definitions hhe 08:20:00 i assume that finishes the api permission part for now? 08:20:01 * tcohen goes to sleep 08:20:05 yes 08:20:11 later #koha 08:20:17 bye tcohen 08:20:20 ok. then if there is nothing more for the REST api i would mov eon 08:20:24 night tcohen 08:20:28 agreed 08:20:40 #topic Highlight easy to test bugs for beginners 08:20:55 we had that last time on the agenda and nobody knew what to say about it 08:20:58 This was something cait and I discussed a while back 08:20:59 kidclamp: was it yours? 08:21:05 yes 08:21:11 ah cool, can you explain 08:21:13 ? 08:21:36 It seems that often when people want toget involved they want to know easy bugs to sign off/test 08:22:03 It would be easy enough to either use the 'Academy' keyword all year round, or have a new keyword tomark beginner bugs 08:22:43 complexity is sort of helpful there, but isn't always filled out and sometimes a single patch is complex but depends on complicated things 08:22:43 i think we should use a new one maybe 08:23:00 we could also have a "testing complexity" pulldown in addition to "patch complexity" 08:23:41 that sounds nice, but does BZ allow that? 08:23:49 no idea how the config works 08:24:14 'testing complexity' is a bit more complicated I think - is it complex to rquire setting up 50 users and branches and checking out a bunch of items, or just tedious :-) 08:24:15 that might be even better than a tag 08:24:46 kidclamp: I would just call that tedious ; ) 08:24:52 kidclamp: we should have a sample db that just has a bit of everything 08:24:58 digging a ditch is not complex, but it is tedious 08:25:17 drojf: we have the sandbox DB already 08:25:19 but i agree, it's not compley 08:25:34 but asking a volunteer to dig a ditch may not encourage him to return ;-) 08:25:42 Joubu: but they don't have active checkouts and holds and acq data and stuff, do they? 08:26:00 ok, first two settings are "Simple" and "Simple but tedious" ; ) 08:26:05 lol 08:26:22 I'll support that 08:26:28 drojf: no indeed 08:26:48 nobody will test these ones... 08:27:03 sorry, reading back now 08:27:29 khall: i would call that… extra…something. making it a good thing people will learn more about koha :P "simple - special experience" 08:27:53 drojf: love it! 08:27:59 much better 08:28:54 ok then somebody needs to talk to rangi asking about the testing complexity thing? if that is an option it looks like we all are in favour of it? 08:29:34 +1 08:29:48 #idea instead of a keyword, add "testing complexity" to BZ 08:30:20 * cait gives up on reading back fast enough 08:30:22 so will developers etc. agree to look for the 'omg complex!' bugs 08:30:28 any questions or so? 08:30:42 no 08:31:02 @later tell tcohen - i want to get involved, will you sit down with me to teach the basics? ;) 08:31:02 cait: The operation succeeded. 08:31:02 heh 08:31:06 cait: i info'd what tcohen wants you to look at 08:31:12 regarding api permissions 08:31:15 because that is one downside to complexity - complex bugs exist and need attention 08:31:51 or do we only makr easy ones 08:31:56 kidclamp: the complexity is already there without the label. i think devs know that ;) 08:32:02 currently there is lots of scary stuff in needs sign-off 08:32:05 I think another testing complexity setting should be "Needs command line access" 08:32:08 it would be good to get some devs in there for signing off too 08:32:14 aka can't be tested in a sandbox 08:32:25 so we can make easy ones esier to spot... but we also need people to help out with complex stuff 08:32:28 but it helps newbies if they can find easier ones 08:32:31 "testable on sandbox" as well 08:32:35 yep agreed 08:32:50 maybe 'system architecture' 08:32:52 ? 08:32:54 but testable on sandbox and easy or hard are different categories 08:33:04 that should probably be an extra thing 08:33:15 or we will have a lot of options in that box 08:33:20 maybe keywords woudl be easier 08:33:24 because you can have multiple 08:33:30 I think don't have 'hard' or 'complex' just mark the simpler ones 08:34:09 if we want to use the BZ api (eg a sandbox could check for the sandbox tastability), it should be separated 08:34:20 testability 08:34:24 tasty too 08:34:31 yummy sand 08:34:41 kidclamp: I'm inclined to agree with you, that's less likely to scare people away from "hard to test" patches 08:35:36 sandbox_ready keyword? 08:35:58 just sandbox 08:36:07 or nosandbox, like i did with nowheezy 08:36:13 it will be less to tag 08:36:14 i guess 08:36:36 I also wouldn't discourage use of 'Academy' year round still, there are those bugs that are very educational to testers - if we mark one right after academy and it isn't dealt with by next academy, probably still relevant? 08:36:41 yeah, I think nosandbox makes the most sense 08:37:17 I would argue the other, mark the sandboxable so you can find those if you use one 08:37:38 if you want to use a sandbox unmarked and nosandbox are equal 08:37:42 drojf: will you talk to rangi about adding the keywords? 08:37:56 khall: nosandbox is something devs would have to add when they add the patch. sandbox could be something people add when actively looking for easy bugs to mark 08:37:58 so should we stick with "Academy" as the easy tag, and add the keyword "nosandbox" and "educational" ( aka tedious ) 08:37:58 'sandbox' mark makes it stand out 08:38:27 drojf +1 08:38:28 so maybe sandbox makes more sense in this context 08:38:40 drojf: ok. I was just assuming most patches are sandbox testable 08:38:45 i think sandbox, nosandbox (so both can be marked when you see it) , but not totally sold on educational 08:38:52 Avademy for easy is ok for me 08:38:57 khall: yes me too, i just thought about the workflow right now 08:39:06 works for me! 08:39:28 drojf: are you volunteering? or kidclamp? 08:39:53 i don't know if the academy is happy if the academy tag is used for everyone, because that will make it impossible for them to claim a few bugs when the academy actually happens 08:40:14 "claim" 08:40:26 don't they usually call out for people to mark bugs around that time? 08:40:48 drojf: true, maybe tis better to just create a new less special keyword 08:40:59 easy, beginner, newbie 08:41:02 something like that 08:41:05 I am happy for it to be a new keyword - I just wanted a keyword and a complexity :-) 08:41:12 if we were going complexity route 08:41:31 new_kewyword+1 08:41:36 kidclamp: can you propose a list of complexities? 08:41:56 cait: i volunteer kidclamp because it is his topic :P 08:41:59 yes, for next meeting - can be a general meeting discussion I think 08:42:21 #action kidclamp to talk to rangi about adding new keywords as discussed in the meeting to indicate easy bugs for beginners and testing complexity 08:42:27 ah 08:42:29 or next meeting 08:42:39 #action kidclamp ... or make a suggestion for the next meeting 08:42:41 I will talk to rangi before 08:42:45 sounds good 08:42:48 and then make suggestion 08:42:53 are we ok to move to action items from last meeting? 08:42:59 we are running late today :) 08:43:15 yes. move ahead 08:43:19 #topic Updates from the QA team 08:43:27 no updates from me - please look at critical bugs, link on the agenda 08:43:30 Joubu: ? 08:43:38 nothing new 08:44:00 sorting bug 17135 fast would be bood 08:44:01 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17135 blocker, P5 - low, ---, koha-bugs, NEW , Fine for the previous overdue may get overwritten by the next one 08:44:01 good 08:44:11 it's a problem in the stable version 08:44:49 you are 3 on it, so decided to stay away from it. Do you need help? 08:45:03 I thin the missing piece now is a database update 08:45:07 to clean up 08:45:21 FU double ups a hopefully last time 08:45:41 and a set of eyes probably doesn't hurt - i didn't have time for testing 08:46:08 the patch set is on bug 14390 actually 08:46:09 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14390 major, P5 - low, ---, kyle, Signed Off , Fine not updated from 'FU' to 'F' on renewal 08:46:36 ok will have a look at the updatedb 08:46:57 moving on 08:47:03 #topic Actions from last meeting 08:47:16 bag to add a note to the next release notes - I got on idea what that was about! 08:47:23 http://meetings.koha-community.org/2016/development_irc_meeting_13_july_2016.2016-07-13-14.08.html 08:47:36 Joubu is going to check if some performance testing can be included in the qa scripts (launch a series of tests and compare diff) Joubu to ask on the mailing list about which namespace scheme should be used for the 'export things' 08:47:37 deprecation of wheezy i think 08:47:55 did we come to a conclusion about the export scheme? 08:47:59 Joubu: we may want to rerun the FU to F cleanup from bug 15675. Just keep that under your hat ( https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48471&action=diff ) 08:48:00 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15675 enhancement, P5 - low, ---, kyle, RESOLVED FIXED, Add issue_id column to accountlines and use it for updating fines 08:48:02 the namespace "discussion" is on http://lists.koha-community.org/pipermail/koha-devel/2016-July/042845.html 08:48:17 khall: k! 08:48:29 #info namespace discussion is on http://lists.koha-community.org/pipermail/koha-devel/2016-July/042845.html 08:48:41 I have started the benchmarks for QA tools: http://lists.koha-community.org/pipermail/koha-devel/2016-July/042844.html 08:48:46 but need feedback 08:48:59 #info Start for benchmarks for QA tools: http://lists.koha-community.org/pipermail/koha-devel/2016-July/042844.html Please comment! 08:49:18 khall to add new benchmark rule to the coding guidelines 08:49:32 and I think I have provided the list of bug numbers waiting for QA (search for "Move stuffs to Koha namespace" and related) 08:49:54 khall volunteers to focus on rewrite patches for QA 08:49:54 khall to provide a proof of concept for using React in Koha 08:49:54 khall to add react/angular and frontend build to to next agenda ;) 08:49:59 cait: I believe I did that in PERL24 08:50:16 thre were lots of action items 08:50:21 ok thx khall 08:50:23 cait: that could use some discussion. 08:50:29 which oneß 08:50:31 ? 08:50:42 React stuff 08:51:07 #info PERL24 was added after the last meeting: https://wiki.koha-community.org/wiki/Coding_Guidelines#PERL24:_Performance_and_cache_related_patches_should_include_benchmarks_of_some_sort_to_prove_their_effects 08:51:15 can we talk about it next dev meeting? 08:51:33 basically, many new js libraries ( like react ) require transpiling which means we need to use a tool like gulp to convert the React js files into regular js files 08:51:51 I don't think it's a big deal, but I wanted to bring it up. 08:52:04 i thin that might be related to owen's action item? 08:52:10 oleonard to start a mailing list thread about the frontend build tool ? 08:52:11 Most importantly, that requires developers to use npm 08:52:28 cait: yes, same thing basically 08:52:37 can you please add this to the next agenda? 08:53:10 #action khall to add react and related topics to next dev meeting agenda 08:53:12 ;) 08:53:22 can do! I think we will end up using gulp most likely 08:53:26 i think Joubu has made a list of bugs available in his summaries 08:53:36 let's seet date and time for the next meeting 08:53:49 the big note is that we already make developers use node/npm for dealing with opac css via less 08:54:07 #topic Set time of next meeting 08:54:08 so there's already precedent for needing/using node/npm as a Koha developer 08:54:24 September 28? 08:54:34 21 utc? 08:54:34 21 utc is fine and might be better for local time adjustments. 08:55:30 I like 21 UTC 08:55:39 it's always too late for everybody 08:55:43 unless kidclamp 08:55:46 and nz 08:55:46 :-) 08:55:59 I thought we ere nice to europe this time 08:56:06 so could try being nice to others... :) 08:56:09 argentina shoudl be better too 08:56:28 yeah 08:56:36 is that an ok? 08:56:48 k 08:56:52 #agreed Next meeting will take place on September 28, 21 UTC 08:56:53 thx a lot 08:56:56 #endmeeting