18:02:39 <abadger1999> #startmeeting fesco
18:02:39 <zodbot> Meeting started Wed Nov  6 18:02:39 2013 UTC.  The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:02:59 <abadger1999> #topic Roll Call
18:03:03 * mattdm is here but booth is crazy -- going to to find a quiet corner
18:03:11 <sgallagh> Salutations. I'm here for one hour.
18:03:14 <pjones> hi
18:03:21 <mitr> Hello
18:03:27 <nirik> morning
18:03:32 * notting is live from the bloodmobile
18:03:42 <sgallagh> notting: Live... or undead?
18:03:53 <t8m> hello
18:04:06 <notting> Grrr. Aargh.
18:04:14 <abadger1999> #chair mattdm sgallagh pjones mitr nirik notting t8m notting
18:04:14 <zodbot> Current chairs: abadger1999 mattdm mitr nirik notting pjones sgallagh t8m
18:04:28 <abadger1999> Cool we're all here.
18:04:46 <abadger1999> #topic #1185 Enable "-Werror=format-security" by default
18:04:47 <abadger1999> .fesco 1185
18:04:49 <zodbot> abadger1999: #1185 (Enable "-Werror=format-security" by default) – FESCo - https://fedorahosted.org/fesco/ticket/1185
18:05:22 <nirik> we were waiting to hear back on results right/
18:05:28 <abadger1999> yeah.
18:05:37 * abadger1999 checks whether those were posted last night
18:05:55 <notting> gcc maintainers did not like this as a gcc change,  FWIW
18:06:03 <abadger1999> k
18:06:25 <abadger1999> notting: that was the "add it to -Wall" bug?
18:06:31 <notting> Yes
18:06:57 * mattdm is back
18:07:11 <nirik> proposal: punt another week, wait for results?
18:07:15 <nirik> unless there's some urgency ?
18:07:33 <mitr> +1
18:07:38 <mattdm> +1 punt!
18:07:42 <abadger1999> +1 punt
18:07:55 <sgallagh> +1 punt
18:08:11 <notting> +1 punt
18:08:12 <abadger1999> #info Adding to gcc's -Wall as a local Fedora patch was rejected
18:08:24 <t8m> +1
18:08:45 <abadger1999> #info Deferred another week awaiting results of mass rebuild
18:08:58 <abadger1999> #topic #1192 OpenH264 as an automatic download by firefox/Statement to the ietf WebRTC working group
18:09:00 <abadger1999> .fesco 1192
18:09:01 <zodbot> abadger1999: #1192 (OpenH264 as an automatic download by firefox/Statement to the ietf WebRTC working group) – FESCo - https://fedorahosted.org/fesco/ticket/1192
18:09:41 <abadger1999> This came up on devel and fab lists.  notting and I hashed out a proposal in the ticket.
18:09:50 <abadger1999> Anyone want to discuss or should we vote on the proposal?
18:10:31 <nirik> I'm not sure how much weight we would pull with ietf... but...
18:10:32 <sgallagh> I missed part of the original legal discussion.
18:10:41 <sgallagh> I assume that the terms of the license grant are unacceptable?
18:11:25 <notting> They're only for the binary, and they don't transfer
18:11:30 <abadger1999> nirik: yeah -- I figure we were asked, so I'm willing to send something but I'm not hopeful that it would have an effect.
18:11:41 <pjones> sgallagh: the terms of the license grant are "cisco can redistribute as many non-redistributable binaries as they'd like"
18:11:43 <sgallagh> notting: That would be a "yes", then
18:11:50 <nirik> abadger1999 / notting would it be possible to put the full proposal in a comment? I'm unclear on if that last comment is replacing point 2 or just adding on?
18:11:57 <abadger1999> nirik: Sure.
18:12:21 <pjones> nirik: looks to be adding to it
18:12:45 <abadger1999> https://fedorahosted.org/fesco/ticket/1192#comment:8
18:12:56 <abadger1999> and yes, it's just adding to it.
18:13:07 * pjones is fine with comment 8
18:13:32 <nirik> sure, +1 to comment 8.
18:13:37 <pjones> But that doesn't answer the question of: can something we ship automatically download from Cisco?
18:14:01 <abadger1999> Proposal: Accept Comment #8 as message to send to the ietf mailing list today.
18:14:04 <abadger1999> +1
18:14:15 <notting> +1
18:14:20 <pjones> abadger1999: +1
18:14:22 <t8m> +1
18:14:24 <mmaslano> +1
18:14:25 <sgallagh> Could we add something to the statement that the approval of OpenH264 would be unfairly skewing the "open standards" such that only commercial vendors with license agreements could participate?
18:14:27 <abadger1999> pjones: true... Would you be okay with crossing that bridge when/if we get to it?
18:14:54 <abadger1999> sgallagh: If you can think of some phrasing right now, I'd be happy to vote on it.
18:14:55 <mattdm> +1 to proposal
18:15:01 <mitr> +0.5 or something.  I still hate the game.
18:15:07 <sgallagh> Stating our philosophy is nice, but it doesn't necessarily demonstrate the negative impact of the decision
18:15:23 <sgallagh> mitr: Game?
18:15:31 <mitr> sgallagh: patent environment
18:16:00 <nirik> personally, I would say we should not ship somethiing that 'automatically downloads' non free stuff. It should be a user choice to do so.
18:16:08 <nirik> but we could yeah wait and see
18:16:29 <mitr> sgallagh: Re: philosophy, there is I think a disconnect between philosphy of the project and philosphy of users in practice - in a (convoluted?) sense, users participate in standards, not vendors
18:16:49 <mitr> nirik: We also have the "WG autonomy" question that is directly related, perhaps we should resolve it first
18:17:04 <notting> nirik: we already ship things that do it on user choice. Although I don't know how well the plugin finder actually works
18:17:07 <sgallagh> Proposed addition: Fedora would also like to point out that the acceptance of an insufficiently-free license on the OpenH264 codec will unfairly affect the ability for non-commercial vendors to implement this open standard. This will result in an inability for equal competition in this "open internet".
18:17:29 <mitr> sgallagh: 0
18:17:29 <nirik> mitr: perhaps. I would not want to allow this is any places in fedora personally tho. ;)
18:17:33 <t8m> sgallagh, +1
18:18:19 <nirik> sgallagh: sure, +1... like I said I don't think it will have that much weight, but sure.
18:18:36 <sgallagh> nirik: I think pointing out the negative impact may carry some limited weight
18:18:37 <mattdm> take out the "would like to point oiut"
18:18:40 <mattdm> just *say it*
18:18:53 <sgallagh> (vs. just saying that it doesn't agree with our principals)
18:18:54 <mattdm> "Acceptance of an insufficiently-free license on the OpenH264 codec will ..."
18:19:03 <sgallagh> We're now asserting a distinct commercial disadvantage
18:19:18 <sgallagh> mattdm: Sure, that's fine with me.
18:19:27 <notting> sgallagh: sure, +1. Fine with mattdm's wordsmith ing too
18:19:28 <sgallagh> I don't words good sometimes.
18:20:17 <abadger1999> "non-commercial vendors like Fedora"
18:20:44 <mclasen> what does non-commercial have to do with it ?
18:21:01 <pjones> mclasen: nothing.
18:21:01 <abadger1999> ^ Maybe show how it applies to Fedora as well?
18:21:14 <mclasen> the downloader works just fine if you're not too finicky about principles
18:21:28 <sgallagh> mclasen: No ability to get a redistribution license without being a legal entity
18:21:51 <abadger1999> I was reading it as -- commercial entities have the money to pay to be able to include it directly in their product.
18:21:56 <mclasen> you don't need one if the user does the downloading...
18:22:06 <mclasen> but I don't want to derail this, carry on
18:22:19 <abadger1999> non-commercial entities have to build in workarounds like depending on the implementation provided by cisco and downloading that at runtime.
18:22:28 <sgallagh> right
18:22:42 <abadger1999> so -- you're still able to implement the standard... but not on the same playing field.
18:22:43 <sgallagh> I'd actually rather avoid saying "like Fedora" there. It's already clear that it affects us.
18:23:01 <sgallagh> Its current wording sounds more general
18:23:37 <sgallagh> right, an implementation that may or may not work and may or may not remain freely licensed forever.
18:24:38 <sgallagh> Anyway, this conversation is rambling at this point. Shall we vote on the version: Acceptance of an insufficiently-free license on the OpenH264 codec will unfairly affect the ability for non-commercial vendors to implement this open standard. This will result in an inability for equal competition in this "open internet".
18:25:13 <nirik> sure, whatever. +1 :)
18:25:21 <mmaslano> +1
18:25:28 <abadger1999> Acceptance of an insufficiently-free license of the OpenH264 codec would mean that non-commercial vendors are not able to implement it on their own terms.  They must rely on the implementation provided by a third party (Cisco) and create workarounds to have the user download that at runtime that a commercial vendor would not need.
18:25:32 <sgallagh> s/ability for/ability of/
18:25:32 <notting> Maybe "entities to implement the standard without being tied to a vendor implementation such as this". Could drop noncommercial
18:25:54 <t8m> sgallagh, +1
18:26:12 <mattdm> sgallagh +1
18:26:19 <pjones> -1 to that language
18:26:32 <sgallagh> Grammar is hard.
18:26:35 <pjones> yep.
18:26:42 <sgallagh> pjones: Whose?
18:26:45 <pjones> yours.
18:27:03 <pjones> I don't like the... sarcasm at the end.
18:27:17 <pjones> If we're making a statement, it needs to be earnest.
18:27:35 <notting> Maybe do a s/noncommercial /open-source/ on toshio 's version?
18:27:43 <sgallagh> Hmm, I didn't really see it as sarcastic, but if it reads that way I agree it should be changed.
18:27:58 <pjones> sgallagh: you used scare quotes.
18:28:02 <abadger1999> notting: works for me.
18:28:08 <pjones> notting: yeah, I can get behind that.
18:28:55 <sgallagh> OK, so Proposal: Acceptance of an insufficiently-free license of the OpenH264 codec would mean that open-source vendors are not able to implement it on their own terms.  They must rely on the implementation provided by a third party (Cisco) and create workarounds to have the user download that at runtime that a commercial vendor would not need.
18:29:09 <notting> +1
18:29:15 <abadger1999> +1
18:29:27 <nirik> +1
18:29:31 <pjones> I'm still not that happy with "commercial vendor" there, but I don't really have a better suggestion
18:29:33 <t8m> seems too weak to me
18:29:35 <pjones> so +1 I guess
18:29:48 <notting> (not that we're going to get a transferable open source license out of Cisco)
18:30:00 <pjones> notting: I don't think they could do so if they wanted to
18:30:20 <notting> pjones: exactly
18:30:22 <t8m> I liked the word "unfairly" in the original sgallagh's versions
18:30:26 <abadger1999> Hmm
18:30:27 <pjones> the terms of their license from mpeg appear to require counted binary distribution
18:31:24 <notting> iirc the counting aspect is why fluendo was the way it was too
18:31:27 <abadger1999> t8m: We could add at the end "This creates an unequal environment for open-source vendors"
18:31:28 <pjones> yep
18:31:37 <t8m> abadger1999, OK
18:32:02 <sgallagh> abadger1999: +1
18:32:33 <notting> Admittedly I doubt mpegla cares about an equal environment. They are a licensing org, after all
18:32:36 <nirik> sure, +1
18:32:55 * abadger1999 still +1
18:32:59 <t8m> +1
18:33:01 <sgallagh> notting: but the IETF may
18:33:01 <pjones> give me a second
18:33:11 * masta looks in
18:33:58 <pjones> instead of "that at runtime that a commercial vendor would not need" something like "their implementation after installation, increasing the burden on open-source users."?
18:34:24 <pjones> (patching text in plain english instead of with diff is harder than it initially seems)
18:34:58 <sgallagh> pjones: I usually use s/old/new/ for that
18:35:15 <pjones> indeed.
18:35:42 <pjones> so anyway
18:35:43 <abadger1999> pjones: I like.
18:35:46 <pjones> my full version would be:
18:36:12 <abadger1999> t8m: Does that remove the need for "unequal environment" for you?
18:36:18 <pjones> Acceptance of an insufficiently-free license of the OpenH264 codec would mean that open-source vendors are not able to implement it on their own terms.  They must rely on the implementation provided by a third party (Cisco) and create workarounds to have the user download their implementation after installation, increasing the burden on open-source users. This creates an unequal environment for open-source vendors.
18:36:24 <abadger1999> +1
18:36:32 <sgallagh> perhaps "unfairly increasing the burden"?
18:36:37 <sgallagh> Or does that sound petulant?
18:36:47 <pjones> I could go either way on "unfairly" there.
18:36:53 <mattdm> +1 (to either ay)
18:37:08 <abadger1999> sgallagh: yeah -- petulant to me to have both unfair and unequal so close together.
18:37:14 <abadger1999> choos one or the other :-)
18:37:19 <abadger1999> *choose
18:37:37 <pjones> I like the unequal statement this way, because it's something the previous statement builds to.
18:37:43 <abadger1999> <nod>
18:37:48 <sgallagh> agreed
18:37:54 <sgallagh> Ok, I'm +1 either way
18:38:02 <pjones> Sonar_Gal: proposal: my text as written above
18:38:05 <sgallagh> Sounds like some people oppose "unfairly"
18:38:14 <pjones> and without the bad completion from my irc client just now ;)
18:38:17 <abadger1999> we're at +3 to this addition.
18:38:23 <notting> +1
18:38:26 <nirik> +1
18:38:29 * pjones is +1 to his proposal
18:38:34 <t8m> pjones, +1
18:38:54 <pjones> I think that's 7
18:39:05 <abadger1999> #info additional text from pjones approved (+1:7, 0:0, -1:0)
18:39:32 <notting> Who shall be our designated IETF spokesperson?
18:39:35 <pjones> I'll add it to the ticket.
18:39:41 <sgallagh> With permission, I'm also going to share this text around to other groups as well.
18:39:55 <sgallagh> (possibly-vain attempt to grow a grass-roots opposition)
18:40:05 <abadger1999> sgallagh: if you need my permision, you can have it.
18:40:20 <abadger1999> notting: If no one else volunteers, I'll send it to the ietf.
18:40:38 <abadger1999> #action abadger1999 to take care of sending the statement to the ietf.
18:40:42 <sgallagh> Well, if anyone thinks this would be a bad idea...
18:41:07 <pjones> sgallagh: go for it
18:41:11 <abadger1999> sgallagh: you need anything else or ready to move on?
18:41:14 <notting> sgallagh : share and enjoy
18:41:26 <nirik> we need the answer to notting's question...
18:41:29 <sgallagh> Nope, sorry to drag this out.
18:41:33 <nirik> ah, nevermind
18:41:36 * nirik reading too slow.
18:41:57 <abadger1999> nirik: keep reading slow and we'll be sure to elect you to the job ;-)
18:42:00 <abadger1999> #topic #1191 Fedora 20 schedule adjustment
18:42:02 <abadger1999> .fesco 1191
18:42:03 <zodbot> abadger1999: #1191 (Fedora 20 schedule adjustment) – FESCo - https://fedorahosted.org/fesco/ticket/1191
18:42:09 * jreznik is here
18:42:27 <notting> There is the how-to handle openh264 download in fedora. Or was that for later?
18:42:34 <abadger1999> jreznik: Care to speak on this?
18:42:43 <jreznik> sure
18:42:46 <abadger1999> notting: I was thinking we'd do that later, if it becomes necessary.
18:42:55 <nirik> notting: I think we deferred it? (I think we should in any case, since we don't know how firefox is going to implement things yet)
18:42:59 <abadger1999> (it might even be a different fesco that has to deal with that).
18:43:06 <jreznik> so we are in similar position as with f18 and we're heading with release to christmas
18:43:20 <nirik> +1 to moving final freeze up a week.
18:43:32 <jreznik> on the last go/no-go meeting were was agreement, that we could cut one week between beta and final to untie our hands a bit
18:43:37 <sgallagh> +1 to moving it up a week, re-evaluate if that proves foolish closer to the date
18:43:49 <mitr> +1
18:43:54 <mmaslano> +1
18:44:04 <t8m> +1
18:44:08 * abadger1999 has vague unease remembering that we tried a few novel ways to get out of slipping past christams before and in the end had to do it anyway.
18:44:24 <abadger1999> but... +1 anyway.. if people think they can do it, might as well try.
18:44:30 <mattdm> I don't like cutting a a week between beta and final
18:44:39 <mattdm> that seems like just wishful thinking
18:44:45 <notting> I don't like the idea of moving in deadlines, but if the go/no go folks already had a handshake agreement...  OK,  I guess?
18:44:46 <jreznik> abadger1999: if we slip once more, then it's clear to release in January
18:44:50 * pjones +1
18:45:05 <jreznik> it does not make sense to try too much
18:45:24 <jreznik> current situation is - we will need a new RC for tomorrow's Go/No-Go
18:45:47 <jreznik> but fix is available, we just need bliver build and RC + validation, should be doable
18:46:03 <jreznik> (unless we find a new showstopper)
18:46:54 <jreznik> btw. we now do early test composes, it helps a lot within that 5 weeks between milestones to stabilize stuff earlier
18:47:12 <abadger1999> jreznik: when would we know if final has blockers that puts us in danger of slipping?
18:47:44 <jreznik> abadger1999: hard to say
18:48:06 <abadger1999> k
18:48:39 <abadger1999> Well, I think some people have reservations but we're at an unofficial +8, -1 right now.
18:48:41 <jreznik> but for final I'd definitely would be ok with skipping christmas instead of any kind of pushing like dec 24 release
18:48:49 <abadger1999> <nod>
18:49:06 <sgallagh> Shall we codify that?
18:49:06 <jreznik> but it would be nice christmas gift :)
18:49:08 <abadger1999> mattdm, notCare to make your vote official?
18:49:15 <sgallagh> If we have another slip, it automatically means January?
18:49:25 <mattdm> uh, sure -1
18:49:35 <abadger1999> err.. that was supposed to be notting but it looks like he's gone.
18:49:46 * sgallagh has to leave in 10 minutes
18:50:00 <pjones> jreznik: I think Dec 24,25, 31, and Jan 1 are /right out/
18:50:07 <abadger1999> sgallagh: yeah -- but I think our decision here is do we slip now or try one more thing to hit our current date?
18:50:20 <jreznik> sgallagh: let's be a bit more flexible around beta, but after that, no
18:50:21 <sgallagh> Mind if we jump to 1194 before I have to leave?
18:50:27 <abadger1999> <nod>
18:50:47 <jreznik> pjones: yeah, I'm not going to try to release anything on friday before christmas during the party as the last year
18:51:11 <abadger1999> #info Move up the final freeze by one week passed (+1:7, 0:0, -1:1)
18:51:20 <jreznik> thank you
18:51:24 <jreznik> just one related topic
18:51:27 <abadger1999> ugh
18:51:33 <abadger1999> 1193 or 1194 :-(
18:51:52 <abadger1999> Since sgallagh has to leave..
18:51:54 <abadger1999> #topic #1194 Ratify Server Working Group governance charter
18:51:56 <abadger1999> .fesco 1194
18:51:57 <zodbot> abadger1999: #1194 (Ratify Server Working Group governance charter) – FESCo - https://fedorahosted.org/fesco/ticket/1194
18:52:05 <abadger1999> I read this, it looks fine to me.
18:52:48 * nirik can +1 or abstain since he's in that group.
18:52:54 <mattdm> yeah looks good to me +1
18:52:57 <sgallagh> Ditto for me. +1 or abstain
18:53:02 <t8m> +1
18:53:04 <abadger1999> I'm surprised that most groups seem to be keeping the +5 votes needed rule instead of establishing abstentions (since fesco seems to dislike that rule for themselves)
18:53:11 <notting> that seems simple enough. +1
18:53:16 <abadger1999> But hey, it's up to the group to decide :-)
18:53:18 <abadger1999> +1
18:53:39 <sgallagh> abadger1999: I think people are concerned about minority decisions succeeding by scheduling meeting times when opponents can't join
18:53:46 <t8m> sgallagh, +1
18:53:54 <abadger1999> <nod>
18:54:05 <mattdm> I think we're also hoping to mostly not have votes in those sorts of situations.
18:54:16 <t8m> abadger1999, I don't think FESCo dislikes the rule for themselves  - at least I don't remember such discussion
18:54:22 <mmaslano> +1
18:54:24 <notting> sgallagh: that's... somewhat dysfunctional. hopefully we would't have to worry about that off of the bat
18:54:39 <abadger1999> sgallagh: well actually -- look at my draft for the env & stacks WG if that's the concern.
18:54:50 <sgallagh> abadger1999: I will catch up on that
18:54:52 <abadger1999> sgallagh: I specify that 0 is different than not voting.
18:55:02 <nirik> interesting.
18:55:09 <abadger1999> We're at +7 I think
18:55:15 * abadger1999 was careful to not double count t8m
18:55:19 <pjones> I'm +1
18:55:32 * nirik notes the various groups seem to be coming up reasonably similar. I wonder if just standardizing them would make sense at some point.... but thats for another day.
18:55:37 <abadger1999> #info Server working group governance charter approved (+1:8, 0:0, -1:0)
18:55:52 <sgallagh> Thanks
18:55:56 <abadger1999> #topic #1193 reboots for all updates -- are we ready for this?
18:55:57 <abadger1999> .fesco 1193
18:55:59 <zodbot> abadger1999: #1193 (reboots for all updates -- are we ready for this?) – FESCo - https://fedorahosted.org/fesco/ticket/1193
18:56:11 <abadger1999> mattdm: So... what's changed from the status quo here?
18:56:29 <mattdm> adam's comment #14 sums it up pretty well
18:56:32 <mitr> My reading of the Change page is that this has been part of the proposal all along.  Is that incorrect?
18:56:33 <sgallagh> I'm inclined to say "yes, we are. People who want to not reboot have the option of using yum/dnf/rpm directly"
18:56:42 <mattdm> mitr I certainly din't read it that way.
18:56:52 <mattdm> and wouldn't have voted to approve it
18:57:17 * nirik also read the change to include this...
18:57:46 <mclasen> it is not actually different - the gnome-shell ui in f19 only offers offline updates too
18:57:47 <Southern_Gentlem> cant vote but alot of users will be not be happy if there is no way to opt -out
18:57:54 * abadger1999 did not read the change to include this.
18:57:57 <mattdm> I'm reareading now, and it pretty clearly says "if an update includes system packages, it will be done as an offline update"
18:57:57 <nirik> we also aren't using the hawkey backend either right?
18:58:02 <mitr> mclasen: That's true but very misleading, as adamw has pointed out
18:58:03 <mclasen> all the people who scream now are using yum anyway
18:58:08 <mitr> ... has already pointed out
18:58:12 <mattdm> which has the strong implication that that's not the case.
18:58:24 <nirik> Southern_Gentlem: you can opt out by just using yum as always.
18:58:35 * adamw meant to go back and read the logs, but I _think_ at the time the change was discussed, the 'online for apps, offline for system' aspect was explicitly part of the proposal
18:58:36 <abadger1999> The way that it specifically calls out offline updates for system updates seems to go along with the previous discussion of offline updates only applying if "OS Components" were updated.
18:58:38 <adamw> but again, i'd have to check the logs.
18:58:56 <mclasen> coment 14 is not correct
18:59:02 <mattdm> mclasen So, you don't want Gnome to appeal to that audience?
18:59:04 <mclasen> update notification do not come from gpk-update-viewer
18:59:28 <adamw> (it'd perhaps help the Change process if the Change pages made it easy to find prior discussion of the Change...)
18:59:43 <jwb> crap.  i forgot FESCo started an hour earlier this week
18:59:45 <mattdm> I don't care if Gnome appeals to the general Fedora desktop user. However, I want *FEDORA* to.
18:59:48 <adamw> mclasen: in F19 i thought they did
18:59:55 <mclasen> no they don't
18:59:57 <adamw> or, rather, they *launch* it
19:00:00 <mclasen> they come from gnome-settings-daemon
19:00:03 * sgallagh has to leave now.
19:00:09 <mclasen> well, _that_ is correct
19:00:16 <adamw> okay, so it's a technicality
19:00:23 <adamw> point being, update notifications give you online updates in f19
19:00:25 <mclasen> no, it isn't
19:00:27 * nirik personally doesn't see this as a big deal. I'd like the change page to reflect reality tho.
19:00:29 <sgallagh> My vote remains at "Offline updates are fine", when it comes up.
19:00:47 * notting is still reading tickets
19:01:05 <mclasen> the f19 behaviour was inconsistent, and we've been critizised for offering offline updates one way, and online updates the other
19:01:19 <mclasen> what is in f20 now is consistent
19:01:24 <adamw> mclasen: i was just establishing the practical situations in f19 vs. f20: in f19, different methods of triggering an update give online or offline with no logic as to which is which. you're right that i was incorrect about what generates the update notifications, but the practical upshot is: in f19, update notifications trigger online updates.
19:01:28 <mitr> adamw: I have nos checked, and there was not really a discussion (you have mentioned an assumption in http://meetbot.fedoraproject.org/fedora-meeting/2013-08-07/fesco.2013-08-07-17.29.log.html but it wasn't discussed)
19:01:31 <adamw> mclasen: yeah, i made that exact point in my comment
19:01:35 <adamw> mitr: ah, thanks
19:01:44 <adamw> mclasen: i'm not defending the f19 situation at all, merely clarifying it...
19:01:47 <mclasen> abadger1999: it turned out to be impractical to offer online updates of applications with the current application packaging
19:02:07 <mclasen> they are not independent enough of either the OS or each other
19:02:16 <mattdm> mclasen and that would have been an excellent time to say "we need to make a major change to this feature as proposed"
19:02:38 <mclasen> mattdm: in an ideal world, where paperwork costs no time, and days never end, certainly
19:02:50 <mclasen> but this feature has not exactly been developed in the closet
19:02:54 <mitr> mattdm: Would it be reasonable to assume that both Server and Cloud would be updated using a different mechanism, (any of command-line yum, Spacewalk, Cockpit, OpenLMI, image rebuild) and therefore doesn't need to care?
19:03:09 <mclasen> hughsie has gone out of his way to make the progress on gnome-software as public as possible
19:03:14 <mattdm> mitr yes, I think that's the case
19:03:19 <notting> mclasen: i'm curious about the 'online updates of applciations with the current application packaging', and what can be done to fix that.
19:03:26 <mclasen> gnome-software is not targetting either the server or cloud
19:03:34 <mattdm> I care about Fedora _as a whole_.
19:03:43 <mitr> mclasen: given the multiple times FESCo had to become actively involved to make sure the packaging and GUI teams are talking to each other, I have my doubts
19:03:44 <mattdm> I am not on FESCo as a cloud-or-server-only guy.
19:03:56 <mattdm> And for that matter, I'm not working on Fedora as only that.
19:04:00 <adamw> mclasen: the change in plan as regards offline/online updating was not communicated anywhere prominent i could find. i only found out about it by explicitly asking in IRC. it would have been useful for testing, documentation, public communication purposes to know the plan earlier. we're all pressed for time, but this isn't just bureaucracy
19:04:02 <mclasen> mitr: fesco is sadly ineffective at making that discussion happen
19:04:06 <mattdm> But that seems irrelvant
19:04:11 <nirik> mitr: the one danger is: applications specificially seeing that and saying "oh, we don't need to care, people can do off-line updates, we can be sloppy"
19:04:14 <mattdm> thank you adamw
19:04:17 <mclasen> mitr: the discussion happened when we sent richard to brno for a week
19:04:36 <mattdm> there is a change management process here for a reason.
19:04:40 <mclasen> mattdm: I don't think you really want gnome on your cloud image, right ?
19:04:44 <mclasen> is this a strawman ?
19:04:54 <nirik> can we move on to what we would like to happen instead of rehashing the past?
19:04:55 <mattdm> mclasen I have no idea why you are even bringing that up.
19:05:07 <mclasen> mattdm: you were the one talking about cloud and server
19:05:15 <adamw> mclasen: not attempting to attack you, just trying to explain that this process really is useful to other parties, it is not pointless bureaucracy: i know QA and docs and other teams watch the Change process to try and keep a handle on what is changing
19:05:26 <nirik> proposal: ask change owners to update page to reflect current reality.
19:05:29 <mattdm> mclasen no that was mitr
19:05:32 <mattdm> nirik -1
19:05:53 <mclasen> adamw: I am not feeling attacked by you, I am feeling sidelined by mattdm who did not seek to talk to me or richard or allan or ryan before filing this ticket
19:06:01 <nirik> mattdm: ok, counter proposal? what do you want here? I'm really not sure...
19:06:09 <mattdm> proposal: ask feature implementers to include a mechanism for online updates for non-system updates, as the feature page describes
19:06:36 <jwb> i'm having a hard time following that proposal
19:06:40 <mitr> (... and for which bodhi is already collecting metadata, btw)
19:06:44 <nirik> and go back to both, with confusion and doom?
19:06:57 <nirik> -1
19:06:58 * abadger1999 is willing to +1 mattdm's proposal.
19:07:00 <mattdm> mclasen this is our discussion process. what's the problem you have with that?
19:07:10 <mattdm> jwb sorry, what's not clear?
19:07:29 <mitr> mattdm: It's one week before a beta, do we want the risk?
19:07:34 <drago01> so we had a problem with the f19 implementation, implemented a fix and now fesco does not like the fix?
19:07:46 <mclasen> mattdm: I have a problem with you not doing any investigation of background, motivation and circumstances that lead to what we have now.
19:07:48 <drago01> and the proposed solution is "revert the fix" ?
19:07:59 * notting agrees with mitr on that particular point
19:08:14 <mclasen> I have not even been invited to this discussion, I just happend to notice the ticket
19:08:20 <t8m> mitr, +1
19:08:29 <mitr> notting: (the practical upshot of this concern "wingging" is... FESCo having very little power to change things)
19:08:34 <mattdm> mitr I don't *want* the risk. But I think we need to acept it.
19:08:43 <mitr> , "winning", hah.  I have no idea how I managed that typo.
19:08:48 <adamw> mattdm: and if desktop team says 'there's no chance of us doing that for f20', what happens?
19:09:15 <mitr> mattdm, adamw: We have implicitly assumed that the contingency plan (in this case, revert to gnome-packageit) is riskless enough.
19:09:30 <notting> mclasen: is the goal still online updates for apps? (for whatever value of 'apps'?)
19:09:30 <adamw> the 'contingency plan', to me, is inarguably worse than the current situation
19:09:32 <mattdm> adamw that is why there is a contingency plan.
19:09:34 <abadger1999> drago01: from the past change/feature discussions.... the fix that would not have raised eyebrows would have been to make gnome-shell notifications also do an online update.
19:09:37 <nirik> adamw: +1
19:09:44 <adamw> so activating the contingency plan would be a terrible outcome that should be avoided.
19:09:53 <mattdm> I don't like doing that, which is why I'm suggesitng the other.
19:10:02 <abadger1999> drago01: or file a Change to hange the scope of the previously agreed Offline Updates.
19:10:07 <notting> mclasen: that is, the long-term goal, not necessarily what is implemented now
19:10:29 <adamw> abadger1999: that's not a good answer to anything. there is no logical reason for update notifications to trigger an online update; the f19 situation did not make any sense, it was just an undesirable outcome of piecemeal development
19:10:46 <mclasen> notting: I think I alluded to that on the list. yes, that is certainly a possibility
19:10:53 <mclasen> and a desired long-term goal
19:11:04 <mitr> mclasen: rjones, as the owner of the change, has been invited
19:11:09 <nirik> we could add a menu item that runs 'gnome-terminal -e yum update' :) online updates!
19:11:19 <drago01> nirik: n
19:11:20 <drago01> o
19:11:20 <mitr> s/rjones/rhughes/
19:11:26 <mclasen> mitr: hughes, not jones - and he's on pto today...
19:11:28 <nirik> drago01: I was not serious for the record.
19:11:40 <drago01> nirik: that's the internet ;)
19:11:41 <adamw> nirik: people who desperately desire a graphical online update method can still install gpk-update-viewer; it's been made a sub-package of gnome-packagekit that is not installed by default
19:11:47 <adamw> (just for the record)
19:12:04 <nirik> sure, or yumex even
19:12:19 <drago01> mattdm: given our amount of updates ... do we even have many situations where there are only application updates?
19:12:21 <jreznik> for contingency plan - there's a deadline when it makes sense to trigger it, not sure it's now - so late...
19:12:28 <drago01> mattdm: we pretty much always have "system updates"
19:12:47 <adamw> for whatever it's worth, my opinion is that on a _practical_ level the best outcome at this point would be to go ahead with what we have now.
19:12:55 * nirik is with adamw
19:12:56 <notting> drago01: that is a related (potentially unsoluble) probelm
19:13:27 <mattdm> drago01 We also need to batch updates. I'd be much more comfortable with this in the context of a plan around that.
19:13:29 <drago01> notting: sure but it means we are talking about a rare case that in practice almost never happens
19:13:56 <mclasen> mattdb: I'll certainly bring that up as a topic in the workstation wg
19:14:59 <mattdm> drago01 that's a reasonable point and I don't have data on it. It is my hunch that it is often the case that we have a set of updates where simply restarting the user session would be sufficient.
19:15:15 <notting> ... are we moving towards anything in particular? should we toss out a proposal? (i have one...)
19:15:23 <mattdm> notting go for it
19:16:05 <notting> proposal: keep f20 behavior as-is, but update Change page to more clearly reflect the current behavior
19:16:10 <drago01> mattdm: from a users pov restart or relogin is more or less the same (the latter is a bit faster but thats it)
19:16:10 <mitr> mattdm: ... and we don't have software that would update only _that_ set of updates.  There are many theoretical solutions, but nobody seems to be working on the required infrastructure
19:16:48 <adamw> non-voting "+1" to notting's proposal
19:17:02 * nirik proposed that a while ago. ;) sure, +1
19:17:10 <adamw> mitr: i don't believe bodhi even lets you mark such updates at present - only 'restart or not'
19:17:19 <mattdm> notting -1
19:17:29 <drago01> adamw: you mean mattdm
19:17:48 <adamw> drago01: i was just following up mitr's comment
19:17:57 <drago01> adamw: oh .. .ignore me
19:18:03 * abadger1999 continues to vote with mattdm on this one... so -1 for now
19:18:08 <t8m> notting, +1 just to move on
19:18:17 <abadger1999> What about this:
19:18:47 <nirik> I don't see the appeal of going back to the f19 behavior.
19:19:07 <abadger1999> Proposal to have a new Change for Offline Updates that states that we're going to have all offline updates in gnome?
19:19:30 <adamw> how is that clearer than correcting the existing Change?
19:19:39 <adamw> in that scenario you have to know to read both Changes together
19:19:48 <drago01> it is the same thing just more bureacratic
19:19:55 <adamw> more work, more prone to confusion
19:20:03 <mattdm> yeah i agree with that.
19:20:05 <jreznik> yep, more work, update current one
19:20:20 <mattdm> I could be 0 or +1 to notting/nirik in the context of a larger picture.
19:20:23 * jreznik is definitely ok to go through that burden if fesco wants but prefers nooooot
19:21:09 <nirik> would adding release-notes/docs for the f20 behavior (and noting all the ways you could still do on-line updates) help sway you mattdm / abadger1999?
19:21:22 <mattdm> nirik absolutely.
19:21:53 <abadger1999> nadaexisting change would be corrected as well.
19:21:55 <notting> i was hoping/assuming a clarified change page would make its way to docs/relnotes. probably should have been more explicit
19:21:57 <abadger1999> adamw: ^
19:22:13 <nirik> so, proposal: keep f20 behavior as-is, but update Change page to more clearly reflect the current behavior, add release-note about it?
19:22:22 <abadger1999> but the idea is that it would be more explicit as to what was intended now and going forward and the scope.
19:22:36 <mattdm> I would also like to see a plan for seamlessly handling online updates in the future. even the handwavy future.
19:22:37 <jreznik> notting: there's a release note bug related to the change page, request for update should go there
19:22:51 <mitr> notting, mattdm: I could be +1, but, so that we learn from this experience, something like
19:22:54 <mitr> #info Change owners are trusted to, _and dependent upon_, highlight all relevant changes.  Not noting important changes (whether due to oversight or intentionally) breaks the Change process, and would sadly motivate FESCo to institute a more heavy-handed and higher-overhead process, which nobody wants to have.
19:22:55 <adamw> i'd think you can make the Change process more explicit in requiring the Change owner to communicate modifications independently of fiddling with this particular practical case
19:22:55 <abadger1999> (release notes could seerve a similar purpose... although that really leaves out the scope portion).
19:22:56 <mitr> ? (+ the appropriate update to Change policy pages)
19:23:01 <adamw> but either of those approaches works okay for me
19:23:16 <mattdm> mitr +10000000
19:23:22 * adamw was assuming the release notes would be documenting this Change in any case, and one of the points of fixing the Change page would be to ensure they did so accurately
19:23:49 <mitr> Can we get an explicit owner to implement the relnote change, just to make sure it won't be forgotten?
19:23:51 <jreznik> https://bugzilla.redhat.com/show_bug.cgi?id=1001335
19:23:56 <jreznik> mitr: ^^^
19:23:58 <abadger1999> mitr: I think you may need a stick... we've been tweaking that wording for ages and yet we always arive back at this place :-/
19:24:00 <mmaslano> mitr: +1
19:24:08 <mitr> jreznik: great
19:24:27 <mitr> abadger1999: We work only with the tools we have
19:24:30 <jreznik> mitr: exactly for this reason - not to forget anything
19:24:32 <adamw> fwiw, once the dust settles, the fact that this has been brought into the open and clarified seems like a fairly positive outcome of the Change process, to me.
19:24:44 <nirik> future plans/scope may well depend on what the workstation wg decides to do.
19:24:55 <abadger1999> nirik: or base design.
19:24:59 <nirik> right.
19:25:07 <nirik> along with grouping updates, etc.
19:25:08 <abadger1999> depending on whether it becomes a fedora standard or a workstation implementation.
19:25:21 <nirik> the entire updates story.
19:25:39 <nirik> anyhow, where are we?
19:25:42 <mattdm> nirik and that's fine too. I just want to be able to tell people that rebooting-for-updates-all-the-time is not the *desired* state and that we're on the road to something.
19:25:55 * mclasen bows out
19:26:12 <abadger1999> hmmm... mattdm -- if that's your goal, how have we addressed that with the proposals?
19:26:27 <mattdm> we... haven't?
19:26:28 <abadger1999> proposals I see seem to say the opposite.
19:26:50 <nirik> I don't think you can promise them that right now... only that the desktop does by default, but you can do your own on-line updates if you wish
19:26:53 <abadger1999> we're documenting offline-updates as the new status quo.
19:26:58 <mitr> mattdm: Structurally I think this is more up to jzeleny's team and Base than GNOME
19:27:25 <adamw> abadger1999: that's just for F20: the practical state for  F20 is 'all offline updates' and we need to explain that
19:27:32 <adamw> the stuff about 'working towards something else' is further down the road
19:27:33 <adamw> (as I read it)
19:27:44 <abadger1999> adamw: but with a lack of any other documentation, it becomes the new normal.
19:27:44 <mattdm> yeah.
19:27:48 <adamw> er, 'all graphical updates offline by default'
19:27:50 <abadger1999> adamw: which is okay in its own right
19:27:58 <adamw> ...'for GNOME'
19:28:07 <abadger1999> adamw: but not if mattdm's goal is to get back to online updates i nthe future.
19:28:33 <mattdm> I would like updates to be more seamless and less painful. Offline updates are nice from a pristine purity point of view but jarring for users.
19:28:40 <nirik> how can we promise anything for the future? :)
19:28:52 <mattdm> the solution of only checking for updates infrequently is a really bad work-around
19:28:53 <adamw> true, if everyone's agreed that we're aiming to have online updates for apps or something in the Glorious Future when it's technically possible, it'd be good to write that down, i guess.
19:29:02 <mitr> nirik: We can't, but having a written record ACKed by all involved parties would be something.
19:29:22 <mattdm> I don't think it's so crazy to try and target a better future, is it?
19:30:01 <mattdm> I need to go back and take my turn at the Fedora booth.
19:30:01 <nirik> I find it distastefull to put in that critera right now... seems like putting in a constraint when we don't know any of the other variables yet.
19:30:07 <mattdm> there are not a lot of us there.
19:30:33 <mattdm> as I said before, my main concern was to talk about this.
19:30:40 <mitr> nirik: "matching state of the art of other OSes" shouldn't be distasteful
19:30:42 <adamw> nirik: look at it as an 'aspiration' not a 'criterion'
19:30:54 <mattdm> I would like to vote +1000000 again to mitr's info statement above
19:31:19 <mitr> yeah, can we make it a formal addition to the process?
19:31:20 * adamw wonders if the FESCo Electoral Commission needs to review mattdm's voting practices ;)
19:31:38 <mattdm> lol
19:31:58 <jwb> i might have missed something, but i'm not sure why making a statement beyond F20 is relevant at all
19:32:08 <jwb> because after F20, it's up to the WGs to define their products.
19:32:09 <nirik> I guess, but it seems like a shot in the dark
19:32:12 <mattdm> and I'll change my vote to 0 on the nirik/notting proposal above
19:32:13 <nirik> right.
19:32:14 <mitr> proposal: Change owners are trusted to, _and dependent upon_, highlight all relevant changes.  Not noting important changes(whether due to oversight, different opinion of importance, or intentionally) breaks the Change process, and would sadly motivate FESCo to institute a more heavy handed and higher-overhead process, which nobody wants to have.
19:32:17 <mitr> mitr + jreznik to update Change policy pages to that effect
19:32:28 <mitr> jreznik2: (I hope that's fine?)
19:32:30 <drago01> adamw: it just means he used up all hs votes for the next 999999 votes ;)
19:32:46 <t8m> mitr, +1 :)
19:32:47 * abadger1999 changes vote to 0 along with mattdm :-)
19:32:54 <pjones> mitr: "and depdended upon to", you mean?
19:32:57 <mitr> pjones: yes
19:32:59 <abadger1999> mitr: +1 although I don't think it has much practical impact.
19:33:02 * mitr is +1 for the record
19:33:07 <nirik> sure, but what abadger1999 said.
19:33:20 <notting> mitr: -1. not generally an fan of implied threats
19:33:50 <nirik> where are we on the other proposal ?
19:33:53 <mitr> notting: would you be fine with stopping before ".. and would"?
19:34:06 * mattdm is off. talk to you all later.
19:34:24 <pjones> -1 - I'm not big on implied threats *and* I don't think there's much point in approving something many of us don't think will have any practical impact.
19:34:44 * pjones notes he's out of here in 11 minutes
19:35:40 <notting> mitr: "trusted to, and dependent upon, highlight" doesn't parse to me. word missing?
19:36:09 <pjones> notting: <pjones> mitr: "and depdended upon to", you mean?
19:36:16 <pjones> except I typoed it as well
19:36:18 <abadger1999> Probably correct to: "trusted and *depended upon* to highlight
19:36:32 <nirik> do we really need to adjust this now?
19:36:42 * mitr will go with whatever the native speakers decide
19:37:16 <pjones> there's no real difference between what I said and what abadger1999 said.
19:37:31 <pjones> but nonetheless, the exact word there isn't the biggest issue
19:37:45 <notting> i can be +1 to the reworded version assuming the "and would" bit is dropped. but i don't think that's the critical item here
19:37:54 <abadger1999> yeah, just how fast we type.
19:37:59 * notting rephrases his earlier proposal:
19:38:39 <notting> proposal: Keep F20 behavior as-is. Update Change page to reflect current implementation, update docs and release notes to match.
19:38:58 <abadger1999> pjones: For mitr's proposal -- are you still -1 with the "and would..." dropped?
19:39:11 * abadger1999 would like to close that one out before voting starts on nottings.
19:39:13 <mitr> notting: +1
19:39:22 <mitr> abadger1999: sorry
19:39:46 <pjones> abadger1999: I could be +1 to it, but...
19:39:59 <pjones> no, actually I think I'm still -1
19:40:05 <pjones> just because I don't think it'll help.
19:40:24 <pjones> notting: +1 to yours.
19:40:45 <abadger1999> #info mitr's proposal to update change policy passed (+1:5, 0:0, -1:1)
19:41:06 <abadger1999> notting: 0
19:41:19 <nirik> notting: +1
19:41:32 <abadger1999> I believe I can state sgallagh was +1  and mattdm was 0
19:41:48 <abadger1999> notting: You would make 5
19:42:01 <notting> i'm +1 to what i proposed
19:42:31 <abadger1999> t8m, mmaslano: you can vote for the record if you like.
19:42:47 <mmaslano> I have no opinion on this issue
19:43:30 <abadger1999> #info  Proposal to Keep F20 behavior as-is (all offline updates for gnome). Update Change page to reflect current implementation, update docs and release notes to match.  Passed (+1:5, 0:2, -1:0)
19:44:28 <abadger1999> We have one stalled bug ticket that could be looked at.
19:44:35 <abadger1999> Do we want to do that now or defer?
19:45:09 * abadger1999 has two announcements for open floor but probably nothing that needs debate
19:45:19 <mitr> I think twoerner has specifically joined the meeting (are you still around?), so we might want to discuss it today
19:45:22 <nirik> is that ticket 1189?
19:45:32 <twoerner> mitr: yes, I am around
19:45:41 <abadger1999> nirik: yeah, 1189
19:46:21 <abadger1999> #topic #1189 Stalled bug 758826 -- requesting intervention
19:46:23 <abadger1999> .fesco 1189
19:46:24 <zodbot> abadger1999: #1189 (Stalled bug 758826 -- requesting intervention) – FESCo - https://fedorahosted.org/fesco/ticket/1189
19:46:32 <abadger1999> .bug 758826
19:46:37 <zodbot> abadger1999: Bug 758826 system-config-firewall should include 'submission' in list of known ports - https://bugzilla.redhat.com/show_bug.cgi?id=758826
19:46:54 <notting> *s-c-firewall*?
19:47:02 <notting> i.e., the non-firewalld-using-version?
19:47:17 <twoerner> yes.. it is still available..
19:47:25 <abadger1999> <nod>
19:47:47 <nirik> if an update is planned, nothing for us to do here?
19:48:10 <twoerner> I am just putting all remaining patches for the new version together...
19:48:27 <twoerner> there are some on my local repo
19:48:39 <notting> the gui for the non-default firewall service is... somethign i have a hard time understanding why it needs escalated to this point. maybe i'm missing something.
19:48:54 <nirik> me too.
19:49:04 <twoerner> me too
19:49:05 <nirik> twoerner: could you update the bug that you are working on a new version?
19:49:07 <abadger1999> twoerner: cool.  If you just want to add one line to the bug like "I'm anticipating pushing an update in a week/2 weeks" that would probably be enough.
19:49:23 <twoerner> ok
19:49:49 <mitr> notting: We kind of signed up for this job last week when we said "escalate individual package problems to FESCo" (although the relative timing is opposite)
19:50:00 <abadger1999> notting: I think it fell out of lat week's meeting (where we said this is what we should do when a maintainer didn't respond to bugs in bugzilla.rh.c)
19:50:09 <notting> abadger1999: mitr: fair enough.
19:50:39 <abadger1999> #info twoerner working on an update.  Will update the bug report.
19:50:45 <abadger1999> #topic Open floor
19:50:59 <twoerner> abadger1999: done
19:51:05 <abadger1999> twoerner: thanks!
19:51:18 <abadger1999> I have two items here
19:51:20 <abadger1999> #topic F21 Change Process
19:51:30 <abadger1999> I discussed this with jreznick earlier
19:51:37 <abadger1999> Many things are in flux in F21 due to the changes for fedora.next but we are still building updates for Rawhide.
19:51:46 <abadger1999> we still do want to coordinate the major changes there so it makes sense to open up the Changes process and start approving early Changes.
19:51:57 <nirik> sounds fine to me
19:52:06 <abadger1999> Cool.
19:52:15 <abadger1999> #info F21 Change Process is open for submissions
19:52:22 <t8m> good
19:52:23 <abadger1999> #topic Elections
19:52:35 <abadger1999> jreznick also reports that the board is ok with January FESCo elections - just using default rules (30 days after release) with a bit of christmas tweaks.
19:52:45 <notting> ok
19:52:57 <abadger1999> So there's no problems there
19:53:04 <nirik> ok
19:53:05 <abadger1999> We will need an election wrangler.
19:53:17 <jreznik2> Ankur is busy with school
19:53:25 <jreznik2> I can do the call
19:53:29 <abadger1999> Excellent
19:53:56 <abadger1999> #info jreznik will send an announcement that we're seeking an Election Wrangler.
19:54:05 <abadger1999> #topic Next week's Chair
19:54:09 <abadger1999> Any volunteers?
19:54:42 * nirik can if no one else wants it
19:55:03 <abadger1999> #info nirik to chair next week's meeting
19:55:06 <abadger1999> Thanks nirik
19:55:10 <abadger1999> #topic Open Floor
19:55:19 <nirik> I have one quick (hopefully) item...
19:55:30 * abadger1999 passes the microphone
19:56:04 <nirik> not wanting to make meetings longer, but do we want to start asking our WG coordinators to give us a short status of their workgroups each meeting? or only when there's something we need to address? or ?
19:56:26 <jwb> i was kind of expecting to file a ticket with FESCo for updates when needed
19:56:29 <t8m> definitely only when there is something we need to address
19:56:51 <abadger1999> At least at the moment I think people are still working on charters and governance... not sure about later.
19:56:57 <t8m> I suppose that filing a ticket could be skipped but please no 'regular status updates of wgs'
19:57:06 <mitr> A monthly status check (if only to get "nothing to report") might be reasonable
19:57:24 <nirik> I wasn't picturing anything elaborate...
19:57:41 <jwb> then just ping the liaisons.  no need to drag them to a meeting if there's nothing to discuss
19:57:49 <nirik> ok.
19:58:01 <mitr> I expect that most of the conversations will happen directly, with people just talking to each other, but having a place to highlight important aspects (... in the spirit of that Change owner's responsibility above :) ) might make sense.
19:58:17 <jwb> mitr, right.  which is why i opened 1195
19:59:21 <nirik> thats all, just wanted to bring it up
19:59:34 <notting> i have a short item
20:00:47 <abadger1999> notting: go ahead
20:00:50 <notting> opinions on "If you have a project in Fedora that is intending to use OpenH264 in some way, please talk to fesco before integrating code to use it" ? b/c it's going to get escalated to us anyway.
20:01:08 <abadger1999> notting: Works for me.
20:01:13 <t8m> notting, OK
20:01:15 <notting> (just more clearly stating the 'we will cross that bridge when we come to it' from earlier)
20:01:16 <nirik> fine, +1
20:01:23 <mitr> notting: +1
20:01:27 <sgallagh> One other thought for open floor: firm deadline on the PRDs? January is quite vague.
20:01:34 <sgallagh> Feel free to defer this to next week
20:01:42 <sgallagh> notting: +1
20:01:58 <nirik> 8th? 15th?
20:02:39 <notting> #info Regarding the earlier discussion on OpenH264, if Fedora community members have a project in Fedora that is intending to use OpenH264 in some way, please talk to FESCo before integrating code to use it.
20:02:58 <abadger1999> Mmm.. Maybe we should defer a week -- one thing that came up in the env and stacks group, for instance, is that we probably are going to have something different than a PRD.
20:03:09 <abadger1999> since we don't directly create a single product.
20:03:31 * sgallagh nods
20:03:40 <sgallagh> Probably choosing the term PRD was incorrect in the first place.
20:03:52 <abadger1999> sgallagh: Want to open a meeting ticket so this is definitely on the agenda next week?
20:03:57 <sgallagh> I've seen some confusion about it (and also discovered that it's a rude word in Czech...)
20:04:03 <sgallagh> abadger1999: Will do
20:04:09 <abadger1999> excellent.
20:04:29 <abadger1999> Okay, if there's nothing else, I'll close in 1 minute.
20:06:31 * abadger1999 notes that 60 seconds takes longer at the end of a meeting than in the middle
20:06:34 <abadger1999> #endmeeting