18:00:20 #startmeeting FESCO (2013-02-13) 18:00:20 Meeting started Wed Feb 13 18:00:20 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:24 #meetingname fesco 18:00:24 The meeting name has been set to 'fesco' 18:00:30 #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:00:30 Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:00:33 * notting is here 18:00:36 #topic init process 18:00:36 * nirik is here. 18:00:44 Hello 18:01:00 hi 18:01:28 yo. 18:01:30 * abadger1999 here 18:03:06 let's start 18:03:17 #topic #896 Refine feature process 18:03:22 .fesco 896 18:03:25 mmaslano: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896 18:04:16 the changes from FUDCon were included into proposal 18:04:26 with mitr and mmaslano we updated it based on FUDCon discussion 18:05:17 so, I wonder if we couldn't change 'feature' ? 'highlight' , 'notable change' something better? I think 'feature' still gets overloaded... 18:05:30 yeah. i was thinking the same thing 18:05:51 as native you can propose better word 18:05:55 if we're calling it the planning process, using the term Feature for the individual submissions seems odd 18:06:08 at least we have "planning process", for jwb... at fudcon we accepted that word, but I'm ok with change 18:06:19 Plans? 18:06:46 kind of obtuse, but i don't want to be all ubuntuish and call them blueprints or something 18:06:48 planning process and the one thing will be ...? 18:06:54 a Plan 18:06:55 roadmap? 18:07:11 as in "27 proposed plans, 1 refused plan"? 18:07:12 it's not roadmap as everyone would understand the world 18:07:24 drago01_, roadmap is somethign you can derive from the set of submitted/approved 18:07:35 hmm true 18:07:37 s/world/word 18:07:41 maybe split the difference. self-contained changes, and complex features? 18:07:50 notting, seems fair 18:08:07 notting: +1 18:08:07 wfm 18:08:08 * nirik is fine with that 18:08:08 Isn't just "change" the word we are looking for here? 18:08:43 * mitr will stop and leave it to the native speakers 18:08:45 mitr: sounds too generic 18:08:52 (at least for me) 18:09:11 notting's proposal works for me 18:09:51 notting: yeah, that works 18:10:23 otherwise I think we hashed out our concerns at fudcon? 18:10:24 it could be harder to communicate it - we are back to "enhancement" and "feature" but 18:10:43 but now - we want to know about that enhancements too 18:11:26 you mean "self-contained changes" and "complex features" ? :) 18:11:56 yep 18:12:30 but as I said - works for me 18:12:39 and seems like there are no objections 18:12:51 i just want "Features" to be purely a marketing term 18:12:59 so whatever accomplishes that works for me 18:13:45 proposal: ack the proposal on my page with renaming to Planning process, self-contained -> changes, and complex -> features 18:13:57 sure 18:13:57 so, perhaps 'self contained' and 'complex' changes... (drop feature from there entirely) 18:14:20 nirik, i'd be happier, but i'm not going to be a stickler about that. lowercase at least helps 18:14:23 then marketing could call out any 'change' as a feature if they desired? 18:14:32 right, that was my thinking 18:14:40 same here 18:14:51 and calling both changes seems to be less confusing 18:14:52 jwb: +1 18:14:54 why not 18:16:34 so, ack the proposal with feature changed to change. ;) 18:16:34 ? 18:16:41 +1 18:16:45 sure, +1 18:16:48 +1 18:17:01 +1 18:17:04 +1 18:17:07 +1 18:18:19 +1 18:18:34 #accepted the new planning process was approved with change of name from features to changes (+7,-0,0) 18:19:24 #topic #980 Add "activate contingency" points to the features process 18:19:29 .fesco 980 18:19:32 mmaslano: #980 (Add "activate contingency" points to the features process) – FESCo - https://fedorahosted.org/fesco/ticket/980 18:22:17 Is this actually proposing a change from the current process? Or just saying that we should be more strict at the pre-beta review time? 18:22:34 does anyone have an opinion on this issue? 18:22:39 what should be the action? 18:22:45 I like the idea of contingency points 18:22:48 i don't know. i don't see anything wrong with what you've listed in comment #3 18:23:04 I'm not sure here. I don't think we specifically discussed this at fudcon. 18:23:19 have we ever used a contingency plan on a feature? 18:23:51 * jreznik is not sure it's possible to force "contingency" by some hard deadline - it's more case by case, we need more communication, maybe sheppard for such cases and review + be strict sometimes :) 18:23:56 don't know about the timing. 18:24:02 We certainly had features that weren't finished in time, but I can't recall a non-trivial contingency plan 18:24:03 we've postponed some so they weren't announced as features 18:24:20 I believe one release had a gnome3 rollback 18:24:49 many features have reduced scope... 18:26:19 reduced scope i somewhat different as it isn't a, can we revert this change because 1/2 of the system is broken but the other half is converted question. 18:26:36 yeah. 18:27:54 The feature process proposal from the previous meeting item contained a "to do" for rawhide merge windows / more being done in side tags, which should reduce the risk of half-converted changes 18:27:55 I agree we should scrutinize features and do something with ones that aren't ready, but I don't think there's a one size fits all contingency. 18:28:17 The side tags aren't a complete solution (or even existing solution) of course 18:28:42 nirik: yep, case by case - there's not fit them all 18:29:28 * pjones has to afk for just a minute 18:29:32 right. more work done/ready/testable before it lands in branch would be good, but thats not really a contingency. 18:29:35 what about a "Point of no return" subsection in the contingency question? 18:29:43 I guess I would say, we should try and reduce need for a contingency 18:31:07 so that each feature could say I can be evaluated at date X for pulling implementing the contingency plan otherwise we have to go forward. 18:31:30 people already suck at estimating percentage complete. i don't think that will work 18:31:36 * abadger1999 anticipates quite a few but not all complex changes saying, "now" for that. 18:32:40 Maybe we need to discuss this on list? 18:32:45 yeah. 18:32:46 Would we be likely suggest a different X than "before beta, but as late as possible"? 18:33:21 * mattdm notes that contingency plans for anything big need to be tested in beta, so that's kind of a hard stop 18:33:45 * abadger1999 would err on the side of "contingency plan is possible to implement within this timeframe" 18:34:22 well, if the contingency plan is implementable, but no one tests the result, that seems bad. 18:34:24 and btw... quoting the just-approved feature changes document: 18:34:27 " Status of complex features will be re-reviewed by FESCo one week before Beta Freeze. " 18:34:46 mattdm: the thing is, that's almost certain to be what happens for 99% of changes 18:34:47 mitr: that may be sufficient. 18:35:10 pjones: that they're not ready for beta? 18:35:20 mattdm: that the contingency plan is never tested 18:35:43 That's a given. Also, activating a contingency is likely to delay the beta. I think I'm fine with both. 18:35:49 pjones: i think, the results of the contingency plan, if implemented is what mattdm means. 18:36:21 so the plan isn't tested but if we have to use it, then the results ned to be tested by beta. 18:36:28 *at beta 18:36:49 the specific problem I want to avoid is realizing during the beta that there's a problem, and leaving us with no reasonable option but to plunge on even if the contingency plan was originally reasonable. 18:37:50 not always there's an option :( as it was for anaconda for example - but it's really extreme example 18:38:17 and I think that's okay for the occasional extremes 18:38:46 but ideally we'll be clear initially when something is *expected* to be like that. 18:40:36 Some other, smaller but core changes end up having scope creep which impacts other projects beyond what's defined in the initial accepted feature/change description. 18:40:41 so something like "in general, fesco must be able to make a choice of whether to go forward with a change or invoke the contingency plan one week before beta. Changes which cannot meet that schedule need to note them on the feature page. 18:40:51 so, what actual changes are we proposing here? it's still not clear to me. 18:40:55 proposal: We have an "check for contingency" point now. 1) Document/emphasize that this is when FESCo will decide on activating the contingency. 2) We recognize that deviations from that point will happen, but we don't establish a detailed policy for them at this time. 3) Close ticket, unless there are other changes. 18:41:17 * nirik is +1 to both of those. 18:41:24 mattdm: Scope creep can't be fixed with the contingency. The more complete Fedora Revamp discussed at fudcon would probably help. 18:41:48 mitr: +1 18:42:36 non-voting but I'm good with that, with an emphasis on the emphasizing. :) 18:42:39 mitr: +1 18:42:45 mattdm: great 18:43:14 tht works for me, +1 18:43:52 mitr: If you incorporate the expectation that changes note when they don't think they can meet the deadline on the planning page, it works for me :-) +1 18:44:03 mitr, sure +1 18:44:20 abadger1999: will do 18:44:56 #accepted We have an "check for contingency" point now. 1) Document/emphasize that this is when FESCo will decide on activating the contingency. 2) We recognize that deviations from that point will happen, but we don't establish a detailed policy for them at this time. 3) Close ticket, unless there are other changes. (+5,-0,0) 18:45:03 * mitr goes ahead and edits the process change page 18:45:08 #topic #1005 At f19 branching time, drop inheritance in rawhide 18:45:14 .fesco 1005 18:45:16 mmaslano: #1005 (At f19 branching time, drop inheritance in rawhide) – FESCo - https://fedorahosted.org/fesco/ticket/1005 18:45:31 so, there's a bit more discussion on this on the ticket. 18:45:42 but I think we approved breaking inheritence... 18:45:54 we can keep trying to see if there's a middle ground before we branch. 18:46:30 * abadger1999 is fine with the previous proposal to just go ahead and break inheritance. 18:47:23 I think comment 13's proposal also runs the risk of overwriting changes. 18:47:24 I'd like to keep the behavior as similar to branches in any other project / repository as possible. 18:48:05 mitr: which means? you are ok with breaking inheritence? 18:48:23 nirik: yes, no inheritance between branches. 18:49:01 ok, so I think we should keep the ticket open to make sure we remember to do this, but nothing further to discuss unless someone comes up with a new proposal. 18:49:21 (long term it might be interesting to have Release: managed automatically to make git merges easier, not only for release branches but also for Change-specific rawhide integration branches, but that's neither here nor there) 18:49:44 this is done by tagging everything over first, even older packages that may have failed mass rebuild, right? 18:50:23 notting: yeah, I guess thats correct. 18:50:31 unless dgilmore has a better idea. ;) 18:51:33 personally, i'd like a lazy way to automate it, but that can likely be done with some scriptiong 18:52:40 we cut off inheritance at branch time 18:53:00 we tag all inherited builds into the branched tag 18:53:12 * nirik nods. 18:54:08 so the difference would be that at branch time we tag in all inherited builds to f20 and turn off inheritance in the rawhide mash configs 18:54:39 and then when we branch f20 instead of tagging inherited builds to f20 we do it to f21 18:55:29 id need to change my workflow slightly, its the same tasks just doen slightly differently 18:55:44 cool. Any objections to doing it that way? 18:55:52 biggest issue will be getting devs to do the right thing 18:56:03 nirik: not at all 18:56:09 yep. I can try and work on that. 18:56:37 anything else on this topic? or shall we move on? 18:56:58 Checking that developers build for rawhide sounds like a technically fairly easy AutoQA test. 18:57:20 yeah, in fact it should also notify about that... 18:57:40 and we can run a upgrade path checking script from time to time. 18:57:43 heh, could write an autoqa test that actually submits the rawhide build. but that sounds Wrong 18:57:55 Do we want to specifically do something about AutoQA now, or defer to see whether it is needed? 18:58:51 mitr: it already does that check. 18:58:51 check is there but not enforced as far as I know 18:58:54 nirik: great 18:59:04 right. it's not enforced. 19:01:45 so... 19:02:05 dropping inheritance was approved in the ticket, no other action, shall we move on? 19:02:14 yep. +1 19:02:20 +1 19:02:37 moving on to features from last week 19:02:49 it's more now for autoqa and enforcing it (so devels know what to do) 19:03:06 #approved dropping the inheritance was approved in ticket 19:03:10 #topic #988 F19 Feature: System Configuration Shell - https://fedoraproject.org/wiki/Features/SystemConfigurationShell 19:03:15 .fesco 988 19:03:16 mmaslano: #988 (F19 Feature: System Configuration Shell - https://fedoraproject.org/wiki/Features/SystemConfigurationShell) – FESCo - https://fedorahosted.org/fesco/ticket/988 19:04:35 my concern here is that with this, and with the openlmi shell, we have two different initiatives trying to do the same thing. 19:04:46 That's... not unheard of in Fedora? 19:04:50 that's not inherently bad, but depending on how the feature is worded, it can be confusing to users 19:05:17 I'm more concerned that feature owners have not responded. 19:05:17 We can state a preference 19:06:02 nirik: +1 19:06:03 nirik: combined with the 0% completion, yeah 19:06:46 how about we give them another week with the note that if we don't hear back we will drop it ? 19:07:38 yeah 19:07:41 how about we drop it and they can file for an exception? 19:07:53 Do we have an actual reason to drop the feature right now? 19:08:02 0% and no response 19:08:33 This is the first time we are discussing it AFAICT, that sounds harsh 19:08:50 oh fine. do it nirik's way 19:09:22 * nirik is fine either way. Hopefully the feature owner has just been busy and will chime in 19:09:25 * jreznik tried to reach feature owner and tell him about openlmi shell and so on - and yeah, no response 19:09:36 also it seems he's not the guy who will implement it 19:09:57 oh? 19:09:59 Looking at the mailing list thread, there actually wasn't a question asked 19:10:13 Just an "if you're interested, please subscribe..." 19:10:32 notting: "I will not be the implementer of this feature (though I worked out an example, see attachement), but focus on the language/API design, documentation and testing. " 19:10:46 it's in ticket 19:11:00 then, i'd like to ask who the implementer is? 19:11:33 The feature owner isn't currently a packager (https://admin.fedoraproject.org/accounts/user/view/tschwaller) 19:13:34 Proposal: Defer 1 week, asking 1) the people who will implement this to add themselves as co-owners, 2) to explicitly answer relationship to OpenLMI (even if it is "separate and distinct"), and auto-close on no response. 19:13:45 mitr: +1 19:13:45 +1 19:13:49 Any other things to ask? 19:15:04 * notting is +1 to that 19:15:35 * pjones +1 to those questions as well 19:15:57 +1 19:16:37 +1 19:17:13 #agreed Defer 1 week, asking 1) the people who will implement this to add themselves as co-owners, 2) to explicitly answer relationship to OpenLMI (even if it is "separate and distinct"), and auto-close on no response. (+7,-0,0) 19:17:27 #topic #1036 F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication 19:17:32 .fesco 1036 19:17:35 mmaslano: #1036 (F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication) – FESCo - https://fedorahosted.org/fesco/ticket/1036 19:17:59 any response from feature owners here? 19:18:45 Nothing on the wiki page, nothing on the mailing list 19:19:06 We deferred this also as a way to detect activity, soooo 19:19:26 proposal: reject feature; let feature owners reopen and resubmit if/when they are interested 19:19:37 +1 19:19:43 * pjones +1 19:19:53 (better wording welcome) 19:19:57 yeah, i'm fine with giving them a late exception if they have answers/become communicative 19:20:33 +1 19:20:42 finally. something we reject. +1 19:21:08 +1 19:22:27 #agreed reject feature; let feature owners reopen and resubmit when they are interested (+5,-0,0) 19:22:38 #topic #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown 19:22:43 .fesco 1040 19:22:45 mmaslano: #1040 (F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown) – FESCo - https://fedorahosted.org/fesco/ticket/1040 19:23:43 So, we have some clarity about a non-enabled-by-default feature. 19:24:09 Security-wise I really don't like it, but I'm also really unsure FESCo should concern itself at such level. 19:24:28 Opinions on that? 19:24:56 yeah. I'm ok with the feature as it is. Concerns about security of it could be reasked on list... or bugs on the application? 19:25:17 mitr: what do you mean security-wise? at an initial reading, if you have the perms to fake the creds to firewalld, you have the perms to blow up the firewall any way you like. what am i missing? 19:25:48 false sense of security by running lockdown and thinking no one can change it ? 19:25:56 notting: /proc/$pid_number_that_i_read_milliseconds_ago_and_may_be_recycled is inherently inreliable. 19:27:18 notting: I'm fine with having such a "management option" (perhaps implemented in an easier way, such as firewall-cmd setting an extra option in its requests?), calling this a security feature (and planning to expand on it without having the underlying mechanisms able to support it) is probably misadvetising. 19:27:59 Also, libvirtd running as root could just as well spawn a firewall-cmd subprocess. 19:29:15 if it was real advertising I guess the feature would be that any use of firewall-cmd would reject changes while it's set? 19:30:07 Not sure what you mean... 19:30:32 mitr: well, it's simpler to implement the 'secure' version of the above (don't allow a whitelist/blacklist). whether that fits the need of what is requested of it, don't know 19:30:44 A feature to switch off _all_ D-Bus configuration (and relying only on writing config files) would make sense I think 19:32:29 in any case, i understand what it's trying to do enough that i'm ok with including it. +1 19:33:21 that works for me as well... +0.5 or something like that 19:33:35 +1 19:33:40 * nirik is +1 sure 19:35:26 +1 19:35:40 yeah, I'm +1 for it, I guess. 19:37:42 #agreed firewalld lockdown feature was accepted (+5.5,-0,0) 19:37:56 #topic #1085 2013-02-13 meeting feature voting 19:38:01 .fesco 1085 19:38:05 mmaslano: #1085 (2013-02-13 meeting feature voting) – FESCo - https://fedorahosted.org/fesco/ticket/1085 19:38:47 * nirik is fine with all the new features. Happy to discuss any that folks want to though. 19:39:32 does anyone want to discuss new features? 19:39:53 no features are mentioned in the ticket, so you are all fine with all of them 19:42:25 #proposal Vote about all new features, just to be sure you've accepted them 19:42:31 +1 19:42:35 +1 19:42:59 i am +1 to the proposal to vote, or +1 to approve all of them. whichever you're asking for. 19:43:20 mmaslano: Just to be sure - you are proposing a single summary vote, aren't you? 19:43:26 yes 19:43:31 sure, +1 19:44:06 +1, sure 19:45:10 #agreed all features from new business are accepted "en bloc" (+5,-0,0) 19:45:17 * pjones is +1 to all of them 19:45:31 #topic Next week's chair 19:46:50 i am very likely to be dragged into another meeting during this time next week 19:47:24 I can serve next time 19:47:48 great 19:47:57 #info mitr will be chairman next week 19:48:05 #topic Open Floor 19:49:06 I have one thing to note... 19:49:16 mmaslano: I wondered if we wanted to revisit the udev device naming since mdomsch replied on the thread. 19:49:51 nirik: I hope you have the same question 19:50:03 we may have the ticket I opened about tor packages reopened. The maintainer reverted a fair bit of changes. I am not sure if they were just cosmetic or if there's still security issues pending on it. If someone else wants to look that would be fine, or I can try 19:50:42 nirik: well, that thread devolved into a request to remove a packager from fedora entirely 19:50:57 nirik: I was looking on the conversation in few bugs. It's hard to say if we should act now 19:50:59 it did, but perhaps we can mediate some solution? 19:52:23 not sure, anyhow it was not on the agenda, so mostly I just wanted to note that it might be next week 19:53:52 nirik: do you have a proposal what to do? 19:54:03 FWIW, we had a conversation about clamav earlier, and (https://fedorahosted.org/fesco/ticket/799), and at that time found no specific issues that _needed_ resolving. I haven't looked at tor. 19:54:08 not yet, I haven't had any time to look in detail to what was reverted, etc 19:54:27 I propose next week 19:55:03 yeah, nothing we can do right now. 19:55:35 abadger1999: do you want to speak about udev? 19:56:00 http://lists.fedoraproject.org/pipermail/devel/2013-February/178226.html 19:56:23 mdomsch, the biosdevname feature owner added some comments to the thread. 19:56:28 Also, after the feature was accepted someone posted example names... which were pretty ugly. 19:56:54 Don't know if we want to revisit the feature or go ahead with it and let them work it out however they want. 19:57:06 OTOH, the week for comments has passed, so the bar for reopening discussion should arguably be a little higher than a single mail to -devel 19:58:18 abadger1999: mdomsch is the original biosdevname author... 99% sure he doesn't own or maintain it these days 19:58:41 https://admin.fedoraproject.org/pkgdb/acls/name/biosdevname 19:59:03 there's two ways we could talk about his critiqque if we choose to: (A) He made the counter proposal of identifying bugs in biosdevname and fixing it rather than starting over with a new strategy. or (B) just look into fixing the udev feature with the points that he had about it. 19:59:04 * nirik isn't really sure how to work it out. Names are going to be not too pretty based on the limitations there. Minimizing changes for our users seems good tho 19:59:06 notting: correct. he says as much in the email. 19:59:59 ! 20:00:34 fedora_richie: you can feel free to speak without raising your hand in the fesco meeting :-) 20:01:01 thank you.. wondering if its time for EMEA ambassadors meeting? 20:01:42 perhaps we should end up and discuss further on list on this? 20:01:51 probably 20:02:03 fedora_richie: one hour 20:02:11 :) cheers 20:02:23 I'd like to close the meeting in a minute if you don't mind 20:02:27 I'm not thrilled about the feature, both about the from-scratch rewrite as a principle and about the "this is ugly to implement" as a justification to drop functionality. However we are sort of running into the limits of volunteer-based projects, and the acceptance process has been completed, so.... 20:02:44 mmaslano: I would like it if we could decide if we want to reopen discussion about it or not. 20:02:59 ah, I thought someone will reopen the dicussion 20:03:02 mmaslano: if we do, then we can talk about what we want to do on the list. 20:03:17 mmaslano: ah, if that's the plan, that works for me :-) 20:03:43 abadger1999: do you want to propose there A or B? 20:04:02 at the moment I don't know which option would be better for Fedora 20:04:34 * mitr would appreciate notting's opinion on this 20:04:42 mmaslano: I'll reply to the thread and say that those seem to be the two directions we could take... I don't know enough about biosdevname or the udev naming to lead beyond that point. 20:04:55 * abadger1999 agrees with mitr :-) 20:05:41 i think the solution in udev is the way to go forward, and we should try and figure out how to handle the cases that they still want biosdevname for there. 20:06:48 notting: okay, I'll concentrate on (B) in my email followup, then. 20:07:02 thanks 20:08:09 * abadger1999 is fine with this topic being done pending more list discussion now 20:13:14 guys, let's go home 20:13:21 #endmeeting