18:00:20 <mmaslano> #startmeeting FESCO (2013-02-13)
18:00:20 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:24 <mmaslano> #meetingname fesco
18:00:24 <zodbot> The meeting name has been set to 'fesco'
18:00:30 <mmaslano> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
18:00:30 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:00:33 * notting is here
18:00:36 <mmaslano> #topic init process
18:00:36 * nirik is here.
18:00:44 <mitr> Hello
18:01:00 <jwb> hi
18:01:28 <pjones> yo.
18:01:30 * abadger1999 here
18:03:06 <mmaslano> let's start
18:03:17 <mmaslano> #topic #896 Refine feature process
18:03:22 <mmaslano> .fesco 896
18:03:25 <zodbot> mmaslano: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896
18:04:16 <mmaslano> the changes from FUDCon were included into proposal
18:04:26 <jreznik> with mitr and mmaslano we updated it based on FUDCon discussion
18:05:17 <nirik> so, I wonder if we couldn't change 'feature' ? 'highlight' , 'notable change' something better? I think 'feature' still gets overloaded...
18:05:30 <jwb> yeah.  i was thinking the same thing
18:05:51 <mmaslano> as native you can propose better word
18:05:55 <jwb> if we're calling it the planning process, using the term Feature for the individual submissions seems odd
18:06:08 <jreznik> at least we have "planning process", for jwb... at fudcon we accepted that word, but I'm ok with change
18:06:19 <jwb> Plans?
18:06:46 <jwb> kind of obtuse, but i don't want to be all ubuntuish and call them blueprints or something
18:06:48 <mmaslano> planning process and the one thing will be ...?
18:06:54 <jwb> a Plan
18:06:55 <drago01_> roadmap?
18:07:11 <mitr> as in "27 proposed plans, 1 refused plan"?
18:07:12 <jreznik> it's not roadmap as everyone would understand the world
18:07:24 <jwb> drago01_, roadmap is somethign you can derive from the set of submitted/approved <whatevers>
18:07:35 <drago01_> hmm true
18:07:37 <jreznik> s/world/word
18:07:41 <notting> maybe split the difference. self-contained changes, and complex features?
18:07:50 <jwb> notting, seems fair
18:08:07 <jreznik> notting: +1
18:08:07 <abadger1999> wfm
18:08:08 * nirik is fine with that
18:08:08 <mitr> 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 <jreznik> mitr: sounds too generic
18:08:52 <jreznik> (at least for me)
18:09:11 <mitr> notting's proposal works for me
18:09:51 <pjones> notting: yeah, that works
18:10:23 <nirik> otherwise I think we hashed out our concerns at fudcon?
18:10:24 <jreznik> it could be harder to communicate it - we are back to "enhancement" and "feature" but
18:10:43 <jreznik> but now - we want to know about that enhancements too
18:11:26 <nirik> you mean "self-contained changes" and "complex features" ? :)
18:11:56 <jreznik> yep
18:12:30 <jreznik> but as I said - works for me
18:12:39 <jreznik> and seems like there are no objections
18:12:51 <jwb> i just want "Features" to be purely a marketing term
18:12:59 <jwb> so whatever accomplishes that works for me
18:13:45 <mmaslano> proposal: ack the proposal on my page with renaming to Planning process, self-contained -> changes, and complex -> features
18:13:57 <jwb> sure
18:13:57 <nirik> so, perhaps 'self contained' and 'complex' changes... (drop feature from there entirely)
18:14:20 <jwb> nirik, i'd be happier, but i'm not going to be a stickler about that.  lowercase at least helps
18:14:23 <nirik> then marketing could call out any 'change' as a feature if they desired?
18:14:32 <jwb> right, that was my thinking
18:14:40 <jreznik> same here
18:14:51 <jreznik> and calling both changes seems to be less confusing
18:14:52 <abadger1999> jwb: +1
18:14:54 <mitr> why not
18:16:34 <nirik> so, ack the proposal with feature changed to change. ;)
18:16:34 <nirik> ?
18:16:41 <mitr> +1
18:16:45 <notting> sure, +1
18:16:48 <jwb> +1
18:17:01 <mmaslano> +1
18:17:04 <abadger1999> +1
18:17:07 <nirik> +1
18:18:19 <pjones> +1
18:18:34 <mmaslano> #accepted the new planning process was approved with change of name from features to changes (+7,-0,0)
18:19:24 <mmaslano> #topic #980 Add "activate contingency" points to the features process
18:19:29 <mmaslano> .fesco 980
18:19:32 <zodbot> mmaslano: #980 (Add "activate contingency" points to the features process) – FESCo - https://fedorahosted.org/fesco/ticket/980
18:22:17 <mitr> 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 <mmaslano> does anyone have an opinion on this issue?
18:22:39 <mmaslano> what should be the action?
18:22:45 <abadger1999> I like the idea of contingency points
18:22:48 <jwb> i don't know.  i don't see anything wrong with what you've listed in comment #3
18:23:04 <nirik> I'm not sure here. I don't think we specifically discussed this at fudcon.
18:23:19 <nirik> 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 <abadger1999> don't know about the timing.
18:24:02 <mitr> We certainly had features that weren't finished in time, but I can't recall a non-trivial contingency plan
18:24:03 <notting> we've postponed some so they weren't announced as features
18:24:20 <abadger1999> I believe one release had a gnome3 rollback
18:24:49 <nirik> many features have reduced scope...
18:26:19 <abadger1999> 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 <nirik> yeah.
18:27:54 <mitr> 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 <nirik> 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 <mitr> The side tags aren't a complete solution (or even existing solution) of course
18:28:42 <jreznik> 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 <nirik> right. more work done/ready/testable before it lands in branch would be good, but thats not really a contingency.
18:29:35 <abadger1999> what about a "Point of no return" subsection in the contingency question?
18:29:43 <nirik> I guess I would say, we should try and reduce need for a contingency
18:31:07 <abadger1999> 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 <jwb> 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 <abadger1999> Maybe we need to discuss this on list?
18:32:45 <nirik> yeah.
18:32:46 <mitr> 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 <mattdm> well, if the contingency plan is implementable, but no one tests the result, that seems bad.
18:34:24 <mitr> and btw... quoting the just-approved feature changes document:
18:34:27 <mitr> " Status of complex features will be re-reviewed by FESCo one week before Beta Freeze. "
18:34:46 <pjones> mattdm: the thing is, that's almost certain to be what happens for 99% of changes
18:34:47 <mattdm> mitr: that may be sufficient.
18:35:10 <mattdm> pjones: that they're not ready for beta?
18:35:20 <pjones> mattdm: that the contingency plan is never tested
18:35:43 <mitr> That's a given.  Also, activating a contingency is likely to delay the beta.  I think I'm fine with both.
18:35:49 <abadger1999> pjones: i think, the results of the contingency plan, if implemented is what mattdm means.
18:36:21 <abadger1999> 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 <abadger1999> *at beta
18:36:49 <mattdm> 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 <jreznik> not always there's an option :( as it was for anaconda for example - but it's really extreme example
18:38:17 <mattdm> and I think that's okay for the occasional extremes
18:38:46 <mattdm> but ideally we'll be clear initially when something is *expected* to be like that.
18:40:36 <mattdm> 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 <abadger1999> 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 <nirik> so, what actual changes are we proposing here? it's still not clear to me.
18:40:55 <mitr> 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 <mitr> mattdm: Scope creep can't be fixed with the contingency.  The more complete Fedora Revamp discussed at fudcon would probably help.
18:41:48 <pjones> mitr: +1
18:42:36 <mattdm> non-voting but I'm good with that, with an emphasis on the emphasizing. :)
18:42:39 <mmaslano> mitr: +1
18:42:45 <mmaslano> mattdm: great
18:43:14 <notting> tht works for me, +1
18:43:52 <abadger1999> 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 <jwb> mitr, sure +1
18:44:20 <mitr> abadger1999: will do
18:44:56 <mmaslano> #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 <mmaslano> #topic #1005 At f19 branching time, drop inheritance in rawhide
18:45:14 <mmaslano> .fesco 1005
18:45:16 <zodbot> mmaslano: #1005 (At f19 branching time, drop inheritance in rawhide) – FESCo - https://fedorahosted.org/fesco/ticket/1005
18:45:31 <nirik> so, there's a bit more discussion on this on the ticket.
18:45:42 <nirik> but I think we approved breaking inheritence...
18:45:54 <nirik> 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 <abadger1999> I think comment 13's proposal also runs the risk of overwriting changes.
18:47:24 <mitr> I'd like to keep the behavior as similar to branches in any other project / repository as possible.
18:48:05 <nirik> mitr: which means? you are ok with breaking inheritence?
18:48:23 <mitr> nirik: yes, no inheritance between branches.
18:49:01 <nirik> 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 <mitr> (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 <notting> this is done by tagging everything over first, even older packages that may have failed mass rebuild, right?
18:50:23 <nirik> notting: yeah, I guess thats correct.
18:50:31 <nirik> unless dgilmore has a better idea. ;)
18:51:33 <notting> personally, i'd like a lazy way to automate it, but that can likely be done with some scriptiong
18:52:40 <dgilmore> we cut off inheritance at branch time
18:53:00 <dgilmore> we tag all inherited builds into the branched tag
18:53:12 * nirik nods.
18:54:08 <dgilmore> 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 <dgilmore> and then when we branch f20 instead of tagging inherited builds to f20 we do it to f21
18:55:29 <dgilmore> id need to change my workflow slightly, its the same tasks just doen slightly differently
18:55:44 <nirik> cool. Any objections to doing it that way?
18:55:52 <dgilmore> biggest issue will be getting devs to do the right thing
18:56:03 <dgilmore> nirik: not at all
18:56:09 <nirik> yep. I can try and work on that.
18:56:37 <nirik> anything else on this topic? or shall we move on?
18:56:58 <mitr> Checking that developers build for rawhide sounds like a technically fairly easy AutoQA test.
18:57:20 <nirik> yeah, in fact it should also notify about that...
18:57:40 <nirik> and we can run a upgrade path checking script from time to time.
18:57:43 <notting> heh, could write an autoqa test that actually submits the rawhide build. but that sounds Wrong
18:57:55 <mitr> Do we want to specifically do something about AutoQA now, or defer to see whether it is needed?
18:58:51 <nirik> mitr: it already does that check.
18:58:51 <jreznik> check is there but not enforced as far as I know
18:58:54 <mitr> nirik: great
18:59:04 <nirik> right. it's not enforced.
19:01:45 <mitr> so...
19:02:05 <mitr> dropping inheritance was approved in the ticket, no other action, shall we move on?
19:02:14 <nirik> yep. +1
19:02:20 <mmaslano> +1
19:02:37 <mmaslano> moving on to features from last week
19:02:49 <jreznik> it's more now for autoqa and enforcing it (so devels know what to do)
19:03:06 <mmaslano> #approved dropping the inheritance was approved in ticket
19:03:10 <mmaslano> #topic #988 F19 Feature: System Configuration Shell - https://fedoraproject.org/wiki/Features/SystemConfigurationShell
19:03:15 <mmaslano> .fesco 988
19:03:16 <zodbot> mmaslano: #988 (F19 Feature: System Configuration Shell - https://fedoraproject.org/wiki/Features/SystemConfigurationShell) – FESCo - https://fedorahosted.org/fesco/ticket/988
19:04:35 <notting> 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 <mitr> That's... not unheard of in Fedora?
19:04:50 <notting> that's not inherently bad, but depending on how the feature is worded, it can be confusing to users
19:05:17 <nirik> I'm more concerned that feature owners have not responded.
19:05:17 <mitr> We can state a preference
19:06:02 <abadger1999> nirik: +1
19:06:03 <notting> nirik: combined with the 0% completion, yeah
19:06:46 <nirik> how about we give them another week with the note that if we don't hear back we will drop it ?
19:07:38 <mmaslano> yeah
19:07:41 <jwb> how about we drop it and they can file for an exception?
19:07:53 <mitr> Do we have an actual reason to drop the feature right now?
19:08:02 <jwb> 0% and no response
19:08:33 <mitr> This is the first time we are discussing it AFAICT, that sounds harsh
19:08:50 <jwb> 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 <jreznik> also it seems he's not the guy who will implement it
19:09:57 <notting> oh?
19:09:59 <mitr> Looking at the mailing list thread, there actually wasn't a question asked
19:10:13 <mitr> Just an "if you're interested, please subscribe..."
19:10:32 <jreznik> 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 <jreznik> it's in ticket
19:11:00 <notting> then, i'd like to ask who the implementer is?
19:11:33 <mitr> The feature owner isn't currently a packager (https://admin.fedoraproject.org/accounts/user/view/tschwaller)
19:13:34 <mitr> 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 <mmaslano> mitr: +1
19:13:45 <nirik> +1
19:13:49 <mitr> 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 <abadger1999> +1
19:16:37 <jwb> +1
19:17:13 <mmaslano> #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 <mmaslano> #topic #1036 F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication
19:17:32 <mmaslano> .fesco 1036
19:17:35 <zodbot> 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 <notting> any response from feature owners here?
19:18:45 <mitr> Nothing on the wiki page, nothing on the mailing list
19:19:06 <mitr> We deferred this also as a way to detect activity, soooo
19:19:26 <mitr> proposal: reject feature; let feature owners reopen and resubmit if/when they are interested
19:19:37 <nirik> +1
19:19:43 * pjones +1
19:19:53 <mitr> (better wording welcome)
19:19:57 <notting> yeah, i'm fine with giving them a late exception if they have answers/become communicative
19:20:33 <abadger1999> +1
19:20:42 <jwb> finally.  something we reject.  +1
19:21:08 <mmaslano> +1
19:22:27 <mmaslano> #agreed reject feature; let feature owners reopen and resubmit when they are interested (+5,-0,0)
19:22:38 <mmaslano> #topic #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown
19:22:43 <mmaslano> .fesco 1040
19:22:45 <zodbot> mmaslano: #1040 (F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown) – FESCo - https://fedorahosted.org/fesco/ticket/1040
19:23:43 <mitr> So, we have some clarity about a non-enabled-by-default feature.
19:24:09 <mitr> Security-wise I really don't like it, but I'm also really unsure FESCo should concern itself at such level.
19:24:28 <mitr> Opinions on that?
19:24:56 <nirik> 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 <notting> 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 <nirik> false sense of security by running lockdown and thinking no one can change it ?
19:25:56 <mitr> notting: /proc/$pid_number_that_i_read_milliseconds_ago_and_may_be_recycled is inherently inreliable.
19:27:18 <mitr> 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 <mitr> Also, libvirtd running as root could just as well spawn a firewall-cmd subprocess.
19:29:15 <nirik> 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 <mitr> Not sure what you mean...
19:30:32 <notting> 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 <mitr> A feature to switch off _all_ D-Bus configuration (and relying only on writing config files) would make sense I think
19:32:29 <notting> in any case, i understand what it's trying to do enough that i'm ok with including it. +1
19:33:21 <mitr> that works for me as well... +0.5 or something like that
19:33:35 <mmaslano> +1
19:33:40 * nirik is +1 sure
19:35:26 <abadger1999> +1
19:35:40 <pjones> yeah, I'm +1 for it, I guess.
19:37:42 <mmaslano> #agreed firewalld lockdown feature was accepted (+5.5,-0,0)
19:37:56 <mmaslano> #topic #1085 2013-02-13 meeting feature voting
19:38:01 <mmaslano> .fesco 1085
19:38:05 <zodbot> 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 <mmaslano> does anyone want to discuss new features?
19:39:53 <mmaslano> no features are mentioned in the ticket, so you are all fine with all of them
19:42:25 <mmaslano> #proposal Vote about all new features, just to be sure you've accepted them
19:42:31 <abadger1999> +1
19:42:35 <mmaslano> +1
19:42:59 <notting> i am +1 to the proposal to vote, or +1 to approve all of them. whichever you're asking for.
19:43:20 <mitr> mmaslano: Just to be sure - you are proposing a single summary vote, aren't you?
19:43:26 <mmaslano> yes
19:43:31 <mitr> sure, +1
19:44:06 <nirik> +1, sure
19:45:10 <mmaslano> #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 <mmaslano> #topic Next week's chair
19:46:50 <notting> i am very likely to be dragged into another meeting during this time next week
19:47:24 <mitr> I can serve next time
19:47:48 <mmaslano> great
19:47:57 <mmaslano> #info mitr will be chairman next week
19:48:05 <mmaslano> #topic Open Floor
19:49:06 <nirik> I have one thing to note...
19:49:16 <abadger1999> mmaslano: I wondered if we wanted to revisit the udev device naming since mdomsch replied on the thread.
19:49:51 <mmaslano> nirik: I hope you have the same question
19:50:03 <nirik> 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 <notting> nirik: well, that thread devolved into a request to remove a packager from fedora entirely
19:50:57 <mmaslano> nirik: I was looking on the conversation in few bugs. It's hard to say if we should act now
19:50:59 <nirik> it did, but perhaps we can mediate some solution?
19:52:23 <nirik> 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 <mmaslano> nirik: do you have a proposal what to do?
19:54:03 <mitr> 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 <nirik> not yet, I haven't had any time to look in detail to what was reverted, etc
19:54:27 <mmaslano> I propose next week
19:55:03 <nirik> yeah, nothing we can do right now.
19:55:35 <mmaslano> abadger1999: do you want to speak about udev?
19:56:00 <abadger1999> http://lists.fedoraproject.org/pipermail/devel/2013-February/178226.html
19:56:23 <abadger1999> mdomsch, the biosdevname feature owner added some comments to the thread.
19:56:28 <mitr> Also, after the feature was accepted someone posted example names... which were pretty ugly.
19:56:54 <abadger1999> 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 <mitr> 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 <notting> abadger1999: mdomsch is the original biosdevname author... 99% sure he doesn't own or maintain it these days
19:58:41 <mitr> https://admin.fedoraproject.org/pkgdb/acls/name/biosdevname
19:59:03 <abadger1999> 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 <abadger1999> notting: correct.  he says as much in the email.
19:59:59 <fedora_richie> !
20:00:34 <abadger1999> fedora_richie: you can feel free to speak without raising your hand in the fesco meeting :-)
20:01:01 <fedora_richie> thank you.. wondering if its time for EMEA ambassadors meeting?
20:01:42 <nirik> perhaps we should end up and discuss further on list on this?
20:01:51 <mmaslano> probably
20:02:03 <abadger1999> fedora_richie: one hour
20:02:11 <fedora_richie> :) cheers
20:02:23 <mmaslano> I'd like to close the meeting in a minute if you don't mind
20:02:27 <mitr> 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 <abadger1999> mmaslano: I would like it if we could decide if we want to reopen discussion about it or not.
20:02:59 <mmaslano> ah, I thought someone will reopen the dicussion
20:03:02 <abadger1999> mmaslano: if we do, then we can talk about what we want to do on the list.
20:03:17 <abadger1999> mmaslano: ah, if that's the plan, that works for me :-)
20:03:43 <mmaslano> abadger1999: do you want to propose there A or B?
20:04:02 <mmaslano> 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 <abadger1999> 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 <notting> 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 <abadger1999> notting: okay, I'll concentrate on (B) in my email followup, then.
20:07:02 <mmaslano> thanks
20:08:09 * abadger1999 is fine with this topic being done pending more list discussion now
20:13:14 <mmaslano> guys, let's go home
20:13:21 <mmaslano> #endmeeting