diff --git a/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.html b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.html new file mode 100644 index 0000000000000000000000000000000000000000..d0478d6df7aef03eff69bc632669eb1ae12d1834 --- /dev/null +++ b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.html @@ -0,0 +1,244 @@ + + + + +#mahara-dev Meeting + + + + +

#mahara-dev Meeting

+ +Meeting started by rkabalin at 20:03:47 UTC +(full logs). + +

+ + + +

Meeting summary

+
    +
  1. +
      +
    1. anitsirk is Kristina Hoeppner, Catalyst IT, + Wellington, NZ (anitsirk, + 20:04:12)
    2. +
    3. Andrew Nicols, Lancaster University, UK + (dobedobedoh, + 20:04:28)
    4. +
    5. Ruslan Kabalin - Lancaster University, + UK (rkabalin, + 20:04:33)
    6. +
    7. richardm Richard Mansfield, Catalyst IT + (richardm, + 20:04:37)
    8. +
    9. is Melissa Draper, Catalyst IT (elky, + 20:04:48)
    10. +
    +
  2. +
  3. Items from last meeting (rkabalin, 20:05:29) +
      +
    1. 3. melissa/elky to publish a dev forum post + about the 6 monthly release cycle (rkabalin, + 20:06:55)
    2. +
    3. https://mahara.org/interaction/forum/topic.php?id=4547 + (anitsirk, + 20:08:12)
    4. +
    5. AGREED: Mahara + release cycle is set to fixed period of 6 month (rkabalin, + 20:24:25)
    6. +
    7. the first release in the new shedule will be in + October (rkabalin, + 20:25:12)
    8. +
    9. AGREED: minor point + release after security fix or major bug (rkabalin, + 20:32:43)
    10. +
    +
  4. +
  5. Discuss/decide on style guidelines for CSS https://reviews.mahara.org/#/c/1098/ Melissa/Hugh (rkabalin, 20:35:09) +
  6. +
  7. Google Apps block in Mahara 1.6? cf. https://mahara.org/interaction/forum/topic.php?id=4641 (Kristina) (rkabalin, 20:37:31) +
      +
    1. : 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). (anitsirk, + 20:38:35)
    2. +
    3. is Hugh Davenport, Catalyst IT Ltd (hughdavenport, + 20:49:26)
    4. +
    5. ACTION: elky look + into removing google apps block from the core (rkabalin, + 20:51:21)
    6. +
    7. https://developers.google.com/safe-browsing/ + (elky, + 20:57:50)
    8. +
    9. ACTION: safeiframe + xss vulnerabilities discussion move to next meeting (rkabalin, + 21:00:05)
    10. +
    +
  8. +
  9. Continued: Discuss/decide on style guidelines for CSS https://reviews.mahara.org/#/c/1098/ Melissa/Hugh (rkabalin, 21:00:51) +
      +
    1. we need volunteers to edit the code guidelines + wiki page for other langs (rkabalin, + 21:05:54)
    2. +
    3. http://en.wikipedia.org/wiki/Rules_lawyer + (elky, + 21:07:48)
    4. +
    5. ACTION: elky/hughdavenport update code guidelines and extend + it to other than php (rkabalin, + 21:09:56)
    6. +
    +
  10. +
  11. hughdavenport: Discuss how long we support releases for and/or the posibility of a LTS release (rkabalin, 21:10:47) +
      +
    1. 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 (rkabalin, + 21:21:44)
    2. +
    3. AGREED: support 3 + versions back, 1.4 will go with 1.6, 1.5 will go with 1.8, 16 with + 1.9 (rkabalin, + 21:30:30)
    4. +
    +
  12. +
  13. next meeting / Chair (rkabalin, 21:30:52) +
      +
    1. AGREED: next dev + meeting Tuesday, July 31st, 7:30 UTC (rkabalin, + 21:41:11)
    2. +
    3. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120731T0730 + (hughdavenport, + 21:42:52)
    4. +
    5. AGREED: elky chair + the next meeting (to be safe) (rkabalin, + 21:46:09)
    6. +
    +
  14. +
  15. any other business (rkabalin, 21:46:28) +
  16. +
