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