[11:22] <AlanBell> is there a way in the LoCo directory to see all the events you are registered to attend?
[11:22] <AlanBell> perhaps a personalised ical feed?
[11:23] <nigelb> Fairly sure there isn't a personalized ical feed.
[11:26] <AlanBell> so am I. Would be cool though
[11:27] <mhall119> AlanBell: file a bug
[11:28] <mhall119> write a patch if you can
[11:29] <nigelb> RSS would be complicated
[11:29] <nigelb> But having a profile page would be awesome.
[11:29] <AlanBell> yeah, will file a bug
[11:30] <AlanBell> are there any recent patches with test scripts to look at?
[11:31] <AlanBell> I couldn't work out how to do a meaningful test for https://code.launchpad.net/~alanbell/loco-directory/backbutton/+merge/73526
[11:54] <AlanBell> who should bug 773243 be assigned to?
[11:54] <ubot4> Launchpad bug 773243 in ubuntu-website "Ubuntu website advertises "Fully compatible with Microsoft Office" (affects: 4) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/773243
[12:52] <nigelb> AlanBell: summit should have good tests
[15:26] <james_w> mhall119, https://code.launchpad.net/~james-w/awstrial/remove-maverick-text/+merge/75572
[15:28] <mhall119> james_w: I was actually joking about you doing awstrial work, that's in ISD's hands now
[15:28] <james_w> yeah
[15:28] <james_w> I was hoping it would still work though :-)
[15:28] <mhall119> I'll take it, don't get me wrong, it's less work for me
[17:00] <mhall119> james_w: I got an error running your multi-sprint tests
[17:01] <james_w> oh
[17:01] <james_w> pastebin and I'll fix it
[17:01] <mhall119> it's in the MP
[17:01] <mhall119> looks like maybe you're using a newer version of Django?
[17:01] <mhall119> it can't find assertIs
[17:02] <james_w> ah
[17:02] <james_w> assertEqual will suffice
[17:04] <james_w> mhall119, fixed
[17:06] <james_w> also argle, non-deterministic behaviour to try and write a test for
[17:07] <james_w> well, I'll just fix the code and keep the test I think
[17:07] <james_w> this is some private meeting fixes I'm working on, not the multi sprint branch
[17:07] <mhall119> ok
[17:10] <mhall119> james_w: my only concern about the multi-sprint is that once you add a Sprint record, you lose the default which uses the summit name
[17:11] <mhall119> this may cause confusion
[17:11] <james_w> hmm
[17:11] <mhall119> we'll just have to make sure people know about it
[17:11] <james_w> ok
[17:11] <mhall119> so right now we'll have uds-p spring
[17:11] <mhall119> sprint
[17:11] <james_w> I would have put some text on the admin page, but I wasn't sure how
[17:11] <mhall119> and if Marianna adds the Linaro sprint, suddenly it won't check the uds-p sprint anymore
[17:12] <mhall119> I think just making them aware will suffice for this cycle, but we might want to discuss how to keep it consistent going forward
[17:13] <mhall119> either dropping the use of a default, or adding the default as a sprint on initial save of a Summit object
[17:13] <james_w> ah, that's a good idea
[17:14] <james_w> I'll set this one up, so it won't be a problem unless anyone changes them
[17:14] <mhall119> ok
[17:16] <mhall119> awesome test case for it though
[17:26] <mhall119> james_w: both your branches have landed in trunk, I also updated http://ec2-50-16-76-22.compute-1.amazonaws.com/ to the latest trunk  and migrated the DB
[17:26] <mhall119> james_w: you can test importing multiple sprints on there if you have one for linaro ready to go
[17:26] <james_w> woop
[17:26] <james_w> thanks
[17:27] <james_w> I don't, but now that I know this is approved I will create one for testing
[17:27] <mhall119> I just ran lpupdate on there with the default sprint
[17:27] <james_w> hmm, it will happily import from staging, I'll try that
[17:28] <mhall119> man, having this ec2 running trunk sure is nice
[17:30] <james_w> yep
[17:37] <mhall119> cjohnston: nigelb: james_w: summit now has 43 unit tests, and they're all passing \o/
[17:38] <james_w> yay
[17:38] <nigelb> You guys are awesome :)
[17:38] <nigelb> I propose a hacking session every UDS.
[17:38] <mhall119> *after* or *before* every UDS
[17:38] <nigelb> *at*
[17:38] <mhall119> ok, but no deployments
[17:38] <nigelb> Yeah
[17:39] <nigelb> This puts all the stakeholders + people who can fix into one place.
[17:39] <mhall119> well we've had sesssions at the last 2 UDSs
[17:39] <james_w> this seems to be working ok
[17:40] <nigelb> Yeah :)
[17:40] <james_w> it fails to import blueprints from staging, as it's hardcoded to production
[17:40] <james_w> but it imported users fine
[17:40] <james_w> so I think we're good to deploy this
[17:40] <nigelb> Hrm, we should take it out into a config
[17:40] <james_w> any objection to a deployment on trunk to summit.ubuntu.com?
[17:41] <mhall119> not from me, but it's going to require some extra work this time because we re-set the South history
[17:41] <james_w> ah
[17:41] <mhall119> so we'll need to ./manage.py reset south
[17:41] <james_w> I can do it, but some clues about that would be appreciated
[17:41] <mhall119> the ./manage.py migrate schedule 0001 --fake
[17:41] <mhall119> and ./manage.py migrate sponsor 0001 --fake
[17:42] <mhall119> then ./manage.py migrate
[17:42] <james_w> ok
[17:42] <james_w> should I merge trunk to stable and production branches first?
[17:43] <mhall119> not to stable, once trunk merges to production we're going to be done with stable
[17:43] <james_w> ah¸ok
[17:43] <james_w> I'll get some lunch and tackle this
[17:43] <mhall119> ok, when do you want to try for a production deployment?
[17:44] <mhall119> we need to let jcastro know to expect it
[17:44] <nigelb> mhall119: why do you want to get rid of stable? :(
[17:44] <mhall119> nigelb: because once trunk merges to production, trunk will be our new stable
[17:45] <nigelb> But what if want to make unstable fixes and stable fixes?
[17:45] <mhall119> so we'll go back to only 2 branches, trunk and production
[17:45] <nigelb> Like james_w did have to do a bit back.
[17:45] <mhall119> you make unstable fixes in feature branches from now on, and propose them back into trunk
[17:45] <nigelb> ah, ok.
[17:45] <nigelb> Nothing undeployable goes into trunk.
[17:45] <nigelb> Makes sense.
[17:45] <james_w> let's say 1:15 from now
[17:45] <mhall119> james_w: wow, that soon? ok
[17:46] <mhall119> james_w: do you know how to make a proper backup of postgres?
[17:46] <james_w> is there a reason to wait?
[17:46] <mhall119> not that I know of
[17:46] <mhall119> except letting people know it's going to happen
[17:46] <mhall119> and backing up the db prior
[17:48] <james_w> yeah, I'll see about the db backup
[17:48] <nigelb> mhall119: pg_dump
[17:48] <james_w> downtime should be short, and I don't think anyone is using it much right now
[17:48] <mhall119> nigelb: yeah, but what parameters do we want?
[17:48] <mhall119> james_w: I'm checking with jorge on that
[17:48] <nigelb> database name?
[17:48] <nigelb> and I'd guess username and password.
[17:48] <james_w> https://code.launchpad.net/~james-w/summit/fix-autoscheduling-conflict-with-private/+merge/75594 was the problem I was fighting with earlier
[17:50] <nigelb> mhall119: "pg_dump summit" should work.
[17:50] <nigelb> unless it fails for authentication
[17:50] <nigelb> you can get credentials from settings.py anyway.
[17:51] <mhall119> james_w: can't we compare user records by their primary key?
[17:52] <mhall119> also, why did you remove local_settings.py.sample?
[18:12] <james_w> mhall119, that wasn't intentional, I must have used mv rather than cp
[18:12] <james_w> mhall119, compare by primary key, you mean implement __eq__ for Attendees?
[18:21] <mhall119> james_w: no, I mean using attendee.pk instead of attendee.name
[18:21] <james_w> ah
[18:22] <james_w> that should work
[18:23] <mhall119> james_w: I've got to pick up the kids from school in a few minutes, so just ping me before you deploy to make sure i'm around
[18:23] <james_w> ok
[18:23] <mhall119> you can go ahead and merge trunk->production if you want though
[18:23] <james_w> I'll hang back to start anything in production
[18:23] <james_w> ok
[18:25] <mhall119> james_w: once this goes out, let's talk about how to fix the caching (or at least providing a means of force-clearing it)
[18:25] <james_w> yeah
[18:25] <james_w> I was thinking about that in the shower this morning
[18:26] <james_w> I've made the .pk change and re-instated local_settings in the autoscheduler branch
[18:26] <james_w> and pushed up a small js branch for a bug I found while testing private meetings
[18:27] <mhall119> cool, I'll review later, it can go out after this deployment
[18:27] <james_w> yeah
[18:27] <james_w> they are important fixes, but don't block deployment
[18:27] <james_w> and once we've done this one we should be able to do frequent deployments of well-tested changes :-)
[18:27] <mhall119> I'm thinking, about the cache, that we make a signal that gets fired whenever some code changes the schedule
[18:28] <james_w> and invalidate everything?
[18:28] <mhall119> that way we can start with a specific URL that you can hit to fire the signal, but also start adding it into the places where it needs to be and eventually not need the URL
[18:28] <mhall119> james_w: that's what we should discuss
[18:28] <james_w> ok
[18:28] <mhall119> ok, leaving now, bbl
[18:28] <james_w> let's do so later
[18:28] <james_w> bye
[18:53] <mhall119> james_w: okay, I'm back
[18:56] <james_w> cool
[18:56] <james_w> just did the merge to production
[18:58] <nigelb> james_w: I <3'd your RT.
[18:58] <nigelb> "summit is such a fuster cluck"
[19:01] <james_w> pg_dump done
[19:01] <james_w> new code in place
[19:01] <mhall119> did you touch the .wsgi files?
[19:01] <james_w> not yet
[19:02] <james_w> I'm thinking that should happen after the migrate commands
[19:02] <mhall119> ah, right
[19:02] <james_w> starting those now based on your instructions
[19:02] <james_w> You have requested a database reset.
[19:02] <mhall119> did you just do the --fake migrations?
[19:02] <james_w> This will IRREVERSIBLY DESTROY any data for
[19:02] <james_w> the "south" application in the database "summit".
[19:02] <james_w> Are you sure you want to do this?
[19:02] <james_w> Type 'yes' to continue, or 'no' to cancel:
[19:03] <james_w> reset first right?
[19:03] <mhall119> yes
[19:03] <mhall119> we have a backup anyway, right?
[19:03] <james_w> yeah
[19:04] <james_w> migrations done
[19:04] <james_w> touching wsgi files
[19:04] <james_w> crossing fingers
[19:05] <james_w> looks good to me
[19:05] <mhall119> looks good to me too
[19:05] <james_w> anyone see any problems?
[19:05] <james_w> we have the new code as well :-)
[19:05] <nigelb> Hrm, today link is falling off the top menu :(
[19:06] <james_w> not for me
[19:06] <nigelb> what browser?
[19:06] <mhall119> nigelb: no it's not
[19:06] <james_w> firefox
[19:06] <mhall119> nigelb: I get "There are no sessions scheduled for today."
[19:07] <mhall119> what do you get?
[19:07] <nigelb> mhall119: No, I meant its not staying in the top menu
[19:07] <mhall119> also, are you going to /today ot /uds-p/today ?
[19:07] <nigelb> but dropped down
[19:07] <mhall119> hmmm, not for me
[19:07] <mhall119> nigelb: what URL are you seeing this on?
[19:08] <nigelb> summit.ubuntu.com
[19:08] <mhall119> nigelb: try ctrl+refresh? maybe you have old theme dadta
[19:08] <nigelb> mhall119: http://people.ubuntu.com/~nigelbabu/today.png
[19:09] <mhall119> or maybe your font settings are causing it?
[19:09] <nigelb> maybe because I don't have Ubuntu font.
[19:09] <nigelb> Right.
[19:14] <cjohnston> whats up with microblogging?
[19:15] <cjohnston> are all of those curacao rooms for hacking?
[19:15] <mhall119> cjohnston: the Hackfest is from a track being assigned to the room
[19:15] <mhall119> I'm not sure what's up with twidenash
[19:16] <cjohnston> Right.. I know that... I assume that those rooms are only for the hackfest tho?
[19:17] <james_w> cjohnston, they are Linaro rooms, assigned to teams to use for hacking
[19:17] <james_w> as Linaro isn't planning to schedule a full roster of sessions, but spend some time hacking as well
[19:18] <james_w> mornings for discussion, afternoons for hacking
[19:18] <james_w> mhall119, let me know when you want to discuss caching
[19:18] <cjohnston> gotcha
[19:20] <mhall119> james_w: should those be private rooms then, so that public meetings aren't auto-scheduled into them?
[19:20] <james_w> hmm
[19:21] <james_w> double hmm
[19:21] <james_w> probably shouldn't be openly scheduled
[19:21] <cjohnston> We don't have a way of displaying the private rooms yet
[19:21] <james_w> maybe they should be private, I'm not sure
[19:22] <james_w> I'll have a look
[19:23] <cjohnston> What does marking a room closed do?
[19:23] <mhall119> james_w: can you either give g+w ./summit/media/js or run: bzr branch bzr+ssh://bazaar.launchpad.net/~django-foundations-dev/twidenash/2.0/ ./twidenash
[19:23] <cjohnston> Does that allow manually scheduling?
[19:23] <mhall119> cjohnston: only through the django admin
[19:23] <cjohnston> hmm
[19:23] <cjohnston> So we need a way to mark a room as avoid auto scheduler
[19:24] <cjohnston> Like a 'Manual Scheduling'
[19:25] <cjohnston> because, unless Linaro has a reason to have them private, there isn't really a reason that they shouldn't be displayed to anyone.
[19:26] <mhall119> cjohnston: maybe "Reserved" would be a good type description
[19:26] <cjohnston> That would work..
[19:30] <james_w> mhall119, done both
[19:31] <cjohnston> james_w: what do you think about a reserved status.. That way the room is still "Public" but the autoscheduler doesn't schedule stuff in there.. similar to private, just being visible to everyone
[19:31] <cjohnston> on the edit page stuff can be manually scheduled
[19:33] <mhall119> fixed microblogging
[19:33] <cjohnston> cool
[19:36] <james_w> cjohnston, maybe
[19:36] <james_w> I need to look in to whether we want the schedule for these rooms to be displayed at all
[19:37] <cjohnston> ok
[19:37] <james_w> we are using the tracks feature though
[19:37] <james_w> so it would only autoschedule sessions in the linaro-hacking track
[19:37] <james_w> in to those rooms
[19:37] <cjohnston> right...
[19:37] <james_w> so if we just schedule it how we want the autoscheduler will leave it along
[19:37] <james_w> alone
[19:38] <cjohnston> wont the conflict resolver mess with it if conflicts arise?
[19:39] <james_w> nope
[19:39] <james_w> not if we manually schedule everything
[19:39] <james_w> the conflict resolver doesn't change hand-scheduled stuff
[19:39] <cjohnston> gotcha
[20:21] <cjohnston> mhall119: oops
[20:21] <nigelb> james_w: the rescheduler does.
[20:22] <mhall119> cjohnston: yeah, sorry about that
[20:22] <james_w> nigelb, does what?
[20:22] <mhall119> statik has requested an official build and release of the latest django-openid-auth though
[20:22] <nigelb> james_w: move things around
[20:22] <james_w> nigelb, where?
[20:22] <cjohnston> whats the eta on that mhall119
[20:22] <mhall119> cjohnston: dunno, let me ask
[20:22] <nigelb> james_w: I think its commented out now. So we may be okay.
[20:22] <cjohnston> be even more awesomer if the memory issues get fixed instead
[20:23] <mhall119> yeah, that's the big concern
[20:23] <cjohnston> thats why i asked about getting them switched
[20:23] <cjohnston> maybe you can say thats a good idea or something
[20:23] <nigelb> Worst case, we could just spawn an ec2 for summit.
[20:24] <nigelb> Really, I'm not that scared about the memory issues.
[20:24] <cjohnston> do you actually think they would point summit to an ec2?
[20:24] <nigelb> Yes, given enough pressure.
[20:25] <james_w> nigelb, the reschedule code only acts on autoscheduled events
[20:25] <nigelb> james_w: AH!
[20:25] <nigelb> the "auto" flag, right.
[20:25] <cjohnston> and you don't think that when we actually add load to summit cranberry will get worse?
[20:25] <james_w> ywp
[20:25] <nigelb> cjohnston: I can't say that for sure.
[20:25] <nigelb> No one can.
[20:25] <nigelb> Because we don't know what's causing the problems
[20:26] <nigelb> Its intermittent.
[20:26] <cjohnston> thats my point... that we need to figure it out
[20:26] <nigelb> Personally, I think its something to do with apache config.
[20:26] <nigelb> But someone needs to spend time figuring that out.
[20:26] <cjohnston> yup
[20:26] <nigelb> I don't have access, neither do you.
[20:26] <nigelb> That leaves IS or mhall119 / Daviey / james_w.
[20:27] <cjohnston> but do mhall119 Daviey and james_w have the correct access to figre it out?
[20:27] <nigelb> And we probably need root at some point.
[20:27] <nigelb> So, they don't have all the access.
[20:27] <mhall119> I only have write access to the summit directory
[20:27] <nigelb> We're screwed with a ghost of a problem.
[20:27] <cjohnston> throw harvest back on cranberry and give us guanabanana
[20:27] <nigelb> And, to make things even more complicated, its one of those things you have to be watching happen.
[20:28] <cjohnston> or wtf ever it is
[20:28] <nigelb> Its guanabana.
[20:28] <cjohnston> whatever
[20:28] <cjohnston> :-P
[20:38] <cjohnston> nigelb: mhall119 are there any of the emails that would be better than another to attach to the RT?
[20:38] <nigelb> pick any
[20:41] <mhall119> cjohnston: for the memory issue?
[20:41] <mhall119> none of the django ones will be especially helpful, because the error gets thrown at random places, whatever happened to be executing when it ran out
[20:42] <cjohnston> I attached the most recent I have
[20:44] <cjohnston> james_w: keeps spamming me :-P
[20:44] <james_w> I can stop working if you want :-)
[20:44] <cjohnston> nope
[20:48] <cjohnston> yay
[20:49] <cjohnston> mhall119: nigelb james_w are we good with marking [summit-hackers] figure out a way to import data locally for testing    to postpone?
[20:49] <nigelb> Yes, go ahead
[20:49] <cjohnston> same with [summit-hackers] JSON export of data to be used for local testing: TODO
[20:49] <cjohnston> [summit-hackers] Add more content/direct links on the front page: TODO
[20:49] <nigelb> the last one is DONE
[20:49] <nigelb> is it it?
[20:49] <cjohnston> [summit-hackers] Making user roles for different users providing different levels of access: TODO
[20:49] <james_w> oh my
[20:49] <cjohnston> more content direct links on front page is different than main nav matching
[20:50] <nigelb> ah
[20:50] <james_w> I reeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaaaaaaaaalllllllllly hate model_mommy
[20:50] <nigelb> You shouldn't forget a single model
[20:50] <nigelb> Or mummy doesn't work ;)
[20:50] <nigelb> The launchpad way is more awesome.
[20:50] <cjohnston> [summit-hackers] Create a mutable item to where meetings in the past are muted: TODO   <--- this one is where the rescheduler doesnt reschedule stuff in the past?
[20:51] <nigelb> cjohnston: That was also for rooms being closed etc.
[20:51] <nigelb> Like sessions happen in Room X on day 1.
[20:51] <nigelb> We close that room.
[20:51] <nigelb> To facilitate that, we delete the room. All hell breaks loose.
[20:51] <cjohnston> So we need to fix that prior to this uds
[20:52] <nigelb> Actually, we need to make room availability better.
[20:52] <nigelb> Like mark time periods where the room is unavailable.
[20:52] <cjohnston> we have that
[20:53] <nigelb> Then we should just tell jcastro to use that next time.
[20:53] <cjohnston> There is busy times...
[20:53] <cjohnston> the ability to add three different times
[20:54] <cjohnston> i dont know if you can add more if you use all three
[20:54] <cjohnston> like say monday wednesday thursday afternoon and friday arent available
[20:55] <cjohnston> I am wondering with all the additional rooms if the schedule is going to be too wide for the screen
[20:55] <nigelb> we should get the schedule to be better.
[20:55] <nigelb> that still bothers me
[20:56] <cjohnston> i wonder if the screens will be available a few days prior to uds
[20:56] <nigelb> ask elmo
[20:58] <cjohnston> mhall119: nigelb james_w https://blueprints.launchpad.net/ubuntu/+spec/community-o-summit    what else do you think we can postpone?
[20:59] <nigelb> the render.py
[20:59] <cjohnston> nigelb: did you ever finish the api bug you were working on?
[21:00] <nigelb> No
[21:00] <nigelb> I don't think I will get to it either.
[21:00] <nigelb> I need more time.
[21:00] <james_w> Fix scheduling conflict resolution and notification
[21:00] <james_w> what's that one?
[21:01] <james_w> Making user roles for different users providing different levels of access <- I'm not sure we'll get to that one
[21:01] <cjohnston> I'm not hugely familiar with the API (read don't know how to do it on my own) but I think thats an important bug to fix to make summit hugely improved
[21:01] <james_w> hmm, we should likely turn the reschedule script off on the last day
[21:01] <james_w> oh no, it won't fight with the admins, so it's ok
[21:01] <nigelb> james_w: it usually is turned off.
[21:02] <nigelb> we forgot last time :-)
[21:02] <james_w> well it shouldn't be
[21:02] <james_w> perhaps add a rule to not reschedule anything that starts in the next N hours?
[21:03] <james_w> Allow people to define their own Busy times, check them for scheduling conflicts <- busy times are implemented, there's just no non-admin interface
[21:03] <nigelb> can we hackup a form for that?
[21:03] <nigelb> I think it should be "easy"
[21:03] <james_w> we could
[21:04] <cjohnston> yup
[21:04] <james_w> I'm not inclined to
[21:04] <cjohnston> well.. i dont know about easy
[21:04] <nigelb> I wish we had more hands for ubuntu webdev.
[21:04] <cjohnston> teach czajkowski to hack summit
[21:24] <mhall119> cjohnston: we can still get a JSON read-only API in before UDS
[21:25] <james_w> does anyone know if we are getting Guidebook again this time?
[21:25] <mhall119> cjohnston: django-openid-auth_0.4 is building in our PPA now, I should be able to re-open that RT tomorrow
[21:25] <mhall119> james_w: I haven't heard either way, I assume we are
[21:38] <cjohnston> james_w: we are afaik
[21:38] <cjohnston> mhall119: sweet
[22:23] <cjohnston> james_w: i dont know that we should mark the private rooms bug as released..
[22:23] <cjohnston> we still dont have a way to display that someone is in a private meeting in a private room
[23:05] <james_w> cjohnston, true, but we can live without it if we have to
[23:05] <james_w> I say file another bug
[23:22] <james_w>  5 files changed, 7 insertions(+), 50 deletions(-)
[23:29] <cjohnston> james_w: have a moment to help me debug code?
[23:44] <james_w> sure
[23:45] <cjohnston> james_w: https://code.launchpad.net/~chrisjohnston/summit/trackleads
[23:46] <cjohnston> I'm getting an error with inner() which is in decorators.py
[23:46] <cjohnston> inner() takes at least 3 arguments (2 given)
[23:46] <cjohnston> I'm sure my lead isn't right.. I'm just lost on getting it right
[23:47] <james_w> why does the lead need to go in there?
[23:49] <james_w> inner() gets the arguments from the url
[23:49] <james_w> so it's taking the summit-name from the start
[23:50] <james_w> and expecting to get the lead next
[23:50] <james_w> but urls.py isn't set up to pass that through
[23:51] <cjohnston> ok