17:00:08 #startmeeting FESCO (2014-04-23) 17:00:08 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:08 #meetingname fesco 17:00:08 The meeting name has been set to 'fesco' 17:00:08 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 17:00:08 #topic init process 17:00:09 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 17:00:19 * notting is here 17:00:20 who all is around for an exciting fesco meeting? 17:00:21 hello 17:00:42 Hello 17:00:55 * jreznik is around for fesco but only for limited time today, so hello! 17:01:26 hi! 17:01:26 we need 1 more for quorum I think. 17:01:40 sorry, my other previous just finished, and I'm going to be AFK for 2-3 minutes now. 17:02:29 hi 17:02:32 no worries. 17:03:58 I see nothing happened in my absence 17:04:08 it all happened so fast. ;) 17:04:17 #topic #1221 → Product working group activity reports 17:04:17 .fesco 1221 17:04:17 https://fedorahosted.org/fesco/ticket/1221 17:04:20 nirik: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 17:04:41 anything anyone would like to discuss or highlight from working groups this week? 17:05:24 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 I have only one thing for working groups - deliverables email I sent todya 17:05:36 https://fedorahosted.org/rel-eng/ticket/5891 17:05:38 yeah. 17:05:47 nirik: you were faster, thanks :) 17:05:51 #info working groups should note on the releng ticket changes they need/desire. 17:06:25 and how theirs deliverables would look like aka lives, install iso, images etc. 17:06:26 anything else on working groups ? or shall we move on. We have a full changes slate. ;( 17:06:40 sorry, irc client was glitched on this channel. 17:06:42 * mattdm is here now. 17:07:18 mattdm: anything to discuss or note from working groups this week? or shall we move on... 17:07:24 (aside from whats in the ticket) 17:07:30 nirik nothing other than what's in the ticket. 17:07:36 cool 17:07:59 #topic #1250 → F21 Self Contained Changes 17:07:59 .fesco 1250 17:07:59 https://fedorahosted.org/fesco/ticket/1250 17:08:00 nirik: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250 17:08:05 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 jreznik: thanks. 17:08:37 https://fedorahosted.org/fesco/ticket/1250#comment:18 17:08:41 has the list for this week 17:09:05 #info sgallagh was -1 for the remote journal change and +1 for all the rest 17:09:31 I agree with sgallagh that the remote journal change should be promoted to Systemwide 17:09:35 I'm fine with all of them 17:09:57 The remote journal change is not actually saying that this is the recommended way to do it or the like 17:10:30 mitr, well it can be perceived so because we would be advertising it in relnotes 17:10:30 mitr: true, but saying it's a 'change' means more people will try and use it 17:10:32 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 I wish we'd rename "Adopt Your Cattle" to something descriptive. 17:11:01 "fedora server in the cloud" ? 17:11:12 t8m, nirik: true. We can clarify, e.g. saying that Server has chosen to keep recommending rsyslog perhaps? 17:11:21 pjones, nirik: that's fine with me, although I would enjoy keeping the fun name in there somewhere as well 17:11:30 (does it really matter?) 17:11:43 t8m, nirik: though that would be a different conversation to have I think 17:11:47 mattdm, for documentation purposes, yes 17:11:53 (does it matter that it's hard to look at it and tell what it's about? Are you serious?) 17:12:10 the current name is cute and fun if you know wtf it's talking about. otherwise it's really confusing 17:12:17 pjones, +1 17:12:24 maybe it's a feature about Cowsay! 17:12:33 I mean, does the name used in the change directly translate to the words used in user-facin documentation? 17:12:34 jwb: I was really hoping it was :) 17:12:34 all hail cowsay! 17:12:45 * mattdm would love a new feature about cowsay. that thing isn't unicode compliant 17:12:57 mattdm, says the guy that repeatedly argued with me about PRDs and media impacts... 17:13:09 mattdm, so yeah, the name of the change should be descriptive 17:13:16 because people look at the change list 17:13:23 not the change pages, just the list 17:13:29 Okay, I'm swayed -- I can rename it 17:13:41 and then they write "here are the features in the upcoming fedora release" 17:13:46 *splat* 17:14:07 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 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 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 nirik: is your concern the usage of http, or something else? 17:16:50 http and ssl certs and two ssl libraries. ;( 17:17:07 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 advertised and/or perceived 17:18:42 ... well, if it's the only implemented way, it's preferred by default 17:18:59 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 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 nirik: +1, if you take the action to raise specific concerns :) 17:21:03 nirik, +1 17:21:06 nirik: +1 17:21:08 nirik: +1 17:21:22 (Reading the mailing list thread I didn't see much indication this was going to be proposed to be deferred :/) 17:21:35 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 notting: for the record, rsyslog can AFAIK transport journal in full, modulo record length limits 17:22:26 #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 nirik: +1 17:22:38 I'll try and raise those concerns, please do raise any I miss 17:22:46 #undo 17:22:46 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 #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 #topic #1287→ approve directory /opt/fedora 17:23:08 .fesco 1287 17:23:08 https://fedorahosted.org/fesco/ticket/1287 17:23:09 nirik: #1287 (approve directory /opt/fedora) – FESCo - https://fedorahosted.org/fesco/ticket/1287 17:24:00 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 +1 17:24:19 +1 17:24:23 +1 17:24:26 +1 17:24:27 It's kind of curious that it isn't through the FPC, but whatever, +1 17:24:27 nirik: yeah, looks that way 17:24:49 #agreed This is approved (+6,0,0) 17:25:24 #topic #1288 F21 System Wide Change: Changes/(A)Periodic Updates to 17:25:24 Images - https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images· 17:25:25 .fesco 1288· 17:25:25 https://fedorahosted.org/fesco/ticket/1288 17:25:26 nirik: Error: '1288\xc2\xb7' is not a valid integer. 17:25:36 nice. ;) 17:26:16 i think someone asked the title be changed to reflect it was for cloud images 17:26:19 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 jwb yes that is fair 17:26:33 * mattdm edits more titles 17:27:04 #info sgallagh was +1 in ticket 17:27:14 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 right 17:27:52 * nirik is +1 we will see if we can tool up for it. ;) 17:28:23 +1 17:28:29 I'm not against this, but rel-eng really needs to weigh in heavily 17:28:45 I think (as I noted on the list) we need to be clear what we will do updated images for. 17:28:53 pjones, and QA? 17:28:54 nirik: fair 17:28:57 jwb: yes 17:29:04 +1 with hope we will be able to do this as it is highly useful 17:29:28 So I'm actually -1 until that input has happened 17:29:36 jwb/pjones yes, definitely want input/help from those groups. Planning to feed contributions/effort *back* to those groups as needed 17:30:09 and nirik, pjones -- making those policies is item #1 in the "detailed description". (In collaboration with Fedora Security) 17:30:20 jwb: I pinged adamw with this change 17:30:30 ahoy 17:30:35 sure. 17:31:01 gah, sorry, didn't really get to taking a look atit 17:31:07 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 right now, we're doing these things as fire drills. I'd like to get out of that. 17:31:24 right. if it doesn't come together we can drop it. 17:31:40 well, fire drill, singular. ;) 17:31:53 hey, we did respin like one time before...ever... 17:31:55 :P 17:31:59 nirik We've done it twice so far -- once for heartbleed, once for root password 17:32:15 oh yeah, forgot about that one, so ok. 2 times. 17:32:29 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 oh, to clarify, would these be just the security updates? or all updates at the time? 17:32:38 mattdm, there's really nothing in terms of content in the Change. 17:32:41 nirik, right 17:32:42 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 nirik, the detailed description seems to imply "all updates" 17:33:42 i mean... why else would you do them monthly? 17:33:44 * nirik nods. 17:33:54 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 jwb yes, the intention was for the monthly updates to include everything. 17:34:07 adamw *nod* 17:34:10 yeah, and all updates is really the only sensible policy. 17:34:29 Right now, when we _have_ done the updates, I've lived in fear of a brown paper bag moment after 17:34:30 so, where are we on votes... +4, -1? 17:34:48 uh, I am +1 17:34:49 like the f20 respun lives? ;) 17:35:01 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 the testing requirements should definitely be covered in the Change page somewhere. 17:36:25 ok, so +5, -1... unless pjones wants to change? 17:36:27 (it's kinda mentioned atm, but more as 'we need to document this' than...actually documenting it.) 17:36:56 and notting hasn't voted I think... 17:37:03 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 sure, fair enough. 17:37:23 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 mattdm: that would be good. 17:37:55 #agreed change approved (+5,-1,0) 17:38:13 #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 #topic #1289 F21 System Wide Change: Playground repository - https://fedoraproject.org/wiki/Changes/Playground_repository· 17:38:18 .fesco 1289· 17:38:18 https://fedorahosted.org/fesco/ticket/1289 17:38:18 nirik: Error: '1289\xc2\xb7' is not a valid integer. 17:38:31 picky picky 17:38:37 https://fedoraproject.org/wiki/Changes/Playground_repository 17:39:52 What's with the trailing elevated dot? 17:40:18 thats my fault. 17:40:37 * nirik has vim show trailing spaces that way. 17:40:42 aah 17:40:46 were people's concerns addressed in the additional week of discussion? 17:41:50 some of mine were, it still seems a bit handwavy tho 17:42:01 sorry I had an appointment this morninga nd it went late 17:42:09 * dgilmore is here now 17:43:21 I guess I am a weak +1 on it now... and we can see how it works out. 17:43:24 I'm +1 to this. Although I hope it can grow into a 'real' repository in future releases. 17:43:26 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 that's the idea 17:43:33 I can't see any outstanding questions; the plan is somewhat curious but AFAICT fairly definite 17:43:35 +1 17:43:35 mattdm, huh? 17:43:59 yeah, I am curious to see how many things will actually be in it... 17:44:13 +1 from me as well we will see how it will be used 17:44:17 im not oppsed but there is a lot of implementation details not yet available 17:44:18 I'm not sure the demand is as high as people think 17:44:21 mattdm, yes, that's the plan - one day full repository 17:44:25 jwb right now, it's implemented as a DNF plugin that pulls together Coprs. 17:44:34 mattdm, yes 17:44:44 so what do you mean by "real"? 17:45:08 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 it's not repository but more set of repositories, real means one standalone repository with all implications it means 17:45:23 as jreznik says, a "full" repository that's mirrored and everything. 17:45:44 but that's kind of a separate discussion and I don't want to hold up the meeting with it.... 17:45:52 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 notting: not that I know of, we might be able to mine some tho 17:46:01 because... i'm pretty sure i would dislike that 17:46:15 if you just want someone to go and run createrepo on it, fine whatever 17:46:21 jwb, not now, it's just Dnf plugin 17:46:26 notting: I'd guess a lot of use is 'newer version' (which this doesn't address) 17:46:32 jreznik_q10, yes, i got that. i'm asking about your and mattdm's desires 17:46:56 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 mitr, that doesn't answer my question. updates-testing is optional too 17:47:17 jwb, well I still prefer this lightweight version for interested folks, future is currently not yet set 17:47:32 mattdm: so we will need to setup releng processes around it 17:47:39 jwb: sorry, I missed the -testing part 17:47:59 we are at +5 17:48:05 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 idea is to try something really lightweight and maybe nirik is true and there's no interest 17:48:23 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 dgilmore: well, there isn't any I guess... it's all really just in copr... a collection of existing coprs 17:48:46 mattdm, ooof. well, with that in mind it certainly gives me pause in my potential inclusion of things in it. 17:48:54 so i'll have to think about it. 17:49:42 notting, as far as I know, it's optional plugin now 17:50:01 jreznik_q10: that... didn't respond to my questin 17:50:04 nirik: but if they want it mirrored then we need to setup some way to mirror it 17:50:05 notting: yeah, it would know about the playground collection... right now it knows about copr... 17:50:21 jwb: What are you concerned/thinking about? You've mentioned some things you dislike, but not why 17:50:22 dgilmore: no mirroring proposed in this change. 17:50:44 nirik: 17:45 < mattdm> as jreznik says, a "full" repository that's mirrored and everything. 17:50:48 nirik: was going on that 17:50:58 notting, I hope definition of repos is not shipped with that plugin 17:51:00 notting: but users have to enable... http://dnf.baseurl.org/2014/03/19/copr-plugin/ 17:51:25 dgilmore: that is not this change, but some indeterminate future that some people desire. ;) 17:51:42 if we move to that then yes, lots more releng work. 17:51:44 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 mitr, i'm concerned about support implications of it being shipped as a mirrored and official optional repo 17:52:46 https://github.com/akozumpl/dnf-plugins-core/blob/master/plugins/copr.py#L53 17:52:48 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 ^ code of plugin 17:53:21 jwb: I haven't seen big support implications of shipping updates-testing, so I don't expect much more with this... 17:53:37 it warns and asks and downloads the repo file from copr.fedoraproject.org 17:53:46 mitr, updates-testing is imminently destined for updates. playground is almost exactly the opposite 17:53:51 nirik: okay 17:54:01 jwb, and that's why this change for beta is really minimalistic - begin with something that's achievable 17:54:01 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 mitr: we did have problems with rawhide tho. ;) 17:54:03 notting: AFAICT the big theme is "avoid overhead of too prescriptive packaging guidelines and review process" 17:54:15 mattdm, that, and even why would we ask the mirrors to mirror a repo of stuff that is explicitly unsupported? 17:54:21 I know that env-and-stacks *did* talk about that to some degree 17:54:35 jwb mirrors mirror all kinds of stuff -- contrib trees and whatnot. 17:54:54 mattdm, only a very very few these days. 17:55:06 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 why include a pointer to crap in fedora-release and ask the mirrors to ship it? 17:55:20 do we need to discuss long term plans? (ie, does that matter to approval of this feature?) 17:55:35 nirik, no. i just said those desires gave me pause. they asked me why. 17:55:37 mitr: ... which is orienting the software installation experience given to users on axes of how it affects packagers 17:55:41 nirik: i think we need to know where it is headed 17:55:43 i'm perfectly happy not talking about it 17:55:48 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 mitr: that seems the wrong way to go 17:56:22 jwb to be clear, I'm happy to talk about it sometime _later_ :) 17:56:34 * jwb shrugs 17:57:08 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 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 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 nirik, unless the dnf plugin is tracking hits to playground, you aren't going to know it's popularity 17:58:18 nirik +1 17:58:30 jwb: true. I wonder if we could ask for some stats as part of this. 17:58:39 jwb: that could be tracked server-side (especially now that it isn't mirrored everywhere) 17:58:41 althought we would see get anecdotes. 17:58:48 still 17:58:59 mitr, or that, sure 17:59:14 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 mitr: one? with scls in copr, scls maybe in main, docker indicies, openshift cartridges... 17:59:47 notting: true 18:00:06 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 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 ok. 18:01:38 dgilmore: ? 18:02:33 #agreed: change approved (+6,0,0) 18:02:43 #topic #1290 F21 System Wide Change: Anaconda Support for Server Roles - https://fedoraproject.org/wiki/Changes/AnacondaServerRoleSupport 18:02:43 .fesco 1290 18:02:44 https://fedorahosted.org/fesco/ticket/1290 18:02:45 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 im not yet decided 18:03:24 nirik: scls cant be done as coprs 18:04:01 dgilmore: hum? 18:04:13 nirik: I brought it up on the list 18:04:36 ok. I'm not sure I follow, but will read up on list. ;) 18:04:57 +1 18:05:12 i am +1 to Anaconda Server Role Support 18:05:15 +1 to this change 18:05:39 I mean, +1 to them developing all the plugins they like... 18:05:53 +1 18:06:32 i do like the idea of starting with kickstart, so +1. 18:06:43 #agreed This change is approved. (+6,0,0) 18:06:59 (um, +1) 18:07:06 (sorry, cat emergency.) 18:07:06 #undo 18:07:06 Removing item from minutes: AGREED by nirik at 18:06:43 : This change is approved. (+6,0,0) 18:07:07 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 #agreed This change is approved. (+7,0,0) 18:07:27 #topic #1291 F21 System Wide Change: BerkeleyDB 6 - https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 18:07:27 .fesco 1291 18:07:27 https://fedorahosted.org/fesco/ticket/1291 18:07:28 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 notting isn't this exactly _why_ anaconda has plugins? 18:08:03 mattdm: in the sense that it's only useful for one product? perhaps. 18:08:27 I'm +1 to this change, but the license thing is sad. :) 18:08:30 re: bdb 6. '+ugh' 18:08:56 notting yeah. and for adding easily separable separate config. anyway, next thing. 18:09:03 +1 18:09:07 im with notting here 18:09:13 +1 to the change -- a) no real choice, b) old version is preserved 18:09:18 +1 18:09:56 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 (preferably, before mass rebuild) 18:10:54 notting: not that I can see... the change owners are just signed up to make the compat package, update, etc... 18:11:16 how many packages are we looking at? 18:11:19 * nirik hits repoquery 18:12:01 the repoquery in the change page is not right. ;) 18:12:10 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 +1 although I am concerned about the work needed for license compatibility checking of dependencies as well 18:12:29 67 packages 18:12:42 +1 with the ugh caveat 18:12:47 http://paste.fedoraproject.org/96336/39827674 18:13:00 mitr, yes, they can do but there is nothing to force them to do it actually 18:13:14 so, one gotcha here... 18:13:25 t8m: I'm not entirely sure that packages staring at v5 is a bad thing 18:13:33 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 mitr: my concern is it requires an *active* decision on the part of 60+ packages 18:14:15 right, someone may not notice, rebuild for something else and get the new one. 18:14:34 ah, right; v5 will be the "new" one. 18:15:12 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 nirik: if that's going to happen, -1. not really liking the idea of automatic license breaking OOTB. 18:15:32 I'm not sure if thats the case, but it seems like. 18:17:22 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 +1 18:17:51 mitr: +1 18:18:17 mitr: +1. i.e., something like 'unmodified package continues to use old version' would be simple enough for me 18:18:29 mitr, +1 18:18:41 notting: yes, or a provenpackager signing up 18:18:56 +1 mitr 18:19:12 ok, thats +5... who wants an action item to do that for us? ;) 18:19:41 I can send that mail right now 18:19:42 #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 #action mitr to talk to change owners about db6 18:20:02 thanks mitr 18:20:15 #topic #1292 F21 System Wide Change: Cockpit Management Console - https://fedoraproject.org/wiki/Changes/CockpitManagementConsole 18:20:16 .fesco 1292 18:20:16 https://fedorahosted.org/fesco/ticket/1292 18:20:17 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 +1 18:20:47 +1 18:20:57 is the system wide aspect here simply the timeline delay request? 18:21:14 not sure. 18:21:15 +1 18:21:33 I'm fine with just allowing them to land later if they need to... instead of moving the entire schedule 18:21:42 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 proposal: allow this feature to land later, as opposed to shifting schedule 18:21:55 notting: +1 18:21:56 +1 18:22:01 +1 18:22:05 notting +1 18:22:08 (that was to notting) 18:22:18 notting, +1 18:22:22 notting: +1 18:23:01 actually, anyone disagree with rewording that as 'approve feature, but allow this feature ...'? 18:23:06 ok, sounds like +6 to accepting the change and allowing it to land later... 18:23:38 no, that's fine 18:23:56 nirik: i think notting agrees so +7 18:23:58 proposed #agreed change is approved, but instead of shifting schedule will allow this change to land later if needed. 18:24:15 (and please holler if they can't work with that) 18:24:23 dgilmore: yeah. 18:24:37 #agreed change is approved, but instead of shifting schedule will allow this change to land later if needed. (+7,0,0) 18:24:45 #topic #1293 F21 System Wide Change: Fedora 21 Make 4.0 Update - https://fedoraproject.org/wiki/Changes/F21Make40 18:24:45 .fesco 1293 18:24:45 https://fedorahosted.org/fesco/ticket/1293 18:24:46 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 +1 18:25:01 +1 18:25:21 +1 18:25:34 +1 18:25:34 * mattdm had trouble reading that verb 18:26:02 If we're gonna be asking people to reword titles for clarity to less-technical journalists.... 18:26:07 +1 in any case 18:26:08 +1 18:26:17 +1 though im not sure what Releng is to do with the new make-devel sub-package 18:26:54 #agreed Change is approved (+7,0,0) 18:27:04 its not a huge deal and will be sorted however needed 18:27:05 dgilmore: I guess it makes make multilib? 18:27:25 nirik: or does it need to be included in the minimal buildroot 18:27:39 dunno. Could you followup on list about that? 18:27:46 yeah 18:28:00 #action dgilmore will followup about make change and make-devel subpackage needs 18:28:02 thanks 18:28:06 #topic #1294 F21 System Wide Change: TCL/TK 8.6 - https://fedoraproject.org/wiki/Changes/f21tcl86 18:28:06 .fesco 1294 18:28:06 https://fedorahosted.org/fesco/ticket/1294 18:28:07 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 dgilmore: very unlikely to be needed in minimal; "gnumake.h", what would need it? 18:28:37 +1 18:28:41 +1 18:28:48 +1 18:29:02 +1 18:29:12 +1 18:29:16 I'd always rather remove them but that's not what we do so +1 18:29:22 +1 18:29:39 #agreed Change is approved (+7,0,0) 18:29:46 mitr: no idea, email sent asking what releng is supposed to actually do 18:29:50 #topic #1295 F21 System Wide Change: SCL - https://fedoraproject.org/wiki/Changes/SCL 18:29:50 .fesco 1295 18:29:50 https://fedorahosted.org/fesco/ticket/1295 18:29:51 nirik: #1295 (F21 System Wide Change: SCL - https://fedoraproject.org/wiki/Changes/SCL) – FESCo - https://fedorahosted.org/fesco/ticket/1295 18:30:25 as they want this shipped in the main repos we have to build in koji 18:30:38 so we will need to work out the workflows 18:30:46 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 and I know your preference :) 18:31:05 I did bring it up on the list 18:31:43 but other than working out the workflows and how to build in koji. I'm okay with it 18:31:55 they will need to have packaging guidelines also 18:31:58 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 "'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 mattdm: well they want ruby 1.93 in f21 18:32:40 when do we decide if everything goes well? presumably we need everything for that by alpha? 18:32:40 we will also need to finalize the git setup 18:32:48 mattdm: so i think its safe to assume it will eb skipping playground 18:33:09 we will need it all in place by branching I think 18:33:45 proposal: ask for detailed description to be updated assuming building straight into the main repo with koji 18:33:57 +1 18:34:17 nirik can you summarize the git setup issues in ... one or two lines of IRC? 18:35:17 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 https://lists.fedoraproject.org/pipermail/devel/2014-April/198242.html 18:35:54 the separate git repos also means building in koji is easier, right? 18:36:18 mattdm: doesnt make much difference 18:36:18 I'm not sure. I don't know how building scls in koji works (I think it does tho) 18:36:35 eh, I like separate repos more, but I know some will disagree 18:36:36 mattdm: all in one they have to do fedpkg build --target=sct-target 18:36:49 seperate branches they do fedpkg build 18:36:51 to me the spec file becomes unmaintainable once you start having so many conditionals 18:37:02 i'm not sure why i should care one way or another? 18:37:06 I personally prefer seperate branches 18:37:06 okay. so... I guess I don't care. 18:37:26 I think that the decision weight should go to whoever is maintaining those spec files 18:37:28 with seperate branches could someone bypass review? 18:37:45 mattdm: well the easiest way for it to work is kinda a mix 18:38:08 have separate beanches for say ruby 18:38:21 but use a common branch for the ruby modules 18:38:40 but that makes it ugly to get the sources 18:38:57 as its not consistent how you get the sources from git 18:39:17 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 +1, but maybe also note that we are generally in favor and just working out the details? 18:40:34 sure, counter proposal? ;) 18:40:46 nirik, +1 with mattdm's addition 18:40:47 meh. we approved 1288 with less detail on implementation 18:41:03 how about.... 18:41:22 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 proposal: accept change, ask change owner to update details based on feedback on list and discussion with releng 18:41:29 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 mattdm: +1 18:41:38 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 mattdm: +1 18:41:51 alright. 18:41:53 mattdm: +1 18:42:14 mattdm: +1 18:42:25 mitr Well, there's important notes from dgilmore (eg. should work in koji, so let's go straight to that) 18:42:29 mattdm, ₊ 18:42:33 mattdm, +1 18:42:40 #agreed Change is accepted. change owner to update details based on feedback on list and discussion with releng (+6,0,0) 18:42:55 #topic #1296 F21 System Wide Change: Ruby193 in SCL - https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL 18:42:55 .fesco 1296 18:42:55 https://fedorahosted.org/fesco/ticket/1296 18:42:57 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 +1 here with the same caveats as the previous change 18:43:28 as a first scl to ship? sure, +1 18:43:39 they go hand in hand 18:43:44 +1 18:43:53 sure, +1 18:43:55 +1 18:43:57 yeah, same as previous one, +1 18:44:10 +1 18:44:15 #agreed Change is accepted. (+7,0,0) 18:44:17 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 mattdm: it doesnt work in f20 afaik 18:45:08 #topic #1297 F21 System Wide Change: Workstation: Enable Software Collections - https://fedoraproject.org/wiki/Changes/Workstation_Enable_Software_Collections 18:45:08 .fesco 1297 18:45:08 https://fedorahosted.org/fesco/ticket/1297 18:45:10 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 hum. did I miss number here... 18:46:09 this implies that they're separate repos? 18:46:33 Or a "no action but comps update" if they are not 18:46:34 I think they might be asking to enable softwarecollections.org upstream repos? 18:47:07 ah, ticket title is wrong. 18:47:27 or I am just confused. nevermind. 18:47:33 jwb do you know the details here? 18:47:42 They are simply installing the 'scl' tool by default 18:47:47 afaik this is enabling the repos provided by softarecollections.org 18:48:00 softwarecollections.org 18:48:30 hhorak asked on the list whether this means enabling softwarecollections.org, and nobody said "no" 18:48:37 So, actually that would seem to be the case 18:48:43 mattdm, not aware 18:48:59 and I guess a comps change so that the tooling to make it all work is installed by default 18:49:17 That does seem to move us into a world with way too many different repo mechanisms 18:49:19 the scl tool doesn't have anything enabled by default I don't thinnk. 18:49:19 i was under the impression it was basically "install the tools, have the tools do whatever they do OOTB" 18:49:32 proposal: ask for clarification, and... particularly, whether the approved change for _in_ Fedora software collections makes this moot 18:49:45 mattdm: sure, +1 18:49:47 mattdm: +1 18:49:50 proposal: stop waiting until the meeting to ask for feedback... 18:49:50 mattdm: +1 18:49:58 mattdm, +1 18:50:03 -1 18:51:03 this is just adding scl-utils... 18:51:18 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 jwb: people did. one person said it was just adding scl-utils, another said it was enabling softwarecollections.org 18:51:33 mattdm, yep, and it isn't working and it's frustrating. 18:51:45 https://www.softwarecollections.org/en/docs/quick-start/ 18:51:46 notting, and nobody followed up 18:52:08 jwb: in terms of the feature owner? yep. 18:52:25 notting, in terms of everyone 18:52:41 jwb: AFAICT various people came into this meeting with definite, but differing, ideas of what this was; not with unresolved questions 18:53:12 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 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 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 (also clearly not working) 18:54:42 mattdm: +1 18:54:43 pjones although we haven't done a great job of making that clear or calling people in. 18:54:47 true 18:54:54 anyway.... 18:54:56 ok, thats +5 on mattdm's proposal... 18:55:14 so probably we should be doing better on both asking for feedback earlier /and/ soliciting participation during the meetings. 18:55:44 #agreed ask for clarification, and... particularly, whether the approved change for _in_ Fedora software collections makes this moot (+5,-1,0) 18:55:47 #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 .fesco 1298 18:55:47 https://fedorahosted.org/fesco/ticket/1298 18:55:48 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 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 oh, who was going to ask for clarification on the last change? any takers? 18:56:23 mitr: it's been something we've asked for, but not demanded 18:56:25 nirik I guess I'll do it -- my proposal 18:56:40 mattdm: thanks. 18:56:45 -1 on empty securetty—the original owner is supporting the counterproposal as well :) 18:56:51 -1 for this change 18:56:52 -1 18:56:55 #action mattdm to ask for clarification on enable scls for workstation 18:56:57 mitr: i think we've expected that at least one of answering questions on-list or in meeting happens 18:57:06 notting: the first one, definitely 18:57:13 -1 for the change. 18:57:19 (which may have been delayed due to summit stuff) 18:57:24 -1 for the change as posted 18:57:25 And yes, I can be persuaded to support the removal of pam_securetty from the default pam config for login 18:57:26 -1 18:57:55 -1 to change 18:58:02 #agreed change is rejected (0,-7,0) 18:58:11 from the ticket, my counter-proposal.... 18:58:15 + 18:58:19 Counter-proposal: Remove securetty from default PAM configuration and remove /etc/securetty, and note this in the release notes. 18:58:20 +1 rather 18:58:28 +1 18:58:40 mattdm, +1 18:58:58 +1 18:59:06 +1 18:59:11 +1? Might just as well be happy with only a recommendation to the util-linux maintainer 18:59:30 Please make sure that upgrades don't start silently allowing more logins, though 18:59:52 #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 #action mattdm to file bugs and talk to docs 19:00:12 #topic #1299 F21 System Wide Change: Smaller Cloud Image Footprint - https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint 19:00:12 .fesco 1299 19:00:12 https://fedorahosted.org/fesco/ticket/1299 19:00:13 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 mitr, they will start to 19:00:40 mitr, I don't see how we could avoid that 19:00:58 mitr, rpm will replace the config file unless changed by admin 19:01:22 mitr, it must be release noted 19:01:36 t8m: touch the file in %pre on upgrades? I don't know. But, oh well. 19:02:00 Re: #1299, +1 to the general idea, -1 to introducing networkd in this fashion 19:02:05 im +1 to Smaller Cloud 19:02:35 Perhaps with the import of existing config file format 19:02:35 mitr Yeah, this is a grab bag of things that will be tried. networkd probably isn't ready in any case. 19:02:53 So to make the cloud a bigger thing we need to vote yes to smaller cloud, eh? 19:02:59 same as mitr +1 to the idea -1 to introducing networkd this way 19:03:03 pjones .... yes? :) 19:03:36 I'm +1 with the assumption that we won't go all crazy with networkd before it's ready :) 19:03:43 mattdm, using the fedora_requires_release_note flag on bugs will do, fwiw 19:03:59 +1 here... I'm also worried about adding another network setup before it's ready 19:04:01 mattdm: might be worth removing that from the change page if it's not the plan anymore.in any case, +1 19:04:17 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 or, "never" is too strong 19:04:41 so, thats +6? 19:04:57 * pjones +1 19:05:08 #agreed Change is approved (+7,0,0) 19:05:20 #action mattdm to follow up on networkd with cloud wg 19:05:30 #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 .fesco 1300 19:05:30 https://fedorahosted.org/fesco/ticket/1300 19:05:31 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 +1 19:05:54 sure, +1, perhaps it will take off. ;) 19:06:01 why not, +1 19:06:12 +1. i don't suppose a provenpackager is bored enough to change *everything* 19:06:13 +1 19:06:25 +1 19:06:34 +1 19:06:34 notting spot definitely said he wasn't that bored :) 19:06:52 #agreed Change is approved (+7,0,0) 19:07:20 are the packaging guidelines already changed so at least for new packages we already get the licenses as %license ? 19:08:01 t8m that's in progress 19:08:19 and a fun one for last... 19:08:22 #topic #1301 F21 System Wide Change: Workstation: Disable firewall - https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall 19:08:23 .fesco 1301 19:08:23 https://fedorahosted.org/fesco/ticket/1301 19:08:24 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 ooh. time for the fireworks. :) 19:09:20 there was a ton of posts on the list on this one 19:09:25 I'd say +1, let's make the hell freeze :) 19:09:28 much of it noise. ;) 19:09:45 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 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 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 mattdm: cloud != workstation, though 19:11:43 nirik: Some GNOME people have replied on the list, but not specifically the owner 19:11:47 FYI, there were 173 posts on the devel list on this change. Might be a record. ;) 19:11:49 notting Yes, definitely. I just wanted to put that there for full disclosure :) 19:12:54 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 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 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 christian replied several times. he's in the WG 19:14:21 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 so, other votes? discussion? proposals? 19:14:27 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 mclasen has opened https://bugzilla.gnome.org/show_bug.cgi?id=727580 to try and fix the underlying problem 19:15:16 i think i have to agree with notting -1 19:15:21 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 twoerner has suggested he's willing to work towards fixing things 19:15:38 jwb: this has been proposed 3 years ago.. but has been rejected by the gnome team 19:15:50 jwb: yes I am still interested 19:15:58 twoerner, it was rejected 3 years ago, or it was similarly rejected 3 days ago? 19:16:27 3 years ago 19:16:30 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 jwb: yes, hopefully 19:17:25 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 so, we are at -4, +1 I think? 19:17:49 jwb: yeah, that actually seems like a better stop gap than this plan 19:18:03 jwb: Actually, the contingency plan is essentially "disable the firewall by default but use a different mechanism to override it" 19:18:25 mitr, there's no discussion on what the home zone does or doesn't do. 19:18:47 or how "public" and "unknown" differ 19:18:54 jwb: I'm taking it for granted that home has ~zero restrictions 19:19:04 so those would both need to be fleshed out 19:19:17 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 what those zones do can be discussed between workstation and firewalld developers 19:19:50 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 I'll go on the record as +1 based on my comments above. 19:20:04 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 so it's -5 +2 19:20:27 mitr, you're making an assumption. it may be accurate, but it's an assumption. 19:20:34 jwb: true 19:20:50 pjones: who was the other +1, did I miss someone? 19:20:56 t8m 19:21:08 (and mattdm now) 19:21:13 ah... right. 19:21:31 #agreed Change is rejected (-5,+2,0) 19:21:33 proposal: ask the proposal owners to work with firewalld developers and reframe proposal based around current contingency plan 19:21:46 +1 19:21:49 mattdm: +1 19:21:53 mattdm: +1 19:21:55 +1 to self 19:21:57 +1 19:22:30 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 But they will be talking anyway :) 19:23:10 well, that was +5,-1... unless we want to rephrase? 19:23:19 mitr: they will? the original proposal seemed to imply a lack of talking, if it got to this point 19:24:06 btw: there will be a meeting about "Firewall and Desktop" tomorrow 19:24:07 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 ^^^ 19:24:24 ok, then perhaps we should just leave it to that? 19:25:14 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 ... future Change proposal 19:25:34 right. ok. 19:25:49 there's one more ticket that I didn't notice that adamw wanted us to look at today... 19:25:57 #topic #1286 New upstream version of dracut inappropriately pushed as stable release update, introduces major regression 19:25:57 .fesco 1286 19:25:58 https://fedorahosted.org/fesco/ticket/1286 19:26:00 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 Sorry I had to be afk for a moment 19:26:57 * dgilmore needs to run and pick up daughter, 19:28:03 Not sure what admonishing the dracut maintainer will end up doing, but I guess we can. 19:28:05 * mattdm reads 19:28:17 so... an update to fix that one bug is in testing https://admin.fedoraproject.org/updates/dracut-037-11.git20140402.fc20 19:28:25 I agree with adamw that such update should not be done in critical package such as dracut 19:28:31 it looks like the bug *did* get attention 19:28:34 Other than that, accept adamw's proposal as stated? 19:29:04 mattdm: sure, after it broke stuff. ;( 19:29:10 mitr: +1 19:29:15 I'd like to see what haraldh has to say; he's so far not commented in the ticket 19:29:16 mitr, +1 19:29:26 nirik yeah. not good, just noting that part of what adam asked for did happen without our involvement 19:29:33 but ... yeah, +1 to mitr's proposal. 19:29:39 I'm +1 to mitr/adamw 19:29:44 and pjones too 19:29:46 * mitr notes this wasn't a proposal actually 19:29:52 mattdm, because adamw did it... 19:29:55 so I basically fixed the bug 19:29:59 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 mattdm, not because the maintainer did 19:30:12 but harald has not responded at all, so i'd really like fesco to be aware that this is going on. 19:30:20 is he on PTO or something? 19:30:36 he's normally fairly responsive 19:30:40 pjones, I have to say that he had at least 7 days to do that 19:30:52 since the time he was cced on the ticket 19:31:15 t8m: yeah, that's why I'm +1 19:31:19 not listed at https://apps.fedoraproject.org/calendar/list/vacation/ 19:31:33 adamw, the usage of that is... spotty. 19:31:42 * mattdm goes to put my upcoming vacation in the calendar 19:31:44 true, but it's what we got. (or is there an RH-internal one too?) 19:31:56 maintainers of mission-critical components should be using it, at least. 19:31:58 * pjones checks 19:32:00 come on. it's not "what we've got." 19:32:20 ? how else can we check? 19:32:27 yeah, he's not been active in irc for about the last 10days. 19:32:28 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 er...hence the part which came next right on the very same line you paraphrased? 19:32:58 Well, I'm trying to look up his internal calendar. 19:33:04 thanks... 19:33:10 I don't anticipate success given the results of my attempt so far. 19:33:28 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 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 jwb: whether he's on vacation or not seems irrelevant to the issue of whether this update violated the updates policy. 19:34:10 jwb but... pushing out a major change in a critpath component and then going on vacation is also not so great 19:34:24 if I'm not supposed to report violations of the updates policy to fesco, what am I supposed to do? 19:34:29 yeah, that's not working. 19:34:34 adamw, mattdm: sure. but people are saying "well the maintainer had 7 days... " 19:34:37 jwb, I have to agree with adamw on this one 19:34:41 so, thats +5? 19:34:45 * nirik recounts 19:34:59 nirik: count me as 0 for now 19:35:06 ok, +4 then... 19:35:07 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 +1 adamw 19:35:37 proposal: attempt contacting maintainer and revisit next week. 19:35:45 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 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 jwb: https://admin.fedoraproject.org/pkgdb/acls/name/dracut shows 2 19:36:39 well, dracut-maint is ? number. ;) 19:36:57 if you're going by commits and approveacls... i don't think that's accurate. 19:36:58 maybe we should suspend kay from fedora development? ;) 19:37:04 jwb: But honestly our practical options in these situations are kind of limited 19:37:16 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 notting: I could go with that wording :) +1 19:37:44 mitr, i'll disagree politely. anyway, not a problem to solve here 19:38:06 * dgilmore is reading back 19:38:28 and "seriously, try not to do again" 19:38:45 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 adamw, well aware of those. duped several myself 19:39:03 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 ok, so thats +6 to... what... does someone want to reword? or want me to? 19:39:26 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 mitr: *and it was so so bad* 19:41:07 nirik: you don't need to reword it on my behalf 19:41:11 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 ok. 19:41:50 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 (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 #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 (hope thats ok with everyone) 19:42:50 thanks. 19:42:59 #topic Next week's chair 19:43:04 who wants it? 19:43:15 nirik: im +1 19:43:19 to above 19:43:34 dgilmore: ok, will note in ticket. 19:43:41 * dgilmore can do next week 19:43:42 I will not be able to attend next week 19:44:03 thanks dgilmore 19:44:11 #info dgilmore to chair next week 19:44:18 #topic Open Floor 19:44:23 any items for open floor? 19:44:51 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 Possibly would help us have shorter meetings too 19:45:21 and we should *also* more strongly request stakeholders to show up for the discussion 19:45:41 so, people should request beforehand items be removed from agenda if questions unanswered? 19:46:11 pjones and if they can't (timezones, other commitments), at least get an rsvp along those lines 19:46:12 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 mattdm: yeah 19:46:43 notting if we remove items from the agenda, that just seems like it's asking for a pile of unaddressed items 19:47:33 perhaps do agenda eariler so we can ask questions about items in it ? 19:47:52 dunno. 19:47:57 perhaps not wait for the agenda and review the Changes as they are announced. 19:47:59 nirik: For Changes, we already _know_ the agenda in advance. 19:48:19 Dropping them from the agenda to indicate that the questions haven't been answered is an idea. 19:48:27 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 Or perhaps, just in the Change threads, mark questions as "blocking my vote"? 19:48:43 mitr, sure 19:49:12 When we had the PRDs due on a monday before the wednesday meeting, that worked pretty well, I think. 19:49:29 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 I've kind of gotten into the habit of thinking of wednesday as "fesco ticket review time" 19:49:48 mattdm, uh... the Changes are announced a _week_ before they're even added to the agenda 19:49:51 which I freely admit is the root of the problem. 19:49:57 mattdm, exactly 19:50:09 waiting for the agenda means you're wasting everyone's time. 19:50:16 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 mattdm: likewise. 19:51:12 If I/we shift that assumption to "these will be discussed and commented on _before_ wednesday", that _should_ help 19:51:19 yeah, we can all try and do better... :( 19:51:42 but sometimes it's hard to beat the back-and-forth of conversational meeting 19:52:13 ok, anything else? or shall we close out? 19:52:37 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 ok, thanks for coming everyone. 19:53:58 #endmeeting