17:00:08 <nirik> #startmeeting FESCO (2014-04-23)
17:00:08 <zodbot> Meeting started Wed Apr 23 17:00:08 2014 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:08 <nirik> #meetingname fesco
17:00:08 <zodbot> The meeting name has been set to 'fesco'
17:00:08 <nirik> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
17:00:08 <nirik> #topic init process
17:00:09 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
17:00:19 * notting is here
17:00:20 <nirik> who all is around for an exciting fesco meeting?
17:00:21 <t8m> hello
17:00:42 <mitr> Hello
17:00:55 * jreznik is around for fesco but only for limited time today, so hello!
17:01:26 <patsy> hi!
17:01:26 <nirik> we need 1 more for quorum I think.
17:01:40 <pjones> sorry, my other previous just finished, and I'm going to be AFK for 2-3 minutes now.
17:02:29 <jwb> hi
17:02:32 <nirik> no worries.
17:03:58 <pjones> I see nothing happened in my absence
17:04:08 <nirik> it all happened so fast. ;)
17:04:17 <nirik> #topic #1221 →  Product working group activity reports
17:04:17 <nirik> .fesco 1221
17:04:17 <nirik> https://fedorahosted.org/fesco/ticket/1221
17:04:20 <zodbot> nirik: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
17:04:41 <nirik> anything anyone would like to discuss or highlight from working groups this week?
17:05:24 <nirik> I'd like to note that jreznik opened a rel-eng ticket asking working groups to note what releng changes they need/want.
17:05:31 <jreznik> I have only one thing for working groups - deliverables email I sent todya
17:05:36 <nirik> https://fedorahosted.org/rel-eng/ticket/5891
17:05:38 <nirik> yeah.
17:05:47 <jreznik> nirik: you were faster, thanks :)
17:05:51 <nirik> #info working groups should note on the releng ticket changes they need/desire.
17:06:25 <jreznik> and how theirs deliverables would look like aka lives, install iso, images etc.
17:06:26 <nirik> anything else on working groups ? or shall we move on. We have a full changes slate. ;(
17:06:40 <mattdm> sorry, irc client was glitched on this channel.
17:06:42 * mattdm is here now.
17:07:18 <nirik> mattdm: anything to discuss or note from working groups this week? or shall we move on...
17:07:24 <nirik> (aside from whats in the ticket)
17:07:30 <mattdm> nirik nothing other than what's in the ticket.
17:07:36 <nirik> cool
17:07:59 <nirik> #topic #1250 →  F21 Self Contained Changes
17:07:59 <nirik> .fesco 1250
17:07:59 <nirik> https://fedorahosted.org/fesco/ticket/1250
17:08:00 <zodbot> nirik: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250
17:08:05 <jreznik> for changes - there are still a few to announce, mostly self contained, trying to get more info or just in backlog as I was out + bank holidays.... but mostly, system wide are reported
17:08:17 <nirik> jreznik: thanks.
17:08:37 <nirik> https://fedorahosted.org/fesco/ticket/1250#comment:18
17:08:41 <nirik> has the list for this week
17:09:05 <nirik> #info sgallagh was -1 for the remote journal change and +1 for all the rest
17:09:31 <t8m> I agree with sgallagh that the remote journal change should be promoted to Systemwide
17:09:35 <mitr> I'm fine with all of them
17:09:57 <mitr> The remote journal change is not actually saying that this is the recommended way to do it or the like
17:10:30 <t8m> mitr, well it can be perceived so because we would be advertising it in relnotes
17:10:30 <nirik> mitr: true, but saying it's a 'change' means more people will try and use it
17:10:32 <mattdm> I'm fine with all of them too. We can ask the journal change to include the clarification that it is one of several possible approaches
17:10:34 <pjones> I wish we'd rename "Adopt Your Cattle" to something descriptive.
17:11:01 <nirik> "fedora server in the cloud" ?
17:11:12 <mitr> t8m, nirik: true.  We can clarify, e.g. saying that Server has chosen to keep recommending rsyslog perhaps?
17:11:21 <mattdm> pjones, nirik: that's fine with me, although I would enjoy keeping the fun name in there somewhere as well
17:11:30 <mattdm> (does it really matter?)
17:11:43 <mitr> t8m, nirik: though that would be a different conversation to have I think
17:11:47 <jwb> mattdm, for documentation purposes, yes
17:11:53 <pjones> (does it matter that it's hard to look at it and tell what it's about?  Are you serious?)
17:12:10 <jwb> the current name is cute and fun if you know wtf it's talking about.  otherwise it's really confusing
17:12:17 <t8m> pjones, +1
17:12:24 <jwb> maybe it's a feature about Cowsay!
17:12:33 <mattdm> I mean, does the name used in the change directly translate to the words used in user-facin documentation?
17:12:34 <pjones> jwb: I was really hoping it was :)
17:12:34 <nirik> all hail cowsay!
17:12:45 * mattdm would love a new feature about cowsay. that thing isn't unicode compliant
17:12:57 <jwb> mattdm, says the guy that repeatedly argued with me about PRDs and media impacts...
17:13:09 <jwb> mattdm, so yeah, the name of the change should be descriptive
17:13:16 <jwb> because people look at the change list
17:13:23 <jwb> not the change pages, just the list
17:13:29 <mattdm> Okay, I'm swayed -- I can rename it
17:13:41 <jwb> and then they write "here are the features in the upcoming fedora release"
17:13:46 <jwb> *splat*
17:14:07 <mattdm> although I think that _for the certain segment where it has instant meaning_, it's more interesting/exciting
17:14:19 * mattdm goes and edits now
17:14:27 <pjones> anyway, didn't mean to completely derail this
17:14:54 * jreznik asked sgallagh_afk if adopt catle is what they want, mattdm wasn't online :D
17:15:10 <nirik> so, I'm +1 to all of them except the remote journal... on that one I really hope we can convince them to change the implementation...but I guess we could adjust the change if so...
17:15:56 <notting> nirik: is your concern the usage of http, or something else?
17:16:50 <nirik> http and ssl certs and two ssl libraries. ;(
17:17:07 <t8m> I actually have no problem with the implementation - the use of https is convenient for some environments. It just shouldn't be advertised as "The preferred way for remote journal"
17:17:36 <t8m> advertised and/or perceived
17:18:42 <notting> ... well, if it's the only implemented way, it's preferred by default
17:18:59 <nirik> so, in the interests of moving on to the other pile of changes... proposal: all self contained changes proposed this week approved, except remote journal, we will work more with change owners and revisit next week.
17:19:00 <mitr> I'm generally unhappy with the whole area, the reinventing and reimplementing and rediscovering the data loss problems, but that's not solving anything; the best I can do is suggest changes to the implementation.
17:20:37 * nirik listens to crickets. Other proposals?
17:20:42 <mitr> nirik: +1, if you take the action to raise specific concerns :)
17:21:03 <t8m> nirik, +1
17:21:06 <pjones> nirik: +1
17:21:08 <mattdm> nirik: +1
17:21:22 <mitr> (Reading the mailing list thread I didn't see much indication this was going to be proposed to be deferred :/)
17:21:35 <nirik> well, it sounds like we have 2: 1) still some questions about protocol... is this going to be the final setup? 2) is this change just to say 'here it is, try it if you want' and not 'this is the default method of doing remote syslogs in fedora 21
17:22:13 <mitr> notting: for the record, rsyslog can AFAIK transport journal in full, modulo record length limits
17:22:26 <nirik> #agreed all self contained changes proposed this week approved, except remote journal, we will work more with change owners and revisit next week. (+5,0,0)
17:22:36 <notting> nirik: +1
17:22:38 <nirik> I'll try and raise those concerns, please do raise any I miss
17:22:46 <nirik> #undo
17:22:46 <zodbot> Removing item from minutes: AGREED by nirik at 17:22:26 : all self contained changes proposed this week approved, except remote journal, we will work more with change owners and revisit next week. (+5,0,0)
17:22:50 <nirik> #agreed all self contained changes proposed this week approved, except remote journal, we will work more with change owners and revisit next week. (+6,0,0)
17:23:07 <nirik> #topic #1287→   approve directory /opt/fedora
17:23:08 <nirik> .fesco 1287
17:23:08 <nirik> https://fedorahosted.org/fesco/ticket/1287
17:23:09 <zodbot> nirik: #1287 (approve directory /opt/fedora) – FESCo - https://fedorahosted.org/fesco/ticket/1287
17:24:00 <nirik> so, I guess this is just a rubber stamp to apply for a name for scls to use?
17:24:14 * notting is +1
17:24:19 <t8m> +1
17:24:19 <pjones> +1
17:24:23 <mattdm> +1
17:24:26 <nirik> +1
17:24:27 <mitr> It's kind of curious that it isn't through the FPC, but whatever, +1
17:24:27 <pjones> nirik: yeah, looks that way
17:24:49 <nirik> #agreed This is approved (+6,0,0)
17:25:24 <nirik> #topic #1288 F21 System Wide Change: Changes/(A)Periodic Updates to
17:25:24 <nirik> Images - https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images·
17:25:25 <nirik> .fesco 1288·
17:25:25 <nirik> https://fedorahosted.org/fesco/ticket/1288
17:25:26 <zodbot> nirik: Error: '1288\xc2\xb7' is not a valid integer.
17:25:36 <nirik> nice. ;)
17:26:16 <jwb> i think someone asked the title be changed to reflect it was for cloud images
17:26:19 <mattdm> this obviously is a declaration of intent to do a lot of actual work, including writing policies -- none of which is done
17:26:28 <mattdm> jwb yes that is fair
17:26:33 * mattdm edits more titles
17:27:04 <nirik> #info sgallagh was +1 in ticket
17:27:14 <mattdm> These titles all came directly from the Cloud SIG todo list, where they were in context. They're now out of that context....
17:27:43 <pjones> right
17:27:52 * nirik is +1 we will see if we can tool up for it. ;)
17:28:23 <mitr> +1
17:28:29 <pjones> I'm not against this, but rel-eng really needs to weigh in heavily
17:28:45 <nirik> I think (as I noted on the list) we need to be clear what we will do updated images for.
17:28:53 <jwb> pjones, and QA?
17:28:54 <pjones> nirik: fair
17:28:57 <pjones> jwb: yes
17:29:04 <t8m> +1 with hope we will be able to do this as it is highly useful
17:29:28 <pjones> So I'm actually -1 until that input has happened
17:29:36 <mattdm> jwb/pjones yes, definitely want input/help from those groups. Planning to feed contributions/effort *back* to those groups as needed
17:30:09 <mattdm> and nirik, pjones -- making those policies is item #1 in the "detailed description". (In collaboration with Fedora Security)
17:30:20 <jreznik> jwb: I pinged adamw with this change
17:30:30 <adamw> ahoy
17:30:35 <nirik> sure.
17:31:01 <adamw> gah, sorry, didn't really get to taking a look atit
17:31:07 <notting> i'm not against the idea of the change. still seems a little nebulous in implementation. so i guess +1, with the caveat that it seems like a good chance of yanking later if it can't be done, or agreed upon how
17:31:21 <mattdm> right now, we're doing these things as fire drills. I'd like to get out of that.
17:31:24 <nirik> right. if it doesn't come together we can drop it.
17:31:40 <nirik> well, fire drill, singular. ;)
17:31:53 <adamw> hey, we did respin like one time before...ever...
17:31:55 <adamw> :P
17:31:59 <mattdm> nirik We've done it twice so far -- once for heartbleed, once for root password
17:32:15 <nirik> oh yeah, forgot about that one, so ok. 2 times.
17:32:29 <adamw> ok, as a handwave, i'd be ok with 'yes but...', can't speak for the rest of QA as I don't think it was run by test@, sorry :(
17:32:32 <nirik> oh, to clarify, would these be just the security updates? or all updates at the time?
17:32:38 <jwb> mattdm, there's really nothing in terms of content in the Change.
17:32:41 <jwb> nirik, right
17:32:42 <notting> almost as much fun as respinning install dvds & the install image inside them
17:33:21 * jreznik is moving to his smartphone (but with hw keyboard, don't worry!)
17:33:31 <jwb> nirik, the detailed description seems to imply "all updates"
17:33:42 <jwb> i mean... why else would you do them monthly?
17:33:44 * nirik nods.
17:33:54 <adamw> cloud validation as it stands isn't really a lot of work (there's no installer and no desktop, which helps a lot) so i don't think it'd be too impossible from a quality perspective, but we would need someone to really commit to testing each of these images as it comes out, or automate it properly.
17:33:58 <mattdm> jwb yes, the intention was for the monthly updates to include everything.
17:34:07 <mattdm> adamw *nod*
17:34:10 <pjones> yeah, and all updates is really the only sensible policy.
17:34:29 <mattdm> Right now, when we _have_ done the updates, I've lived in fear of a brown paper bag moment after
17:34:30 <nirik> so, where are we on votes... +4, -1?
17:34:48 <mattdm> uh, I am +1
17:34:49 <nirik> like the f20 respun lives? ;)
17:35:01 <adamw> the cloud quality requirements are a reasonable target for automation, but i'm not sure it could get Done in time for this change to kick in, so we'd need to cover at least the possibility of it requiring manual testing for a while.
17:35:37 * pjones wonders where dgilmore is
17:35:54 <adamw> the testing requirements should definitely be covered in the Change page somewhere.
17:36:25 <nirik> ok, so +5, -1... unless pjones wants to change?
17:36:27 <adamw> (it's kinda mentioned atm, but more as 'we need to document this' than...actually documenting it.)
17:36:56 <nirik> and notting hasn't voted I think...
17:37:03 <pjones> nirik: I'd still rather hear from rel-eng before I vote yes.  As you've already got 5, I'm willing to stay -1 on that basis, especially since it won't hold it back anyway.
17:37:15 <nirik> sure, fair enough.
17:37:23 <mattdm> I can take this back to the cloud wg and ask for the communication with qa, releng, and security to get started _now_
17:37:32 <pjones> mattdm: that would be good.
17:37:55 <nirik> #agreed change approved (+5,-1,0)
17:38:13 <mattdm> #action mattdm to take this back to the cloud wg and ask for the communication with qa, releng, and security to get started _now_
17:38:18 <nirik> #topic #1289 F21 System Wide Change: Playground repository - https://fedoraproject.org/wiki/Changes/Playground_repository·
17:38:18 <nirik> .fesco 1289·
17:38:18 <nirik> https://fedorahosted.org/fesco/ticket/1289
17:38:18 <zodbot> nirik: Error: '1289\xc2\xb7' is not a valid integer.
17:38:31 <nirik> picky picky
17:38:37 <nirik> https://fedoraproject.org/wiki/Changes/Playground_repository
17:39:52 <pjones> What's with the trailing elevated dot?
17:40:18 <nirik> thats my fault.
17:40:37 * nirik has vim show trailing spaces that way.
17:40:42 <pjones> aah
17:40:46 <notting> were people's concerns addressed in the additional week of discussion?
17:41:50 <nirik> some of mine were, it still seems a bit handwavy tho
17:42:01 <dgilmore> sorry I had an appointment this morninga nd it went late
17:42:09 * dgilmore is here now
17:43:21 <nirik> I guess I am a weak +1 on it now... and we can see how it works out.
17:43:24 <mattdm> I'm +1 to this. Although I hope it can grow into a 'real' repository in future releases.
17:43:26 <jreznik_q10> well, it was discussed several times on env and stacks meetings, it's mostly effortless way how to have something now as Beta and see how it's really being used
17:43:31 <jreznik_q10> that's the idea
17:43:33 <mitr> I can't see any outstanding questions; the plan is somewhat curious but AFAICT fairly definite
17:43:35 <mitr> +1
17:43:35 <jwb> mattdm, huh?
17:43:59 <nirik> yeah, I am curious to see how many things will actually be in it...
17:44:13 <t8m> +1 from me as well we will see how it will be used
17:44:17 <dgilmore> im not oppsed but there is a lot of implementation details not yet available
17:44:18 <nirik> I'm not sure the demand is as high as people think
17:44:21 <jreznik_q10> mattdm, yes, that's the plan - one day full repository
17:44:25 <mattdm> jwb right now, it's implemented as a DNF plugin that pulls together Coprs.
17:44:34 <jwb> mattdm, yes
17:44:44 <jwb> so what do you mean by "real"?
17:45:08 <notting> do we have any stats as to who is currently using coprs for 'stuff not able to be put in fedora due to assorted pkging rules' vs 'newer test versions of existing stuff'?
17:45:14 <jreznik_q10> it's not repository but more set of repositories, real means one standalone repository with all implications it means
17:45:23 <mattdm> as jreznik says, a "full" repository that's mirrored and everything.
17:45:44 <mattdm> but that's kind of a separate discussion and I don't want to hold up the meeting with it....
17:45:52 <jwb> mattdm, jreznik_q10: would it's repo file be shipped in fedora-release and sit alongside e.g. the updates-testing repo?
17:45:57 <nirik> notting: not that I know of, we might be able to mine some tho
17:46:01 <jwb> because... i'm pretty sure i would dislike that
17:46:15 <jwb> if you just want someone to go and run createrepo on it, fine whatever
17:46:21 <jreznik_q10> jwb, not now, it's just Dnf plugin
17:46:26 <nirik> notting: I'd guess a lot of use is 'newer version' (which this doesn't address)
17:46:32 <jwb> jreznik_q10, yes, i got that.  i'm asking about your and mattdm's desires
17:46:56 <mitr> jwb: AFAICT this is always going to be optional (and I would insist on that)
17:47:01 * pjones can be +1 here
17:47:13 <jwb> mitr, that doesn't answer my question.  updates-testing is optional too
17:47:17 <jreznik_q10> jwb, well I still prefer this lightweight version for interested folks, future is currently not yet set
17:47:32 <dgilmore> mattdm: so we will need to setup releng processes around it
17:47:39 <mitr> jwb: sorry, I missed the -testing part
17:47:59 <nirik> we are at +5
17:48:05 <mattdm> jwb, I *would* like to see it something like updates-testing. But that's really a discussion for the future. Willing to be wrong on that, and still in favor of this. :)
17:48:13 <jreznik_q10> idea is to try something really lightweight and maybe nirik is true and there's no interest
17:48:23 <notting> jreznik_q10: by 'dnf plugin', that means the plugin is configured/coded out of the box to know where the list of approved coprs is, etc? i.e., it's essentially shipping a repo definition that may or may not be considered third party
17:48:26 <nirik> dgilmore: well, there isn't any I guess... it's all really just in copr... a collection of existing coprs
17:48:46 <jwb> mattdm, ooof.  well, with that in mind it certainly gives me pause in my potential inclusion of things in it.
17:48:54 <jwb> so i'll have to think about it.
17:49:42 <jreznik_q10> notting, as far as I know, it's optional plugin now
17:50:01 <notting> jreznik_q10: that... didn't respond to my questin
17:50:04 <dgilmore> nirik: but if they want it mirrored then we need to setup some way to mirror it
17:50:05 <nirik> notting: yeah, it would know about the playground collection... right now it knows about copr...
17:50:21 <mitr> jwb: What are you concerned/thinking about?  You've mentioned some things you dislike, but not why
17:50:22 <nirik> dgilmore: no mirroring proposed in this change.
17:50:44 <dgilmore> nirik: 17:45 < mattdm> as jreznik says, a "full" repository that's mirrored and everything.
17:50:48 <dgilmore> nirik: was going on that
17:50:58 <jreznik_q10> notting, I hope definition of repos is not shipped with that plugin
17:51:00 <nirik> notting: but users have to enable... http://dnf.baseurl.org/2014/03/19/copr-plugin/
17:51:25 <nirik> dgilmore: that is not this change, but some indeterminate future that some people desire. ;)
17:51:42 <nirik> if we move to that then yes, lots more releng work.
17:51:44 <notting> jreznik_q10: then how does it know what's part of the playground repo if it's not configured to go to the playground repo?
17:52:30 * notting can't shake the idea that we keep piecemeal talking about having a playground repo, having coprs, setting some rules on third-party software, discussing the web apps thing, and yet don't actually have a plan on where we expect to end up
17:52:40 <jwb> mitr, i'm concerned about support implications of it being shipped as a mirrored and official optional repo
17:52:46 <nirik> https://github.com/akozumpl/dnf-plugins-core/blob/master/plugins/copr.py#L53
17:52:48 <jreznik_q10> it's defined on copr side, plugin just knows who to talk but I really don't have these details, msuchy gave some details in his mail
17:53:06 <nirik> ^ code of plugin
17:53:21 <mitr> jwb: I haven't seen big support implications of shipping updates-testing, so I don't expect much more with this...
17:53:37 <nirik> it warns and asks and downloads the repo file from copr.fedoraproject.org
17:53:46 <jwb> mitr, updates-testing is imminently destined for updates.  playground is almost exactly the opposite
17:53:51 <dgilmore> nirik: okay
17:54:01 <jreznik_q10> jwb, and that's why this change for beta is really minimalistic - begin with something that's achievable
17:54:01 <mattdm> jwb you mean if someone installs something from this, forgets that they did, and then files bug reports or otherwise asks for help?
17:54:01 <nirik> mitr: we did have problems with rawhide tho. ;)
17:54:03 <mitr> notting: AFAICT the big theme is "avoid overhead of too prescriptive packaging guidelines and review process"
17:54:15 <jwb> mattdm, that, and even why would we ask the mirrors to mirror a repo of stuff that is explicitly unsupported?
17:54:21 <mattdm> I know that env-and-stacks *did* talk about that to some degree
17:54:35 <mattdm> jwb mirrors mirror all kinds of stuff -- contrib trees and whatnot.
17:54:54 <smooge> mattdm, only a very very few these days.
17:55:06 <jwb> mattdm, for lack of a better analogy, the playground repo is almost equivalent to the staging stuff in the kernel.  it's crap, we know it's crap, it needs work to not be crap.
17:55:19 <jwb> why include a pointer to crap in fedora-release and ask the mirrors to ship it?
17:55:20 <nirik> do we need to discuss long term plans? (ie, does that matter to approval of this feature?)
17:55:35 <jwb> nirik, no.  i just said those desires gave me pause.  they asked me why.
17:55:37 <notting> mitr: ... which is orienting the software installation experience given to users on axes of how it affects packagers
17:55:41 <dgilmore> nirik: i think we need to know where it is headed
17:55:43 <jwb> i'm perfectly happy not talking about it
17:55:48 <mitr> notting: A really general plan for packaging, or for what Workstation will end up doing for developers, would be interesting, yes; but with Docker and Atomic and DNF at the same time I'm not sure that any one person can even see the full picture right now
17:55:49 <notting> mitr: that seems the wrong way to go
17:56:22 <mattdm> jwb to be clear, I'm happy to talk about it sometime _later_ :)
17:56:34 * jwb shrugs
17:57:08 <jwb> i had some plans.  i might not execute on those depending on what people's end-game is for playground.  we can talk about that when/whereever
17:57:36 <nirik> well, to my mind, this change would be a way to see if it's even worth doing... and if people want to make it more of a thing, I'd probibly want to discuss that after I see how popular this thing is.
17:57:37 <mitr> notting: I think this is kind of bifurcating the "mere user" case (default repos), and "ubercool software developer with entirely new in-flux ecosystems" case (now they can live within the Fedora ecosystem, by only one more command)
17:58:09 <jwb> nirik, unless the dnf plugin is tracking hits to playground, you aren't going to know it's popularity
17:58:18 <mattdm> nirik +1
17:58:30 <nirik> jwb: true. I wonder if we could ask for some stats as part of this.
17:58:39 <mitr> jwb: that could be tracked server-side (especially now that it isn't mirrored everywhere)
17:58:41 <nirik> althought we would see get anecdotes.
17:58:48 <nirik> still
17:58:59 <jwb> mitr, or that, sure
17:59:14 <nirik> right, it's one instance for frontend and 1 for backend with packages
17:59:21 * mattdm would love to see more stats for more things in general
17:59:30 <notting> mitr: one? with scls in copr, scls maybe in main, docker indicies, openshift cartridges...
17:59:47 <mitr> notting: true
18:00:06 <nirik> anyhow, I think we are at +5, so it's approved? or would anyone who hasn't voted like to vote? or anyone want to change their existing vote?
18:00:25 <notting> nirik: i can be +1 on your logic of 'try something, see how and if it sticks'
18:00:26 * nirik will suggest stats
18:01:32 <nirik> ok.
18:01:38 <nirik> dgilmore: ?
18:02:33 <nirik> #agreed: change approved (+6,0,0)
18:02:43 <nirik> #topic #1290 F21 System Wide Change: Anaconda Support for Server Roles - https://fedoraproject.org/wiki/Changes/AnacondaServerRoleSupport
18:02:43 <nirik> .fesco 1290
18:02:44 <nirik> https://fedorahosted.org/fesco/ticket/1290
18:02:45 <zodbot> nirik: #1290 (F21 System Wide Change: Anaconda Support for Server Roles - https://fedoraproject.org/wiki/Changes/AnacondaServerRoleSupport) – FESCo - https://fedorahosted.org/fesco/ticket/1290
18:02:59 <dgilmore> im not yet decided
18:03:24 <dgilmore> nirik: scls cant be done as coprs
18:04:01 <nirik> dgilmore: hum?
18:04:13 <dgilmore> nirik: I brought it up on the list
18:04:36 <nirik> ok. I'm not sure I follow, but will read up on list. ;)
18:04:57 <mitr> +1
18:05:12 <dgilmore> i am +1 to Anaconda Server Role Support
18:05:15 <nirik> +1 to this change
18:05:39 <pjones> I mean, +1 to them developing all the plugins they like...
18:05:53 <t8m> +1
18:06:32 <notting> i do like the idea of starting with kickstart, so +1.
18:06:43 <nirik> #agreed This change is approved. (+6,0,0)
18:06:59 <mattdm> (um, +1)
18:07:06 <mattdm> (sorry, cat emergency.)
18:07:06 <nirik> #undo
18:07:06 <zodbot> Removing item from minutes: AGREED by nirik at 18:06:43 : This change is approved. (+6,0,0)
18:07:07 <notting> a little nervous of the 'anaconda has plugins! everyone write plugins to change anaconda!' aspect, rather than perhaps considering whether the core can be changed
18:07:10 <nirik> #agreed This change is approved. (+7,0,0)
18:07:27 <nirik> #topic #1291 F21 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
18:07:27 <nirik> .fesco 1291
18:07:27 <nirik> https://fedorahosted.org/fesco/ticket/1291
18:07:28 <zodbot> nirik: #1291 (F21 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6) – FESCo - https://fedorahosted.org/fesco/ticket/1291
18:07:33 <mattdm> notting isn't this exactly _why_ anaconda has plugins?
18:08:03 <notting> mattdm: in the sense that it's only useful for one product? perhaps.
18:08:27 <nirik> I'm +1 to this change, but the license thing is sad. :)
18:08:30 <notting> re: bdb 6. '+ugh'
18:08:56 <mattdm> notting yeah. and for adding easily separable separate config. anyway, next thing.
18:09:03 <mitr> +1
18:09:07 <dgilmore> im with notting here
18:09:13 <mattdm> +1 to the change -- a) no real choice, b) old version is preserved
18:09:18 <dgilmore> +1
18:09:56 <notting> is there a provenpackager signed up to do the work determining whether packages can migrate, and patching those that can/can't?
18:10:01 <notting> (preferably, before mass rebuild)
18:10:54 <nirik> notting: not that I can see... the change owners are just signed up to make the compat package, update, etc...
18:11:16 <nirik> how many packages are we looking at?
18:11:19 * nirik hits repoquery
18:12:01 <nirik> the repoquery in the change page is not right. ;)
18:12:10 <mitr> Provenpackagers helping certainly doesn't hurt, still, I'd expect this is something that the individual package owners both can do, and can do fairly efficiently
18:12:13 <t8m> +1 although I am concerned about the work needed for license compatibility checking of dependencies as well
18:12:29 <nirik> 67 packages
18:12:42 <pjones> +1 with the ugh caveat
18:12:47 <nirik> http://paste.fedoraproject.org/96336/39827674
18:13:00 <t8m> mitr, yes, they can do but there is nothing to force them to do it actually
18:13:14 <nirik> so, one gotcha here...
18:13:25 <mitr> t8m: I'm not entirely sure that packages staring at v5 is a bad thing
18:13:33 <nirik> the new one with the new license will be default right? so a simple rebuild will get the new one with no other action?
18:13:56 <notting> mitr: my concern is it requires an *active* decision on the part of 60+ packages
18:14:15 <nirik> right, someone may not notice, rebuild for something else and get the new one.
18:14:34 <mitr> ah, right; v5 will be the "new" one.
18:15:12 <dgilmore> someone will have to sit down and work out what can link to the new one and make some change so that it uses it
18:15:13 <notting> nirik: if that's going to happen, -1. not really liking the idea of automatic license breaking OOTB.
18:15:32 <nirik> I'm not sure if thats the case, but it seems like.
18:17:22 <mitr> propoal: ask the owner for clarification, and suggest that we need a plan that doesn't result in license violations by ommission
18:17:31 <nirik> +1
18:17:51 <dgilmore> mitr: +1
18:18:17 <notting> mitr: +1. i.e., something like 'unmodified package continues to use old version' would be simple enough for me
18:18:29 <t8m> mitr, +1
18:18:41 <mitr> notting: yes, or a provenpackager signing up
18:18:56 <mattdm> +1 mitr
18:19:12 <nirik> ok, thats +5... who wants an action item to do that for us? ;)
18:19:41 <mitr> I can send that mail right now
18:19:42 <nirik> #agreed ask the owner for clarification, and suggest that we need a plan that doesn't result in license violations by ommission (+5,0,0)
18:20:00 <nirik> #action mitr to talk to change owners about db6
18:20:02 <nirik> thanks mitr
18:20:15 <nirik> #topic #1292 F21 System Wide Change: Cockpit Management Console - https://fedoraproject.org/wiki/Changes/CockpitManagementConsole
18:20:16 <nirik> .fesco 1292
18:20:16 <nirik> https://fedorahosted.org/fesco/ticket/1292
18:20:17 <zodbot> nirik: #1292 (F21 System Wide Change: Cockpit Management Console - https://fedoraproject.org/wiki/Changes/CockpitManagementConsole) – FESCo - https://fedorahosted.org/fesco/ticket/1292
18:20:28 <mitr> +1
18:20:47 <t8m> +1
18:20:57 <mattdm> is the system wide aspect here simply the timeline delay request?
18:21:14 <nirik> not sure.
18:21:15 <nirik> +1
18:21:33 <nirik> I'm fine with just allowing them to land later if they need to... instead of moving the entire schedule
18:21:42 <mattdm> because I'm for the feature in general, but want to be clear on whether we are voiting to bump the schedule by 2-4 weeks
18:21:49 <notting> proposal: allow this feature to land later, as opposed to shifting schedule
18:21:55 <nirik> notting: +1
18:21:56 <pjones> +1
18:22:01 <dgilmore> +1
18:22:05 <mattdm> notting +1
18:22:08 <pjones> (that was to notting)
18:22:18 <t8m> notting, +1
18:22:22 <mitr> notting: +1
18:23:01 <notting> actually, anyone disagree with rewording that as 'approve feature, but allow this feature ...'?
18:23:06 <nirik> ok, sounds like +6 to accepting the change and allowing it to land later...
18:23:38 <pjones> no, that's fine
18:23:56 <dgilmore> nirik: i think notting agrees so +7
18:23:58 <nirik> proposed #agreed change is approved, but instead of shifting schedule will allow this change to land later if needed.
18:24:15 <notting> (and please holler if they can't work with that)
18:24:23 <nirik> dgilmore: yeah.
18:24:37 <nirik> #agreed change is approved, but instead of shifting schedule will allow this change to land later if needed. (+7,0,0)
18:24:45 <nirik> #topic #1293 F21 System Wide Change: Fedora 21 Make 4.0 Update - https://fedoraproject.org/wiki/Changes/F21Make40
18:24:45 <nirik> .fesco 1293
18:24:45 <nirik> https://fedorahosted.org/fesco/ticket/1293
18:24:46 <zodbot> nirik: #1293 (F21 System Wide Change: Fedora 21 Make 4.0 Update - https://fedoraproject.org/wiki/Changes/F21Make40) – FESCo - https://fedorahosted.org/fesco/ticket/1293
18:24:56 <mitr> +1
18:25:01 <nirik> +1
18:25:21 <notting> +1
18:25:34 <t8m> +1
18:25:34 * mattdm had trouble reading that verb
18:26:02 <mattdm> If we're gonna be asking people to reword titles for clarity to less-technical journalists....
18:26:07 <mattdm> +1 in any case
18:26:08 <pjones> +1
18:26:17 <dgilmore> +1 though im not sure what Releng is to do with the new make-devel sub-package
18:26:54 <nirik> #agreed Change is approved (+7,0,0)
18:27:04 <dgilmore> its not a huge deal and will be sorted however needed
18:27:05 <nirik> dgilmore: I guess it makes make multilib?
18:27:25 <dgilmore> nirik: or does it need to be included in the minimal buildroot
18:27:39 <nirik> dunno. Could you followup on list about that?
18:27:46 <dgilmore> yeah
18:28:00 <nirik> #action dgilmore will followup about make change and make-devel subpackage needs
18:28:02 <nirik> thanks
18:28:06 <nirik> #topic #1294 F21 System Wide Change: TCL/TK 8.6 - https://fedoraproject.org/wiki/Changes/f21tcl86
18:28:06 <nirik> .fesco 1294
18:28:06 <nirik> https://fedorahosted.org/fesco/ticket/1294
18:28:07 <zodbot> nirik: #1294 (F21 System Wide Change: TCL/TK 8.6 - https://fedoraproject.org/wiki/Changes/f21tcl86) – FESCo - https://fedorahosted.org/fesco/ticket/1294
18:28:09 <mitr> dgilmore: very unlikely to be needed in minimal; "gnumake.h", what would need it?
18:28:37 <mitr> +1
18:28:41 <nirik> +1
18:28:48 <t8m> +1
18:29:02 <notting> +1
18:29:12 <mattdm> +1
18:29:16 <pjones> I'd always rather remove them but that's not what we do so +1
18:29:22 <dgilmore> +1
18:29:39 <nirik> #agreed Change is approved (+7,0,0)
18:29:46 <dgilmore> mitr: no idea, email sent asking what releng is supposed to actually do
18:29:50 <nirik> #topic #1295 F21 System Wide Change: SCL - https://fedoraproject.org/wiki/Changes/SCL
18:29:50 <nirik> .fesco 1295
18:29:50 <nirik> https://fedorahosted.org/fesco/ticket/1295
18:29:51 <zodbot> nirik: #1295 (F21 System Wide Change: SCL - https://fedoraproject.org/wiki/Changes/SCL) – FESCo - https://fedorahosted.org/fesco/ticket/1295
18:30:25 <dgilmore> as they want this shipped in the main repos we have to build in koji
18:30:38 <dgilmore> so we will need to work out the workflows
18:30:46 <mattdm> dgilmore yeah, I see that it says "3. Build SCL in koji or magically add SCL builds from Copr (depends on preference of releng) "
18:30:51 <mattdm> and I know your preference :)
18:31:05 <dgilmore> I did bring it up on the list
18:31:43 <dgilmore> but other than working out the workflows and how to build in koji. I'm okay with it
18:31:55 <dgilmore> they will need to have packaging guidelines also
18:31:58 <mattdm> I didn't get a chance to comment on the list, but I'd like to see a timeline for the playground->main plan
18:32:01 <mattdm> "'d like to add it into Playground repo. If everything goes well, I'd like to add it into main Fedora repository."
18:32:31 <dgilmore> mattdm: well they want ruby 1.93 in f21
18:32:40 <mattdm> when do we decide if everything goes well? presumably we need everything for that by alpha?
18:32:40 <nirik> we will also need to finalize the git setup
18:32:48 <dgilmore> mattdm: so i think its safe to assume it will eb skipping playground
18:33:09 <dgilmore> we will need it all in place by branching I think
18:33:45 <mattdm> proposal: ask for detailed description to be updated assuming building straight into the main repo with koji
18:33:57 <dgilmore> +1
18:34:17 <mattdm> nirik can you summarize the git setup issues in ... one or two lines of IRC?
18:35:17 <nirik> mattdm: it was brought up on list. Change owner just wants to use the existing git repos... ie 'ruby' would build both real ruby and the scl ruby. But it means a ton of junk in the package spec... counter proposal was seperate git repos for them... scl-ruby193 or whatever.
18:35:53 <nirik> https://lists.fedoraproject.org/pipermail/devel/2014-April/198242.html
18:35:54 <mattdm> the separate git repos also means building in koji is easier, right?
18:36:18 <dgilmore> mattdm: doesnt make much difference
18:36:18 <nirik> I'm not sure. I don't know how building scls in koji works (I think it does tho)
18:36:35 <pjones> eh, I like separate repos more, but I know some will disagree
18:36:36 <dgilmore> mattdm: all in one they have to do fedpkg build --target=sct-target
18:36:49 <dgilmore> seperate branches they do fedpkg build
18:36:51 <pjones> to me the spec file becomes unmaintainable once you start having so many conditionals
18:37:02 <notting> i'm not sure why i should care one way or another?
18:37:06 <dgilmore> I personally prefer seperate branches
18:37:06 <mattdm> okay. so... I guess I don't care.
18:37:26 <mattdm> I think that the decision weight should go to whoever is maintaining those spec files
18:37:28 <nirik> with seperate branches could someone bypass review?
18:37:45 <dgilmore> mattdm: well the easiest way for it to work is kinda a mix
18:38:08 <dgilmore> have separate beanches for say ruby
18:38:21 <dgilmore> but use a common branch for the ruby modules
18:38:40 <dgilmore> but that makes it ugly to get the sources
18:38:57 <dgilmore> as its not consistent how you get the sources from git
18:39:17 <nirik> proposal: defer a week, ask change owner to update based on feedback on list and discuss with releng how best to implement and what timeline might be?
18:40:13 <mattdm> +1, but maybe also note that we are generally in favor and just working out the details?
18:40:34 <nirik> sure, counter proposal? ;)
18:40:46 <t8m> nirik, +1 with mattdm's addition
18:40:47 <notting> meh. we approved 1288 with less detail on implementation
18:41:03 <mattdm> how about....
18:41:22 <nirik> well, toshio will also be back next week, and he's dug into things a lot more than I on this, so it would be nice to have his feedback
18:41:23 <mattdm> proposal: accept change, ask change owner to update details based on feedback on list and discussion with releng
18:41:29 <dgilmore> Im okay with approving it today, its going to take some work to get the details sorted. it will make its deadline or not
18:41:37 <dgilmore> mattdm: +1
18:41:38 <mitr> nirik: note thet there has been very little specific feedback on the list, there's... very little to update based on what's now there
18:41:45 <pjones> mattdm: +1
18:41:51 <nirik> alright.
18:41:53 <notting> mattdm: +1
18:42:14 <mitr> mattdm: +1
18:42:25 <mattdm> mitr Well, there's important notes from dgilmore (eg. should work in koji, so let's go straight to that)
18:42:29 <t8m> mattdm, ₊
18:42:33 <t8m> mattdm, +1
18:42:40 <nirik> #agreed Change is accepted. change owner to update details based on feedback on list and discussion with releng (+6,0,0)
18:42:55 <nirik> #topic #1296 F21 System Wide Change: Ruby193 in SCL - https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL
18:42:55 <nirik> .fesco 1296
18:42:55 <nirik> https://fedorahosted.org/fesco/ticket/1296
18:42:57 <zodbot> nirik: #1296 (F21 System Wide Change: Ruby193 in SCL - https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL) – FESCo - https://fedorahosted.org/fesco/ticket/1296
18:43:27 <dgilmore> +1 here with the same caveats as the previous change
18:43:28 <notting> as a first scl to ship? sure, +1
18:43:39 <dgilmore> they go hand in hand
18:43:44 <mattdm> +1
18:43:53 <nirik> sure, +1
18:43:55 <mitr> +1
18:43:57 <pjones> yeah, same as previous one, +1
18:44:10 <t8m> +1
18:44:15 <nirik> #agreed Change is accepted. (+7,0,0)
18:44:17 <mattdm> As I understand it, openshift won't work in f21 without this -- it's not going to be updated to the new rails in time
18:45:00 <dgilmore> mattdm: it doesnt work in f20 afaik
18:45:08 <nirik> #topic #1297 F21 System Wide Change: Workstation: Enable Software Collections - https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections
18:45:08 <nirik> .fesco 1297
18:45:08 <nirik> https://fedorahosted.org/fesco/ticket/1297
18:45:10 <zodbot> nirik: #1297 (F21 System Wide Change: Workstation: Enable Software Collections - https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections) – FESCo - https://fedorahosted.org/fesco/ticket/1297
18:46:00 <nirik> hum. did I miss number here...
18:46:09 <notting> this implies that they're separate repos?
18:46:33 <mitr> Or a "no action but comps update" if they are not
18:46:34 <mattdm> I think they might be asking to enable softwarecollections.org upstream repos?
18:47:07 <nirik> ah, ticket title is wrong.
18:47:27 <nirik> or I am just confused. nevermind.
18:47:33 <mattdm> jwb do you know the details here?
18:47:42 <nirik> They are simply installing the 'scl' tool by default
18:47:47 <dgilmore> afaik this is enabling the repos provided by softarecollections.org
18:48:00 <dgilmore> softwarecollections.org
18:48:30 <mitr> hhorak asked on the list whether this means enabling softwarecollections.org, and nobody said "no"
18:48:37 <mitr> So, actually that would seem to be the case
18:48:43 <jwb> mattdm, not aware
18:48:59 <dgilmore> and I guess a comps change so that the tooling to make it all work is installed by default
18:49:17 <mitr> That does seem to move us into a world with way too many different repo mechanisms
18:49:19 <nirik> the scl tool doesn't have anything enabled by default I don't thinnk.
18:49:19 <jwb> i was under the impression it was basically "install the tools, have the tools do whatever they do OOTB"
18:49:32 <mattdm> proposal: ask for clarification, and... particularly, whether the approved change for _in_ Fedora software collections makes this moot
18:49:45 <notting> mattdm: sure, +1
18:49:47 <mitr> mattdm: +1
18:49:50 <jwb> proposal: stop waiting until the meeting to ask for feedback...
18:49:50 <dgilmore> mattdm: +1
18:49:58 <t8m> mattdm, +1
18:50:03 <nirik> -1
18:51:03 <nirik> this is just adding scl-utils...
18:51:18 <mattdm> jwb the meeting is basically when we sit down together and go over them. it'd probably be more efficient to make sure everything was covered before, but it's basically been the way we've been functioning....
18:51:28 <notting> jwb: people did. one person said it was just adding scl-utils, another said it was enabling softwarecollections.org
18:51:33 <jwb> mattdm, yep, and it isn't working and it's frustrating.
18:51:45 <nirik> https://www.softwarecollections.org/en/docs/quick-start/
18:51:46 <jwb> notting, and nobody followed up
18:52:08 <notting> jwb: in terms of the feature owner? yep.
18:52:25 <jwb> notting, in terms of everyone
18:52:41 <mitr> jwb: AFAICT various people came into this meeting with definite, but differing, ideas of what this was; not with unresolved questions
18:53:12 <mattdm> jwb it sometimes means that there is a one week delay, and it _definitely_ makes these meetings go on. but it could be worse.
18:53:22 <jwb> ok, i'm done on this tangent.  it's not going to be productive.  if you guys want to continue to wait a week to get questions answered because you asked them in IRC, fine.
18:53:41 * nirik is +1 for the change, but if folks want to clarify we can
18:54:18 <pjones> jwb: I think you can just as clearly state that as "because the feature owner didn't show up to the meeting", which has also always been something we've asked.
18:54:31 <pjones> (also clearly not working)
18:54:42 <pjones> mattdm: +1
18:54:43 <mattdm> pjones although we haven't done a great job of making that clear or calling people in.
18:54:47 <pjones> true
18:54:54 <mattdm> anyway....
18:54:56 <nirik> ok, thats +5 on mattdm's proposal...
18:55:14 <pjones> so probably we should be doing better on both asking for feedback earlier /and/ soliciting participation during the meetings.
18:55:44 <nirik> #agreed ask for clarification, and... particularly, whether the approved change for _in_ Fedora software collections makes this moot (+5,-1,0)
18:55:47 <nirik> #topic #1298 F21 System Wide Change: The securetty file is empty by default - https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
18:55:47 <nirik> .fesco 1298
18:55:47 <nirik> https://fedorahosted.org/fesco/ticket/1298
18:55:48 <zodbot> nirik: #1298 (F21 System Wide Change: The securetty file is empty by default - https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default) – FESCo - https://fedorahosted.org/fesco/ticket/1298
18:55:49 <mitr> pjones: I don't think we've typically expected participation; it certainly helps the conversation if possible, but it's never been required and it may be rather impractical
18:56:10 <nirik> oh, who was going to ask for clarification on the last change? any takers?
18:56:23 <pjones> mitr: it's been something we've asked for, but not demanded
18:56:25 <mattdm> nirik I guess I'll do it -- my proposal
18:56:40 <nirik> mattdm: thanks.
18:56:45 <mitr> -1 on empty securetty—the original owner is supporting the counterproposal as well :)
18:56:51 <t8m> -1 for this change
18:56:52 <dgilmore> -1
18:56:55 <nirik> #action mattdm to ask for clarification on enable scls for workstation
18:56:57 <notting> mitr: i think we've expected that at least one of answering questions on-list or in meeting happens
18:57:06 <mitr> notting: the first one, definitely
18:57:13 <nirik> -1 for the change.
18:57:19 <notting> (which may have been delayed due to summit stuff)
18:57:24 <notting> -1 for the change as posted
18:57:25 <t8m> And yes, I can be persuaded to support the removal of pam_securetty from the default pam config for login
18:57:26 <pjones> -1
18:57:55 <mattdm> -1 to change
18:58:02 <nirik> #agreed change is rejected (0,-7,0)
18:58:11 <mattdm> from the ticket, my counter-proposal....
18:58:15 <nirik> +
18:58:19 <mattdm> Counter-proposal: Remove securetty from default PAM configuration and remove /etc/securetty, and note this in the release notes.
18:58:20 <nirik> +1 rather
18:58:28 <mattdm> +1
18:58:40 <t8m> mattdm, +1
18:58:58 <notting> +1
18:59:06 <pjones> +1
18:59:11 <mitr> +1?  Might just as well be happy with only a recommendation to the util-linux maintainer
18:59:30 <mitr> Please make sure that upgrades don't start silently allowing more logins, though
18:59:52 <nirik> #agreed counterproposal: Remove securetty from default PAM configuration and remove /etc/securetty, and note this in the release notes. (+6,0,0)
19:00:03 <nirik> #action mattdm to file bugs and talk to docs
19:00:12 <nirik> #topic #1299 F21 System Wide Change: Smaller Cloud Image Footprint - https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint
19:00:12 <nirik> .fesco 1299
19:00:12 <nirik> https://fedorahosted.org/fesco/ticket/1299
19:00:13 <zodbot> nirik: #1299 (F21 System Wide Change: Smaller Cloud Image Footprint - https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint) – FESCo - https://fedorahosted.org/fesco/ticket/1299
19:00:19 <t8m> mitr, they will start to
19:00:40 <t8m> mitr, I don't see how we could avoid that
19:00:58 <t8m> mitr, rpm will replace the config file unless changed by admin
19:01:22 <t8m> mitr, it must be release noted
19:01:36 <mitr> t8m: touch the file in %pre on upgrades?  I don't know.  But, oh well.
19:02:00 <mitr> Re: #1299, +1 to the general idea, -1 to introducing networkd in this fashion
19:02:05 <dgilmore> im +1 to Smaller Cloud
19:02:35 <mitr> Perhaps with the import of existing config file format
19:02:35 <mattdm> mitr Yeah, this is a grab bag of things that will be tried. networkd probably isn't ready in any case.
19:02:53 <pjones> So to make the cloud a bigger thing we need to vote yes to smaller cloud, eh?
19:02:59 <t8m> same as mitr +1 to the idea -1 to introducing networkd this way
19:03:03 <mattdm> pjones .... yes? :)
19:03:36 <mattdm> I'm +1 with the assumption that we won't go all crazy with networkd before it's ready :)
19:03:43 <randomuser> mattdm, using the fedora_requires_release_note flag on bugs will do, fwiw
19:03:59 <nirik> +1 here... I'm also worried about adding another network setup before it's ready
19:04:01 <notting> mattdm: might be worth removing that from the change page if it's not the plan anymore.in any case, +1
19:04:17 <mitr> mattdm: Well... I'd argue that Yet Another Config Format is intherently never ready.  But I can be outvoted on such things :)
19:04:41 <mitr> or, "never" is too strong
19:04:41 <nirik> so, thats +6?
19:04:57 * pjones +1
19:05:08 <nirik> #agreed Change is approved (+7,0,0)
19:05:20 <mattdm> #action mattdm to follow up on networkd with cloud wg
19:05:30 <nirik> #topic #1300 F21 System Wide Change: Use license macro in RPMs for packages in Cloud Image - https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image
19:05:30 <nirik> .fesco 1300
19:05:30 <nirik> https://fedorahosted.org/fesco/ticket/1300
19:05:31 <zodbot> nirik: #1300 (F21 System Wide Change: Use license macro in RPMs for packages in Cloud Image - https://fedoraproject.org/wiki/Changes/Use_license_macro_in_RPMs_for_packages_in_Cloud_Image) – FESCo - https://fedorahosted.org/fesco/ticket/1300
19:05:43 <mitr> +1
19:05:54 <nirik> sure, +1, perhaps it will take off. ;)
19:06:01 <pjones> why not, +1
19:06:12 <notting> +1. i don't suppose a provenpackager is bored enough to change *everything*
19:06:13 <dgilmore> +1
19:06:25 <mattdm> +1
19:06:34 <t8m> +1
19:06:34 <mattdm> notting spot definitely said he wasn't that bored :)
19:06:52 <nirik> #agreed Change is approved (+7,0,0)
19:07:20 <t8m> are the packaging guidelines already changed so at least for new packages we already get the licenses as %license ?
19:08:01 <mattdm> t8m that's in progress
19:08:19 <nirik> and a fun one for last...
19:08:22 <nirik> #topic #1301 F21 System Wide Change: Workstation: Disable firewall - https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall
19:08:23 <nirik> .fesco 1301
19:08:23 <nirik> https://fedorahosted.org/fesco/ticket/1301
19:08:24 <zodbot> nirik: #1301 (F21 System Wide Change: Workstation: Disable firewall - https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall) – FESCo - https://fedorahosted.org/fesco/ticket/1301
19:09:19 <mattdm> ooh. time for the fireworks. :)
19:09:20 <nirik> there was a ton of posts on the list on this one
19:09:25 <t8m> I'd say +1, let's make the hell freeze :)
19:09:28 <nirik> much of it noise. ;)
19:09:45 <mitr> I can actually see some merit in the proposal, but the presented rationale, and presented plans to enable functionality and "secure it later", force me to be -1
19:10:23 * mattdm notes that we have never shipped firewalld on the cloud image
19:10:31 <nirik> I've not heard much from change owners or workstation working group about all the list stuff... is there any sense that they might  want to revisit this? or ?
19:11:11 <mattdm> and disabled iptables for f20. because the cloud images are meant to be used in an environment which provides its own firewall layer, and both amazon and openstack recommend disabling per-image package filtering.
19:11:24 <notting> mattdm: cloud != workstation, though
19:11:43 <mitr> nirik: Some GNOME people have replied on the list, but not specifically the owner
19:11:47 <nirik> FYI, there were 173 posts on the devel list on this change. Might be a record. ;)
19:11:49 <mattdm> notting Yes, definitely. I just wanted to put that there for full disclosure :)
19:12:54 <mattdm> To me, this is the kind of thing that should trust the workgroups for for their own products -- unless the security team wants to pull the emergency brake
19:13:22 <pjones> honestly the language here isn't very clear (but I haven't read the thread) - he switches between "disable the firewall" and "disable firewalld"
19:13:22 <nirik> I'm a bit torn... I'd normally be -1, but I also trust the folks in the workstation group to do whats best... and rejecting this seems like second guessing them
19:14:20 <jwb> christian replied several times.  he's in the WG
19:14:21 <mitr> mattdm: So, hypothetically, if the firewall were to be removed, I'd want an automated test that is constantly verifying we haven't enabled more incoming ports unexpectedly (like we've had 2 cases resently), and perhaps even keep the firewall running but open ports >1024.
19:14:26 <nirik> so, other votes? discussion? proposals?
19:14:27 <notting> i can but help read how the change is written as 'we don't like how it works now, so we want to write a new thing, but we don't know how to do it yet, so we'll disable it in the meantime.'. and as such, i'd be -1. either fix it, or come up with something better, but removal in favor of maybe doing something later?
19:14:37 <jwb> mclasen has opened https://bugzilla.gnome.org/show_bug.cgi?id=727580 to try and fix the underlying problem
19:15:16 <dgilmore> i think i have to agree with notting -1
19:15:21 <mitr> mattdm: But with the approach of "damn security, just do the minimum that enables DAAP to work", that's seems a bit too much to ask
19:15:22 <jwb> twoerner has suggested he's willing to work towards fixing things
19:15:38 <twoerner> jwb: this has been proposed 3 years ago.. but has been rejected by the gnome team
19:15:50 <twoerner> jwb: yes I am still interested
19:15:58 <jwb> twoerner, it was rejected 3 years ago, or it was similarly rejected 3 days ago?
19:16:27 <twoerner> 3 years ago
19:16:30 <jwb> because 1) workstation isn't GNOME and 2) it seems like something that happened 3 years ago isn't set in stone.
19:16:59 <twoerner> jwb: yes, hopefully
19:17:25 <jwb> the contingency plan, to me, seems reasonable
19:17:25 * pjones is also -1 ; there needs to be a better transition plan that doesn't just leave everything open
19:17:48 <nirik> so, we are at -4, +1 I think?
19:17:49 <pjones> jwb: yeah, that actually seems like a better stop gap than this plan
19:18:03 <mitr> jwb: Actually, the contingency plan is essentially "disable the firewall by default but use a different mechanism to override it"
19:18:25 <jwb> mitr, there's no discussion on what the home zone does or doesn't do.
19:18:47 <pjones> or how "public" and "unknown" differ
19:18:54 <mitr> jwb: I'm taking it for granted that home has ~zero restrictions
19:19:04 <pjones> so those would both need to be fleshed out
19:19:17 <jwb> i'm taking it for granted that 3 zones is better than the existing set, which is really confusing and has much more overlap
19:19:36 <jwb> what those zones do can be discussed between workstation and firewalld developers
19:19:50 <nirik> I guess I'll go with -1 as well and we can ask firewalld folks and workstation folks to try and come up with a better plan?
19:19:55 <mattdm> I'll go on the record as +1 based on my comments above.
19:20:04 <mitr> jwb: That's orthogonal.  We can have $n sets but if the "contingency" is to use the zone that is least restrictive by default that's the same thing.
19:20:26 <pjones> so it's -5 +2
19:20:27 <jwb> mitr, you're making an assumption.  it may be accurate, but it's an assumption.
19:20:34 <mitr> jwb: true
19:20:50 <nirik> pjones: who was the other +1, did I miss someone?
19:20:56 <pjones> t8m
19:21:08 <pjones> (and mattdm now)
19:21:13 <nirik> ah... right.
19:21:31 <nirik> #agreed Change is rejected (-5,+2,0)
19:21:33 <mattdm> proposal: ask the proposal owners to work with firewalld developers and reframe proposal based around current contingency plan
19:21:46 <dgilmore> +1
19:21:49 <pjones> mattdm: +1
19:21:53 <notting> mattdm: +1
19:21:55 <mattdm> +1 to self
19:21:57 <nirik> +1
19:22:30 <mitr> mattdm: -1; the possibility to reframe is implied, and based on my current understanding the current contingency plan is a _bad_ starting point
19:22:47 * mattdm notes that already-in-progress firewalld rewrite in C may help with one of the other issues noted in the discussion: startup performance
19:22:49 <mitr> But they will be talking anyway :)
19:23:10 <nirik> well, that was +5,-1... unless we want to rephrase?
19:23:19 <notting> mitr: they will? the original proposal seemed to imply a lack of talking, if it got to this point
19:24:06 <twoerner> btw: there will be a meeting about "Firewall and Desktop" tomorrow
19:24:07 <mitr> notting: All I really know is that there is a phone call scheduled.  No opinion on whether it is sufficient or indicative of long-term changes.
19:24:11 <mitr> ^^^
19:24:24 <nirik> ok, then perhaps we should just leave it to that?
19:25:14 <mitr> nirik: The two accepted proposals are not in conflict, so let's move on and deal with any future proposal if any?
19:25:22 <mitr> ... future Change proposal
19:25:34 <nirik> right. ok.
19:25:49 <nirik> there's one more ticket that I didn't notice that adamw wanted us to look at today...
19:25:57 <nirik> #topic #1286 New upstream version of dracut inappropriately pushed as stable release update, introduces major regression
19:25:57 <nirik> .fesco 1286
19:25:58 <nirik> https://fedorahosted.org/fesco/ticket/1286
19:26:00 <zodbot> nirik: #1286 (New upstream version of dracut inappropriately pushed as stable release update, introduces major regression) – FESCo - https://fedorahosted.org/fesco/ticket/1286
19:26:16 <t8m> Sorry I had to be afk for a moment
19:26:57 * dgilmore needs to run and pick up daughter,
19:28:03 <nirik> Not sure what admonishing the dracut maintainer will end up doing, but I guess we can.
19:28:05 * mattdm reads
19:28:17 <mitr> so... an update to fix that one bug is in testing https://admin.fedoraproject.org/updates/dracut-037-11.git20140402.fc20
19:28:25 <t8m> I agree with adamw that such update should not be done in critical package such as dracut
19:28:31 <mattdm> it looks like the bug *did* get attention
19:28:34 <mitr> Other than that, accept adamw's proposal as stated?
19:29:04 <nirik> mattdm: sure, after it broke stuff. ;(
19:29:10 <nirik> mitr: +1
19:29:15 <pjones> I'd like to see what haraldh has to say; he's so far not commented in the ticket
19:29:16 <t8m> mitr, +1
19:29:26 <mattdm> nirik yeah. not good, just noting that part of what adam asked for did happen without our involvement
19:29:33 <pjones> but ... yeah, +1 to mitr's proposal.
19:29:39 <mattdm> I'm +1 to mitr/adamw
19:29:44 <mattdm> and pjones too
19:29:46 * mitr notes this wasn't a proposal actually
19:29:52 <jwb> mattdm, because adamw did it...
19:29:55 <adamw> so I basically fixed the bug
19:29:59 <mitr> I'm not sure how much would that "comprehensive evaluation of changes" be enforceable, or matter, or actually be different from just plain "reviewing of incompatible changes" beyond using scary language
19:30:02 <jwb> mattdm, not because the maintainer did
19:30:12 <adamw> but harald has not responded at all, so i'd really like fesco to be aware that this is going on.
19:30:20 <jwb> is he on PTO or something?
19:30:36 <jwb> he's normally fairly responsive
19:30:40 <t8m> pjones, I have to say that he had at least 7 days to do that
19:30:52 <t8m> since the time he was cced on the ticket
19:31:15 <pjones> t8m: yeah, that's why I'm +1
19:31:19 <adamw> not listed at https://apps.fedoraproject.org/calendar/list/vacation/
19:31:33 <jwb> adamw, the usage of that is... spotty.
19:31:42 * mattdm goes to put my upcoming vacation in the calendar
19:31:44 <adamw> true, but it's what we got. (or is there an RH-internal one too?)
19:31:56 <adamw> maintainers of mission-critical components should be using it, at least.
19:31:58 * pjones checks
19:32:00 <jwb> come on.  it's not "what we've got."
19:32:20 <adamw> ? how else can we check?
19:32:27 <nirik> yeah, he's not been active in irc for about the last 10days.
19:32:28 <jwb> what we've got is a bunch of people that work for the same company involved here that can answer that question by asking internally.  pretending we don't have that is silly
19:32:51 <adamw> er...hence the part which came next right on the very same line you paraphrased?
19:32:58 <pjones> Well, I'm trying to look up his internal calendar.
19:33:04 <adamw> thanks...
19:33:10 <pjones> I don't anticipate success given the results of my attempt so far.
19:33:28 <jwb> adamw, my point is that this all went down without anyone actually checking that before filing tickets and voting to admonish someone
19:33:35 <adamw> so yeah, the feedback so far indicates my 'fix' (actually reverting the upstream change which seems to be causing the problems) is covering at least the major breakage we know about so far
19:34:05 <adamw> jwb: whether he's on vacation or not seems irrelevant to the issue of whether this update violated the updates policy.
19:34:10 <mattdm> jwb but... pushing out a major change in a critpath component and then going on vacation is also not so great
19:34:24 <adamw> if I'm not supposed to report violations of the updates policy to fesco, what am I supposed to do?
19:34:29 <pjones> yeah, that's not working.
19:34:34 <jwb> adamw, mattdm: sure.  but people are saying "well the maintainer had 7 days... <blah blah>"
19:34:37 <t8m> jwb, I have to agree with adamw on this one
19:34:41 <nirik> so, thats +5?
19:34:45 * nirik recounts
19:34:59 <mitr> nirik: count me as 0 for now
19:35:06 <nirik> ok, +4 then...
19:35:07 <adamw> obviously harald should be able to state his position, i'm not calling for a summary burning at the stake. =) i just want fesco to be aware this is going on, and talk to harald about it.
19:35:16 <mattdm> +1 adamw
19:35:37 <nirik> proposal: attempt contacting maintainer and revisit next week.
19:35:45 <jwb> frankly, we should probably have a discussion on why we only have 1 person as a maintainer for something critical like this to begin with, but that's a different issue
19:35:48 <adamw> at the time of filing the ticket i also thought fesco might be able to help fix the immediate breakage, but that's no longer needed at least so far.
19:36:13 <mitr> jwb: https://admin.fedoraproject.org/pkgdb/acls/name/dracut shows 2
19:36:39 <nirik> well, dracut-maint is ? number. ;)
19:36:57 <jwb> if you're going by commits and approveacls... i don't think that's accurate.
19:36:58 <adamw> maybe we should suspend kay from fedora development? ;)
19:37:04 <mitr> jwb: But honestly our practical options in these situations are kind of limited
19:37:16 <notting> proposal's probably worded a bit more strongly than i would have, but +1 on the "that's not ok, plz fix ASAP, and determine what might else be broken" idea
19:37:41 <mitr> notting: I could go with that wording :) +1
19:37:44 <jwb> mitr, i'll disagree politely.  anyway, not a problem to solve here
19:38:06 * dgilmore is reading back
19:38:28 <mattdm> and "seriously, try not to do again"
19:38:45 <adamw> jwb: btw, now I come to think of it, there may be some dupes of the bug filed against kernel, might be worth looking out for when doing triage...
19:38:59 <jwb> adamw, well aware of those.  duped several myself
19:39:03 <adamw> ah, thanks.
19:39:14 * mitr still dimly remembers the age when "Fedora is the OS that fixes bugs by rebasing, not by backporting" was the received truth...
19:39:17 <nirik> ok, so thats +6 to... what... does someone want to reword? or want me to?
19:39:26 <jwb> which is to say, i'm guilty of not tracking down someone to fix it as well.  i feel shame for that.
19:41:02 <pjones> mitr: *and it was so so bad*
19:41:07 <notting> nirik: you don't need to reword it on my behalf
19:41:11 <adamw> mitr: given dracut's development practices, sensitivity, and certain previous incidents...rebasing dracut to fix bugs doesn't seem like it's ever going to work out well.
19:41:47 <nirik> ok.
19:41:50 <mitr> adamw: Oh certainly.  Also in some ideal hypothetical case, upstream regressions would be so extremely rare that Fedora's update policy wouldn't matter
19:42:02 <adamw> (some of the apparent, ahem, frustration evident in the ticket is due to the fact that this is not an isolated incident; we've had major problems with dracut before.)
19:42:43 <nirik> #agreed Fesco agrees this is not ok, needs to be fixed, needs determining what else might be broken, and should not be allowed to happen moving forward. (+6,0,0)
19:42:48 <nirik> (hope thats ok with everyone)
19:42:50 <adamw> thanks.
19:42:59 <nirik> #topic Next week's chair
19:43:04 <nirik> who wants it?
19:43:15 <dgilmore> nirik: im +1
19:43:19 <dgilmore> to above
19:43:34 <nirik> dgilmore: ok, will note in ticket.
19:43:41 * dgilmore can do next week
19:43:42 <t8m> I will not be able to attend next week
19:44:03 <nirik> thanks dgilmore
19:44:11 <nirik> #info dgilmore to chair next week
19:44:18 <nirik> #topic Open Floor
19:44:23 <nirik> any items for open floor?
19:44:51 <mattdm> I guess I want to amplify jwb's admonishment that we would be more productive here if we made sure more questions were answered *before* the meeting
19:45:12 <mattdm> Possibly would help us have shorter meetings too
19:45:21 <pjones> and we should *also* more strongly request stakeholders to show up for the discussion
19:45:41 <notting> so, people should request beforehand items be removed from agenda if questions unanswered?
19:46:11 <mattdm> pjones and if they can't (timezones, other commitments), at least get an rsvp along those lines
19:46:12 <t8m> Sometimes only rejecting changes at the meeting makes the change owners to respond to questions... but of course we should be asking questions earlier than at the meeting.
19:46:18 <pjones> mattdm: yeah
19:46:43 <mattdm> notting if we remove items from the agenda, that just seems like it's asking for a pile of unaddressed items
19:47:33 <nirik> perhaps do agenda eariler so we can ask questions about items in it ?
19:47:52 <nirik> dunno.
19:47:57 <jwb> perhaps not wait for the agenda and review the Changes as they are announced.
19:47:59 <mitr> nirik: For Changes, we already _know_ the agenda in advance.
19:48:19 <mitr> Dropping them from the agenda to indicate that the questions haven't been answered is an idea.
19:48:27 <jwb> they're announced and sit on the devel list for at a minimum of a week before they have that 'meeting' keyword added.
19:48:29 <mitr> Or perhaps, just in the Change threads, mark questions as "blocking my vote"?
19:48:43 <jwb> mitr, sure
19:49:12 <mattdm> When we had the PRDs due on a monday before the wednesday meeting, that worked pretty well, I think.
19:49:29 <mitr> I don't know... I'd kind of assume that to be the default... and it still doesn't address "i have received an answer but I don't like it so I'll propose sending it back for changes"
19:49:34 <mattdm> I've kind of gotten into the habit of thinking of wednesday as "fesco ticket review time"
19:49:48 <jwb> mattdm, uh... the Changes are announced a _week_ before they're even added to the agenda
19:49:51 <mattdm> which I freely admit is the root of the problem.
19:49:57 <jwb> mattdm, exactly
19:50:09 <jwb> waiting for the agenda means you're wasting everyone's time.
19:50:16 <mattdm> I know, and I try and read them and comment on them, but I assume that the meeting is when we all get together to talk about them.
19:50:26 <pjones> mattdm: likewise.
19:51:12 <mattdm> If I/we shift that assumption to "these will be discussed and commented on _before_ wednesday", that _should_ help
19:51:19 <nirik> yeah, we can all try and do better... :(
19:51:42 <mattdm> but sometimes it's hard to beat the back-and-forth of conversational meeting
19:52:13 <nirik> ok, anything else? or shall we close out?
19:52:37 <mattdm> I guess that's all, unless we want to make more formalized demands of ourselves
19:53:26 * nirik would like to demand of himself lunch. ;)
19:53:55 <nirik> ok, thanks for coming everyone.
19:53:58 <nirik> #endmeeting