=== greeneggsnospam is now known as jsgotangco === thomas__ is now known as The-Kernel === ubuntusucks is now known as elkkubuntu === elkkubuntu is now known as myrttiubuntu === myrttiubuntu is now known as ubuntunonaked === ubuntunonaked is now known as ubuntunonakedgir === ubuntunonakedgir is now known as ubuntuhowfix === ubuntuhowfix is now known as howfixhowfixhowf === howfixhowfixhowf is now known as howfixbadubuntu [07:21] howfixbadubuntu? [07:21] howfixbadubuntu? [07:21] howfixbadubuntu? [07:22] howfixbadubuntu? [07:22] plz? === howfixbadubuntu is now known as ubuntushit [07:24] Hobbsee: could you do the same on -motu ? :) [07:26] gpocentek: for the love of anythign good, use !ops when wanting something from an op, like a kickban. or /query me [07:26] * Hobbsee sees lots of red everywhere, and so has no idea if that's current, or was from hours ago [07:28] Hobbsee: /lastlog -h is nice. [07:28] Mithrandir: that's true, but i tend to read most of it anyway [07:29] * Hobbsee needs nalioth's irssi ban script [07:37] moin [07:37] damned tor [07:37] if he comes up anywhere else, call !ops [07:40] Hobbsee: #ubuntu-bugs #ubuntu-desktop #ubuntu-mobile [08:23] dholbach: only has ops in 1, no staffer to kline beyond that [08:37] Hobbsee: OK === ogra__ is now known as ogra === Mez is now known as Mez|Away === Mez|Away is now known as Mez [11:42] @schedule Copenhagen [11:42] * soren kicks ubotu === Thirsteh` is now known as Thirsteh === asac_ is now known as asac === Hobbsee is now known as LongPointyStick [12:58] heya [12:58] Evening. [12:59] Hey folks. [12:59] good morning [12:59] #startmeeting [12:59] Meeting started at 12:59. The chair is dholbach. [12:59] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [12:59] * TheMuso will do minutes/announcements, if nobody else wants to. [12:59] Welcome to the MOTU Meeting [12:59] thanks a lot TheMuso [12:59] we have an agenda at: https://wiki.ubuntu.com/MOTU/Meetings [12:59] First up is persia [13:00] [TOPIC] Hardy Freeze Schedule. Discussion to consider the merits of earlier UVFUniverse and NewPackagesFreezeUniverse to allow greater time for QA for the LTS. [13:00] New Topic: Hardy Freeze Schedule. Discussion to consider the merits of earlier UVFUniverse and NewPackagesFreezeUniverse to allow greater time for QA for the LTS. === Hobbsee_ is now known as Hobbsee [13:00] [LINK] https://wiki.ubuntu.com/HardyReleaseSchedule [13:00] LINK received: https://wiki.ubuntu.com/HardyReleaseSchedule [13:00] morning. now is the meeting? [13:00] Hobbsee: Yes. [13:00] In August (specifically the meeting of the 10th), we were discussing the possible freeze schedules for Hardy, in light of it being an LTS release. We didn't gome to a conclusion, but some ideas were presented, including: [13:00] 1) Not allowing any new packages [13:01] 2) Matching UVF / NPUF with DIF [13:01] 3) Requiring specs for everything [13:01] I wanted to revisit this discussion as Hardy is opening, and build some consensus if we wanted to adjust any freeze dates for Universe, so these could be communicated when the official schedule was developed at UDS. [13:02] a shame we don't have slangasek here [13:02] let's try to get another few release team members [13:02] I'd like to add manage a way to do Universe rebuilds and actually do them. [13:02] Ah. Found it. Previous meeting log: [13:02] 1) I understand the meaning, but I am not for it, only because UbuntuStudio is likely to push new packages in, but at the same time, we will keep them updated. [13:02] on a schedule. [13:02] ScottK: Well, we're reliant on lucas for those. [13:02] [LINK] https://wiki.ubuntu.com/MeetingLogs/MOTU/20070810 [13:02] LINK received: https://wiki.ubuntu.com/MeetingLogs/MOTU/20070810 [13:03] 2) Agreed. [13:03] 3) Not sure if we need to go that far. [13:03] ScottK: That sounds really good, and fits well with the idea of earlier freezes for Universe. [13:03] Fujitsu: Do they actually get done? Maybe need one earlier? [13:03] ScottK: We normally have one or two, fairly late. [13:03] Fujitsu: Did we have one for gutsy? [13:03] Ok, what is the problem we want to solve generally? [13:03] persia: I believe so, but I don't think bugs were filed. [13:04] The general issue is that if LTS is to be supported, it ought to be fairly QA clean to start: no FTBFS, no unmetdeps, no plain doesn't work, etc. [13:04] dholbach: Have Universe not suck for LTS support. [13:04] persia: agreed. [13:04] Fujitsu: Ah. I didn't hear about it :( [13:04] persia: me neither [13:04] persia, ScottK: I could think of other measures to get that done: QA lists announced regularly and early, good efforts coordinated with QA team members, etc [13:05] * ScottK adds "and have better communications about it". [13:05] Is that part of the solution? [13:05] * Hobbsee ignores the meeting, and plays with red fire [13:05] dholbach: Those are great measures, sure, and a good thing, but I think they are orthagonal to the question of whether we want to adjust freezes. [13:06] persia: I think they are solutions to the problem. [13:06] * norsetto thinks that if he hears orthogonal again will join Hobbsee [13:06] I'm not directly opposed to introducing freezes earlier, but to me these seem more obvious solutions [13:06] Where I was leading up to is I think moving New Package Freeze back to Feature Freeze/UVF and doing a rebuild then is a good start to transition for development to fixing. [13:06] dholbach: But it gives us more time to clean up. [13:07] early rebuilds sounds good [13:07] And get things in deacent shape. [13:07] dholbach: OK. I'm just wanting to re-raise the previous discussion, as there seemed to be interest, but no conclusion. I'm not convinced about freeze dates, but didn't want it to be lost. Other measures are useful, but separate. [13:08] more and earlier freezes will put more pressure on the UVF team and I'm sure there will be stuff we want to get in before release [13:08] I thought pitti's thread on revised freezed dates dumped all that into one date anyway? [13:08] ScottK: As a UVF member from the last cycle, how much more load do you think that would be? [13:09] ScottK: Pitti proposed that, but it's not represented on the current draft schedule. [13:09] Depends on what we're talkign about. [13:09] If it's move New package freeze to Feb 14, no big deal. [13:09] ScottK; Moving UVF earlier = more pressure for UVF [13:09] If it's much more than that, it'll get to be painful. [13:10] ScottK: should we discuss raising the number of people in the -uvf team? [13:10] I think we also ought to consider mapping out the endgame of the final freeze on more detail. [13:10] dholbach: No, I don't think so. [13:10] ScottK: Seconded. [13:10] ScottK: Yeah, rather than sort of... working it out as we go, a day in advance. [13:10] ScottK: what does mapping out the endgame of the final freeze on more detail mean? [13:10] Does anyone feel we need more that six weeks between upstream / feature / new freeze and beta? [13:10] persia: no [13:11] dholbach: As in, when does universe go into hard freeze. [13:11] dholbach: This time I was working with the RM a day or two before to figure out when the last chance to upload for Gutsy would be. [13:11] ScottK, TheMuso: ok thanks [13:11] I think it was reasonably well communicated as it happened, so no last minute suprises, but there were last day or two suprsises. [13:12] so the discussion right now is: move NPF from 28.2. to 14.2.? [13:12] do you think that's going to help a lot with our QA efforts? [13:12] That's the minimalist solution. [13:12] I think it's a 2 part problem. [13:12] That's one. [13:12] I'm happy with no change or minimal change. There doesn't seem to be the interest in freeze adjustment there was in August, so perhaps it was only a perceived issue, rather than a real issue. [13:13] Part two is it seemed like there wasn't a big bug fix push until the very end, but of course that's often not visible, so I"m not sure. [13:13] I'm happy to discuss tools and measures to make Universe QA better [13:13] ScottK: I think part 2 is just us preparing a push plan earlier (and at least me reviewing the RC list prior to beta freeze) [13:13] dholbach: Is there any timeline for universe rebuilds? [13:13] persia: I think it might be a good idea to identify some bug fix internal milestones too [13:14] Fujitsu: I don't know about it, but I can ask. [13:14] persia: Along the lines of what you just said. [13:14] I think we need to pus the RC list more as well. [13:14] push [13:14] ScottK: Agreed, but I don't think that's clearly dependent on freeze dates. [13:14] TheMuso: Agreed. [13:14] There's enough bugs in the bug tracker already - are we merely aiming for ftbfs/unmetdeps? [13:14] persia: No, more of goals. [13:14] TheMuso: Absolutely. Debcheck as well. [13:14] persia: Whats debcheck? [13:14] dholbach: If we had none of that at release, that'd be a huge victory. [13:15] dholbach: No. More than that, but it's not something we need to decide now, and it's also not something we need to stuff in the bugtracker. [13:15] ok, let's try to come to a conclusion on freeze dates before we drift away [13:15] TheMuso: http://alt.qeuni.net/~william/debcheck/ [13:15] oh that [13:15] * Fujitsu should update that for hardy soon. [13:16] Is it in the TODO? [13:16] at the least, so its findable? [13:16] Based on discussion, for my agenda item, I'd like to hear votes on whether anyone thinks it would be useful to adjust NewPackagesForUniverseFreeze to match UpstreamVersionFreeze. I didn't hear any other proposals today. [13:16] +1 [13:16] ok, let's vote [13:16] persia: I'd say yes, as it means we can do more bugfixing. [13:16] so +1 [13:16] [VOTE] NPF matching with UVF [13:16] Please vote on: NPF matching with UVF. [13:16] Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0 to MootBot [13:16] E.g. /msg MootBot +1 #ubuntu-meeting [13:17] +1 [13:17] +1 received from Fujitsu. 1 for, 0 against. 0 have abstained. Count is now 1 [13:17] +1 [13:17] +1 received from persia. 2 for, 0 against. 0 have abstained. Count is now 2 [13:17] +1 [13:17] +1 received from ScottK. 3 for, 0 against. 0 have abstained. Count is now 3 [13:17] +1 [13:17] +1 received from nxvl. 4 for, 0 against. 0 have abstained. Count is now 4 [13:17] +1 [13:17] +1 received from TheMuso. 5 for, 0 against. 0 have abstained. Count is now 5 [13:17] +1 [13:17] +1 received from geser. 6 for, 0 against. 0 have abstained. Count is now 6 [13:17] 0 [13:17] dholbach: +0 [13:17] +0 [13:17] Abstention received from dholbach. 6 for, 0 against. 1 have abstained. Count is now 6 [13:17] Ok, I'll pass this on to the ubuntu-release team [13:17] dholbach: Thanks. [13:17] so it gets included in the UDS release scheduling session [13:18] [TOPIC] Universe rebuilds [13:18] Vote is in progress. Finishing now. [13:18] Final result is 6 for, 0 against. 1 abstained. Total: 6 [13:18] New Topic: Universe rebuilds [13:18] ScottK: do you know who our contacts are for that? [13:18] dholbach: No I don't, but Fujitsu was saying lucas earlier [13:19] Ok, I'll make sure to get an answer from IS people on that and report on the list [13:19] it'd be good to have results early [13:19] dholbach: Thanks, yeah. [13:19] lucas did the last rebuilds [13:19] I'd like to see rebuilds at least after DIF and UVF. [13:19] (if there are resources) [13:19] Sounds good. [13:19] And probably around beta too. [13:19] agreed. [13:19] iwj's autopkgtest dug up some of them too [13:19] Fujitsu: Yes. [13:19] I'm not sure when it runs [13:19] Fujitsu: That'd be nice, but there's not much time, and 10,000 packages [13:20] [ACTION] dholbach to pass on NPF decision [13:20] ACTION received: dholbach to pass on NPF decision [13:20] [ACTION] dholbach to ask IS people about universe rebuilds [13:20] ACTION received: dholbach to ask IS people about universe rebuilds [13:20] persia: But if it's the 3rd one it shouldn't turn much up, so the results should be actionable. [13:20] I'll also coordinate that with release managers to get it on the schedule [13:20] ScottK: True. Saves me running rebuilds locally :) [13:21] If we can keep things sane early on, it'll be easier to manage at the end. [13:21] Same with the RC bugs. [13:21] can we move on to Universe QA efforts? [13:21] what should happen (and when) to packages where don't manage to fix the FTBFS? [13:21] It also saves us chasing Debian FTBFS bugs that don't affect us. [13:21] ScottK: only to a certain degree: we still need to check dates on dependencies, rebuilds, and bug filing, but it makes it easier. [13:21] geser: That's a good way to move into removal policy. [13:21] [TOPIC] Universe QA measures for Hardy [13:21] New Topic: Universe QA measures for Hardy [13:21] geser: Erm, you hit them harder to make it work :P [13:22] dholbach: I'd say be aggressive about removals is one thing. [13:22] so what's on our list apart from FTBFSes and unmetdeps? [13:22] Expunging ancient cruft before release. [13:22] Deskto pfiles [13:22] desktop files even [13:22] I'm wary about desktop files [13:22] Is there anything special or new for Hardy? If we have rebuilds, and advertise debcheck, RCbugs, automated FTBFS list, and the like, won't we be in good shape? [13:23] seb128: ^ (desktop files) [13:23] We managed to get openssl097 killed finally only on Monday before release. [13:23] TheMuso: What about .desktop files? [13:23] dholbach: thanks, reading [13:23] persia: people want menu entries for packages they install [13:23] dholbach was asking what else for Q [13:23] QA and they come up a lot in bugs [13:23] ScottK: That's entirely my fault: I need to read my mail more. [13:23] stop adding desktop files until there is a proper way to translate those [13:23] persia: But the key thing is we killed it. [13:23] there is a rosetta spec about that [13:23] I don't think its important, but thought it was worth mentioning [13:23] Do we have a policy at all about removals? [13:24] dholbach: Ah. Yes. I don't really consider that a QA issue, given the contention between poor translations & coverage. [13:24] seb128: Makes sense. [13:24] ok good [13:24] thanks seb128 :) [13:24] ok, who will work on getting regular lists of things like unmetdeps? how do we maintain them? [13:24] seb128: Has it been around for the requisite 2 years yet? [13:24] Fujitsu: I think the defacto removal policy is file a bug if a package annoys you enough. [13:24] dholbach: unmetdeps is done by debcheck. [13:25] Fujitsu: I don't understand your "requisite 2 years" [13:25] Fujitsu: so the list is actively updated and we can work from using it? [13:25] seb128: Is implementation in rosetta planned during the Hardy cycle? [13:25] dholbach: Updated every six hours. [13:25] Fujitsu: care to add to MOTU/TODO? [13:25] dholbach: Sure. [13:25] good [13:25] persia: no idea, but I would doubt of it, rosetta doesn't move really quickly [13:25] seb128: That's about what I thought. [13:25] one thing I'd really like to see for hardy is: more bugs tagged as bitesize and packaging [13:26] we really want to have huge lists we can show to new contributors to get working on them [13:26] seb128: Just noting that LP moves slower than a glacier often. [13:26] * TheMuso tends to fix such bugs if he comes accross them. [13:26] does anybody have an idea, how we can get more of our universe bugs fixed? [13:26] dholbach: I don't see that as a useful QA thing. It's a good way to feed contributors, but there's heaps of bugs that got tagged, but not fixed for gutsy, which just indicates that people use tagging as a proxy for actually doing the work,. [13:27] persia: Hense my just fixing them. [13:27] TheMuso: Right. [13:27] dholbach: of course, it's hard to do QA when people keep requesting billions of new packages into the archive, or updated versions, just because they can [13:27] I have lots of people who ask me which tasks they can start working on [13:27] and lots of those easy bugs GOT fixed [13:27] Hobbsee: those are not bitesize tasks [13:28] or often enough are not [13:28] I generally trawl bug lists if I have time. So if thats the case, they get fixed. [13:28] dholbach: For getting more bugs closed, there are two main things: firstly better coordination with the bug team, and secondly more focus on actually reviewing packages completely before uploading, rather than just fixing a bug. [13:28] dholbach: sorry, related to earlier, with the NPF [13:28] Hobbsee: ah ok [13:28] persia: how would you like to see the coordination happening? whom to talk to? what do you expect of the team? [13:29] persia: What do you mean by reviewing packages completely? [13:29] Fujitsu: reviewing the bugs of a package you're about to upload [13:29] the desktop team does that a lot [13:29] dholbach: I'd suggest, in terms of actual work getting done, it's as, if not more, important to look into why MOTUs become less active and seeing what can be done to get ones that have gone inactive back. [13:29] (at least looking at 'fix committed' bugs of the package, that have patches attached) [13:29] dholbach: That's the issue. I don't know. I don't have the feeling that MOTU and bugsquad are working closely to close things, but I don't know how to fix that. I do think tagging is best done by bugsquad (including MOTUs wearing a bugsquad hat) [13:30] dholbach: Right, everybody should be doing that. [13:30] ScottK: aye [13:30] But mostly its life getting in the way [13:30] ScottK: market research on inactive MOTUs is a good idea, but I feel we need easy todo list items for new contributors to reach out to people who are not MOTUs yet too [13:30] Fujitsu: Right. Lots of people don't. I read all my changelogs, and often see three updates by three different people in three days, all for simple things. [13:30] persia: so you think that something like universe bug days would be a good measure? [13:30] dholbach: I've noticed a lot of experience contributors drop off. [13:31] dholbach: Recruiting is good, but not really a QA topic, no? New contributors need to learn, and the orphan packages are not always the best place. [13:32] I'm just saying that as we work on universe bugs (not all universe packages are orphaned ones), we should make sure to keep the list of easy and manageable tasks for new contributors growing [13:32] dholbach: Universe bug days only work if someone runs them, and we've had no volunteers for all of Gutsy. That might change, but I'd rather see someone who wants to tackle interaction with bugsquad come up with a solution, rather than imposing one. [13:32] I think that's already going to help (as one part of the puzzle) [13:32] dholbach: I don't think getting the easy bugs fixed is our major problem. It's the hard one. [13:32] persia: maybe we should discuss this on the bugsquad lists, if we can come up with some ideas for it [13:33] one/ones [13:33] As one part. Not having lots of people reach for the MOTU bar, get it, and look for another challenge is the other side of the coin. [13:33] ScottK: right, I said it's one part of the puzzle [13:33] dholbach: Perhaps. I don't yet have enough ideas to feed such a discussion well. [13:33] right [13:33] I just think it's an incredibly small one. [13:33] it'll get them involved, but OK, let's leave the tagging discussion out for now [13:34] any more measures we can think of [13:34] ? [13:34] Agressive removal policy [13:34] we've had problems with that before and it should be discussed on ubuntu-devel@ [13:34] So, in summary, for QA, we'll focus on debcheck, RC bugs, and whole-package-maintenance. We'll agressively remove cruft, and do a couple whole-archive rebuild runs. [13:34] you always have people among the 8 million ubuntu users who still use the package you'Re removing [13:34] Early look at transistions and seeing what can be done to accelerate them. [13:34] all sounds good, yes [13:35] can we transform some of them into action items? [13:35] In the openssl097 case we only finished the transition because I accidentally noticed it was almost done. [13:35] dholbach: There are lots of packages that are safe to remove with some investigation. Old versions of libraries with 10 packages that need porting, debmake, etc. [13:35] ScottK: nice :) [13:35] We need a sustained look at that kind of thing. [13:35] ScottK: I guess the archive admins won't be happpy to review the removed packages again for hardy+1 when they get synced again [13:35] ScottK: Back in Just we ported 7 or 8 packages that hadn't been recompiled since Dapper :) [13:35] geser: They can blacklist them. [13:35] s/Just/June/ [13:36] persia: One of which is about to be subject to a removal request [13:36] geser: The blacklist persists across cycles [13:36] ScottK: so you want to remove packages for ever because we didn't fix a ftbfs? [13:36] still, I'd like to have something like guidelines for removal discussed, "agressive removal" does not sound very inviting [13:36] geser: I didn't say what the agressive removal policy should be. Just that we should have one. [13:37] dholbach: Agreed, it needs to be defined. [13:37] * persia proposes "oldlibs review & porting" in place of "agressive removal" [13:37] who wants to start the discussion on ubuntu-devel? [13:37] One other issue is supporting Dapper --> Gutsy upgrades. [13:37] I don't think it needs ubuntu-devel discussion, except perhaps for leaf apps. Most of the good targets are infrastructure, and not contentious. [13:38] ScottK: Dapper -> Gutsy? Dapper -> Hardy? [13:38] persia: not for every package, but for something policy-like [13:38] There are things that may need to be done with replaces/conflicts that we wouldn't normally think of [13:38] Gutsy/Hardy yes [13:38] ScottK: mvo will run test upgrades and file bugs for them [13:38] dholbach: On universe too? [13:38] Fujitsu: yes, AFAIK [13:38] OK. [13:38] dholbach: When will he start? [13:38] dholbach: Do we need a policy? If people have time, getting rid of oldlibs, etc. seems to be in line with NBS stuff. [13:38] who will talk to him about that? [13:39] persia: still, "agressive removal" should be defined somewhere [13:39] dholbach: Agreed and probably not right now. [13:39] ScottK: I think it runs in the datacenter every now and then [13:39] * persia doesn't really like the term "aggressive removal" anyway. [13:39] ok, so who will talk to mvo about that? [13:39] who will start the removal discussion? [13:39] persia: Pick one. [13:40] dholbach: I'll conspire with StevenK and try to come up with something to start the removal discussion. [13:40] ScottK: thanks [13:40] [ACTION] ScottK to start discussion about removal policy together with ScottK [13:40] ACTION received: ScottK to start discussion about removal policy together with ScottK [13:40] :) [13:40] oops [13:40] Heh. [13:40] At least coordination will be easy. [13:40] well the other S*K :) [13:41] lalala [13:41] ok, I'll talk to mvo [13:41] [ACTION] dholbach to talk to mvo about upgrade tests including Universe [13:41] ACTION received: dholbach to talk to mvo about upgrade tests including Universe [13:41] * ajmitch will sit back on a beach & relax [13:41] anything else before we move on? [13:41] dholbach: Is there going to be anything at UDS to do with MOTU? i.e do you have any specs planned? [13:41] ajmitch is one of the people dholbach should work on remotivating. [13:41] ajmitch: I thought you were going to update & revise the RC buglist? [13:41] [TOPIC] UDS Specs [13:41] New Topic: UDS Specs [13:41] ScottK: Ok, I'll try my best. :-) [13:42] persia: that too [13:42] Who is going? [13:42] * TheMuso is. [13:42] \o/ [13:42] ScottK: I'm a lost cause, sorry [13:42] * ScottK will be there Sunday/Monday (probably) [13:42] sistpoty and siretart, superm1 are [13:42] dholbach: you will make mvo cry ;-) [13:42] And at least one hopeful will also be there. [13:42] I'm mentoring him. [13:42] and a couple of others I can't remember right now [13:42] sorry? [13:42] siretart: you'll be at UDS [13:42] yes! :) [13:43] things I wanted to do at UDS are: [13:43] and you can't imagine how much I'm looking forward to that [13:43] review bzr best practices [13:43] revisit packaging guide on the wiki [13:43] dholbach: How does that relate to MOTU? [13:43] revisit ubuntu process docs on the wiki [13:43] The bzr thing? [13:44] ScottK: it concerns ubuntu developers in general [13:44] * ScottK isn't sure how. [13:44] ScottK: I guess for packaging with bzr [13:44] exactly [13:44] * proppy wonders how expensive is paris-boston [13:45] * Hobbsee is not going to UDS [13:45] proppy: cheaper than flying from NZ [13:45] * norsetto tells proppy that the flight is nothing compared to the hotel ..... [13:45] any other business before we move on to fixed items? [13:46] ok, next meeting time? [13:46] +344 hours [13:46] dholbach: Was that your personal list or list of stuff you think it MOTU related? [13:46] persia: erm? :) [13:46] persia: smart alec. [13:47] Fri, November 2nd, 20:00 UTC [13:47] isn't that during UDS? [13:47] TheMuso: It was handy from the 10th August meeting :) [13:47] ScottK: oh, also revisit motu processes and see if we have any bottlenecks we should try to fix [13:47] geser: Yes. [13:47] geser: that's happened before [13:47] geser: yes [13:47] that will be interesting for those of us at UDS. [13:47] We may not be able to attend. [13:48] depending on the goings on at the time. [13:48] right [13:48] Ah. Right. 0:00 UTC? 4:00 UTC? [13:48] maybe we should defer the discussion to the mailing list? [13:48] and ask who would come to the meeting anyway (UDS or not)? [13:49] I think we should schedule for a time convenient from UDS that doesn't conflict with the sessions. [13:49] (on Friday) [13:49] 20:00 UTC would be what? 16:00 local? [13:49] dholbach: Yes [13:49] dholbach: I agree. Chances are we'll be so exhausted that we won't want to attend. [13:49] Something like that. Maybe a little later? [13:49] dholbach: Yes. 00 is also out of the question. [13:50] I think that'll be the time the event closes [13:50] UTC that is [13:50] persia: later would not work [13:50] not sure if that makes much sense :-/ [13:50] dholbach: IT does to me. [13:50] once UDS is wrapped up, everyone goes out & gets drunk [13:50] * ScottK would say push it a week. [13:50] from what I've heard, at least :) [13:50] ScottK: Aye, I'm enclined to agree. [13:50] * persia defers [13:51] Let us get back, and recover. :) [13:51] ScottK: Agreed. [13:51] 9th November. What time? [13:51] I can't promise I can make it there, because I'll be at another conference, but that should be fine [13:52] 13:00 UTC? (same time) [13:52] this was at 12:00 [13:52] (This started 12;00 UTC) [13:52] And afaik the mentoring meeting starts soon [13:53] right, 12:00 UTC seems to be a good time for a bunch of us, it seems [13:53] * persia likes shifting times for people in other timezones, but finds 12:00 very convenient. [13:53] * geser can't before 14 UTC [13:53] 20:00? [13:53] I could do 20:00 [13:53] (before that is too early here) [13:53] (regarding the next agenda item: I'll figure something out regarding the Q&A sessions) [13:54] oops [13:54] 20 UTC WFM [13:54] TheMuso: We'll be in AEDT by then, won't we? [13:54] I thought Open Week would handle the Q&A session bits. [13:54]