20:03:47 #startmeeting 20:03:47 Meeting started Wed Jun 27 20:03:47 2012 UTC. The chair is rkabalin. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:03:58 Hello and welcome to 17th Mahara Developer Meeting 20:04:12 #info anitsirk is Kristina Hoeppner, Catalyst IT, Wellington, NZ 20:04:13 Please state your names with #info prefix 20:04:28 #info Andrew Nicols, Lancaster University, UK 20:04:33 #info Ruslan Kabalin - Lancaster University, UK 20:04:37 #info richardm Richard Mansfield, Catalyst IT 20:04:43 hi richardm 20:04:47 hi anitsirk 20:04:48 #info is Melissa Draper, Catalyst IT 20:05:21 not that many people 20:05:29 #topic Items from last meeting 20:06:19 go directly to point 3, since dajan/anzelijg is not here 20:06:40 i also haven't seen a wiki page from anzeljig yet 20:06:55 #info 3. melissa/elky to publish a dev forum post about the 6 monthly release cycle 20:07:17 I'm trying to find it 20:08:12 https://mahara.org/interaction/forum/topic.php?id=4547 20:08:39 anitsirk, wins by seconds :D 20:09:13 rkabalin and dobedobedoh: did you have a chance to look it over? 20:09:32 no 20:09:42 Sorry - not had a chance 20:10:18 Makes a lot of sense to me. I'd vote that we tie it in relatively close to the moodle cycle 20:10:49 i'm not so sure. moodle is released in dec / jan or june and that is right on the edge of academic years 20:11:13 that's why we were proposing april / october as per an earlier discussion we once had to give people time to make the switch in the summer 20:11:37 If it's released just before the holidays, it gives people a chance to evaluate changes and make sure that they're happy with things first 20:12:39 Just my thoughts ;) 20:13:22 timing with holidays is only relevant outside the US. US holidays are all over the place because each district gets to decide on their own 20:13:55 elky: not entirely. there are universities who pretty much have a summer session which is often used to update systems 20:14:14 the actual holiday days vary but so do they in europe and in nz 20:14:16 We make use of that, but it's easier to schedule if the release is definitely out 20:14:49 and april / october would ensure that. those with lots of customizations may need a bit more than 2-4 weeks to get their testing sorted etc. 20:15:17 true 20:15:19 anitsirk, that's where freezing helps 20:15:24 either way - looks good to me :) 20:16:03 ok. so shall we try the 6 monthly cycle for the next release and aim for october? 20:16:04 I like the idea of fixed date release 20:16:36 I do too 20:16:48 yep, we need to try to be able to say if it is good or not 20:17:24 yep. if we never try we'll never know 20:17:34 regarding 'release when there are updates to release' 20:17:36 and we need to try it for more than 1 release too 20:17:58 there always be updates I think 20:18:08 security updates 20:18:34 security should go to current stable 20:18:43 rkabalin, they do 20:19:03 and all debian/ubuntu packages in supported distro versions 20:19:44 in the rare case when there is absolutlely no new feature to release, we potentially can skip one release 20:19:52 rkabalin: i see your question. it's related to either release when therea re updates to release or have a fixed date for the release. 20:19:52 but I doubt it will happen 20:20:06 i hope that won't happen. :-) 20:20:41 I suggest to have a fixed date as normal release cycle 20:20:47 rkabalin, it could mean having releases leaving out security bugs becuase of time though. 20:20:55 and i'd really not like to have to do that 20:20:58 but just have a backup case in case we have nothing to release 20:21:11 but even with a normally fixed date we could still be flexible, cf. moodle HQ just now with 2.3 20:21:13 er, security fixes 20:21:25 moodle also has a much bigger workforce 20:21:39 but they still had to push the release back 20:21:55 I see what you meant elky 20:21:58 i don't think, with the current contributor rate, we can maintain a scheduled point-release thing 20:22:02 And it wasn't just moodle HQ contributing though 20:22:15 that's possibly the bigger issue 20:22:23 you are robably right, fixed day relase cycle and no excuses 20:22:23 elky: you mean 1.6.1, 1.6.2? i'm only talking about 1.6, 1.7 20:22:30 anitsirk, oh 20:22:44 i thought we already agreed to doing those scheduled :D 20:23:05 minor updates in between major point releases i'd do when we have security updates / major things to fix 20:23:06 it is always useful to agree again :) 20:23:18 then somebody put an #agreed somewhere ;-) 20:23:37 i think rkabalin might have to do that in order for it to show up 20:23:55 i think i messed that up last time during the voting as i wasn't chair and thus the agreed didn't show in the minutes 20:24:15 anitsirk, i thought that was because you had a superfluous : 20:24:25 #agreed Mahara release cycle is set to fixed period of 6 month 20:25:12 #info the first release in the new shedule will be in October 20:25:37 I think we agree about updates too, yes? 20:26:06 we release despite whether we have updates or not 20:26:34 i think elky is now talking about minor point releases 20:26:35 for 1.6.1 etc? 20:26:58 we need to say something since it was raised in the forum post 20:27:20 at least i read it as being raised 20:27:26 I think that point releases should be more flexible 20:27:36 Since they're bug fix releases 20:27:40 i would see for the first fixed release. if we only release security fixes, a fixed minor release may not be good. if we also put other bug fixes in - like moodle - we could stick more to a minor release schedule 20:28:17 dobedobedoh: i think we may not have settled on that yet. so far we've only done security bug fixes and really major regular bug fixes, but not much beyond that 20:28:38 so i think we need to be clear of what "bug fix" means. regular and security or only security 20:29:09 I guess it depends on manpower 20:29:29 and on how many users are affected to what degree 20:30:48 I do not see a reason to have minor point release shedule at the moment 20:31:22 rkabalin, nor i. mostly because i don't think we'd be able to honor it 20:31:22 there are not that many fixes go to stable, so that we would be able to predict 20:32:08 so, I suggest to stick to the current policy 20:32:19 agreed 20:32:32 minor point release after security fix or major bug 20:32:43 #agreed minor point release after security fix or major bug 20:33:18 do we have anything else related to this? 20:33:39 i don't think so 20:33:41 no 20:33:44 ok 20:33:53 yes, but it's hugh's item and he's not here 20:34:03 point 4 - we are missing the person 20:34:06 unless hughdavenport is really here and pretending to not be? 20:34:27 i think we're missing everyone for the agenda items except kristina 20:34:33 he' not in the office yet. 20:34:38 elky: you share an item with hugh 20:34:48 ok, let us go to the main topics 20:34:57 anitsirk, yeah, i completely forgot about it and he's not here. 20:35:09 #topic Discuss/decide on style guidelines for CSS https://reviews.mahara.org/#/c/1098/ Melissa/Hugh 20:35:52 anitsirk, i'd be quite surprised if he's not awake though. perhaps send him an sms? 20:35:55 i guess we need to table that as elky just said she forgot about it and hugh isn't here 20:36:09 elky: sure. go ahead 20:36:31 next topic 20:36:35 uh... i have to look his # up first... do you have it in your phone? 20:37:31 #topic Google Apps block in Mahara 1.6? cf. https://mahara.org/interaction/forum/topic.php?id=4641 (Kristina) 20:37:39 hugh is on his way. he'll be here in about 10 minutes 20:37:43 ok. google apps. 20:37:53 i think before i write much, just glance over the forum post 20:38:22 the gist: i was wondering if we still need the google apps block in 1.6 now that we have the safeiframe feature and the admin interface to easily add any iframe base url (1.6 feature). 20:38:35 #info: the gist: i was wondering if we still need the google apps block in 1.6 now that we have the safeiframe feature and the admin interface to easily add any iframe base url (1.6 feature). 20:39:30 the task of us maintaining filters lists can die in a big chemical fire as far as i'm concerned, especially since there's a more flexible alternative 20:39:41 I may be slightly bitter about it ;) 20:39:41 it's always a hassle to update when google makes any changes. the only disadvantage i would see is that we lose the built-in help instructions of how to get the embed code 20:40:07 You'd also lose the ability to centrally change all existing google docs 20:40:21 dobedobedoh: what do you mean? 20:40:39 Well, if lots of google apps docs are in place, and google change the link 20:40:45 then that'll break them all (I assume?) 20:40:53 dobedobedoh, you add new filters, not take old filters out 20:40:57 Ah ok 20:40:58 that's how we do it now 20:40:58 but that happened now 20:41:03 In which case, ignore me ;) 20:41:16 anitsirk, i think he means the ones already in the data of the blocks 20:41:32 and in the safeiframe thing you can do the same. you can add as many google urls. glogster needs quite a few as well, but only one icon shows up 20:42:21 anitsirk, there should be a way to make an instructions box for the admin to fill out accordingly 20:42:51 i'd be for removing the block to make things simpler because we still need the google stuff in the safeiframes so that can be used in text boxes etc. 20:43:28 then we also know all external content can be put in via the "External media" block. 20:43:50 If we removed it, I assume there would be an upgrade path? 20:43:53 but of course with deprecating a feature, there is the question of how to migrate it to the external media block for example 20:43:56 anitsirk, how would that go past an upgrade? what would happen to blocks that are already made? would they be converted? 20:44:00 dobedobedoh: there definitely has to be one 20:44:06 otherwise people will lose all their data 20:44:07 heh, 3 of us thought the same thing :D 20:44:29 well, i'm not a dev so i don't know how that would work. i just know it would need to be done. ;-) 20:44:42 anitsirk, iirc they're very close to text blocks, we might be able to convert easily 20:44:59 I support safeiframe, but do not see the reason why we need remove google aps block... 20:45:24 i thought of the external media block as the format of that is closer (no need to click on "HTML" first to get to the source). but whatever is best 20:45:28 rkabalin, mostly because i had to update it fully one hundred times between 1.4 and 1.5 20:45:37 not quite... 20:46:03 ok, no block maintainer 20:46:08 then remove 20:46:23 rkabalin: this is a feature that broke most of the time and if admins don't patch their code, the block can't be used. updating the base url in the admin interface seems much easier 20:46:25 or rather list in contrib plugin 20:46:46 that's where it was before but because it was a high-in-deman feature, we put it into core 20:47:06 I see 20:47:06 and at the time it was really great to have. i had many positive comments about it. 20:47:13 it was the best we had at the time 20:47:27 but even if we put it back into contrib, we need an upgrade path, don't we? 20:47:32 yes 20:47:52 the windows live plugin is still in contrib and essentially the same. but i think almost all can be done via safeiframe now 20:48:14 if i understood gregor right, he may well stop maintaining it too 20:48:26 in the contrib it will be in the state - "if we have enthusiastic maintainer - it is upgraded" 20:48:47 if not, then it is getting old 20:48:49 we have other options now: safeiframe, then at some point probably also laurent's oembed code... 20:49:05 morning all, sorry i'm late 20:49:14 hi hughdavenport 20:49:26 #info is Hugh Davenport, Catalyst IT Ltd 20:50:11 so should we think about deprecating the block and having an upgrade path for 1.6 or worry about that for 1.7? 20:50:17 anitsirk, how about we table this with one of us tasked to look at the upgrade path? 20:50:19 so, yes, we probbaly can remove google app block from the core, I am conviced now 20:50:26 actually i've got another safeiframe related question, once we've decided on googleapps 20:50:38 elky: sure. who wants to look into it? 20:50:44 i guess me 20:50:48 hehe 20:50:53 since i'm the one who wants to burn it 20:51:21 #action elky look into removing google apps block from the core 20:51:35 richardm, does your q require us knowing the upgrade path? 20:51:48 great. 20:52:07 no, in 1.6 a site admin can trivially create xss via the iframe list, do we care? 20:52:28 or should there be something in config.php to turn that on maybe? 20:52:35 oh. that's not good 20:52:48 so they could put any code in and have XSS? 20:53:02 well, they can whitelist any dodgy site they like 20:53:08 richardm, the site admin touches the code in 90% of cases. think a config option that can't be done by someone without disk access would be good 20:54:11 elky: site admin = front end user, sys admin / dev = backend user. so if you want to stop me from putting in XSS code, you could have that in the config to prevent me as i don't have access to that on the server. ;-) 20:54:12 so we disable the iframe config list by default, and force it to be enabled in config.php? 20:54:32 anitsirk, yes, but a majority of cases those are the same person 20:54:46 mhh. but then the site admin can still do XSS. shouldn't we prevent that? 20:55:14 once enabled, we still have the same problem if the admin forgets to disable it in config.php afterwards 20:55:22 so perhaps it should be a timer or something 20:55:56 i think we have to accept that people will find a way to shoot themselves in the foot with or without our help 20:56:24 perhaps we can do something with google's safebrowsing list 20:57:05 if it involves a domain that returns a positive response, it can't be included unless someone does changes the config file to allow it 20:57:50 #link https://developers.google.com/safe-browsing/ 20:58:30 yeah sounds like a lot more work to use that 20:58:45 but i guess that's not really going to be my problem 20:58:46 it does, but it's an option and we have to decide how much we care 20:58:48 shall we move iframe discussion to next meeting? 20:58:53 rkabalin, yep 20:58:56 safeiframe 20:59:17 we're approaching an hour of meeting time 20:59:27 as it will take some time to decide something on it 21:00:05 #action safeiframe xss vulnerabilities discussion move to next meeting 21:00:11 right 21:00:17 back to point 2 21:00:18 yep, action me for further thoughts on that, i might re-allocate though 21:00:25 Hugh is here not 21:00:28 now 21:00:29 he is now 21:00:51 #topic Continued: Discuss/decide on style guidelines for CSS https://reviews.mahara.org/#/c/1098/ Melissa/Hugh 21:01:21 hughdavenport, did you have further thoughts on that? 21:01:37 what have you said so far? 21:01:41 nothing 21:01:53 nothing, i forgot all about it since last meeting 21:02:05 righto 21:02:26 hope you remeber anything about it hughdavenport ;) 21:02:37 lemme go look at minuteses 21:02:59 i just think that we need to extend the coding guidelines for languages other than php, we use php, js, css, but the current guidelines just mention php and have a small link for js 21:03:03 css has nothing at all 21:03:15 that is great idea 21:03:20 I think 21:03:21 *most* of the css has TAB indents, not space indents 21:03:31 aiui 21:04:04 hughdavenport, where by "most" you mean "somewhere above 50%"? 21:04:24 i think this just needs someone to take the charge and edit the page for other languages for next meeting, i would say me but i'm on leave next month 21:04:34 it's all over the place. anywhere _we_ have touched it, it has spaces. Wherever our designer has, i think it's tabs 21:04:35 elky: more like "all the css i've touched has had it" 21:04:53 though i think sometimes i've kept with the tabs and sometimes spaces 21:05:14 but yes, volunteers to edit the guidelines wiki page for other langs? 21:05:19 anyone willing to work on this documentation extending? 21:05:20 yeah, same, it's usually depended on if its a new definition or old 21:05:37 yeh 21:05:54 #info we need volunteers to edit the code guidelines wiki page for other langs 21:05:55 hughdavenport you like rules lawyering? 21:06:20 by that do you mean checking over the page? 21:06:26 * hughdavenport hasn't heard that saying 21:07:06 perhaps you haven't been involved in wikipedia ever? 21:07:15 negatory 21:07:22 Its community is roughly 90% rules lawyers 21:07:30 only made one edit to make me win a bet that I may of been wrong about :P 21:07:48 http://en.wikipedia.org/wiki/Rules_lawyer 21:08:27 so, back to the topic 21:08:29 aaaanyway, do you want to update the doc? 21:08:51 heh, i would but on leave next month 21:09:06 uni probably wouldn't like it if i actually worked during that leave :P 21:09:17 oh, right. i guess that's me again then 21:09:36 i am going to be hating on you so much when you get back, i sense it now. 21:09:38 i would be fine with reviewing changes etc 21:09:41 hehe 21:09:52 my brain will have fallen out by then 21:09:56 #action elky/hughdavenport update code guidelines and extend it to other than php 21:10:08 hughdavenport, that'll dull the pain 21:10:36 righto, next topic? 21:10:40 next topic 21:10:47 #topic hughdavenport: Discuss how long we support releases for and/or the posibility of a LTS release 21:10:51 ah fun 21:10:55 heh 21:11:37 so do we want to support 3 releases or do we want an LTS (i think that would just be confusing for everyone involved) 21:11:45 right, so now that we have moved to 6 monthly cycles, I don't think our current approach of supporting back 2 versions will suffice. basically only a year of support and requires users to upgrade once a year on a certain day 21:12:11 2-year support? 21:12:11 other option is an LTS approach, but would need some thinking about that, and not sure if would suit us, as still not the biggest team :D 21:12:45 LTS, my forst thougt was no (for now at least) 21:12:46 i think 1.5 should suffice, gives users half a year to get a into g and upgrade, 2 years could be a bonus, with extra work on us 21:12:49 hughdavenport, it's also confusing. it is perpetually confusing with UBuntu for example 21:13:29 where it = lts 21:13:32 though, it also comes down to how many things in debian we support, that now has 2 year stable releases, so i guess 2 years fits nicely there 21:13:56 so 2 year support? starting when? 21:14:02 phased in? 21:14:10 2 year / 4 releases 21:14:16 that kinda means we're maintaining 4 releases worth of patches 21:14:27 only security though 21:14:29 security updates are going to start taking a month on their own :-/ 21:14:36 which we already do for debian 21:14:40 we can't say that we're suddenly still supporint 1.3 for security. has to be phased in as we release new versions 21:14:52 dobedobedoh: yeh, that is a point 21:14:57 #agreed 2-year support (4 releases) 21:15:04 dobedobedoh, yes, it'd just mean we won't drop 1.4 21:15:17 what? there was agreement? 21:15:34 i don't recall agreeing. 21:15:42 #undo 21:15:42 Removing item from minutes: 21:15:43 i think that we can drop 1.4 when 1.6 is released, under old rules, but then from then on support everything 21:15:45 sorry 21:15:57 everything=for 4 releases 21:16:57 hughdavenport, that means 1.5 would only go for 1 year, no? 21:17:17 1.5 will go until 1.7 is released 21:17:24 1 year 21:17:33 basically yeh :P 21:17:55 unless we decide that it is in the new system, then we support for 2 years 21:18:09 why 1.5 can't go till 1.9? 21:18:21 what about when a major release happens? 21:18:27 because with hugh's logic, it's already out 21:18:44 i would say it can, as it is 6 months before 1.6, so is part of new cycle 21:18:54 ah, old rules 21:19:01 ok 21:19:04 so drop 1.4 when 1.6 comes, 1.5 stays 2 years, 1.6 2 years, etc 21:19:16 whether 1.5 stays 2 years or 1 is up for discussion 21:19:29 it coudl stay for 18 months? 21:19:43 hughdavenport, so previously with 9/10 month release cycles, we're upgrading from 18mths to 2 years of support to avoid 1 year support 21:20:48 yeh basically 21:21:03 otherwise you get schools and the such having to upgrade on the same day every year 21:21:08 I think that's making our work load significantly bigger, yes. it means for an ubuntu lts, the support would be nearing 7 years of security updates 21:21:35 how many do we have for the 18mths? 21:21:44 #info discussing possibility to support release for 2 years, will be phased in from next release. Re. existing, we drop 1.4 when 1.6 comes, 1.5 stays 2 years, 1.6 2 years, etc, optinally 1.5 can stay for 18 months 21:21:47 usually 6 21:21:51 we can stick with 18mnths, with supporting only 3 releases back 21:21:57 1.2 is still going 21:22:16 elky: for how long? 21:22:30 anitsirk, give me 5 to check 21:22:34 how does that relate to debian? as that also has 2 year stables which is akin to ubuntu lts 21:23:46 april 2015 21:24:04 until lucid lts EOLs 21:24:31 hughdavenport, 5 years server is longer than 4 years 21:24:45 ah yeh, they support servers for ages.. 21:25:36 so should we stick with just 18months, 3 releases back 21:25:36 1.4 geos when 1.6 comes, 1.5 stays till 1.8, 1.6 till 1.9, etc 21:25:57 so nov 2009 to april 2015 21:26:04 5.5 years 21:26:09 then would be similar to what we have now, and can continue to rage at ubuntu :P 21:26:16 yep 21:26:51 do everyone agree? 21:27:03 yup, im happier with this 21:27:09 18 month / 3 releases back 21:27:13 Looks good to me 21:27:22 will 1.4->1.6 be 18 months? 21:27:27 #agree support 3 versions back, 1.4 will go with 1.6, 1.5 will go with 1.8, 16 with 1.9 21:27:39 richardm, no, old rules for 1.4 21:27:53 richardm: roughly i think, but then our previous releases weren't always on time 21:27:59 when was 1.4? 21:28:32 about this time last year 21:28:34 heh, apparently drupal supports 4 years back :P 21:28:51 swt, so will be just under 18 months, but still over a year, i'm happy with that 21:29:02 and gives a precise time when support stops 21:29:04 hughdavenport, that also results in drupal 6 staying forever 21:29:14 heh i can guess 21:29:56 anything else we need to discuss on this topic? 21:30:12 unless any complaints on the 3 versions back, then no 21:30:30 #agreed support 3 versions back, 1.4 will go with 1.6, 1.5 will go with 1.8, 16 with 1.9 21:30:52 #topic next meeting / Chair 21:31:11 one month from now is 27 July 2012, 7:30 UTC 21:32:04 i'll not be able to make the july meeting as i'll be travelling. in july i'll be in the US and thus the time zone won't work. but never mind me. 21:32:08 ok, or move it 1 week forward 21:32:41 still not good ;-) but don't worry about me. i'll read the minutes 21:32:54 1 August? 21:33:31 anitsirk, what are your travel dates? 21:33:39 rkabalin: i'll be in europe on the 6th. that's the earliest when any of our regular times would work for me. but don't worry about me 21:33:49 but i might not have internet right away 21:34:06 i'll be gone 11 july to 1 september 21:34:39 i should be able to make the august dev meeting fine as i'll be at my parents place then (i believe if it works out to be before aug. 25). 21:34:40 hughdavenport, what are your leave dates? 21:34:48 other than that it's a bit tricky. 21:34:54 9-20, but i can remote in 21:35:16 August 8th then? 21:35:27 hughdavenport, no you won't, you'll have enough to deal with 21:35:31 rkabalin: i can't promise. 21:35:39 just pick a july date ;-) 21:35:42 hehe, i'll probably enjoy the break :P 21:35:48 if you try, i'll make the sysadmins suspend your vpn access :P 21:35:58 he doesn't need vpn for the dev meetings 21:36:07 what anitsirk said :P 21:36:16 let us do August 1st, 7:30 UTC 21:36:25 any objections? 21:36:35 nope 21:36:39 anitsirk, but it'll stop him from doing worky stuff by accident 21:37:06 fine with everyone? 21:37:09 nope, but it does mean we missed july 21:37:22 as in yes it's fine, but... 21:37:24 so, you want a week earlier? 21:37:41 25th July 21:38:00 (less than month from now).. 21:38:13 aug 1 is fine 21:38:23 we'll pretend it's july 21:38:54 July 31st 21:39:10 not to pretend :) 21:39:21 OK? 21:39:30 hehe, ok 21:39:35 This is Tuesday 21:40:16 fine with everyone? 21:40:25 Works for me 21:41:11 #agreed next dev meeting Tuesday, July 31st, 7:30 UTC 21:41:20 who wants to chair? 21:41:53 if we go by the rotation schedule, it's NZ 21:42:02 as it's in our evening. but i can't ;-) 21:42:31 I'll do it again 21:42:49 sure? 21:42:52 #link http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120731T0730 21:42:53 hugh may possibly be snowed under playing catchup 21:43:04 oh god :( 21:43:07 moreso than usual 21:43:19 hehe 21:43:28 nothing can happen next month, then i will be happy 21:43:40 murphy heard that. 21:43:53 General request: Can we (please) swap the order of the meetings on the wiki page? Every single time, I look at the time for the top meeting and keep turning up at the wrong time :| 21:44:25 )) 21:44:36 dobedobedoh, ok, it's actually getting too long, i'll reformat it altogether 21:44:36 murphy can join mysql in the pit of flames i created 21:44:42 and the wrong year 21:45:24 Sorry - I'll bring up the otherpiece of my AOB in the AOB section 21:45:43 so, elky, you will chair the next meeting? or Hugh? 21:45:48 i will 21:45:50