+

+ + + + +Meeting ended at 21:53:18 UTC +(full logs). + +

+ + + +

Action items

+
    +
  1. elky look into removing google apps block from the core
  2. +
  3. safeiframe xss vulnerabilities discussion move to next meeting
  4. +
  5. elky/hughdavenport update code guidelines and extend it to other than php
  6. +
+

+ + + +

Action items, by person

+
    +
  1. elky
      +
    1. elky look into removing google apps block from the core
    2. +
    3. elky/hughdavenport update code guidelines and extend it to other than php
    4. +
  2. +
  3. hughdavenport
      +
    1. elky/hughdavenport update code guidelines and extend it to other than php
    2. +
  4. +
+

+ + + +

People present (lines said)

+
    +
  1. elky (126)
  2. +
  3. rkabalin (109)
  4. +
  5. anitsirk (79)
  6. +
  7. hughdavenport (68)
  8. +
  9. dobedobedoh (37)
  10. +
  11. richardm (12)
  12. +
  13. maharameet (3)
  14. +
+

+ + + +Generated by MeetBot 0.1.4. + diff --git a/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.html b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.html new file mode 100644 index 0000000000000000000000000000000000000000..b90819ab68473d79db8067e78a494b4834225dd4 --- /dev/null +++ b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.html @@ -0,0 +1,461 @@ + + + + +#mahara-dev log + + + + +
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
+ diff --git a/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.txt b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.txt new file mode 100644 index 0000000000000000000000000000000000000000..8f10b3f91494c8374fb1eb3858dce729c55ca395 --- /dev/null +++ b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.txt @@ -0,0 +1,434 @@ +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 ok +21:45:54 just to be safe +21:46:09 #agree elky chair the next meeting (to be safe) +21:46:27 dobedobedoh, also, i did https://wiki.mahara.org/index.php/Mahara_Wiki/NewFrontpage +21:46:28 #topic any other business +21:46:44 ahem +21:46:47 Well, there goes my AOB ;) +21:46:51 elky beat me to it +21:47:01 did you also have a new front page? +21:47:11 I was going to suggest doing it +21:47:26 And And even volunteer to do it! +21:47:28 dobedobedoh, i got bleeped off at it a few weeks back +21:47:50 but i haven't got around to doing kristina's suggested fixes and moving it into place +21:48:33 dobedobedoh, feel free to hack on it and make it bettereer +21:48:46 betterer* +21:49:05 I'll try and take a look, but it looks a million times betterererer already +21:49:13 inorite! +21:49:19 i like how you corrected bettereer to betterer, neither are words :P +21:49:37 i just stole the dev area stuff i did last year +21:49:40 hughdavenport, :D +21:50:15 hughdavenport, pro tip: never let me teach vocabulary to kids. +21:50:17 you confused non-english with betterer, I almost started thinking the is a word +21:50:59 heh +21:51:22 aaaaanyway +21:51:36 any other business? +21:52:16 ok +21:52:18 then +21:52:20 none else from me +21:52:25 Just to wish us (and Kristina) next week at maharauk +21:52:41 ooh, yes, good luck! +21:52:53 have fun next week at maharauk dobedobedoh and rkabalin. thanks for organizing it :-) +21:53:03 thanks +21:53:08 thanks :) +21:53:18 #endmeeting \ No newline at end of file diff --git a/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.txt b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.txt new file mode 100644 index 0000000000000000000000000000000000000000..889c945e44a7728b7b365d69cdd0a5e991e089c3 --- /dev/null +++ b/public_html/mahara-dev/2012/mahara-dev.2012-06-27-20.03.txt @@ -0,0 +1,126 @@ +=================== +#mahara-dev Meeting +=================== + + +Meeting started by rkabalin at 20:03:47 UTC. The full logs are available +at +http://meetbot.mahara.org/mahara-dev/2012/mahara-dev.2012-06-27-20.03.log.html +. + + + +Meeting summary +--------------- +* anitsirk is Kristina Hoeppner, Catalyst IT, Wellington, NZ (anitsirk, + 20:04:12) +* Andrew Nicols, Lancaster University, UK (dobedobedoh, 20:04:28) +* Ruslan Kabalin - Lancaster University, UK (rkabalin, 20:04:33) +* richardm Richard Mansfield, Catalyst IT (richardm, 20:04:37) +* is Melissa Draper, Catalyst IT (elky, 20:04:48) +* Items from last meeting (rkabalin, 20:05:29) + * 3. melissa/elky to publish a dev forum post about the 6 monthly + release cycle (rkabalin, 20:06:55) + * LINK: https://mahara.org/interaction/forum/topic.php?id=4547 + (anitsirk, 20:08:12) + * AGREED: Mahara release cycle is set to fixed period of 6 month + (rkabalin, 20:24:25) + * the first release in the new shedule will be in October (rkabalin, + 20:25:12) + * AGREED: minor point release after security fix or major bug + (rkabalin, 20:32:43) + +* Discuss/decide on style guidelines for CSS + https://reviews.mahara.org/#/c/1098/ Melissa/Hugh (rkabalin, + 20:35:09) + +* Google Apps block in Mahara 1.6? cf. + https://mahara.org/interaction/forum/topic.php?id=4641 (Kristina) + (rkabalin, 20:37:31) + * : 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). + (anitsirk, 20:38:35) + * is Hugh Davenport, Catalyst IT Ltd (hughdavenport, 20:49:26) + * ACTION: elky look into removing google apps block from the core + (rkabalin, 20:51:21) + * LINK: https://developers.google.com/safe-browsing/ (elky, + 20:57:50) + * ACTION: safeiframe xss vulnerabilities discussion move to next + meeting (rkabalin, 21:00:05) + +* Continued: Discuss/decide on style guidelines for CSS + https://reviews.mahara.org/#/c/1098/ Melissa/Hugh (rkabalin, + 21:00:51) + * we need volunteers to edit the code guidelines wiki page for other + langs (rkabalin, 21:05:54) + * LINK: http://en.wikipedia.org/wiki/Rules_lawyer (elky, 21:07:48) + * ACTION: elky/hughdavenport update code guidelines and extend it to + other than php (rkabalin, 21:09:56) + +* hughdavenport: Discuss how long we support releases for and/or the + posibility of a LTS release (rkabalin, 21:10:47) + * 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 (rkabalin, 21:21:44) + * AGREED: support 3 versions back, 1.4 will go with 1.6, 1.5 will go + with 1.8, 16 with 1.9 (rkabalin, 21:30:30) + +* next meeting / Chair (rkabalin, 21:30:52) + * AGREED: next dev meeting Tuesday, July 31st, 7:30 UTC (rkabalin, + 21:41:11) + * LINK: + http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120731T0730 + (hughdavenport, 21:42:52) + * AGREED: elky chair the next meeting (to be safe) (rkabalin, + 21:46:09) + +* any other business (rkabalin, 21:46:28) + +Meeting ended at 21:53:18 UTC. + + + + +Action Items +------------ +* elky look into removing google apps block from the core +* safeiframe xss vulnerabilities discussion move to next meeting +* elky/hughdavenport update code guidelines and extend it to other than + php + + + + +Action Items, by person +----------------------- +* elky + * elky look into removing google apps block from the core + * elky/hughdavenport update code guidelines and extend it to other + than php +* hughdavenport + * elky/hughdavenport update code guidelines and extend it to other + than php +* **UNASSIGNED** + * safeiframe xss vulnerabilities discussion move to next meeting + + + + +People Present (lines said) +--------------------------- +* elky (126) +* rkabalin (109) +* anitsirk (79) +* hughdavenport (68) +* dobedobedoh (37) +* richardm (12) +* maharameet (3) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot