18:00:01 <nirik> #startmeeting FESCO (2013-02-06)
18:00:01 <zodbot> Meeting started Wed Feb  6 18:00:01 2013 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <nirik> #meetingname fesco
18:00:01 <zodbot> The meeting name has been set to 'fesco'
18:00:01 <nirik> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
18:00:01 <nirik> #topic init process
18:00:02 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:00:07 <jwb> here
18:00:14 <pjones> hello.
18:00:20 <mmaslano> hi
18:00:22 <mitr> Hello
18:00:31 * sgallagh buckles up. It's going to be a bumpy ride.
18:00:43 * abadger1999 here but finishing up in FPC meeting
18:01:06 * notting is here
18:01:52 <nirik> ok, missing t8m I guess...
18:02:23 <nirik> ah, there he is. ;)
18:02:32 <nirik> ok, lets go ahead and dive in...
18:02:35 <nirik> #topic #896 Refine Feature process
18:02:35 <nirik> .fesco 896
18:02:35 <nirik> https://fedorahosted.org/fesco/ticket/896
18:02:38 <zodbot> nirik: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896
18:02:47 <nirik> do we have anything on this? or we need to write up things from fudcon first?
18:02:56 <jwb> the latter.  i asked about it in the ticket
18:03:05 <jwb> propose we just move on
18:03:13 <nirik> yeah, unless there's something we should just move on for now...
18:03:15 <nirik> yep.
18:03:32 <nirik> shall we do the schedule at the end? or now?
18:03:41 * jreznik_n9 already started talking to docs/marketing
18:03:54 <t8m> jwb, +1 jreznik wanted to write up the things afaik but I suppose he is now quite overwhelmed with the features and
18:04:10 <jwb> sure.  understandable.
18:04:14 <nirik> #topic #966 Fedora 19 Schedule proposal (DRAFT!)
18:04:14 <nirik> .fesco 966
18:04:14 <nirik> https://fedorahosted.org/fesco/ticket/966
18:04:15 <zodbot> nirik: #966 (Fedora 19 Schedule proposal (DRAFT!)) – FESCo - https://fedorahosted.org/fesco/ticket/966
18:04:22 <jreznik_n9> t8m, and travelling, sorry
18:04:34 <pjones> I think maybe we should do this one at the end?  even though we'll all be exhausted by then.
18:04:36 <nirik> so, we could defer this more until after features, but I think we have a good idea of the load...
18:04:43 <nirik> yeah, I'm ok with either way.
18:04:51 <jwb> i don't really think any of the features we're going to talk about are going to change it much
18:05:00 <jreznik_n9> yep
18:05:01 <jwb> unless we decided to switch DEs or something
18:05:03 <mitr> The mass rebuild has already been scheduled, so we probably have a good enough idea
18:05:44 <nirik> so, I'm fine with the proposed schedule for f19... but it leaves one big question/issue... what do we do about f20?
18:05:53 <jwb> ignore it
18:05:56 <notting> jwb: did spaleta get his OpenCDE feature in?
18:06:19 <jwb> notting, no... be we're talking about Cinnamon and Gnome3 today, so still a possibility
18:06:24 <mattdm> The cloud images feature (next up on the agenda?) asks for an update of koji. I talked to Jay this morning and he says we can likely get the integration accomplished to meet the draft schedule, one more week before alpha freeze would be nice.
18:06:52 <t8m> I think f20 is not so big problem - do we really have to stick with the releases in mid summer and mid winter?
18:07:00 <mitr> jwb: Cinnamon brings in all of 3 new packages (at least per (yum groupinfo cinnamon-desktop), I don't think there would be that much impact.
18:07:06 <jwb> nirik, i think f20 schedule is going to evolve from f20 feature/planning process anyway
18:07:32 <jreznik_n9> and we could end with different model for f20...
18:07:39 <t8m> jreznik_n9, +1 even that
18:07:46 <nirik> jwb: well, perhaps, but it leaves it in a nasty place. 6 months from f19 would be december, and nov/dec are nasty for releases due to holidays.
18:07:52 <jwb> mitr, firstly, was a joke.  secondly, i don't care if it brings in 0 new packages.  the proposal is to make it the default desktop
18:07:56 <mitr> jreznik_n9: Actually having a smaller release only to smooth out the new model might be a good idea
18:08:21 <nirik> so, perhaps a tenative f19.1 or 20 for early nov would be possible.
18:08:24 <notting> i wouldn't worry about f20 much now
18:08:40 <jwb> i don't think we have the time, information, or energy to talk about f20 today
18:08:46 <nirik> alright.
18:08:47 <jwb> we can deal with it next week
18:08:53 <nirik> so, votes? or counterproposals?
18:08:55 <jwb> or later, when we have more info
18:09:19 <notting> mattdm: if they want another week before alpha... shift everything in that schedule out a week
18:09:29 <sgallagh> nirik: As mattdm said, the cloud images feature wants another week before alpha
18:09:41 <mattdm> notting: yes.
18:09:58 <nirik> jreznik_n9: what do you think about pushing out a week before alpha?
18:10:12 <t8m> +1 to the proposed schedule but I am not against the 1 week shift either
18:10:24 <mitr> I can't see branching one week earlier making much of a difference for stabilization - (and if anything, branching later would decrease the theoretical desire to work on rawhide instead of the branch), but I don't really mind it.
18:10:36 * nirik votes the same as t8m.
18:10:45 <notting> i'm +1 to the shifted-one-week schedule
18:10:45 <jreznik_n9> one week plus is ok for me, more pressure on f20 but it's only a week
18:10:48 <mitr> [that's WRT comment #21, not the cloud feature]
18:10:51 <mmaslano> +1 to proposed schedule
18:10:53 <sgallagh> I'm slightly in favor of the shifted schedule
18:11:04 <pjones> notting: shifted farther out?
18:11:10 <sgallagh> yes, sorry. +1 week
18:11:12 <notting> pjones: yeah
18:11:32 <mitr> mattdm: what would have to be dropped from the cloud feature if koji weren't done?
18:11:33 <jreznik_n9> so 25th ga
18:11:35 <notting> actually, i'd love to hear from the anaconda people - how do they feel about this schedule for their f19 UI completers?
18:11:35 <nirik> mmaslano: you ok with the +1 week?
18:11:38 <pjones> yeah, I could be +1 to that.  I still think we need to take a broader look at what the things on the schedule really mean, but it's basically what we should be shooting for.
18:11:41 <mmaslano> nirik: yeah
18:11:57 <sgallagh> notting: Should we pull in dcantrell
18:11:58 <sgallagh> ?
18:12:06 <mattdm> mitr: well, if we can't build the images in koji at alpha time, it brings up a semantic argument about what "testable at alpha" means.
18:12:13 <pjones> notting: I suspect that's going to depend entirely on what we decide "alpha blocker" means this time around
18:12:17 <notting> sgallagh: dcantrell or clumens. unless pjones wants to speak for the team
18:12:23 <mitr> mattdm: IOW, koji is an absolute prerequisite?
18:12:42 <pjones> notting: I'm not very involved in that feature, so probably best to get one of them
18:12:44 <mattdm> well, the feature is basically *about* a koji update.
18:12:54 <nirik> mitr: well, if we make them outside koji in alpha and inside after we really didn't test them in alpha as they are delivered after right?
18:13:07 <mattdm> so parts of it can be tested individually without actually updating the production koji
18:13:10 <notting> pjones: fair enough
18:13:17 <mattdm> but it'd be really best to have it there by alpha
18:13:19 <mitr> nirik: hm, I see the problem
18:13:20 <abadger1999> what about a counterproposal of: Lengthen development time for both f19 and f20 to put f20 release in May
18:13:33 <sgallagh> mattdm: Except that we wouldn't then have "official" alpha images.
18:13:35 <pjones> abadger1999: boooo
18:13:40 <abadger1999> pjones: :-)
18:13:50 <pjones> abadger1999: we shouldn't be deciding when F20 is going to land when we don't know what we're going to want to be in F20.
18:13:51 <mattdm> sgallagh: right, also. That would be not nearly as nice.
18:14:00 <nirik> abadger1999: I think may is too soon/short for the number and size of features we have
18:14:06 <sgallagh> Proposal: Adjust the proposed schedule out one week to accommodate the cloud image Feature.
18:14:12 <pjones> abadger1999: I'm all for a longer schedule, but I think that's some irresponsible reasoning
18:14:22 <abadger1999> pjones: except... we do know we don't want to be anywhere close to December
18:14:22 <nirik> oh, f20
18:14:25 * nirik re-reads
18:14:43 * nirik doesn't understand
18:14:57 <pjones> abadger1999: true, but still - let's talk about F19 right now since we know about F19 right now, and talk about F20 when we know about it.
18:15:13 <sgallagh> nirik: He's calling for an 11-month F20 schedule. I don't think we should discuss this now
18:15:40 <nirik> ah, ok.
18:15:51 <abadger1999> sgallagh: who is he? /me missed context
18:16:01 <drago01> abadger1999: you
18:16:02 <sgallagh> abadger1999: he == you
18:16:11 <nirik> well, we have +6 I think on the +1 week schedule... unless we wish to get more feedback before approving.
18:16:18 <abadger1999> sgallagh: that's not my proposal then :-)
18:16:20 <jwb> nirik, +1 from me
18:16:20 <notting> paging the anaconda people
18:16:30 <notting> erm, "we are paging ..."
18:16:31 <nirik> abadger1999: can you repeat your proposal? I didn't grok it.
18:16:39 <sgallagh> abadger1999: Then I can't parse "put f20 release in May" in any other way
18:16:48 <pjones> sgallagh: no, he's saying to lengthen both, so he's talking about a 7.5month schedule for each, roundabout.
18:16:52 <sgallagh> ahh
18:16:56 * jreznik_n9 is back
18:16:56 <abadger1999> Right, what pjones said.
18:16:57 <sgallagh> mea culpa
18:17:22 <pjones> which I'm obviously all for on general principle, but I don't think we should be talking about F20 right now with no idea what's going in the box.
18:17:30 <pjones> clumens: so here's the proposed schedule: https://fedorahosted.org/fesco/ticket/966
18:17:43 <mitr> pjones: I don't think the F19 way of "features first, then schedule" is ideal (and we heard QA having problems with it ad FUDCon)
18:17:44 <clumens> let me review what we said we were going to do
18:17:54 <pjones> mitr: no, but the other way was abysmal failure
18:18:01 <abadger1999> clumens: Comment 21: https://fedorahosted.org/fesco/ticket/966#comment:21
18:18:05 <pjones> mitr: so if we're comparing "totally fucked the dog" with "not ideal"...
18:18:13 <notting> poor doggie
18:18:19 <gholms> >_<
18:18:27 <jreznik_n9> do it as early as possible - with f20 planning starting earlier
18:18:53 <mitr> pjones: My general view of F18 is that it shows underlying problems with the platform and possibly development process, rather than with the planning or scheduling process.  Of course that's open to strong disagreement.
18:18:59 <jreznik_n9> but we really have to sort out f19 today, guys getting nervous
18:19:02 <nirik> sadly, open source projects are pretty horrible about year ahead+ planning.
18:19:05 <pjones> clumens: so anyway, the question is: are we screwing people working on the UI rewrite if we go with a schedule like that?
18:19:20 <jwb> someone ping me when we're talking about something that we can actual do something about.  like f19.
18:19:38 <t8m> jwb, +1
18:19:39 * gholms rings the 15 minute bell
18:19:49 * nirik waits for input from anaconda team folks
18:19:55 <jreznik_n9> mitr, +1
18:20:10 <clumens> pjones: reviewing our feature, it looks like the only schedule drivers there are:  advanced storage, new firstboot whatever, and perhaps fleshing out text mode.
18:20:14 <clumens> the other stuff's just minor
18:20:15 <drago01> mitr: imho that was (very) bad planning
18:20:34 <pjones> drago01: yeah, I think mitr knows I strongly disagree with the statement already :)
18:20:37 <nirik> clumens: additionally we are talking about adding a week before alpha
18:21:15 <drago01> pjones: ;)
18:22:00 <kalev> I would very much like to see F20 get back on track with the schedule, so that it's in sync with most upstream projects that release twice a year, like GNOME
18:22:16 <kalev> F19 is already releasing 3 (!) months after GNOME 3.8, which is pretty bad
18:22:37 <clumens> looking at the proposed schedule, my feeling is that the feature complete deadline is probably fine but the alpha deadline seems to be pushing it, given that our work on finishing up advanced storage and new firstboot will then have to compete with the inevitable flood of "this is gonna be an alpha blocker!"
18:22:44 <nirik> http://paste.fedoraproject.org/2622/
18:22:57 <pjones> kalev: I've heard that argument before, and I still don't see how it's really true that that's awful
18:23:04 <nirik> clumens: see above paste. any better?
18:23:30 <nirik> did I add a week corrected there for everyone? please check. ;)
18:23:30 <pjones> clumens: that jives with what I thought, which was roughly: it depends on what we decide "alpha blocker" means this time
18:23:40 <sgallagh> kalev: So in other words, we'll end up with 3.8.1 with some of the bugs hammered out?
18:24:00 <kalev> pjones: We are losing people who want to use new GNOME. Other prominent distros release earlier with GNOME 3.8 and we lose upstream developer base because of that.
18:24:07 <clumens> mitr: the alpha coming in april is definitely better than it coming in march
18:24:15 <clumens> err, nirik
18:24:22 <pjones> kalev: all the data spot has says the people we're losing aren't going because they want new gnome.
18:24:26 <kalev> sgallagh: GNOME 3.8.1 is Apr 17.
18:24:53 <clumens> pjones: right, and hopefully this time blockers will be greatly reduced because we won't be mucking with the fundamentals
18:24:59 <nirik> proposal: https://fedorahosted.org/fesco/ticket/966#comment:22
18:25:06 <sgallagh> kalev: Great, so that will make Beta
18:25:22 <nirik> kalev: I understand your concerns, there's not much we can do about it in f19... there's 0 way we are going to be able to release in april.
18:25:26 <sgallagh> kalev: Not to start a flame war, but what other prominent distro ships GNOME?
18:25:54 <kalev> sgallagh: Ubuntu?
18:26:05 <clumens> anyway, i can definitely live with the amended schedule.  we've not planned anything that's nearly as drastic in scope in last time.  it's largely just tweaks.
18:26:08 <clumens> some of which are already done
18:26:13 <t8m> nirik, +1
18:26:38 * jreznik_n9_ is trying to open proposal, net sucks on highway even in Netherlands
18:26:41 <sgallagh> kalev: Ah, I missed the memo that they were shipping a GNOME respin. Ok, fair point.
18:26:46 <drago01> nirik: he said f20 though
18:26:48 <notting> clumens: great
18:26:53 <notting> i'm +1 to the amended schedule, then
18:26:53 * nirik is +1 to his own proposal
18:26:54 <pjones> nirik: alright, I can be +1 to that
18:26:58 <kalev> nirik: Yeah, I wasn't arguing about f19, too late for that, let's just get back on track with f20.
18:27:01 <abadger1999> nirik: +1
18:27:11 <mmaslano> +1 to nirik's proposal
18:27:12 <mitr> OK, given 2 owners of fairly prominent features preferring the later schedule, and no strong driver not to, +1 to the amended schedule
18:27:16 <nirik> kalev: ok, understood.
18:27:21 <jreznik_n9_> nirik, could you paste it here
18:27:21 <sgallagh> nirik: -1. I'd prefer the one week addon.
18:27:29 <nirik> sure.
18:27:42 <nirik> sgallagh: that _is_ the one week addon, unless I messed up something.
18:27:50 <sgallagh> nirik: Sorry, I was misreading Trac
18:27:51 <t8m> sgallagh, but nirik's schedule is with the one week add on
18:28:06 <nirik> sure, paste coming for jreznik_n9_:
18:28:09 <sgallagh> nirik: It's kind of stupid that "comment: 22" looks like it belongs to the above comment.
18:28:09 <nirik> 2013-04-02 Alpha Change Deadline/Software?? String Freeze
18:28:09 <nirik> 2013-04-16 Alpha Public Availability
18:28:09 <nirik> 2013-05-07 Features 100% Complete Deadline / Beta Change Deadline
18:28:09 <nirik> 2013-05-21 Beta Release Public Availability
18:28:09 <nirik> 2013-06-10 Final Change Deadline
18:28:10 <nirik> 2013-06-25 Final (GA) release
18:28:16 <nirik> yeah, thanks trac. ;)
18:28:19 <sgallagh> nirik: I am +1
18:28:57 <nirik> thats +7?
18:29:16 * abadger1999 anticipates a July 4th release :-)
18:29:36 <nirik> #agreed schedule as in https://fedorahosted.org/fesco/ticket/966#comment:22
18:29:49 <sgallagh> abadger1999: Yay! Fireworks at the release parties :-D
18:30:04 <pjones> the downside of that schedule is, as usual, that slippage means we're in a holiday weekend
18:30:19 <nirik> yeah, typical. ok, moving on then?
18:30:21 <notting> abadger1999: katy perry for everyone? oh wait, horrible idea
18:30:25 * jreznik_n9_ is back again, sorry
18:30:26 <clumens> at least it's not a holiday week?
18:30:29 <nirik> #topic #1008 F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages
18:30:29 <nirik> .fesco 1008
18:30:29 <nirik> https://fedorahosted.org/fesco/ticket/1008
18:30:31 <zodbot> nirik: #1008 (F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages) – FESCo - https://fedorahosted.org/fesco/ticket/1008
18:30:32 <abadger1999> and US only :-)
18:30:53 <nirik> ok, I'm +1 for this. Not sure it will all happen, but I'm happy for mattdm to try.
18:31:02 <mmaslano> +1
18:31:04 <mattdm> thanks :)
18:31:30 <nirik> dgilmore isn't opposed either, just notes that it's lots of work and he may not have time to do it.
18:31:35 <notting> i'm +1
18:31:44 <jgreguske> nirik: I'll volunteer the help if he needs it
18:31:52 <nirik> cool
18:32:09 <t8m> +1
18:32:19 <sgallagh> +1
18:32:49 <pjones> +1
18:32:56 <jwb> +1
18:33:01 <mitr> +1 in the sense that "I don't have any objections to the feature", not "I really really want to rel-eng do this even if they feel they can't"
18:33:11 <mitr> s/feel/felt/
18:33:20 <pjones> mitr: likewise
18:33:28 <nirik> abadger1999: ?
18:33:34 <abadger1999> +1 to shoot for doing it.
18:33:43 <nirik> #agreed Feature is approved (+9, 0, 0)
18:33:51 <nirik> #topic #1076 2013-02-06 meeting feature voting
18:33:51 <nirik> .fesco 1076
18:33:51 <nirik> https://fedorahosted.org/fesco/ticket/1076
18:33:53 <zodbot> nirik: #1076 (2013-02-06 meeting feature voting) – FESCo - https://fedorahosted.org/fesco/ticket/1076
18:34:04 <abadger1999> may vote to do a contingency plan later in the cycle.
18:34:11 <nirik> ok, could everyone look at my list at the end of this ticket and see if there's any feature you want to discuss I missed?
18:34:21 <mattdm> hurrah
18:34:34 <nirik> I can ask again at the end to make sure we didn't miss any...
18:34:52 <nirik> There were a few where people had questions, but said it wouldn't cause them to vote differently.
18:35:11 <pjones> nirik: that's... the list of ones we'll talk about?
18:35:21 <nirik> notting: did your cups questions get answered? or would you prefer to discuss here.
18:35:34 <mitr> nirik: As the one who brought up firewalld lockdown - perhaps we can just skip it if noone else wants to discuss it
18:35:36 <nirik> There was also some anaconda newui question that I updated the ticket with
18:35:44 <mitr> nirik: whatever is easiest
18:35:56 <notting> nirik: it got answered - i had wondered if "no browsing" qualified for enacting the contingency plan
18:35:58 <nirik> pjones: at the end yeah, 18 of them. ;)
18:36:02 <notting> nirik: so i'm ok with it
18:36:07 <nirik> notting: so, we drop cups from discussion?
18:36:12 <notting> nirik: sure, fine with me
18:36:19 <nirik> ok.
18:36:24 <abadger1999> For next time: It would be nice to see a list of features we don't want to discuss (easier to remember that you want to pull something off that list than whether you want to add something to the discussion list)
18:36:39 <t8m> abadger1999, +1
18:36:39 <nirik> abadger1999: yeah, sorry.
18:37:14 <nirik> ok then, shall we start the marathon?
18:37:33 <nirik> #topic #1035 F19 Feature: Dracut HostOnly - https://fedoraproject.org/wiki/Features/DracutHostOnly
18:37:33 <nirik> .fesco 1035
18:37:33 <nirik> https://fedorahosted.org/fesco/ticket/1035
18:37:35 <zodbot> nirik: #1035 (F19 Feature: Dracut HostOnly - https://fedoraproject.org/wiki/Features/DracutHostOnly) – FESCo - https://fedorahosted.org/fesco/ticket/1035
18:37:55 <nirik> haraldh: you happen to be around? ;)
18:38:06 <t8m> I really don't like this even if it is just returning back to situation we had before
18:38:17 <haraldh> nirik, yep
18:38:25 <mitr> I think it's fine and beneficial to have this feature; having it enabled by default is not a good tradeoff.
18:38:29 <notting> i'm ok with it. RHEL 5 compatibility!
18:38:29 <sgallagh> As noted on the list, I don't like sacrificing stability for speed, especially when the latter hasn't been benchmarked.
18:38:43 <sgallagh> notting: I thought we were against bug-for-bug compatibility?
18:38:51 <t8m> sgallagh, :)
18:39:10 <pjones> this one I'm a little worried about - couple of issues.
18:39:32 <nirik> haraldh: I also had some questions about the rescue mode (which seems more interesting to me here) posted to the list the other day if you get a chance to look.
18:39:38 <haraldh> hah: so when I introduced the generic image, everyone was concerned about size :-)
18:39:45 <mitr> sgallagh: Chris Murphy did soime tests - ~1 second speedup on SSD, 4 seconds on rotating
18:39:47 <haraldh> can't make it right, it seems
18:40:12 <sgallagh> mitr: Ok, and that's considered significant because...?
18:40:19 <pjones> haraldh: no, I like the idea, but there are some implementation details I'm worried aren't scoped out
18:40:20 <mitr> sgallagh: I'm not saying it is.
18:40:21 <t8m> mitr, which to me seems very well not worth it
18:40:46 <drago01> sgallagh: 1 second would be ~17% here ;)
18:41:13 <pjones> mitr: it saves a lot of size on /boot, which is a problem we've been having
18:41:22 <haraldh> nirik, well, it's not the same as the rescue mode, but we could install such a script also
18:41:28 <sgallagh> drago01: Sure, but in the grand scheme of things, 1-4s is *nothing* at boot time.
18:41:40 <nirik> haraldh: is there any docs on what it is/can do?
18:41:43 <pjones> sgallagh: uh, what are you on?
18:42:01 <jwb> pjones, IBM pSeries H server apparently
18:42:12 <notting> jwb: if so, my deepest sympathies
18:42:13 <t8m> pjones, does it really with the rescue mode?
18:42:21 <mitr> pjones: even with the larger default /boot size?
18:42:23 <sgallagh> pjones: Sorry, allow me to rephrase.
18:42:29 <jwb> notting, high on the list of things i do not miss
18:42:43 <haraldh> nirik, well, I haven't thought the rescue mode through, but you will have more debug tools and of course all fsck tools
18:42:49 <drago01> sgallagh: well in a a perfect world boot time should be near zero ... so I welcome any change that gets us near that goal
18:42:50 <pjones> mitr: we still have plenty of upgraded machines to think of, where right now they're doing tricks like lowering the number of kernels installed to make it work
18:42:51 <sgallagh> pjones: It's a small speed-up on a *very* rare operation. I'm not opposed to it being possible to enable this for systems that need fast recovery.
18:42:52 <nirik> haraldh: network? ssh?
18:42:55 <haraldh> nirik, yep
18:42:58 <sgallagh> But it should *not* be default operation.
18:43:10 <pjones> sgallagh: that's some ideal world awesomeness you're dreaming of there
18:43:14 <haraldh> nirik, we can install all we want in it
18:43:42 <haraldh> nirik, of course only what is installed on the system :)
18:43:47 <nirik> haraldh: well, in that case it might be nice to talk to anaconda folks and see if it could replace the rescue mode there or use that one, so we don't have two different ones. ;)
18:44:01 <sgallagh> pjones: I've always stuck with the policy of "do things correctly first, fast later"
18:44:18 <t8m> drago01, in a perfect world you don't have to boot
18:44:22 <pjones> sgallagh: correctly is still "we don't need everything to be generic most of the time"
18:44:30 <mitr> In that case we can also expect the rescue image to become closer in size to the netinst image, which is ~300 MB?
18:44:31 <notting> t8m: well, we can fix anaconda to ensure that happens. wait.
18:44:42 <drago01> heh
18:44:59 <pjones> t8m: notting: reminds me of what the statisticians have said: 93% of people die.
18:45:01 <nirik> mitr: I guess it depends on how we merge the two things...
18:45:14 <notting> the need for the rescue image, or the non-host specific image, is for the case when you move the disk or disk image to disparate hardware. i don't think that's the case that needs optimizing for out of the box
18:45:26 <mitr> nirik: Sure, anaconda contains more than the rescue image.  But as a rough guideline we must be talking about a ~100 MB image, which would negate all of the space savings
18:45:48 <pjones> haraldh: nevertheless, what I actually wanted to discuss is that I don't think it's anaconda that should be creating that image
18:45:53 <drago01> notting: now that almost all of the (desktop/laptop) uses ahci and it is built in
18:46:00 <drago01> notting: that does not matter much in practice
18:46:01 <nirik> mitr: well, possibly, I'm not sure all thats in rescue mode. I only ever use it to start net/mount install/give me a shell...
18:46:05 <drago01> i.e just works
18:46:15 <pjones> haraldh: probably the right thing to do is a) make an easy way to test if one exists, and if not, b) make kernel's .spec create it instead of some other one.
18:46:37 <pjones> haraldh: so the first time you install, we create a generic image, and after that we create host-only
18:46:41 <haraldh> pjones, right
18:46:47 <nirik> mitr: if anaconda switches to just calling/booting the dracut one, it could be much smaller.
18:46:49 <haraldh> pjones, no objections
18:46:52 <pjones> okay.
18:47:05 <notting> pjones: meh. can't we just make a rescue dracut module, add that to anaconda's stage 2, and have it copy it over on installation?
18:47:07 <mitr> nirik: you mean anaconda could be much smaller, right?
18:47:43 <nirik> mitr: yeah, since it wouldn't need to carry that extra path/code...
18:48:05 <jwb> pjones, i think you mean "grubby" when you say kernel.spec
18:48:05 <mitr> nirik: I was thinking about the size of things put in /boot, since pjones brought that up as a limitation
18:48:45 <nirik> mitr: I think a dracut rescue could also be not too big if it doesn't embed anaconda... but I don't have in front of me a spec for 'rescue mode' telling all that it needs to be/do.
18:49:02 <mitr> nirik: right, that's unclear
18:49:11 <haraldh> notting, also a possibility, _but_ if the anaconda image needs updates for tools, then these tools are not updated in the rescue image
18:49:13 <t8m> I'd say at least the rescue mode implementation should be clarified before the feature can be accepted. And/or the host only mode should not be default.
18:49:43 <mitr> So, to go back a bit, what is the primary benefit we expect here?  Faster boot?  Disk space?  Faster kernel update?   If it is faster boot exclusively, would it be too crazy to generate a two-part initrd, and teach the first part to load the second part if more drivers are necessary?
18:49:54 <mitr> [yes it might be too crazy because the fallback path wouldn't get tested]
18:50:12 <haraldh> notting, meaning: if the machine couldn't be installed without a anaconda update, the rescue image might also not work
18:50:44 <haraldh> 300MB? omg.. no, I was thinking in the range of < 50MB
18:51:06 <nirik> so, we are getting close to 15min here.
18:51:45 <nirik> anyone care to vote, propose changes to the feature or ask to defer?
18:51:53 <pjones> jwb: well, I'd assumed new-kernel-package would be being told, but it could go either way
18:51:56 <haraldh> mitr, good point with the fallback path not getting tested
18:52:02 <notting> i'm +1 to defaulting to hostonly as-is
18:52:15 <jwb> pjones, i would prefer it to go the grubby way
18:52:20 <pjones> jwb: sure whatever ;)
18:52:25 <nirik> I guess I am a weak +1, but I would like to see the rescue mode more sorted out. ;)
18:52:25 <jwb> please and thank you
18:52:30 <mitr> I'm -1 to making this default
18:52:39 <t8m> I am -1 in the current form of the feature
18:53:05 <haraldh> t8m, what needs tweaking?
18:53:08 <nirik> +2/-2
18:53:09 <pjones> notting: I strongly object to doing this outside of packaging
18:53:21 <t8m> haraldh, the rescue mode should be clarified and it should not be default
18:53:23 <sgallagh> -1 to making it default, +1 to making it optional/configurable
18:53:30 <t8m> it = host only
18:53:41 <drago01> sgallagh: it already is configureable
18:53:42 <mmaslano> -1 to default
18:53:48 <nirik> +2/-4
18:53:53 <drago01> sgallagh: edit dracut.conf and rebuild the initrd
18:54:00 <abadger1999> The legal objection was cleared correc?  (If I understood, that was only if an rpm package shipped a prebuilt initrd and we're going to be creating the rescue image with grubby on the user's system)
18:54:03 <sgallagh> drago01: Great, then it's easy to agree to :)
18:54:12 * pjones is +1 with the changes he,harald,and jwb just agreed on
18:54:17 <jwb> i'm a +1 i guess
18:54:23 <jwb> ooh.  a tie
18:54:25 <nirik> +4/-4
18:54:27 <jwb> who's the tie breaker?
18:54:28 <gholms> Heh
18:54:29 <drago01> sgallagh: the default case should be the fast not the "bloated" one
18:54:31 <nirik> abadger1999 is.
18:54:35 * abadger1999 hasn't voted yet.
18:54:41 <jwb> it's all up to you abadger1999
18:54:42 <abadger1999> I was going to vote +0 though ;-)
18:54:46 <pjones> abadger1999: I don't see any way there's a legal objection since we're building on a user's machine
18:54:47 <nirik> ha ha
18:54:49 <sgallagh> drago01: We'll agree to disagree on that point.
18:55:01 <abadger1999> pjones: <nod>  Just didn't see that wrapped up in the thread.
18:55:06 <nirik> do we need a vice president to come vote? ;)
18:55:25 <drago01> sgallagh: yeah not the right time / place for having this discussion
18:55:29 <pjones> abadger1999: they've clearly got everything going into it already, so we're in gplv2 section 3a AFAICS
18:55:47 <haraldh> I mean, the admin can turn it off/on anyway
18:55:50 <abadger1999> T o those who voted -1, is there anything we could change to the implementation of the proposal to allow you to vote +1.
18:55:56 <pjones> (modulo the fact that we're probably in 3b/3c for the code that /made/ those things)
18:56:12 <t8m> abadger1999, I think if it was not default it would get enough votes
18:56:27 <nirik> it's already the case tho.
18:56:28 <abadger1999> <nod> -- but isn't that basically where we are now?
18:56:32 <pjones> yes.
18:56:36 <nirik> then the feature would be 'rescue mode' I guess?
18:56:56 <haraldh> yes, "rescue mode" is crucial, if you have it on
18:57:02 <haraldh> it = host-only
18:57:06 <pjones> nirik: as I see it now, it's "the first time we create a generic one, thereafter we create a hostonly"
18:57:06 <mitr> abadger1999: Well announcing the admin's possibility to speed this up can still be a feature.
18:57:07 * abadger1999 registers a weak +1
18:57:24 <notting> mitr: but that feature's been there for 6 releases or so
18:57:26 <pjones> haraldh: could we further amend it so that we don't retain the hostonly - we just build hostonly for the kernel that would replace it?
18:57:28 <pjones> er
18:57:30 <mitr> notting: hm
18:57:32 <pjones> s/hostonly/generic/
18:57:48 <nirik> #agreed Feature is approved, (+5, -4, 0)
18:57:54 <haraldh> pjones, rephrase please :)
18:58:04 <jwb> feature passed
18:58:34 <pjones> haraldh: so just make it rolling.  first install, we generate a generic initrd, then hostonly until the kernel that would cause the generic one to be removed.  when that happens, we generate a new hostonly for the new kernel.
18:58:39 <pjones> er
18:58:44 <pjones> dammit, generate a new generic one
18:58:50 <mitr> Actually - how about always building both?  That would cost us in space and upgrade time, but remove some reliability concerns.
18:58:50 <pjones> so we've always got 1 generic + n hostonlys
18:59:13 <nirik> mitr: then we use _more_ space in /boot
18:59:18 <mitr> nirik: yes
18:59:25 <pjones> mitr: that would probably blow the size limitation we've bumped users up to pretty badly
18:59:49 <nirik> anyhow, I would like to ask folks to work with haraldh on any changes in #fedora-devel...
18:59:53 <nirik> and we can move on. ;)
18:59:56 <pjones> right now with a 500MB /boot we're using ~350MB for 3 kernels.
18:59:56 <haraldh> ok
19:00:00 * abadger1999 likes pjones' tweak
19:00:21 <nirik> #topic #1036 F19 Feature: Enterprise / distributed two-factor authentication -  https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication
19:00:23 <nirik> .fesco 1036
19:00:23 <nirik> https://fedorahosted.org/fesco/ticket/1036
19:00:26 <zodbot> nirik: #1036 (F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication) – FESCo - https://fedorahosted.org/fesco/ticket/1036
19:00:44 <nirik> I don't like the name of this feature. ;)
19:01:03 <sgallagh> I dislike nearly everything about this, not least that the Feature owners aren't replying to queries.
19:01:24 <notting> man, FI's 2FA isn't enterprisey enough?
19:01:34 <mitr> sgallagh: Could you elaborate? AFAICS it's just an unfortunately-named "new package added" feature
19:02:05 <t8m> sgallagh, same question as mitr
19:02:18 <t8m> or they did not define the scope correctly
19:02:35 <sgallagh> Well, they're trying to add a new authentication system to Fedora without involving any of the existing auth folks in the process.
19:02:55 <sgallagh> They've ignored my emails asking for detail and potential involvement with the authhub project.
19:03:07 <mmaslano> so -1 for now?
19:03:28 <sgallagh> I'm pretty firmly -1 on this.
19:03:44 <notting> i'd be fine with it if it was redefined in terms of what it is (adding those two packages as an alternative 2FA solution), as opposed to how it's defined now
19:03:58 * nirik nods.
19:03:59 <sgallagh> I don't care if they add the packages, but I don't want us advertising untested auth stuff
19:04:19 <t8m> notting, +1
19:04:32 <mitr> sgallagh: well it's an OpenID web service and a PAM module... not that much of an authentication system
19:04:45 <nirik> so, yeah, I'm -1 now, if they rescope, rename and start working with everyone we can revisit. ;)
19:05:03 <pjones> notting: yeah, I think the problem here is mostly descriptive, and they could rephrase it and I'd be for it.
19:05:15 <t8m> -1 same as nirik
19:05:18 <mitr> Proposal: Defer for renamed feature that addresses the above
19:05:22 <sgallagh> nirik: Are we proposing to allow them to resubmit after Feature Submission Freeze?
19:05:36 <mitr> (deferring both gives a chance to redeem, and auto-rejects the feature if the owner is really nonresponsive)
19:05:43 <notting> well, they can retitle, or we can arbitrarily retitle it for them
19:05:51 <nirik> sure, I'm fine with defering...
19:05:51 <notting> but i'd be +1 to mitr's proposal too
19:05:59 <pjones> sgallagh: we're not considering it "unsubmitted", I think.
19:06:07 <nirik> sgallagh: I'd say sure, since I don't really see this having any impact on anything.
19:06:34 <nirik> but sure, +1 defer and ask feature owners to address issues.
19:06:47 <abadger1999> +1 defer
19:06:49 <sgallagh> DItto:  +1 defer and ask feature owners to address issues.
19:06:55 <jwb> sure
19:07:14 <mmaslano> +1 defer
19:07:40 <t8m> +1
19:07:44 <t8m> (to defer)
19:08:08 <nirik> pjones: ?
19:08:36 <pjones> I'm +1 to deferring, as I said above.
19:08:40 <nirik> #agreed Feature is defered. Feature owners are asked to address concerns. (+9, 0, 0)
19:08:45 <nirik> ok, moving on
19:08:49 <nirik> #topic #1038 F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice
19:08:50 <nirik> .fesco 1038
19:08:50 <nirik> https://fedorahosted.org/fesco/ticket/1038
19:08:52 <zodbot> nirik: #1038 (F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice) – FESCo - https://fedorahosted.org/fesco/ticket/1038
19:08:55 <pescetti> [Andrea Pescetti, feature owner, here if needed]
19:09:08 <pescetti> ...and if it helps, sgallagh's proposal in https://fedorahosted.org/fesco/ticket/1076 would be perfectly OK, the feature proposal does not ask for anything else.
19:09:42 <t8m> My only concern is with the size impact on mirrors.
19:09:43 <nirik> pescetti: welcome. Thanks for stopping by.
19:09:53 <sgallagh> Proposal (from the ticket): make sure that they can coexist and let them maintain it if they want  to. Make no modification at this time to the defaults on Live media.
19:10:00 * nirik is fine with the feature, but we need to sort out soffice/etc.
19:10:23 <mitr> We may need to sort out 1) soffice 2) unopkg 3) swriter 4) oowriter
19:10:28 <t8m> (and of course Libreoffice should be still preferred as default which implicates it keeps the soffice, ooffice binaries)
19:10:40 <drago01> mitr:  oocalc ? ooimpress? ...
19:10:47 <pjones> my biggest concern here really is doubling the size of updates.
19:10:55 <mitr> 1) and 2) are pretty obviously used in all.  3) is the documented executable name, which is nevertheless not provided, with 4) being considered as "a linux-only modification" in an OOo wiki
19:11:04 <nirik> I think the size argument seems odd here.
19:11:05 <mitr> drago01: taking 3) and 4) as a class of names
19:11:23 <pjones> it might actually be worth just having them /conflict/, in terms of sorting out all the program names.  it's that or alternatives, probably?
19:11:28 <nirik> we ship all kinds of crazy big things.
19:11:41 <sgallagh> pjones: If at all possible, I'd rather they not conflict in the long-term.
19:11:47 <abadger1999> pjones: Using Conflicts in this case would be contrary to packaging guidelines
19:11:52 <notting> in the sense of 'allowing people to tilt at their own windmills', i'm ok with it, but i'm disinclined to be required to change the LO packaging just because someone wants to tilt at this one
19:11:53 <drago01> pjones: alternatives is kind of weird for gui apps imo
19:11:54 <sgallagh> I can potentially see a lab environment where students might want a choice.
19:11:55 <t8m> sgallagh, +1
19:12:01 <abadger1999> because systems may very well want both of these installed.
19:12:03 <mitr> As long as AOO isn't installed by default, I'm fine with alternatives
19:12:10 <abadger1999> (different than the mariadb vs mysql use case)
19:12:11 <pjones> drago01: yeah, doesn't work very well since desktop stuff ignores it
19:12:21 <jwb> notting, +1
19:12:25 <pjones> abadger1999: I continue to not care ;)  We get to ask FPC for things if we need to.
19:12:43 <mitr> sgallagh: I don't think there's a strong conflict in the GUI (menus etc), it's the path names and perhaps MIME priority
19:12:55 <mmaslano> notting: I agree
19:13:13 <abadger1999> pjones: <nod>  But I don't think a case could be made that this is a worthwhile use of conflicts there.
19:13:14 <pjones> notting: yeah, that's a pretty good point.
19:13:15 <mitr> notting: I would be open to asking LO to set up alternatives (but without asking LO to give up any of the interface paths)
19:13:16 <nirik> I hope we can work out the conflicting packages nicely
19:13:27 <sgallagh> mitr: MIME priority is generally a per-user setting in the desktop env, so I'm not worried about that. Using alternatives for the main binaries is probably fine.
19:13:34 <mitr> sgallagh: right
19:13:41 <nirik> but I'm not sure fesco needs to do that... I hope LO and AOO people can do that. ;)
19:13:56 <pjones> mitr: well, I'd be content with telling pescetti to send the LO guys patches to set up alternatives without LO changing interface paths ;)
19:14:00 <mitr> (well we still need to get the MIME priority _by default_ to point to the preferred implementation)
19:14:12 <abadger1999> alternatives would be the wrong technology... if they want to explore using environment-modules, they could go that route though.
19:14:15 <mitr> pjones: fair point :)
19:14:34 <nirik> abadger1999: +1
19:14:35 <sgallagh> mitr: Yes, but as I proposed, for now let's leave the defaults at LO
19:15:06 * notting goes back to the mysql idea, of letting people have an AOO copr
19:15:09 <mitr> sgallagh: definitely  Is that even a question?
19:15:18 <t8m> pjones, +1
19:15:23 <sgallagh> mitr: Yes, a loaded one :)
19:15:43 <sgallagh> (more a straw-man)
19:15:48 <nirik> so, where are we?
19:15:53 <pescetti> The proposal does not (obviously) ask to alter defaults.
19:16:20 * nirik is +1 for the feature
19:16:30 <nirik> did anyone want to propose changes to the feature?
19:16:33 <mitr> Yeah, the proposal only mentions the conflict without resolving it currently.
19:16:39 <sgallagh> I'm inclined to stick with my original proposal and trust that these two communities can sort the details out.
19:16:41 <pjones> nirik: I think we've mostly agreed that LO-by-default is fine, alternatives is reasonable, and we're okay with it as long as it's obvious which is which in the gui so you don't accidentally mix and match apps?
19:16:44 <mitr> So a mere "+1" is ambiguous
19:16:52 <nirik> pjones: I'm -1 on alternatives.
19:16:58 <pjones> nirik: oh, why?
19:17:13 * pjones scans back but doesn't see...
19:17:17 <t8m> +1 with the conflict resolved somehow (I would not allow the conflict to stay explicit)
19:17:20 <nirik> because thats a per machine default. Not a per user one.
19:17:32 <pjones> o_O
19:17:43 <sgallagh> nirik: Sure, but desktop files can point at the real binary, rather than the alternatives representation
19:17:45 <pjones> surely most machines that run *OO at all are single-user machines.
19:17:50 <mitr> nirik: Given our clear preference for LO, I'm not inclined to spend too much time on enabling admins of multi-user systems to give users choice
19:18:00 <mmaslano> +1 but solve the conflict before and prefer LO
19:18:01 <pjones> right, the desktop files won't care.  alternatives is *just* for people running it on the command line.
19:18:12 <sgallagh> And if we're sticking with making the GUI selection obvious, users can choose the correct one for their needs that way.
19:18:13 <nirik> mitr: right, so I would prefer a solution to the conflicts that does not involve alternatives.
19:18:20 <mitr> pjones: *OO might be one of the more frequent cases where a Linux system is provided to a larger class of users in a computer lab
19:18:25 <t8m> nirik, +1
19:18:29 <pjones> mitr: true
19:18:41 <pjones> mitr: but those are still mostly invoking from desktop, I wold think
19:18:52 <mitr> pjones: yes
19:19:01 <pjones> mitr: also those are situations where the institution running the machine has picked one or the other and not installed both
19:19:11 <nirik> I'm happy approving the feature but would ask feature owner to work it out with LO maintainers, if some agreement cannot be reached, bring that conflict back to us. ;)
19:19:19 <t8m> which means that if AOO just use binaries like aoofice aoowriter etc. would be fine
19:19:28 <pjones> mitr: because those are "we support this one only for our users" cases
19:19:42 <sgallagh> pjones: Most likely, but not guaranteed. I remember my college labs having both StarOffice, MSOffice (in WINE) and one other installed.
19:19:42 <pescetti> nirik: Definitely available, (firendly) discussion already started.
19:19:48 <pjones> yeah, alternatives isn't necessary, just kind of nice.  just making them take different file names is fine
19:19:51 <abadger1999> Proposal: Feature is accepted under the condition that the conflicts must be worked out. openoffice and libreoffice packagers get to work them out.  There is no fesco mandate that libreoffice must change to accomodate openoffice at this time.  alternatives is not the way to resolve the conflicts but environment-modules may be looked at as a similar means to achieve that.
19:19:57 <nirik> there could be cases where someone love librecalc, but prefers aoowriter. ;)
19:20:12 <nirik> abadger1999: +1
19:20:16 <notting> nirik: dooon't care .... (about that case)
19:20:32 <pjones> nirik: awfully hard to care about that.  that person knows how to run whichever they want on purpose.
19:20:35 <nirik> pescetti: excellent. :)
19:20:36 <mitr> abadger1999: I don't care about the last sentence but +1
19:20:41 <pjones> abadger1999: yeah, +1
19:20:42 <abadger1999> +1
19:20:47 <sgallagh> abadger1999: I'm +1 to that proposal
19:20:51 <jwb> abadger1999, +1
19:20:57 <notting> abadger1999: i could be +1 to that. i'd be fine with Conflicts: if it came to that, so... *shrug*
19:21:26 <nirik> thats +7?
19:21:30 <mitr> Let's support doing things right even in cases where it doesn't matter :)
19:21:40 <nirik> t8m / mmaslano ?
19:21:42 <abadger1999> notting: I guess we can revisit that if the LO and OO packagers can't work out a compromise.
19:21:48 <mmaslano> I said +1
19:21:55 <nirik> oh, sorry.
19:21:56 <t8m> +1
19:22:01 * nirik looks back to see who he missed.
19:22:08 <t8m> (I actuall said it as well)
19:22:29 <nirik> #agreed Feature is accepted under the condition that the conflicts must be worked out. openoffice and libreoffice packagers get to work them out.  There is no fesco mandate that libreoffice must change to accomodate openoffice at this time.  alternatives is not the way to resolve the conflicts but environment-modules may be looked at as a similar means to achieve that. (+9, 0, 0)
19:22:37 <nirik> #topic #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown .fesco 1040
19:22:37 <nirik> https://fedorahosted.org/fesco/ticket/1040
19:22:48 <nirik> mitr: you had questions here?
19:23:01 <nirik> .fesco 1040
19:23:04 <zodbot> nirik: #1040 (F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown) – FESCo - https://fedorahosted.org/fesco/ticket/1040
19:23:17 <mitr> The devel discussion today arrived at a point where it is, at least to me, completely unclear what the feature does
19:23:27 <mitr> But it doesn't impact the release overall and it's off by default, so I can be +1 anyway :)
19:23:47 <nirik> I htink the lockdown applies to dbus sending apps
19:23:51 <notting> my understanding is that it locks local *applications* from changing the firewall (not users)
19:24:14 <notting> but i'm +1
19:24:16 <nirik> yeah, so system-config-printers couldn't tell it to open cups ports
19:24:19 <mitr> notting: We don't have "application" as a security concept at all
19:24:21 <nirik> for example
19:24:58 <mitr> There's nothing to reliably distinguish system-config-printer from firewall-cmd, it's just a D-Bus caller with a valid polkit authorization running in an users' session.
19:25:20 <t8m> mitr, +1
19:25:37 <nirik> yeah, it seems like it's the interface perhaps? or is it looking at names?
19:25:51 <mitr> Does anyone want to -1 or ask for deferral?
19:26:03 <mitr> If not, we can get this figured out on the mailing list later
19:26:18 <nirik> I guess I would like to defer now... given I am not clear how it acts.
19:26:41 <nirik> proposal: defer for now, ask feature owner for more details.
19:26:52 <sgallagh> Let's send it back to discussion and ask for the Feature page to add details.
19:27:05 <mmaslano> defer
19:27:07 <abadger1999> +1 defer
19:27:14 <mitr> OK, +1 defer
19:27:27 <sgallagh> +1 defer
19:27:28 <abadger1999> If we're confused, users who read the release notes will be confused too
19:27:36 <nirik> #agreed Feature is deferred for now, feature owner to provide more details.
19:27:39 <mitr> abadger1999: good point about the relnotes
19:27:49 <nirik> #topic #1042 F19 Feature: GNOME 3.8 - https://fedoraproject.org/wiki/Features/Gnome3.8
19:27:49 <nirik> .fesco 1042
19:27:49 <nirik> https://fedorahosted.org/fesco/ticket/1042
19:27:51 <zodbot> nirik: #1042 (F19 Feature: GNOME 3.8 - https://fedoraproject.org/wiki/Features/Gnome3.8) – FESCo - https://fedorahosted.org/fesco/ticket/1042
19:28:00 <nirik> This feature has no contingency plan.
19:28:05 <nirik> do we care?
19:28:05 * notting was -1 to defer. whatevs.
19:28:22 <mitr> Historically GNOME was never a problem, but, well, lessons learned from F18 and all
19:28:27 <nirik> or was it added.
19:28:40 <nirik> https://fedoraproject.org/wiki/Features/Gnome3.8#Contingency_Plan
19:28:54 <jwb> that's kind of laughable
19:29:00 <jwb> it's not a contingency plan
19:29:11 <jwb> it's basically saying "we'll ship whatever we wind up with"
19:29:16 <sgallagh> That reads as "If 3.8 isn't ready, ship it anyway"
19:29:22 <nirik> sure.
19:29:28 <jwb> anyway, i don't care.  i don't think we have a choice.  so +1
19:29:32 <nirik> given our schedule tho, I'm not too worried.
19:29:44 <notting> it's roughly the same as the KDE contingency plan
19:29:46 <drago01> nirik: was about to say the same
19:29:49 <t8m> except we always did that in regards to Gnome
19:29:55 <notting> i'm fine with it. +1
19:29:56 <mitr> GNOME 3.8 schedule puts release at Mar 27, we have a feature freeze in Apr 4, so good enough I suppose
19:29:57 <nirik> anyhow, +1 to the feature.
19:29:59 <pjones> since it'll land months before the beta even if it slips...
19:30:00 <pjones> +1
19:30:02 <abadger1999> Too big to fail? ;-)  [ /me agrees with nirik about schedule though]
19:30:12 <mitr> +1 to the feature
19:30:14 <sgallagh> Yeah, I'm fine with it. +1
19:30:15 <abadger1999> +1
19:30:18 <nirik> I'm not sure what kind of plan things like this could have...
19:30:20 <t8m> +1 whatever
19:30:27 <nirik> "Apply Epoch and ship previous version"?
19:30:31 <sgallagh> The GNOME guys always come through in the end.
19:31:09 <sgallagh> nirik: That wouldn't likely work anyway. GNOME 3 will likely pull along changes underneath it as well.
19:31:31 <abadger1999> Perhaps contingency plans on some things should be -- there can be no contingency plan for this, we either do it or don't.
19:31:52 <mitr> sgallagh: I very much hope that shipping older GNOME on top of newer base would be possible - but we really don't need to solve this now.
19:31:58 <pjones> abadger1999: that's what we said about anaconda.  of course we also said the schedule was insufficient.
19:32:02 <abadger1999> so we know if we'll need to watch it closely right from the start.
19:32:06 <mmaslano> +1 to the feature (who cares)
19:32:10 <nirik> #agreed Feature is approved (+9, 0, 0)
19:32:23 <nirik> #topic #1045 F19 Feature: Cinnamon as Default Desktop - https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop
19:32:23 <nirik> .fesco 1045
19:32:23 <nirik> https://fedorahosted.org/fesco/ticket/1045
19:32:25 <zodbot> nirik: #1045 (F19 Feature: Cinnamon as Default Desktop - https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop) – FESCo - https://fedorahosted.org/fesco/ticket/1045
19:32:33 <jwb> yeah... -1
19:32:48 <mmaslano> 0, why do we need default again?
19:32:51 * notting is -1
19:32:58 <abadger1999> I don't necessarily like how we do default desktop but I do not think this feature is the answer.
19:33:00 <abadger1999> -1
19:33:09 <pjones> strong -1
19:33:23 <pjones> (same as what abadger1999 said)
19:33:25 <nirik> so, for a variety of reasons, including: it's not got a track record, not enough maintainer resources, too much work to redo everything else, unclear advantages, unclear if it will be replaced by upstream gnome efforts, too quick to fork, etc. -1
19:33:30 <mitr> Given the Fedora discussions about expected RH-Fedora interaction, I want to go on record as being deeply unhappy with GNOME direction, and seeing similar feelings widespread among Fedora contributors
19:33:33 <t8m> same as abadger1999 -1
19:33:50 <mitr> However, the person proposing this feature doesn't own any of the packages, and the owner of them hasn't responded on the list, so -1
19:34:15 <sgallagh> -1, for basically all of the same reasons as mitr
19:34:17 <mmaslano> I guess he responded, but anyway I'm afraid they don't have enough manpower
19:34:19 <nirik> mmaslano: well, it's hard to present people with "what would you like to download? sakjhsdf [ ] sakjhdaywhgdad [ ] or akjsgsads [ ]
19:34:31 <mitr> nirik: "to redo everything else" - Cinnamon is just a wm and a file manager, it's really not that big a change AFAICS
19:34:34 <pjones> mitr: I think both of your comments there are fair, sure.
19:34:43 <nirik> mitr: all our docs, all our wiki pages, all our websites
19:34:48 <jwb> nirik, mmaslano, NOT GOING TO FIX THIS TODAY
19:34:53 <nirik> right.
19:35:21 <sgallagh> Now *KDE as Default* on the other hand... No, let's not discuss this now :)
19:35:29 <notting> to elaborate: i think we need a default, and asking the person downloading fedora to choose between 2/4/6 desktops is crazy. i think gnome is a good default, and i prefer gnome3 to gnome2, forks thereof, kde, etc. i think the "we should have a different default every release" proposal that came up is sheer crazypants. so, -1s all around
19:35:48 <nirik> #agreed Feature is declined. (0, 8, 1)
19:35:58 <nirik> #topic #1055 F19 Feature: New firstboot - https://fedoraproject.org/wiki/Features/NewFirstboot
19:35:58 <nirik> .fesco 1055
19:35:58 <nirik> https://fedorahosted.org/fesco/ticket/1055
19:36:00 <zodbot> nirik: #1055 (F19 Feature: New firstboot - https://fedoraproject.org/wiki/Features/NewFirstboot) – FESCo - https://fedorahosted.org/fesco/ticket/1055
19:36:10 <nirik> sgallagh: you had some questions/concerns here I think?
19:37:01 <sgallagh> Mostly the same as I raised on the list: I'm all in favor of NewFirstBoot, but I want the voted proposal to include the language "must coordinate with GNOME Initial Experience to avoid duplication"
19:37:42 <nirik> the feature does include: "Anaconda, initial-setup and Gnome Inital Experience will communicate..."
19:37:51 <nirik> so, hopefully everyone is talking to each other.
19:37:53 <sgallagh> This includes dealing with the situation where KDM is selected as the display manager, rather than GDM
19:38:22 <sgallagh> nirik: That language assumes GDM (which is where GIE runs). I want to be assured that KDM is addressed.
19:38:29 <nirik> and hopefully lightdm too. ;)
19:38:35 <jreznik_n9_> it's there and as far as I know there should not be conflict
19:38:37 <sgallagh> Sure, but who uses that? ;-)
19:38:43 <mitr> sgallagh: The plan is to have some of the settings possibly move between installation-time and firstboot, so GNOME IE has to cooperate in any case
19:39:15 <sgallagh> mitr: I was present for a two-hour discussion on this topic recently, at the end of which I was not convinced of that.
19:39:32 <jreznik_n9_> and for kdm/lightdm it's like with old firstboot
19:39:33 <nirik> sgallagh: would you like us to defer to try and answer those questions? or ?
19:39:37 <t8m> sgallagh, I do
19:39:47 <mitr> sgallagh: and, with respect to the previously-dicussed feature, I'd be fine with putting the onus to communicate on the other party :)
19:39:58 <notting> sgallagh: i am +1 to the feature, because if those meetings aren't getting them on the same page, anything we do here ain't gonna do it either
19:40:00 <jreznik_n9_> unless they want implement kie/lie ;-)
19:40:11 <nirik> notting: true.
19:40:31 <pjones> I
19:40:36 <pjones> Can't type, apparently.
19:40:42 <pjones> But nevertheless I'm +1 to the feature.
19:40:47 <sgallagh> I'm just trying to be clear that NewFirstBoot needs to be the place for anything system-wide, that it cannot be deferred to GIE.
19:40:47 <jwb> +1
19:40:52 <t8m> so +1 - I think the current situation with firstboot is a mess anyway
19:40:54 <sgallagh> With that in mind, I'm +1 here
19:40:57 * nirik is +1 too
19:41:07 <mmaslano> +1 with sgallagh comment
19:41:21 <mitr> +1
19:41:43 <mitr> (and +1 to the comment about system-wide things belonging to firstboot)
19:42:29 <nirik> abadger1999: ?
19:42:40 <abadger1999> +1
19:42:43 <nirik> #agreed Feature is approved (+9, 0, 0)
19:42:49 <nirik> #topic #1056 F19 Feature: OpenAttestation - https://fedoraproject.org/wiki/Features/OpenAttestation
19:42:49 <nirik> .fesco 1056
19:42:49 <nirik> https://fedorahosted.org/fesco/ticket/1056
19:42:51 <zodbot> nirik: #1056 (F19 Feature: OpenAttestation - https://fedoraproject.org/wiki/Features/OpenAttestation) – FESCo - https://fedorahosted.org/fesco/ticket/1056
19:43:16 <nirik> notting: you had questions here?
19:43:32 <notting> i guess i just had questions as to what it was trying to prove
19:43:40 * mclasen wonders why he wasn't invited to talk about gnome-initial-setup...
19:43:58 <notting> if it's only measuring the kernel & initramfs it's not actually attesting about the security/non-tamperedness of the system
19:44:07 <notting> but hey, if they want it even in that state... i guess?
19:45:06 <nirik> mclasen: https://fedoraproject.org/wiki/Features/InitialExperience ? or https://fedoraproject.org/wiki/Features/NewFirstboot ?
19:45:22 <nirik> notting: yeah, it's not clear to me either actually.
19:45:44 <mitr> notting: My impression of the TPM effort is that "what is a secure state we check for" is a problem without a widely-understood practical solution, but that doesn't prevent anyone from piling on layers and layers of other parts of the stack.
19:46:05 <mclasen> nirik: I don't know, I just heard that decisions are made about my project without talking to me - I guess I'll be waiting for patches
19:46:07 <t8m> mitr, +1
19:46:18 <pjones> I'me +1 to this, I guess.  It requires tboot, which we don't install unless you specifically ask for it with either yum or kickstart.
19:46:21 <nirik> mclasen: ok, if you can be more specific I can try and help...
19:46:24 <pjones> (well, globbing still pulls it in)
19:46:34 <mclasen> nirik: I'll read the logs, thanks
19:46:35 <notting> so, i'm a weak +1 in that it's not something to deny, but it's certainly not what i'd consider a solution to the problem space
19:46:37 <sgallagh> I'm +1
19:46:43 <nirik> sure, +1 I guess.
19:46:46 <mitr> OTOH, this attestation service/database at least makes it concievable that "last known state of $whatever" is stored in a database that actually exists instead of a handwavy "stored somewhere", so probably an improvement
19:46:51 <pjones> mclasen: I don't think we've discussed it yet...
19:46:55 <mitr> +1, echoing notting
19:46:55 <notting> compared to like dm-verirty, or something
19:47:05 <t8m> +1 anyway
19:47:07 <mmaslano> +1
19:47:33 <nirik> abadger1999: ? :)
19:47:37 <pjones> notting: I thought that went without saying TBH
19:47:56 <abadger1999> +1  same as notes notting
19:48:01 <nirik> #agreed Feature is approved (+9, 0, 0)
19:48:06 * abadger1999 butchered that sentence
19:48:07 <jwb> i didn't vote
19:48:07 <nirik> #topic #1064 F19 Feature: Simplify Java/Maven Packaging using XMvn - https://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging
19:48:07 <nirik> .fesco 1064
19:48:07 <nirik> https://fedorahosted.org/fesco/ticket/1064
19:48:09 <zodbot> nirik: #1064 (F19 Feature: Simplify Java/Maven Packaging using XMvn - https://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging) – FESCo - https://fedorahosted.org/fesco/ticket/1064
19:48:12 <nirik> jwb: oops. ;(
19:48:16 * nirik checks his eyes.
19:48:25 <jwb> it's ok.  i would have been +1 anyway
19:48:29 <nirik> jwb: you want to vote +1? or shall I roll back?
19:48:31 <nirik> ok
19:48:41 <nirik> abadger1999: any news on guidelines here?
19:48:47 <mmaslano> +1
19:48:54 <abadger1999> nirik: We approved them today :-)
19:48:56 <mmaslano> they started commits already
19:49:03 <t8m> +1
19:49:05 <nirik> cool. +1 then.
19:49:19 <mitr> +1
19:49:21 <nirik> so, I assume they are just commiting and the mass rebuild will pick them up? or are they building too?
19:49:22 <notting> +1
19:49:38 <abadger1999> sochotni: You still around to answer questions?
19:49:46 <nirik> +5 so far
19:49:47 <abadger1999> +1 from me regardless
19:50:05 <jwb> +1
19:50:06 <nirik> looks like they are just commiting, which is fine with me.
19:51:02 * nirik waits for last 2 folks to vote.
19:51:44 <sgallagh> +1
19:52:39 * pjones +1
19:52:46 <nirik> #agreed Feature is approved (+9, 0, 0)
19:52:58 <nirik> #topic #1066: F19 Feature: Network Team driver - Update for new features -  https://fedoraproject.org/wiki/Features/TeamDriverUpdate
19:52:59 <nirik> .fesco 1066
19:52:59 <nirik> https://fedorahosted.org/fesco/ticket/1066
19:53:01 <zodbot> nirik: #1066 (F19 Feature: Network Team driver - Update for new features - https://fedoraproject.org/wiki/Features/TeamDriverUpdate) – FESCo - https://fedorahosted.org/fesco/ticket/1066
19:53:09 <jwb> i don't think this is really a feature
19:53:19 <notting> that was my concern as well
19:53:26 <nirik> I looked at this to make sure it was enabled in the kernel, and it has been for ages?
19:53:39 <jwb> we took some extra patches in the f18 timeframe
19:53:46 <jwb> basically backports of stuff in net-next
19:53:51 <jwb> but that's all it was
19:54:02 <pjones> It would be nice if there was any language in here about NM integration
19:54:03 <nirik> so, perhaps they want press for their driver existing?
19:54:11 <nirik> but that seems yeah...
19:54:12 <pjones> because they can "improve experience" all day long without anybody seeing it.
19:54:45 <mitr> We have quite a few "version bump" features, that would be OK;  except that https://fedoraproject.org/wiki/Features/TeamDriverUpdate#Release_Notes almost goes out of its way not to be exciting.
19:55:34 <jwb> it's not a version bump
19:55:34 <nirik> yeah, without anything higher level using it, this is pretty dry.
19:55:38 <notting> mitr: the version bump features are usually all for much large components, or collections of components
19:55:41 <abadger1999> mitr: I was thinking about that today but... most were either "must coordinate with others (a la boost)
19:55:57 <abadger1999> or "Visible to a lot of end user desktops"
19:56:30 <sgallagh> Yeah, I'm inclined to vote this the same way I intend to about the yum groups thing: -1 as a Feature, go ahead and land it without fanfare.
19:56:39 <pjones> nirik: quick, 0xp * 100 = ?
19:56:51 <pjones> yeah, still no users experiencing anything.
19:57:21 <t8m> sgallagh, +1
19:57:43 <mitr> +1 to sgallagh
19:57:51 <abadger1999> +1 sgallagh
19:57:57 * pjones +1 to that as well
19:58:07 <notting> +1
19:58:10 <nirik> sure, +1 to that proposal too.
19:58:25 <nirik> thats -7
19:58:31 <nirik> (I think)
19:58:35 <jwb> +1 to the proposal
19:58:53 <sgallagh> Matches my count. (With one more from jwb since I started typing)
20:00:08 <nirik> #agreed The feature is declined. (0, -8, 0)
20:00:11 <nirik> #topic #1068: F19 Feature: Trusted Network Connect (TNC) - https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
20:00:11 <nirik> .fesco 1068
20:00:11 <nirik> https://fedorahosted.org/fesco/ticket/1068
20:00:15 <zodbot> nirik: #1068 (F19 Feature: Trusted Network Connect (TNC) - https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29) – FESCo - https://fedorahosted.org/fesco/ticket/1068
20:00:52 <sgallagh> #info go ahead and land team driver enhancements without fanfare
20:01:25 <pjones> I'd like to see this resubmitted with a summary and / or detailed description in english.
20:02:09 <pjones> (instead of this bizarre blend of marketting copy and security speak)
20:02:14 <pjones> marketing
20:02:39 <nirik> and a glossary. ;)
20:03:07 <notting> the questions about integration with NM did get answered some on devel@
20:03:10 <nirik> I guess they have NM integration also in scope now?
20:03:50 <mitr> notting: fwiw, NM can integrate enabling/disabling it, but setting up a policy for "what to authenticate" (returning back to the open attestation feature) would be still separate
20:04:07 <nirik> I guess I am ok with the feature, but agree it would be nice to ask them to rework the page to be english.
20:04:13 <mitr> nirik: +1
20:04:31 <abadger1999> notting: Do you understand how they are implementing this?  The contingency section says that wpa_supplicant and NetworkManager aren't being touched.
20:04:33 <sgallagh> nirik: Or at least the Release Notes
20:04:36 <notting> the submitter is non-native, so i'd prefer we phrase that better
20:04:45 <abadger1999> but I'm wondering if we're losing something in translation
20:04:55 * nirik tries again.
20:05:38 <notting> abadger1999: not exactly, no
20:05:41 <pjones> Well, it'd be nice for the summary to say something other than "check the detailed description", which is all it says right now.
20:05:43 <nirik> proposal: Feature is approved, but please rework feature page to be more high level descriptive of what the feature is and does.
20:05:57 <pjones> and I don't think "clients' posture" means anything to anybody not working on the feature.
20:07:08 <sgallagh> nirik: +1
20:07:10 <notting> nirik: +1
20:07:13 <abadger1999> nirik: +1
20:07:17 <nirik> or perhaps: Feature is approved, but please rework feature page to use less jargon and acronyms and be more high level descripive.
20:07:17 <nirik> ?
20:07:23 <nirik> (if I could speel)
20:07:51 <pjones> +1 to your second version, once you respell it
20:07:54 <t8m> nirik, +1
20:07:59 <mmaslano> +1 to nirik
20:08:20 <jwb> +1
20:09:46 <nirik> #agreed Feature is approved, but please rework feature page to use less jargon and acronyms and be more high level descriptive of the feature ( +8, 0, 0)
20:09:55 <nirik> #topic #1069: F19 Feature: Add LVM Thin provisioning support to the yum-fs-snapshot #plugin - https://fedoraproject.org/wiki/Features/YumFsSnapshotThinpSupport
20:09:55 <nirik> .fesco 1069
20:09:55 <nirik> https://fedorahosted.org/fesco/ticket/1069
20:09:56 <zodbot> nirik: #1069 (F19 Feature: Add LVM Thin provisioning support to the yum-fs-snapshot plugin - https://fedoraproject.org/wiki/Features/YumFsSnapshotThinpSupport) – FESCo - https://fedorahosted.org/fesco/ticket/1069
20:10:39 <notting> i asked a bunch of questions, but i'm ok with this. +1
20:11:04 <nirik> ok, +1 from me.
20:11:11 <sgallagh> +1
20:11:43 <pjones> +1
20:11:45 <t8m> +1
20:11:51 <jwb> +1
20:12:02 <mmaslano> +1
20:12:03 <mitr> +1
20:12:16 <abadger1999> +1
20:12:18 <nirik> #agreed Feature is approved (+9, 0, 0)
20:12:25 <nirik> #topic #1070: F19 Feature: Yum Groups as Objects - https://fedoraproject.org/wiki/Features/YumGroupsAsObjects
20:12:25 <nirik> .fesco 1070
20:12:25 <nirik> https://fedorahosted.org/fesco/ticket/1070
20:12:27 <zodbot> nirik: #1070 (F19 Feature: Yum Groups as Objects - https://fedoraproject.org/wiki/Features/YumGroupsAsObjects) – FESCo - https://fedorahosted.org/fesco/ticket/1070
20:13:17 <sgallagh> -1 It doesn't fix the real problem and is only a marginal improvement on the current state. Let them land it, but not as a feature.
20:13:31 <abadger1999> +1
20:13:40 <abadger1999> (To be clear, that's a +1 to feature)
20:13:55 <t8m> same as sgallagh
20:13:56 * notting is +1 to it as a feature, as it changes the behavior of certain yum commands
20:14:02 * nirik is also a weak +1, as this is something lots of people hit, even tho it's not a full solution.
20:14:14 <jwb> +1
20:14:20 <nirik> so, -2/+4 so far
20:14:21 <mitr> +1 as a feature, if only to relnote the behavior change
20:14:28 <abadger1999> The yum group behaviour is a long time UI wart that people have asked questions about.  To me this is a notable and visible change
20:14:29 <sgallagh> Given the description of how they plan to solve it, I kind of think it will be less helpful than the old behavior.
20:14:34 <mmaslano> +1
20:14:37 <sgallagh> Since now it's also order-dependenty
20:14:39 <sgallagh> *dependent
20:15:15 <nirik> so, thats -2/+6...
20:15:36 <nirik> pjones: ?
20:15:55 <pjones> sorry, got distracted here
20:16:06 <pjones> I'm not sure it needs to be a feature, but hey, sure, +1, go ahead.
20:16:22 <nirik> #agreed Feature is approved (+7, -2, 0)
20:16:29 <nirik> #topic #1071: F19 Feature: systemd Calendar Timers - https://fedoraproject.org/wiki/Features/SystemdCalendarTimers
20:16:29 <nirik> .fesco 1071
20:16:29 <nirik> https://fedorahosted.org/fesco/ticket/1071
20:16:32 <zodbot> nirik: #1071 (F19 Feature: systemd Calendar Timers - https://fedoraproject.org/wiki/Features/SystemdCalendarTimers) – FESCo - https://fedorahosted.org/fesco/ticket/1071
20:17:35 <jwb> +1
20:17:48 <abadger1999> There was a long discussion but it all seemed to aim at things other than the feature?
20:17:58 <jwb> yeah.  i don't understand the discussion
20:17:58 <nirik> so, the feature itself doesn't want to convert or change anything.
20:18:05 <notting> as "this is a feature in systemd", i'm fine, +1. as to "what should fedora do with this feature in its pacakges"... that's a different discussion (that i don't think we need to have now?)
20:18:06 <nirik> simply to make the feature known to users.
20:18:16 <abadger1999> Yeah, so I think I'm +1 to the feature
20:18:21 <jwb> notting, sure, which the feature doesn't even attempt to address
20:18:28 * nirik is +1 for the feature.
20:18:44 <mitr> +1
20:18:58 <nirik> thats +5 so far.
20:19:02 <sgallagh> Agreed, +1 to the feature itself.
20:19:15 <mmaslano> um I abstain 0
20:19:15 <t8m> +1 if "#info Do not hurry up converting your cron jobs to timers" is added
20:19:22 <nirik> I do think we need to address conversion and packaging and such, but that should not be now or related to the feature.
20:19:43 <t8m> nirik, I think it should be F20 material
20:20:06 <nirik> sure, so should we say: "no packages should convert to using this yet" ?
20:20:14 * pjones is +1
20:20:14 <t8m> nirik, please +1
20:20:33 <sgallagh> nirik: Yes, +1 to that rider
20:20:37 * abadger1999 is fine with that addition
20:20:37 <mitr> t8m: Do you have a specific concern?
20:20:46 <pjones> yeah, that's reasonable.
20:20:47 <t8m> mitr, confusion of users/admins?
20:20:55 <mitr> t8m: ok
20:21:07 <nirik> I'll note that systemd itself does use them already. ;) 2 timer units
20:21:22 <t8m> nirik, I think use within systemd itself is OK
20:21:22 <nirik> oh, those are old style I think
20:21:24 <notting> nirik: they don't use the calendar scheduling, they're generic timer units that have been in systemd for a few releases now
20:21:29 <nirik> yeah.
20:21:52 <nirik> so, final proposal: Feature is approved. No packages should convert to using this feature yet"
20:21:53 <mitr> I'd be fine with that addition, although I'm not 100% sure that we would want to patch upstreams that start to use them...
20:22:16 <jwb> seems excessive, but whatever
20:22:18 <mitr> +1 to nirik's wording (which doesn't have the "upstream" problem)
20:22:25 <t8m> nirik, +1
20:22:25 <sgallagh> Can we rephrase that to "There is no *requirement* to convert packages to use this feature"
20:22:35 <t8m> sgallagh, that's too weak
20:22:47 <notting> i'm ok with the rider. i'd like to work more on where we want to end up
20:22:51 <sgallagh> ok
20:22:53 <nirik> sgallagh: I think folks wanted a stronger thing there... or we get people converting and doing things perhaps in a way we don't like
20:22:54 <notting> but that's unrelated to the tech being there
20:23:00 <sgallagh> Fair enough
20:23:07 <sgallagh> I withdraw my suggestion
20:23:21 * nirik is +1 to his own proposal.
20:23:30 <nirik> thats +3 so far.
20:23:43 <mitr> nirik: It's not like there is a thousand ways to do it... but, true, some packaging guidelines for matching admins' expectations might be necessary (remembering the confusion about disabling service vs.socket...)
20:23:54 <mmaslano> +1 to nirik
20:24:43 <t8m> anybody else?
20:24:50 <nirik> +4 so far...
20:24:50 <notting> nirik: +1, for lack of a better way to put it
20:24:52 <sgallagh> +1, if I forgot to do so
20:25:16 * notting is getting close to having to leave
20:25:44 <nirik> any other votes? thats +6
20:25:56 <abadger1999> +1
20:26:08 <nirik> we are getting toward the end. ;)
20:26:31 <nirik> #agreed Feature is approved. No packages should convert to using this feature yet. (7, 0, 0)
20:26:36 <nirik> #topic #1072: F19 Feature: systemd/udev Hardware Database - https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase
20:26:36 <nirik> .fesco 1072
20:26:36 <nirik> https://fedorahosted.org/fesco/ticket/1072
20:26:37 <pjones> nirik: +1 to your wording
20:26:38 <zodbot> nirik: #1072 (F19 Feature: systemd/udev Hardware Database - https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase) – FESCo - https://fedorahosted.org/fesco/ticket/1072
20:27:28 <nirik> so, I share notting's concerns here about putting a db we have to update all the time in a core component that we don't want to update all the time.
20:27:35 <t8m> me as well
20:28:15 <jwb> i'm going to defer to whatever notting thinks here.
20:28:18 <mitr> Same here
20:28:20 <notting> but that is an issue with the mechanics of packaging of the feature which don't even extend to Conflicts: or similar issues. the idea of the feature is ok
20:28:39 <nirik> yep. I agree.
20:28:47 <nirik> it looks like you can update it on the fly.
20:28:55 <nirik> but it would be nice to be a seperate package.
20:29:05 <pjones> I'm not sure that's a big issue - it looks like if it doesn't have data it'll still do sane things, so updating the data shouldn't be a driver for new package versions very often
20:29:09 <nirik> -r--r--r--. 1 root root 5.3M Feb  6 13:28 /etc/udev/hwdb.bin
20:29:18 <mitr> notting: I'm not convinced that mixing descriptive data and "udev program" in the same place is structurally sound, but it's also not really a FESCo-level concern
20:30:28 <nirik> I'd be ok to just +1 the feature, but I'm worried if we do packaging concerns will be forgotten.
20:30:37 <notting> we never really update hwdata in fedora, so it's unlikely to be a huge concern there
20:30:38 <mitr> My question is really - what do we want to do here as an alternative to just accepting the feature?
20:31:49 * nirik shrugs. I guess I am a weak +1 to just approving the feature and hope upstream will adjust packaging based on concerns.
20:31:53 <abadger1999> Proposal: Feature is approved conditional on notting's concerns about how we ship the data being addressed
20:32:05 <sgallagh> abadger1999: +1
20:32:08 * pjones doesn't care, he's +1 to it in general
20:32:08 <nirik> sure, +1 on that
20:32:31 <mitr> That works for me, +1
20:32:39 <mmaslano> +1
20:32:42 <abadger1999> +1
20:32:47 <t8m> +1
20:33:03 <notting> that's probably stronger than i would put it... but sure
20:33:24 <pjones> well, "being addressed" is vague enough that "no" covers it.
20:33:25 <notting> the packaging is suboptimal, IMO. its' not *wrong*
20:34:09 * nirik sees +8.
20:34:20 <nirik> #agreed Feature is approved conditional on notting's concerns about how we ship the data being addressed (+8, 0, 0)
20:34:30 <abadger1999> notting: <nod>  My wiggle room in the proposal would be -- Essentially, they have to convince you that it's okay to ship like that. :-)
20:34:44 <nirik> ok, so thats the last feature I had.
20:35:01 <nirik> could everyone look over the full list and yell if there's any that we didn't address that they would like to?
20:35:11 <abadger1999> More mobile Broadband -- I had a small thing
20:35:24 <nirik> ok, just a sec, let me prep topic. ;)
20:35:41 <mitr> Can we also return to Apache OpenOffice for a very small moment?
20:35:55 <nirik> mitr: sure, after mobilebroadband?
20:36:01 <mitr> nirik: of course
20:36:04 <nirik> #topic #1051 F19 Feature: More Mobile Broadband - https://fedoraproject.org/wiki/Features/MoreMobileBroadband
20:36:04 <nirik> .fesco 1051
20:36:04 <nirik> https://fedorahosted.org/fesco/ticket/1051
20:36:06 <zodbot> nirik: #1051 (F19 Feature: More Mobile Broadband - https://fedoraproject.org/wiki/Features/MoreMobileBroadband) – FESCo - https://fedorahosted.org/fesco/ticket/1051
20:36:19 <abadger1999> Would be great if the Feature would note or feature owners would notify the people/packages that need to be modified for the new API.
20:36:56 <nirik> #info Feature owners should notify any people/packages that need to be modified for the new API
20:37:16 <nirik> cool. Do you want to defer until that happens? or just approve and revisit?
20:37:28 <abadger1999> I'm okay to approve and revisit.
20:37:43 <nirik> ok.
20:37:50 <abadger1999> The mmeaty portion of the feature seems great.  It's just the coordination portion that I want to see addressed.
20:38:01 <nirik> anything else on this feature from anyone?
20:38:35 <nirik> #topic #1038 F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice
20:38:36 <nirik> .fesco 1038
20:38:36 <nirik> https://fedorahosted.org/fesco/ticket/1038
20:38:38 <nirik> mitr: ?
20:38:39 <zodbot> nirik: #1038 (F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice) – FESCo - https://fedorahosted.org/fesco/ticket/1038
20:38:57 <mitr> pescetti just sent this to the list: "The aliases discussed involved oowriter, oocalc...; the openoffice.org alias wasn't mentioned".  Do we want to forestall the discussion and clarify?
20:39:13 <mitr> (that is /usr/bin/openoffice.org, to provide context)
20:39:29 <jwb> no
20:39:31 <pescetti> Well, it's not that urgent, I hope I got it right.
20:39:43 <t8m> I would very much doubt that anyone uses that alias from command line
20:39:44 <fenrus02> installing both should not conflict
20:39:51 <jwb> if the packagers are talking, they can continue to talk
20:40:00 * nirik nods.
20:40:18 <abadger1999> I'd want input from the libreoffice maintainers before deciding something... they may be fine with oo taking over some of those; they may have good reasons to want to keep all of them.  I just don't know.
20:40:18 <mitr> ok
20:40:52 <nirik> yeah, I'd really prefer if everyone tries to talk and be reasonable... (sometimes it happens! )
20:41:19 <pescetti> OK for me too. We will definitely try to talk and clarify it together.
20:42:23 <nirik> #info maintainers to continue to talk and try and work out solutions to the overlapping files.
20:42:29 <nirik> anything else on this?
20:42:39 <nirik> does anyone have any further features they want to discuss?
20:42:43 <law> i didn't see glibc-2.17 discussed...  i thought it was ready for voting...
20:43:06 <jwb> law, it was approved without discussion
20:43:11 <law> ah, works for me
20:43:17 <pjones> didn't figure you'd complain ;)
20:43:19 <fche> better than discussion without approval
20:43:36 * nirik looks over the list one last time.
20:43:50 <sgallagh> law: We had 45 things to discuss today. We decided ahead of time which ones no one was planning to argue with.
20:43:53 <pjones> law: fche: we're doing a new thing where we try to vote en block for everything nobody on fesco feels the need to discuss
20:43:58 <ajax> ooh, 2.17 added clock_gettime to libc finally.
20:44:00 <ajax> thanks!
20:44:05 <pjones> it is working somewhat better than the old method.
20:44:14 <nirik> #topic Next week chair
20:44:21 <nirik> who wants the gavel next week?
20:44:35 <t8m> I won't be around next week.
20:44:54 <mmaslano> I can do it
20:45:00 <nirik> mmaslano: thanks!
20:45:05 <nirik> #action mmaslano to chair next week
20:45:09 <nirik> #topic Open Floor
20:45:18 <sgallagh> I will not be around for next week
20:45:24 <notting> sorry, have to head out now
20:45:34 <nirik> any items for open floor? or any last minute calls for feature rediscussion? ;)
20:45:40 <abadger1999> Just an fyi from fpc.
20:46:02 <abadger1999> on banning sysinit scripts in subpackages: https://fedorahosted.org/fpc/ticket/243#comment:2
20:46:24 <abadger1999> vote for the ban failed, +1: 4, 0: 4, -1: 0
20:46:26 <nirik> ok, so the existing ones will just linger?
20:46:52 <abadger1999> So we decided that by and large we considered the current guidelines sufficient
20:46:53 <nirik> I guess at the packagers discretion ?
20:47:00 <abadger1999> nirik: Yeah, at packager discretion...
20:47:01 <pjones> so, we should communicate that with the people who are still riding that horse.
20:47:15 <pjones> (the "everything must change" horse, that is.)
20:47:32 <abadger1999> basically, we couldn't see either any harm or any benefit, therefore we were hesitant to ban them.
20:47:39 * nirik considers asking all of them politely to just stop doing it. I bet it would get some of them... but thats off topic I suppose.
20:47:54 <abadger1999> pjones: note -- this is different than converting to ship a systemd unit file
20:48:03 <abadger1999> pjones: That's still in the guidelines as a must.
20:48:48 <abadger1999> pjones: this was a ban on sysvinit subpackages (the main package ships a unit file... the sysvinit script is for some theoretical person who needs that for some alternate init system, to copy over to debian, something else)
20:48:58 <nirik> it's these: http://paste.fedoraproject.org/2627/
20:49:09 <pjones> abadger1999: yeah, I got that.
20:49:12 <abadger1999> k
20:49:14 <abadger1999> cool.
20:49:14 * nirik finds them a complete waste, but whatever.
20:49:28 <pjones> nirik: like oh so many whole packages ;)
20:49:50 <nirik> well, a more deliberate waste. going out of the way to be a waste... but sure.
20:50:27 <nirik> anyhow, any other open floor items ?
20:51:12 * nirik will close out the meeting in a minute then if nothing else comes up
20:51:30 <jwb> we need to come up with something for 9 more minutes
20:51:47 <sgallagh> jwb: No. No we don't
20:51:51 <fche> haha
20:51:52 <mmaslano> jwb: no we don't
20:51:52 <pjones> jwb: I don't think this is like budgets, where it's "use it or lose it"
20:51:58 <mmaslano> let's go home
20:52:20 <abadger1999> more like use it and lose it ;-)
20:52:35 <nirik> ha.
20:52:40 <nirik> ok, thanks for coming everyone. :)
20:52:45 <nirik> #endmeeting