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