17:02:31 <mjg59> #startmeeting FESCO (2012-08-20)
17:02:31 <zodbot> Meeting started Mon Aug 20 17:02:31 2012 UTC.  The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:02:35 <notting> limburgher: game time?
17:02:36 <mjg59> #meetingname fesco
17:02:36 <zodbot> The meeting name has been set to 'fesco'
17:02:36 <mjg59> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:02:36 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:02:37 <mjg59> #topic init process
17:02:40 * notting is here
17:02:42 * limburgher here
17:02:43 <pjones> morning.
17:02:46 * nirik is here.
17:02:57 <mitr> Hello
17:03:07 <mjg59> jwb: Here?
17:03:11 * hpa is lurking
17:03:32 <mjg59> I think mmaslano said she'd be on holiday?
17:03:38 <limburgher> I seem to recall such.
17:03:58 <mjg59> And t8m, maybe?
17:04:11 <jreznik> mjg59: yep, she's on holiday
17:04:35 <jreznik> t8m is not available today too if I remember it correctly
17:05:02 <jwb> mjg59, i am, sorry
17:05:07 <mjg59> Ok, cool
17:05:13 <mjg59> So, followups:
17:05:17 <mjg59> #topic #888 	F18 Feature: UEFI Secure Boot - https://fedoraproject.org/wiki/Features/SecureBoot
17:05:20 <mjg59> .fesco 888
17:05:22 <zodbot> mjg59: #888 (F18 Feature: UEFI Secure Boot - https://fedoraproject.org/wiki/Features/SecureBoot) – FESCo - https://fedorahosted.org/fesco/ticket/888
17:05:32 <mjg59> I think we're still waiting on the board for this
17:05:48 <nirik> do we even need this open? or was there something more for fesco here?
17:05:58 <pjones> What, exactly, are we waiting for?
17:06:00 <jwb> not fesco, no
17:06:13 <mjg59> Yeah, fair enough
17:06:17 <mjg59> I'll close this, then
17:06:21 <nirik> I think there were questions to the board if XYZ would meet their requests
17:06:44 <limburgher> KK.
17:06:46 <mjg59> Ok. How about we go through the exception requests and things first, and feature freeze progress at the end?
17:07:05 <limburgher> <nod>
17:07:06 <mitr> I'd prefer keeping this open - AFAICS it's undecided whether we will be able to do this for F18, and the rel-eng impact is non-trivial and perhaps woth tracking?
17:07:33 <mitr> OTOH "leave it to rel-eng" works as well, the contingency plan is probably not very risky
17:07:42 <mjg59> mitr: We're doing it for F18 unless the board explicitly says we're not
17:07:43 <pjones> mitr: care to make a comment to that effect on trac so that next time this comes up we remember why it's there?
17:07:46 <mjg59> I don't think it's a fesco issue
17:08:41 <notting> as much as fesco is oversight for eng/qa/releng, it is. but not without specific items that require fesco to intervene there
17:08:59 <mjg59> Moving on, unless anyone has anything else on this?
17:09:18 <mitr> mjg59: Is my reading of "the board would be illing to approve if ..." as an implicit prohibition incorrect?
17:09:29 <mjg59> mitr: It's not something the board needs to approve
17:09:55 <mjg59> mitr: It's something the board can prohibit in the sense that they're in a position of oversight over everyone else in the project
17:10:21 <nirik> I think feature owners will work with the board to implement it in a way that they will approve of it...
17:10:40 <mjg59> mitr: But the board don't need to say yes, they merely need not to say no
17:10:41 <nirik> if thats not done in time or causes too much issue, we can bring it back up in fesco?
17:11:09 <mjg59> nirik: I think we'd bring it back to fesco if there's anything relevant to fesco
17:11:20 <mjg59> The contingency plans are clear
17:11:22 * nirik nods.
17:11:44 <mitr> mjg59: I'm mostly concerned about timing - this should really be settled by beta.  Intuitively, having a ticket open to track that this "needs to happen" seems right, OTOH that ticket is not directly associated with any action, so... meh
17:11:56 <mjg59> mitr: Well, it's the same as any other feature
17:12:02 <mjg59> If it's not finished in time, it's not finished in time
17:12:17 <mitr> fair enough
17:12:28 <nirik> yeah, we don't normally have tickets pending for each feature...
17:12:40 <pjones> The worst case is exactly the same as having done nothing, so if it doesn't make it, the contingency solves itself.
17:12:52 <pjones> (it's just awful is all.)
17:13:25 <mjg59> So I'll close this for now?
17:13:35 * nirik thinks thats best...
17:13:39 <mitr> ok
17:14:08 <limburgher> Least worst.
17:14:24 <mjg59> #agreed close, no longer a fesco issue
17:14:30 <mjg59> #topic #934     Exception request F18 Feature: rngd default-on - https://fedoraproject.org/wiki/Features/rngd_default_on
17:14:34 <mjg59> .fesco 934
17:14:35 <zodbot> mjg59: #934 (Exception request F18 Feature: rngd default-on - https://fedoraproject.org/wiki/Features/rngd_default_on) – FESCo - https://fedorahosted.org/fesco/ticket/934
17:14:46 <mjg59> I spoke to hpa about this and all my concerns were dealt with, so I'm +1
17:14:56 <jwb> mine as well, so +1
17:15:00 <pjones> likewise, +1
17:15:09 <mitr> +1 - it's kind of sad that the kernel can't do this internally, but that's what it is...
17:15:15 * nirik was +1 last time I think... again, I don't like adding default running stuff, but... oh well.
17:15:16 <mjg59> And we're +3 in the ticket
17:15:36 <hpa> mitr: some pressure from distros might allow that path to be optionally enabled
17:15:59 <mjg59> limburgher ?
17:16:11 <mitr> One concern that popped up around here is that rngd should ideally be started earlier than the random encryption key for swap is generated - OTOH running rngd at all is a clear improvement
17:16:14 <hpa> mitr: for the lack of "customer" demand, it's not going to happen
17:16:30 <hpa> mitr: yes, the earlier it is started the better
17:17:07 <mitr> hpa: Looking at the comments in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/char/random.c;h=b86eae9b77dfaeb04dd2d4efefd6ebc01b9e0a93;hb=HEAD#l1039 ... would distro demand override that?
17:17:44 * mjg59 wonders where limburgher got to
17:17:45 <limburgher> +1
17:17:47 <mjg59> Cool
17:18:09 <mjg59> #agreed exception granted for rngd default-on (+1 9, 0 0, -1 0)
17:18:14 <mjg59> #topic #937     Fedora 18 Feature Freeze Exception: Simplified crash reporting via ABRT Server - https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting
17:18:15 <hpa> mitr: I don't know.  I can tell you that without distro demand it won't happen.
17:18:18 <mjg59> .fesco 937
17:18:20 <zodbot> mjg59: #937 (Fedora 18 Feature Freeze Exception: Simplified crash reporting via ABRT Server - https://fedoraproject.org/wiki/Features/SimplifiedCrashReporting) – FESCo - https://fedorahosted.org/fesco/ticket/937
17:18:28 * hpa disappears
17:18:40 <nirik> thanks hpa
17:19:02 <mjg59> So this is already deployed and in F18
17:19:06 <limburgher> Pretty close, what's left?
17:19:23 <mjg59> Unclear
17:19:33 <mjg59> So given that it's done, I can't see any reason not to grant
17:19:36 <limburgher> Maybe it should be 100%
17:19:38 <limburgher> ?
17:19:40 <mitr> +1
17:19:43 <limburgher> +1
17:19:50 <mjg59> +1
17:19:56 <nirik> +1 if it's done I suppose. any improvemts on abrt welcome
17:20:00 <mitr> Note that this does change the developer experience significantly - no backtraces with variable values any more.
17:20:22 <notting> +1. it also implies that it's not reporting to bugzilla any more?
17:20:39 <jwb> +1 i guess
17:20:44 <mitr> notting: reportedly the stand-alone server will forward to bugzilla
17:21:10 <mitr> forward agglomareted data, that is
17:21:19 <jreznik> and hopefully no dupes any more...
17:21:44 <mjg59> pjones: ?
17:21:50 <mitr> We'll see how it goes...
17:22:22 <limburgher> jreznik:  From your client to root's client. . .
17:22:51 <pjones> yeah, I'm +1
17:23:51 <mjg59> #agreed - exception granted for ABRT improvements (+1 7, 0 0, -1 0)
17:24:00 <mjg59> #topic #938     Fedora 18 Feature Freeze Exception: GNOME 3.6 - https://fedoraproject.org/wiki/Features/Gnome3.6
17:24:03 <mjg59> .fesco 938
17:24:04 <zodbot> mjg59: #938 (Fedora 18 Feature Freeze Exception: GNOME 3.6 - https://fedoraproject.org/wiki/Features/Gnome3.6) – FESCo - https://fedorahosted.org/fesco/ticket/938
17:24:05 <mjg59> +1
17:24:11 <pjones> +1
17:24:13 <limburgher> +1
17:24:22 <nirik> yeah, +1, seems just a clerical error. ;)
17:24:23 <jwb> +1
17:24:27 <mitr> +1
17:24:38 <notting> +1
17:25:28 <mjg59> #agreed exception granted for GNOME 3.6 (+1 7, 0 0, -1 0)
17:25:34 <mjg59> #936    Clarify non-persistent service permission grant
17:25:34 <mjg59> .fesco 936
17:25:36 <zodbot> mjg59: #936 (Clarify non-persistent service permission grant) – FESCo - https://fedorahosted.org/fesco/ticket/936
17:26:29 <mjg59> I think talking about the network here was pretty clearly intended to mean *listening* to the network
17:26:35 <mjg59> So I've no objection to clarifying this
17:26:50 <notting> yes, that works for me
17:26:55 <nirik> yeah.
17:27:00 <limburgher> Dittto
17:27:05 * nirik is happy to add wording to note listening...
17:27:22 <pjones> likewise, I'm okay with that.
17:27:25 <jwb> sure
17:28:18 <nirik> thats the proposal in comment #6?
17:28:42 <mjg59> Yeah
17:28:48 <mjg59> mitr: You agree with that?
17:29:22 <mitr> I have some trouble thinking of an useful example covered by this case - as mentioned in the ticket, even if cloud-init technically fulfilled the suggested criteria it shouldn't run by default IMHO.
17:29:55 <mitr> OTOH, in practice it was up to maintainers without any explicit FESCo oversight whether to start services by default or not, so relaxing the rules to be closer to the earlier state is fine with me.
17:30:33 <mjg59> Ok, so:
17:30:58 <mitr> (re: useful example: if it can't listen, it can only initiate the connection, and if it must not require configuration, what does it connect to?)
17:31:09 <Southern_Gentlem> noname64
17:31:31 <mjg59> #proposal reword the requirements to indicate that network access is acceptable, but not network listening
17:31:37 <mjg59> Southern_Gentlem: That's a dreadful password
17:32:03 <mjg59> Any objections to that?
17:32:13 <nirik> +1 here.
17:32:23 <mitr> +1.
17:32:34 <notting> +1
17:32:42 <limburgher> +1
17:32:45 <mjg59> +1
17:32:51 <jwb> +1
17:33:24 <mjg59> pjones: ?
17:33:26 <mitr> How much do we care about "full installs" / "stateless images" that contain a lot of software, not all necessarily used?  Do we want to particularly emphasize that "installing a package" does not necessarily mean that the actual user wants to use it?  (or perhaps the other way, assume that installing a package does convey such an intent?)
17:33:33 <pjones> +1
17:33:47 <mjg59> #agreed non-persistent service permission grant should be reworded
17:33:54 <mjg59> Anyone want to take responsibility for doing that?
17:34:02 <pjones> mitr: that's /always/ been the assumption before
17:34:32 <mitr> pjones: which "that"?
17:34:35 <pjones> though it's a little tricky to assume intent (either way) in the face of our constant dependency expansion
17:34:53 <pjones> mitr: we've always assumed that having it installed means you intend to use it
17:35:02 <notting> well, the preset policy changes that, some
17:35:07 <pjones> yes.
17:35:46 <mitr> pjones: I was thinking it's always been the opposite, interesting.
17:36:00 <pjones> huh.
17:36:22 <pjones> Well, the thing about assumptions.
17:36:51 <mjg59> Ok
17:36:52 <nirik> shall we move on?
17:36:52 <mjg59> #topic #932     F18 Features - progress at Feature Freeze
17:36:52 <mjg59> .fesco 932
17:36:53 <pjones> Anyway, I think given how we tend to have things packaged such strictness is probably outdated anyway
17:36:54 <zodbot> mjg59: #932 (F18 Features - progress at Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/932
17:37:35 <mjg59> So we have a new list
17:37:39 <abadger1999> From FPC side, it's always been the opposite...
17:38:22 <mjg59> Which of these do we think are especially concerning?
17:38:52 <mjg59> https://fedorahosted.org/fesco/ticket/932#comment:4 is the updated list
17:38:55 <mitr> initial experience, package groups - interact with the larger F18 installer changes?
17:39:57 <mjg59> mclasen just got back from PTO so probably hasn't updated this
17:39:57 <notting> package groups has landed in both yum and anaconda, it's just not built yet in anaconda (unless anaconda was built sometime between last friday and now)
17:40:55 * sgallagh is around to discuss KRB5 DIR if needed
17:41:02 * nirik notes some owncloud stuff passed review last night.
17:41:28 <jreznik> mjg59: yep, he replied, he's going to update it once he collects info...
17:41:38 <mjg59> It looks like there's some stuff here which might not land, but it doesn't seem obvious that there's anything that's destined to fail and which will hit anyone else in the process
17:41:52 <mjg59> So I'm inclined to say that things are going ok at the moment?
17:42:06 <mitr> seems so to me as well
17:42:12 <jwb> i don't think the PPC items even need to be listed
17:42:32 <jwb> i mean, good for them for following the feature process, but...
17:43:04 <nirik> yeah, most of the things still in this state are kind of standalone...
17:43:36 <jreznik> jwb: it's quite important feature for desktop on ppc64...
17:43:53 <mjg59> jreznik: Which isn't a primary arch?
17:44:03 <jreznik> mjg59: you're right
17:44:07 <jwb> jreznik, great.  are they releasing in lock-step with the primary arch?  if not, then it doesn't matter in the slightest how far they are along
17:44:37 <jwb> again, good for them and i commend them for filing, but it isn't a fesco concern
17:45:56 <nirik> so, any of the features we want to drop at this point? or ?
17:46:04 <mjg59> I'm inclined to leave them all at this point
17:46:07 <nirik> sugar at 0% is pretty worrysome...
17:46:24 <mjg59> Yeah, I'd imagine that that'll need at least an exception
17:46:33 <jreznik> nirik: I talked to pbrobinson, he promised to update it by Monday but...
17:46:35 <mjg59> But if we drop it then there's just no sugar update, so, eh
17:46:37 <jwb> aside from sugar, the rest seem fine
17:46:37 <limburgher> Can that be accurate?
17:46:43 <jreznik> he believes he can make it with exception granted
17:47:03 <nirik> ok... I look forward to seeing the request. ;)
17:47:41 <mitr> Well, if we drop it, then it isn't a feature, that doesn't necessarily mean that it doesn't get done - only the freeze policies are a real restriction
17:47:47 <mjg59> Yeah
17:48:08 <pjones> yeah, I don't think we really need to drop it at this point if he still thinks he can make it
17:48:16 <mjg59> Anyone object to just noting that this is the current state of everything and that we're not too concerned yet?
17:48:34 <mitr> So the real concern is "will it get tested", and, well...
17:48:47 <mitr> No, sounds reasonable.
17:49:16 * nirik is ok with that for now.
17:49:41 <limburgher> Ok for leave nodes, for sure.
17:49:59 <limburgher> s/leave/leaf/
17:50:11 <limburgher> Sorry for my broken English, I'm an American.
17:50:16 <mjg59> #agreed Happy with current state of feature process
17:50:18 <mjg59> Ok
17:50:26 <mjg59> .topic Open Floor
17:50:39 <mjg59> Anyone have anything they'd like to bring up?
17:51:04 <limburgher> Did anyone see https://fedorahosted.org/fpc/ticket/204 besides me?
17:51:19 <limburgher> We don't have a Trac for it just, but I thought I'd mention it.
17:51:46 <mjg59> Ugh that looks pretty awful
17:52:03 <pjones> yeah, it really does
17:52:09 <notting> limburgher: given that it's a fpc ticket, no, i didn't see it
17:52:12 <nirik> I asked him not to do that... but then the owner of the other repo said they updated and it should be fine.
17:52:25 <mitr> What does "renamed or of a higher release than upstream" mean?
17:52:28 <mjg59> So there are components being pushed into F17 which are of a greater version than a third party repo, and he's only doing it piecemeal rather than having the entire stack ready?
17:52:36 <limburgher> notting: No, but it was on the packaging list too, I think.
17:52:40 <mjg59> mitr: I assume that upstream have their own third party repo
17:53:00 <jwb> limburgher, there's a packaging list?
17:53:09 <mjg59> nirik: Did you get a response from him?
17:53:37 <limburgher> jwb: there is, and It wasn't on it.  My mistake.
17:53:44 <nirik> yes, he seemed to agree not to do that... but as I said, the other upstream/3rdparty repo guy said they updated and it wouldn't matter anymore... so perhaps thats why he resumed.
17:54:04 <nirik> I don't understand why you would want to push them one at a time anyhow personally.
17:54:11 <limburgher> Ok, so it may not even be our issue yet.
17:54:27 <mitr> In general I don't think third-party repos should block any packaging work in Fedora
17:54:30 <notting> nirik: i suspect it's either that or maintain a forest of build overrides.
17:54:38 <limburgher> nirik: Right, I mean what if you got 75% percent of the way through and found out it wasn't do-able?  You'd have a pile of unusable stuff out there.
17:54:38 <pjones> mitr: yeah, pretty hard to argue that they should
17:54:47 <limburgher> mitr: Agreed.
17:54:58 <mjg59> mitr: I agree, but if you're pushing stuff into stable then you should be doing it for good reason
17:55:04 <nirik> notting: sure, but is that really that much harder than doing that and updates?
17:55:21 <mitr> mjg59: "i just packaged this awesome tarball" is generally a good enough reason, when the package in question wasn't in the distribution before.
17:55:23 <mjg59> mitr: If you're providing a subset of components that are only useful when used with a third party repo, you shouldn't be breaking that
17:55:35 * nirik also would personally build it in rawhide first, then go back to stable releases. But perhaps thats just me
17:55:45 <limburgher> nirik:  No. :)
17:55:48 <notting> nirik: it's probably less documented. but i would still recommend against piecemeal pushing, yes.
17:56:12 <mitr> There are the end users to think about - is there some kind of yum magic upstream could recommend to their users so that the Fedora packages would be excluded for users that want to use the upstream repo?
17:56:13 <nirik> mitr: there's no hard guideline against it, but it would seem like it would alienate your users...
17:56:43 <limburgher> mitr:  Not viable, if the 3rd party RPMs have Fedora Requires. . .
17:56:52 <pjones> mitr: yes - the magic is "you should be maintaining your packages in fedora if possible"
17:56:59 <notting> mitr: i can't even find the repo in question, but i may be looking in the wrong place. mate-desktop.org seems to just have arch/debian/ubuntu
17:57:04 <limburgher> pjones:  BLASPHEMY!
17:57:07 <notting> mitr: oh how cute. random dropbox URL.
17:57:24 <pjones> limburgher: then I guess I'll burn :)
17:57:37 <nirik> notting: yes, it's a dropbox url. ;)
17:57:57 <mitr> While I'm generally concerned about various interpersonal conflicts that seem to appear around mate at an alarming rate, I'm not sure that there is anything we can or should do in this case.
17:57:58 <limburgher> pjones: Only if you weigh the same as a duck.
17:58:02 <nirik> anyhow, if you like I can try and talk with him again... or we could ask rdieter (his sponsor) to do so...
17:58:06 <pjones> limburgher: howard?
17:58:32 <limburgher> pjones:  I assume any duck would suffice for this purpose.
17:58:37 <limburgher> mitr:  Well put.
17:59:00 <pjones> mitr: +1
17:59:08 <mjg59> Yeah, I don't think there's anything we should explicitly do here
17:59:15 <nirik> I suppose it comes down to: should we ask him not to push parts of the stack to stable before the entire thing is done, or do we want to not micromanage or dictate that?
17:59:19 <notting> pjones: howard is from cleveland, and we do know that some things from cleveland are more flammable than you may expect.
17:59:38 <mjg59> I think this is inconsiderate behaviour, and it's not a good indicator that it'll be well maintained when it's complete
17:59:38 <limburgher> mjg59:  Fine by me, I just wanted to make sure we were all aware.
17:59:39 <pjones> notting: just the lake and the river, right?
17:59:59 <kushal> jokes are going above my head :(
18:00:20 <mjg59> But it's not breaching any rules we've put in place and it'd be difficult to work out how to forbid this without also forbidding more reasonable breakage of third-party repositories
18:00:22 <limburgher> kushal:  Sorry, Monty Python and the Holy Grail, the Howard the Duck.
18:00:22 <notting> i'm fine with telling him "you may not want to do it this way" ,but unsure whether that needs done with the Voice Of FESCo
18:00:23 <pjones> nirik: we could... send him a polite note saying that his package management style is unusual?
18:00:34 <limburgher> notting: <nods>
18:00:39 <mjg59> nirik: I think if you talk to him and rdieter, that'd be fine
18:00:51 <kushal> limburgher, thanks for the hints
18:00:58 <limburgher> kushal: NP.
18:01:05 <nirik> sure, I'll ask them again... as a suggestion.
18:02:29 <mjg59> Ok, sounds good
18:02:42 <gholms|pto> What happened with the cloud-init ticket?  Any questions I can answer (albeit on a phone keyboard)?  My plane just touched down, so I missed that conversation.  :-\
18:04:04 <mjg59> gholms|pto: No, rewording the requirements was approved
18:04:14 <mjg59> gholms|pto: Although there's still some concern about whether enabling it by default is a good idea
18:04:40 <gholms|pto> Understood.  Anything I can do to help address that?
18:05:24 <mjg59> mitr: ^
18:07:05 <mitr> gholms|pto: see https://fedorahosted.org/fesco/ticket/936#comment:6
18:07:31 <mitr> I'm going just bu what somebody else posted on a mailing list, it might not be accurate.
18:07:52 <gholms|pto> Ok.  I can respond in the ticket.
18:07:59 <gholms|pto> Tjanks, all
18:08:05 <gholms|pto> *Thanks
18:08:17 * gholms|pto boards another plane
18:08:21 <dwa> I've got one quick note, re. what jwb said about PPC features. We (fedora for power) had been asked to follow the feature process as closely as possible, so if that's something that fesco finds annoying/unnecessary it's probably worth a discussion with dgilmore & I to see what fesco wants from secondary arches who have features that (might) impact primary in some way.
18:09:09 <jwb> there's nothing wrong with what you've done.  i simply said it making release or not wasn't a fesco concern at this point
18:09:36 <limburgher> dwa: It's always good for us to be aware of that sort of thing.
18:10:11 <nirik> perhaps something else to consider in a features rework world...
18:10:20 <dwa> jwb: limburgher: nod. and we are trying to stick to primary's schedule especially for Features vs. arch-specific bugfixes.
18:10:22 <nirik> seperate out or note differently the secondary arch features.
18:12:00 <mitr> nirik: I think that will be usually automatically handled by treating "self-contained" features in a light-weight way.
18:12:11 <nirik> yeah, quite possible
18:12:41 <dwa> nirik: also probably worth contemplating how much fesco cares about features that are mostly secondary-arch specific but have the potential to impact primary as well
18:12:56 <nirik> sure
18:13:40 * dwa is done
18:13:44 <mjg59> Anything else?
18:14:12 <nirik> chair for next week?
18:14:36 <pjones> A bunch of us probably won't make it next week - lots of flying to san diego
18:14:39 <mjg59> I'm going to be out next week
18:14:50 <pjones> (and the week after that is a US holiday)
18:14:56 <notting> i can chair next week
18:15:08 <nirik> will we have quorum? I should be around.
18:15:22 <jwb> i may or may not be around
18:15:35 <limburgher> I should be here next week, not the following.
18:16:50 <mitr> I won't be here next time.
18:18:08 <notting> that's three definitely out, and one maybe
18:19:50 <notting> limburgher: whatever happened with the potential reschedule?
18:21:22 <limburgher> notting:  Thanks!  I completely forgot!
18:21:31 <limburgher> We had one time we all said we could make it.
18:21:49 <pjones> And it was?
18:22:39 <limburgher> Sorry, fetching. :)
18:22:54 <limburgher> 1700 UTC.
18:22:59 <limburgher> On wednesdays
18:23:29 <nirik> so that would be the day after all our deadlines instead of the day before... but sure.
18:23:38 <mjg59> So 1300 EDT?
18:23:44 <jwb> yes
18:23:57 <pjones> Well, okay.
18:23:57 <mjg59> Sure, that works
18:24:19 <pjones> I still won't make next week, but that's nice in general as it has less US holiday collision chances
18:24:27 <notting> do we want to do wednesday?
18:24:30 <mjg59> Yeah, I'll still also be out
18:24:32 <limburgher> So next meeting is 29th at 1700 UTC?
18:24:36 <jwb> if we move to wed next week, i'll definitely be out
18:24:46 <notting> yeah, i'm conferencing then too
18:25:09 <mjg59> So maybe skip next week?
18:25:48 <pjones> yeah, we could make the next meeting Sept 5
18:25:54 <limburgher> 9/5?  Ok.
18:26:14 <mjg59> Works for me
18:26:21 <mjg59> Any objections?
18:26:25 <mjg59> And who's going to chair?
18:26:29 <notting> i can
18:26:39 <mjg59> Great
18:27:27 <mjg59> Anything else?
18:27:35 <mjg59> If not I'll close in 3 minutes
18:30:39 <mjg59> Ok, thanks everyone
18:30:41 <mjg59> #endmeeting