10:01:27 #startmeeting Koha IRC Meeting 10:01:27 Meeting started Wed Jan 9 10:01:27 2013 UTC. The chair is kf. Information about MeetBot at http://wiki.debian.org/MeetBot. 10:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 10:01:27 The meeting name has been set to 'koha_irc_meeting' 10:01:37 #link http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_January_2013 10:01:42 http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_January_2013 10:01:43 welcome all to the koha irc meeting 10:01:46 hello :) 10:01:53 Guys 10:01:53 please introduce yourself with #info 10:01:55 http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_January_2013#Agenda 10:02:00 #info Katrin Fischer, BSZ 10:02:01 #info Owen Leonard, Athens County Public Libraries 10:02:05 #info Mirko Tietgen, Berlin 10:02:09 #info MJ Ray, software.coop member, England 10:02:16 thx slef and drojf for the link 10:02:24 #info Joanne Dillon (JD) at Te Takere/Horowhenua District Libraries 10:02:29 just if some one else stumblled upon this issue - The 'Version' parameter was missing in database 10:02:32 #info Kathryn Tyree, Catalyst IT, NZ 10:02:33 #info Colin Campbell ptfs-europe ltd. 10:02:36 #info David Nind, Wellington, NZ 10:02:36 #info Thomas Dukleth, Agogme, New York City 10:02:43 that seem to have fixed the rediection issue 10:03:12 hm forgot the topic... 10:03:13 #info Irma Birchall CALYX Sydney, Australia 10:03:26 #topic Announcements 10:03:37 does someone have an announcemnt to make? 10:04:13 ok, moving on to next topic then 10:04:20 #topic Update on 3.8 10:04:24 i anounce i'm going to get tea water 10:04:37 you are too late, the topic has moved on 10:05:00 I think neither our RMaint nor our RM are here today, so I am moving forward if noone speaks up 10:05:46 it would be nice if short updates were left in the agenda if they can't make it 10:05:47 #topic Update 3.10 10:05:53 Hi, Is there any problem with 'debean' and ICU feature for multilanguage search indexing. 10:05:54 magnus++ for that reason 10:06:04 slef: agreed :) 10:06:16 WaqarAzeem: we are in a meeting right now - it shouldn't take long - maybe ask in a few minutes? 10:06:25 i followed and artical and got this error without any trance ... [warn] previous transaction didn't reach commit 10:06:39 #topic Update on 3.12 10:06:40 I am really sorry for this ... 10:06:59 Hm, maybe I could try and say a few things 10:07:11 just the usual reminder to add test plans and good descriptions to your patches 10:07:29 WaqarAzeem: no problems, but we want to concentrate on news for a few minutes, so ICU help a bit later probably. 10:07:42 and please keep signing off and testing 10:07:53 what's the situation with database updates? 10:07:56 I think so far 3.12 is moving along as planned, some bigger features have gone in too 10:08:10 slef: afaik you can see it in bugzilla 10:08:10 * oleonard-away asks that everyone listen to kf and really do add test plans and good descriptions to patches! 10:08:18 the follow-ups still need sign-off I think 10:08:32 * oleonard didn't mean to be away 10:08:43 #info paul Poulain, BibLibre, France 10:08:54 (sorry for being a little bit late ! 10:08:55 slef: the new system has been reverted, so for the time being, you just submit your patches with the updatedatabase bit 10:09:08 does that answer your question? 10:09:20 yeah pretty much. Anyone got the bug number? 10:09:31 as someone who might be testing your patch, chances are higher with a test plan. and by higher i mean i might actually consider doing it 10:09:35 there are a lot linked to the main bug I think, look for database improvements 10:09:48 yes, and also you save a lot of time for testers and qa team 10:10:11 and time is really precious when it comes to shorten the list of things waiting for attention :) 10:10:22 by test plan you mean the comment with 1.2.3. and description of success/failure? 10:10:34 ther is doc on the wiki 10:10:43 oleonard: could you find it maybe for me? looking for the bug number 10:11:07 bug 7167 10:11:07 bug 7167 is commented out of control 10:11:07 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167 new feature, P1 - high, ---, jonathan.druart, Signed Off , updatedatabase improvements 10:11:09 #link http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7167 10:11:09 04Bug 7167: new feature, P1 - high, ---, jonathan.druart, Signed Off , updatedatabase improvements 10:11:30 #info current discussion about the database update changes can be found in bugzilla - start with bug 7167 10:11:32 drojf: Would a test plan not be self evident as part of the comments in well written tests? 10:11:46 #link http://wiki.koha-community.org/wiki/Bug_Reporting_Guidelines#Description 10:11:49 perhaps 10:12:08 ah, i was thinking about 10:12:10 #link http://wiki.koha-community.org/wiki/Commit_messages 10:12:15 which reminds me... editing out "The application crashed." 10:12:29 the 7167 has a short follow-up, that should be not so hard to test, and it's a VERY handy improvement! 10:12:56 I think I woudl like to moove on to magnus's suggestion at this point 10:13:01 as it seems a good fit right now 10:13:09 kf: yeah I think we're proving magnus's motivation ;) 10:13:18 #topic A "Developer's handbook" on the wiki? 10:13:46 #vote Yes 10:13:49 ;) 10:13:54 #info proposal in the agenda: http://wiki.koha-community.org/wiki/General_IRC_meeting,_9_January_2013 10:14:09 who is against more documentation - not me :) 10:14:14 +1 from me too 10:14:15 Fleshing out the coding guidelines section, or incorporating it? 10:14:31 oleonard: I think he just wanted to bring all the links/pages together 10:14:36 thd: i can test the functionality of a patch without reading the whole source code. five steps of "do 1, then 2, ... does x work?" are much faster to get thorugh than reading a lot of perl and comments. also non-developers might be testing things (like in a sandbox) and they will probably not touch the patch file at all 10:14:50 +1 What could possibly be wrong with more documentation. 10:15:00 yeah for documentation 10:15:03 +1 10:15:04 I was not trying to manipulate the vote.. I think :) 10:15:19 let me know if/when I can return to test plans 10:15:35 oleonard: moving on ok for you? 10:15:36 +1 10:15:39 +1 from me too 10:15:44 +1 (who could vote -1 ?) 10:15:47 slef: if there is need to discuss, we can create a topic for that 10:15:54 Yes, I think I am confused about where test plans should go. 10:15:58 +1 10:16:00 but let's put it at the end, ok? 10:16:19 OK 10:16:34 #agreed votes are pro creating a 'developer's handbook' on the wiki :) 10:16:44 #topic KohaCon2013 10:16:52 hi, I'm new in koha and ubuntu but. i want to install koha on ubuntu server 12.04.01. Can you give me a step by step tutorial about how to install it 10:16:57 I am not aware of any news here, is someone present who knows more? 10:17:04 Also known as the Magical Mystery Con 10:17:15 lol 10:17:32 oleonard: ooh, do we get to wear costumes? ;) 10:17:33 would someone like to email the organisers and ask how it's going? 10:17:46 I can do that 10:17:55 the last few meetings it was "we are almost done with the hotel stuff"? 10:17:55 mib_vwg7di: someone will direct you to an appropriate resource after the meeting. 10:17:59 #action kf to email the organisers and ask how it's going 10:18:05 thx slef 10:18:15 at tleast that is the last thing i remember about kohacon 10:18:26 (I think I'm allowed to use #action but only chair can use #agreed and #startvote) 10:18:30 ok, next topic... giving you a second to stop me 10:18:47 #topic Cleaning bugzilla 10:18:59 drojf: do you want tos a few words about your proposal? 10:19:28 there is not much to say i think. we have a long backlog on bugzilla with stuff dating to 2009 (i closed all 2008) 10:19:51 drojf++ for that 10:20:06 my proposal would be to close something like "all from 2009+2010" or something so we return to a useful bugtracker one day 10:20:11 please ask my question 10:20:12 I'm really hesitent about marking them WONTFIX as there are probably a few lurking there which we should still fix. The problem is finding the wood among the trees. 10:20:26 I agree with slef 10:20:27 we would not lose the old entries, just mark them resolved/wontfix or something, with the option to reopen 10:20:28 mib_vwq7dj: we are currently holding a community meeting, please come back a bit later 10:20:30 drojf: Is there a way of distinguishing what was closed without full assessment? 10:20:49 I agree with slef too, but I think discussing this is good 10:20:56 mib_vwq7dj: look at INSTALL.ubuntu* in the downloads, or http://wiki.koha-community.org/wiki/Koha_on_Lucid_using_Koha_packages 10:21:02 i dont know much about bugzilla, maybe we can add a reason? closed-automatically or something? 10:21:11 you can do bulk edits 10:21:18 What kind of bug would be a candidate for automatic closing? 10:21:23 and rangi can turn off mailing for this if you want that 10:21:33 mib_vwq7dj: sorry, wrong link: http://wiki.koha-community.org/wiki/Koha_on_Ubuntu 10:21:51 maybe we could do it on a month to month basis in a joint effort? 10:22:12 oleonard: The proposal is bugs over some given age which concerns me unless they can be easily found. 10:22:15 like create a mail to the list ever 2 weeks or so with the oldest 50 bugs still open 10:22:27 and ask people to take a look and close or comment 10:22:42 oleonard: i would close some things that are "old". maybe "all added/edited last 2009" for starters. a klot of that is imported from an old tracker, reported by people that do not work with us anymore 10:22:43 kf++ 10:22:43 drojf: I think it would be pretty harmful to let people point at Koha and say "they say they won't fix $BUG, which is a horrible bug they've known about for years" 10:22:49 could be a saved search 10:22:56 once the list is done, pull up the next 10:22:58 slef: that is what we do now 10:23:01 slef++ 10:23:02 but we dont tell 10:23:09 i don't see how that is better 10:23:11 drojf-- 10:23:18 drojf: no, we're just waiting until we get around to it. 10:23:27 slef: we will never get around to it 10:23:36 drojf: I sympathise with the problem that they often get in the way. 10:23:47 thd: There is no reason to take karma from drojf 10:23:48 unless a fairy drops a lot of time or money on us 10:23:50 I am torn between drojf and slef actually, I can se both points, but I think blindly closing feels wrong 10:23:55 kf: I'd actually go for 12 bugs every 6 days orsomething like that. 10:24:05 20 every week? :) 10:24:22 not saying one alone has to do it 10:24:33 drojf: did your research find out how many are "old"? 10:24:46 (and no, i am not a fan of blindly closing. if we can magane to look at a handful of old things every week, i would prefer that) 10:24:56 Bugs are sorted by date effectively. Is date sorting not sufficient? 10:25:19 slef: i had numbers, but not at home/not my computer. don't remember, but a few hundreds i think 10:25:24 kf & drojf = I also can suspend mails when bulkmodifying bugs 10:25:25 s/Bugs/Open bugs/ 10:25:47 how long is reasonable for us to take to review the old bugs? 10:25:51 paul_p: thx for the info :) 10:25:56 * slef tries to construct a report 10:26:06 what about adding 1st a comment like "is this bug still valid with 3.10 ? in case of no feedback, this bug will be closed in X days" 10:26:24 paul_p++ 10:26:26 yeah,b ut turning off mail for those might be pointless if you want a comment :) 10:26:33 I think we might be better served marking bugs as resolved which are really fixed 10:26:38 i think i spent a few hours looking at 2008 bugs and checking if valid or not. that were... maybe 30? dont remember 10:26:40 oleonard++ 10:26:41 paul_p: I hate it when debian does that. Results in lots of false closures. 10:26:44 kf = of course, I would do that for batch closing ;-) 10:26:47 I'm not sure what the benefit is of closing bugs which are still valid 10:27:05 ok, what I think 10:27:18 bulk closing needs a bigger group/some discussion on the mailing list before we do it 10:27:27 oleonard = the concern of drojf is that there are so much bugs open, that finding the ones that should really have our attention is impossible 10:27:28 because I woudl not feel comfortable deciding that right now 10:27:39 can I suggest 10:27:42 next meeting with a mail to the mailing list would be ok for me tho 10:27:48 paul_p: I think closing fixed bugs will help better than closing unfixed ones 10:27:54 oleonard: The issue is that many bugs are listed but no longer valid. 10:28:08 thd: Is that really the issue? 10:28:14 so maybe until then we could try and do some review process and see if that works 10:28:15 we do some form of kf's "N bugs a week" idea, get through all "old" bugs in 3(?) months, then reconsider bulk closures? 10:28:19 oleonard: and they are not all valid. there is stuff "one person" reported, that person is not on bugzilla. we will never find out. there is stuff that is already fixed by other patches. i would not want to close it all if i knew it is all valid 10:28:39 That is my understanding of the issue please correct me if I am mistaken. 10:28:52 oleonard I think that is because, if I want to fix a bug, I don't know which one to start with. And i'll choose a recent one, for sure. Thus old bugs will never be updated probably 10:29:32 paul_p: nto sure that's true 10:29:37 252 bugs are > 700 days since bug changed. 10:29:50 if a customer reports a bug, you should try seraching first, see if there is more information about the problemon bugzilla 10:29:52 then you can work from that 10:30:14 = about 2.8 bugs per day to get through them in 3 months 10:30:18 you might miss good hints otherwise and on top the original reporter gets feedback about the progress 10:30:27 sorry all, I have to leave, one of my children just got engaged! Bye!!! 10:30:34 congratulations! 10:30:35 slef: that sounds very do-able, if people really do it :) 10:30:35 We need some name better than won't fix for a designation for any prospective date based closing. 10:30:35 Irma: congratulations and bye 10:30:37 Maybe the next few bug squashing days could focus on reviewing the oldest ones first? 10:30:51 davidnind++ 10:30:58 davidnind++ I like that idea 10:31:09 thd: I think we might have REMIND... checking 10:31:26 #idea next few bug squashing days could focus on reviewing the oldest bugs first 10:31:30 slef: Setting "remind" didn't accomplish anything in the past when it was done 10:31:31 oleonard = for me, there are enough valid & known things to do to NOT focusing on old things that I don't know if they're still relevant 10:31:35 thd: yes, we have REMIND 10:31:47 #idea have a regular mail to the mailing list and a searched report with oldest n bugs for review 10:31:48 oleonard: oh sure, but it's a nicer automatic closure reason than WONTFIX 10:32:00 if we source this out to only bug squashing days i assume that is not going anywhere far. or is that supposed to be a plus to a regular checking of old bugs? 10:32:02 The worst bugs as in most annoying but not blockers may be the oldest valid bugs but especially difficult to fix. 10:32:04 so I won't focus on those very old bugs (except for those affected to me, I already cleaned them a few weeks/months ago iirc) 10:32:34 drojf: I would say plus :) 10:32:37 paul_p: Going through old bugs would be a nice way to get folks involved who wouldn't submit patches for GBSD 10:32:42 thd: but then you have discussions there on the bug 10:32:55 oleonard: from the documentation, "WONTFIX: The problem described is a bug which will never be fixed." which isn't really true if we're auto-closing with "please reopen if this is still a problem" 10:32:56 and see they are active 10:33:15 drojf: would you be OK with RESOLVED REMIND instead of WONTFIX? 10:33:24 slef: definitely 10:33:25 it might be poss to have the oldest bugs visible on the dashboard, if there's no objection to making old bugs more visible 10:33:33 +1 for RESO REMIND 10:33:35 wontfix sounds cruel 10:33:41 kathryn: I think rangi already did something similar to that 10:33:44 let's check :) 10:33:59 I was just looking for it...but my eyes are tired! 10:34:02 drojf: hey don't blame me, you put it in your proposal 10:34:05 POSSIBLY RESOLVED REMIN would be better 10:34:08 kathryn: ah, oly for needs sign-off! 10:34:09 slef: :) 10:34:23 #idea add oldest open bugs to koha's dashboard 10:34:32 it's late for you! 10:34:56 ok 10:34:57 oldest open bugs with enhancements filtered out please! 10:35:09 woudl someone volunteer to create a report/mail the mailing list? 10:35:11 slef: Do you not think that RESOLVED REMIND is as misleading as WONTFIX? 10:35:15 and yes,only bugs, not enhancements I would think 10:35:36 I don't thing automatic closing is a good idea - people have put effort and time into creating. The minimum that should be done is reviewing it. I guess the issue is how this is done... 10:35:36 +1 for only bugs in the dashboard 10:35:51 thd: it's still not great, so I'd still prefer to try the mailing old bugs to -devel idea first, but it's better than WONTFIX. 10:36:03 kf: I volunteer. 10:36:08 slef: thank you! 10:36:24 #action slef volunteers to mail the mailing list with old bugs to review 10:36:30 What does RESOLVE REMIND mean? Doesn't make any sense to me me (but I'm not a developer...) 10:36:35 I already have a script that does email and bugzilla. 10:36:36 #idea prefer RESOLVED REMIND to RESOLVED WONTFIX 10:36:51 slef: sounds perfect :) 10:37:02 davidnind: it's not actually defined in the bugzilla help... but I see it as "ask us about this again later if you care about it" 10:37:24 slef: thanks 10:37:33 hm good description, we should put that on the wiki somewhere maybe 10:37:35 I think all resolved remind does it possibly remind the original submitter since they should get an email notification of the change 10:37:50 The presumption of RESOLVED seems mistaken to me. It should be unambiguously qualified. 10:38:01 But resolved remind wouldn't show up in searches, so how is it found by others? 10:38:05 thd: I look for improvements even in the possibilities I don't prefer. 10:38:30 oleonard: are you sure? 10:38:43 slef: No, I assume. 10:38:48 * slef tests 10:38:55 slef: What about POSSIBLY RESOLVED REMIND or some variant which is not certainly resolved. 10:39:07 resolved doesn't show up - I just tested 10:39:26 @query Incorrect encoding convertion in MARC record form 10:39:27 thd: I think we shouldn't invent so many new things in bugzilla 10:39:28 slef: No results for "Incorrect encoding convertion in MARC record form." 10:39:31 (but oleonard = would adding a status (something like "old bug to verify if it's still valid") please you to avoid "RESO - REMIND" ? 10:39:34 thd: it gets painful 10:39:37 oleonard: you're correct 10:39:47 s/(but// 10:39:50 kf: What do you mean by does not show up? 10:39:55 that was bug 1634 10:39:55 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1634 normal, P3, ---, gmcharlt, RESOLVED REMIND, Incorrect encoding convertion in MARC record form 10:40:05 if you search for keywords, the bug does not show up if it's marked resolved 10:40:11 only if you specify your search to make then 10:40:16 or add ALL at the begining of your query 10:40:25 @query ALL Incorrect encoding convertion in MARC record form 10:40:34 slef: 04Bug http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=1634 normal, P3, ---, gmcharlt, RESOLVED REMIND, Incorrect encoding convertion in MARC record form 10:40:39 I did not know that. 10:41:10 but with ALL you'll also get RESO-FIXED & CLOSED, right ? 10:41:16 probably most users will want to do ALL searches, so they can see it was fixed in version 3.X.Y and know what they want to upgrade to 10:41:27 this should be publicised more 10:41:31 ok, I think we put down some ideas and have a plan to try out - could we agree on moving to the next topic? 10:41:36 10:41:40 kf: yes, sorry boss. 10:42:09 just trying to make this not go forever :) 10:42:15 kf: yes, sorry boss. 10:42:16 kf: sounds ok for me 10:42:18 drojf: are you ok witht hat, as it was your proposal? 10:42:19 ah, ok 10:42:23 :) 10:42:28 #topic Actions from General IRC meeting, 5 December 2012 10:42:34 not sure what goes here, someone? 10:42:47 but... that was last year! 10:42:50 * slef scrabbles 10:42:50 * drojf hides 10:43:11 ok, the only action items I can see are: 10:43:11 people start thinking about if we have disabled any features by default that shouldn't be 10:43:12 Action Items ------------ * people start thinking about if we have disabled any features by default that shouldn't be 10:43:40 so, have people thought about it? ;) 10:43:43 anyone been thinking deeply about Koha over the holidays? ;-) 10:43:53 I woudl like to see that as another reminder and encourage to file bugs if you have an idea :) 10:43:56 I still think the time travel feature is too dangerous to enable by default 10:44:08 #action people keep thinking about if we have disabled any features by default that shouldn't be 10:44:13 oleonard: agreed, but we should have the beamer/transporter activated 10:44:33 ok 10:44:46 test plans? 10:44:53 ice 10:44:56 icu 10:44:58 * drojf hides even more 10:45:01 # Test plans 10:45:22 drojf: I think we can't activate that by default as long as pakages don't support it as option 10:45:29 #topic Test plans 10:45:35 slef, thd? 10:45:43 Where do test plans go? 10:45:49 kf: yes i actually mean the missing icu option in the packages 10:45:52 into the commit message 10:45:57 bug description/comments or commit messages? 10:46:19 #link http://wiki.koha-community.org/wiki/Commit_messages 10:46:20 I feel like I'd expect it in the bug description, not the commit messages. 10:46:27 see the example for a good commit message there 10:46:31 i think jcamins_away would like to see them in the commit message 10:46:40 If you use git-bz to attach patches your test plan will appear in Bugzilla automatically with the commit message 10:46:43 slef: the problem is, they get rewritten, amended, etc. a lot, so it's quite hard to findon bugzilla 10:46:44 Can the commit message be arbitrarily long? 10:46:51 and I like to see in git how things work, test plans help with that there too 10:47:08 thd: yes 10:47:11 thd: I haven't heard someone reached a limit yet :) and I write pretty long commit messages when testing sometimes 10:47:33 I think if you have something really big, you could put a link to a wiki page 10:47:49 slef = hélas, as long as it's impossible to update description, we can't rely on the bug description, because the test plan changes between initial submission of the bug & the patch ! 10:47:52 if it is huge, have an rfc or something? 10:47:55 Shouldn't a test plan should pertain to a bug, not to a patch? 10:48:03 drojf: yep, that's what I think too 10:48:07 and paul_p: agreed 10:48:19 The test plan tells QA how to test the patch slef 10:48:20 paul_p: last test plan wins? 10:48:29 slef yep ;-) 10:48:33 slef: often you find more problems ... than you initially thought there were 10:48:37 slef: Test plans should relate to both a bug and a patch. 10:48:50 Please keep in mind that the guidelines have already been set by the RM, so this discussion shouldn't be about whether to change it 10:48:51 and some patches for one feature also endanger other parts, so test plans need to be a bit bigger 10:49:02 oleonard++ 10:49:04 oleonard: ok. 10:49:09 and jcamins++ for good instructions :) 10:49:38 oleonard: so one of the workflow and the commit messages wiki page is probably wrong, or do we want N(patches)+1 test plans for each bug? 10:50:01 I think test plan describes more than one test 10:50:05 a series of steps and tests to do 10:50:38 The commit messages page should be considered the official version at this time. I don't know what other pages conflict with that advice 10:51:11 Danger is lots of commit messages currently do not tell you what change they introduce 10:51:26 oleonard: http://wiki.koha-community.org/wiki/Bug_Reporting_Guidelines#Description 10:51:26 * kf nods 10:51:39 oleonard: not conflict exactly, but seems to duplicate 10:52:01 ColinC: and it's taking too much time to find out 10:52:06 Bug reporting is separate from commit messages I think 10:52:31 yes, bug reporting is for everyone, we can help people there, also new developers 10:52:36 kf: and http://wiki.koha-community.org/wiki/Commit_messages doesn't tell people to say what changes they introduce. 10:52:43 but I think haveing soe guidelines is good and makes you think about what you do even 10:53:02 A description of what problem the bug addresses, or what feature it adds. 10:53:07 bug/feature description 10:53:22 #link http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs 10:53:24 You're right slef, and it should 10:54:06 so more from the code side of things? 10:54:17 #info that's not perfect for us, as it doesn't include the bug/feature summary, which is one thing we do better, but it does show how to describe the change fully 10:55:31 kf: I think that's what ColinC was driving at, but he'd have to confirm. 10:55:34 Can I also grumble about blank wiki commit messages here? ;-) 10:55:45 slef: thought you already did recently :) 10:55:47 again? :P 10:56:02 hehe 10:56:33 I am all for documentation 10:56:49 so maybe we could amend that it should also contain developer like descriptions of changes? 10:56:54 as well as functional description? 10:57:30 ok, final query from me on this: in the most common case (test plan from bugzilla still applies), should I repaste the test plan from the bugzilla, or write "see bugzilla"? 10:57:44 repaste 10:58:18 slef: Because someone may not be looking at Bugzilla, just applying patches using git-bz 10:58:20 you never know what happens on bugzilla between you putting the patch there and me or somene else looking at it 10:58:37 +1 for repaste. more load on bugzilla but the latest infos in the latest entry 10:58:52 oleonard: if they're not looking at Bugzilla, how do they know if the patch fixes the bug? 10:58:58 * slef boggles 10:59:08 it's all in the commit 10:59:11 message 10:59:13 ideally 10:59:20 the commit message could be fibbing 10:59:25 slef: RM or QA looking at Bugzilla emails for instance? 10:59:31 oh yes 10:59:34 and anyway, you still have to look at Bugzilla to mark it "Signed Off" 10:59:44 s/fibbing/misunderstanding the bug report 10:59:45 I have to read a gazillion of mails lately and more than happy to get a complete picture 10:59:52 slef: git-bz! 11:00:03 git-bz++ 11:00:07 and it may not mention the other two bugs it inadvertantly fixed or the three it introduced 11:00:18 ColinC: that's true 11:00:23 oleonard: has someone extended it to edit the bugzilla fields and not bothered to send a pull request? 11:00:31 you can't see relations betwee bugs (yet) 11:00:42 slef: there is a git-bz repo on kc-org now 11:00:52 forkers :P 11:01:41 ok, anything that should be added to the minutes? #info etc? 11:01:52 paul_p: I think that your proposal to change bug status without necessarily changing resolution is much better than some hybrid non-standard resolution. 11:03:05 kf: was that announced and I just missed it? 11:03:27 slef: I am not sure 11:03:32 i didn't know 11:03:39 but that does not mean anything 11:03:42 ohhhh I see 11:03:43 * thd about to be involuntarily disconnected 11:03:44 #link http://git.koha-community.org/gitweb/?p=git-bz.git;a=summary 11:04:05 people set up a repo on k-c because I wasn't including koha-specific changes (as I actually use git-bz for other things) 11:04:26 ? 11:04:44 maybe just set one pu because it's flexible 11:04:49 and a central place 11:05:28 "Teach git-bz to optionally sign off when applying patches ... DO NOT USE THIS OPTION AS AN ALTERNATIVE TO ACTUALLY TESTING CODE." 11:05:30 * drojf giggles 11:06:11 argh, and it hardcodes koha-patches@... 11:06:15 we have reached an hour now - i would like to sset the date/time for next meeting 11:06:39 6 February 2:00? (previous meetings: 7 Nov - 2:00, 5 Dec - 18:00, 9 Jan - 10:00) 11:06:51 #topic Time/date for next meeting 11:07:11 ah, the evil time. go nuts with the date, will be in bed :) 11:07:18 same here 11:07:32 davidnind: thx for looking upt eh times .) 11:07:35 davidnind++ 11:07:48 slackers ;) 11:07:53 and noone who will be awake then is here? 11:07:53 evil must mean happy for me :) 11:08:06 I think something like 3/4 pm for you 11:08:07 iirc 11:08:08 6 Feb looks ok to me at the mo 11:08:27 oh! 6 feb is public holiday in NZ so not ideal 11:08:44 oh. maybe better take a week later then 11:08:50 kathryn: would 7th be ok? 11:08:53 kathryn: move by a day or two weeks? 11:09:05 I think having another meeting sooner is better, not postpone it too long 11:09:20 That time is okay for me, but if it's bad for everyone else let's not do it then 11:09:27 or you can go for 13th if you don't mind me missing 11:09:33 day either side is no worries for the Catalyst lot so far as I know :) 11:09:42 7th? 11:09:42 7th is worth a try 11:09:45 oleonard: only bad for everyone else that likes today's time ;) 11:09:48 thanks wahanui 11:10:06 happy with day either side 11:10:14 I never got to be friends with the new meeting times 11:10:21 7th is good 11:10:22 ok, 7th 11:10:22 7th is better for being well after ALA midwinter. 11:10:35 wahanui: gerundio's stomach? 11:10:36 gerundio's stomach is complaining too much 11:10:45 #info Next meeting is 7 February 2:00 UTC 11:10:46 (13th is fine too) 11:10:49 hope that was right 11:10:50 :) 11:11:11 kf++ 11:11:16 #endmeeting