18:00:01 #startmeeting FESCO (2013-02-06) 18:00:01 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:01 #meetingname fesco 18:00:01 The meeting name has been set to 'fesco' 18:00:01 #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:00:01 #topic init process 18:00:02 Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:00:07 here 18:00:14 hello. 18:00:20 hi 18:00:22 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 ok, missing t8m I guess... 18:02:23 ah, there he is. ;) 18:02:32 ok, lets go ahead and dive in... 18:02:35 #topic #896 Refine Feature process 18:02:35 .fesco 896 18:02:35 https://fedorahosted.org/fesco/ticket/896 18:02:38 nirik: #896 (Refine Feature process) – FESCo - https://fedorahosted.org/fesco/ticket/896 18:02:47 do we have anything on this? or we need to write up things from fudcon first? 18:02:56 the latter. i asked about it in the ticket 18:03:05 propose we just move on 18:03:13 yeah, unless there's something we should just move on for now... 18:03:15 yep. 18:03:32 shall we do the schedule at the end? or now? 18:03:41 * jreznik_n9 already started talking to docs/marketing 18:03:54 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 sure. understandable. 18:04:14 #topic #966 Fedora 19 Schedule proposal (DRAFT!) 18:04:14 .fesco 966 18:04:14 https://fedorahosted.org/fesco/ticket/966 18:04:15 nirik: #966 (Fedora 19 Schedule proposal (DRAFT!)) – FESCo - https://fedorahosted.org/fesco/ticket/966 18:04:22 t8m, and travelling, sorry 18:04:34 I think maybe we should do this one at the end? even though we'll all be exhausted by then. 18:04:36 so, we could defer this more until after features, but I think we have a good idea of the load... 18:04:43 yeah, I'm ok with either way. 18:04:51 i don't really think any of the features we're going to talk about are going to change it much 18:05:00 yep 18:05:01 unless we decided to switch DEs or something 18:05:03 The mass rebuild has already been scheduled, so we probably have a good enough idea 18:05:44 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 ignore it 18:05:56 jwb: did spaleta get his OpenCDE feature in? 18:06:19 notting, no... be we're talking about Cinnamon and Gnome3 today, so still a possibility 18:06:24 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 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 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 nirik, i think f20 schedule is going to evolve from f20 feature/planning process anyway 18:07:32 and we could end with different model for f20... 18:07:39 jreznik_n9, +1 even that 18:07:46 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 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 jreznik_n9: Actually having a smaller release only to smooth out the new model might be a good idea 18:08:21 so, perhaps a tenative f19.1 or 20 for early nov would be possible. 18:08:24 i wouldn't worry about f20 much now 18:08:40 i don't think we have the time, information, or energy to talk about f20 today 18:08:46 alright. 18:08:47 we can deal with it next week 18:08:53 so, votes? or counterproposals? 18:08:55 or later, when we have more info 18:09:19 mattdm: if they want another week before alpha... shift everything in that schedule out a week 18:09:29 nirik: As mattdm said, the cloud images feature wants another week before alpha 18:09:41 notting: yes. 18:09:58 jreznik_n9: what do you think about pushing out a week before alpha? 18:10:12 +1 to the proposed schedule but I am not against the 1 week shift either 18:10:24 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 i'm +1 to the shifted-one-week schedule 18:10:45 one week plus is ok for me, more pressure on f20 but it's only a week 18:10:48 [that's WRT comment #21, not the cloud feature] 18:10:51 +1 to proposed schedule 18:10:53 I'm slightly in favor of the shifted schedule 18:11:04 notting: shifted farther out? 18:11:10 yes, sorry. +1 week 18:11:12 pjones: yeah 18:11:32 mattdm: what would have to be dropped from the cloud feature if koji weren't done? 18:11:33 so 25th ga 18:11:35 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 mmaslano: you ok with the +1 week? 18:11:38 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 nirik: yeah 18:11:57 notting: Should we pull in dcantrell 18:11:58 ? 18:12:06 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 notting: I suspect that's going to depend entirely on what we decide "alpha blocker" means this time around 18:12:17 sgallagh: dcantrell or clumens. unless pjones wants to speak for the team 18:12:23 mattdm: IOW, koji is an absolute prerequisite? 18:12:42 notting: I'm not very involved in that feature, so probably best to get one of them 18:12:44 well, the feature is basically *about* a koji update. 18:12:54 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 so parts of it can be tested individually without actually updating the production koji 18:13:10 pjones: fair enough 18:13:17 but it'd be really best to have it there by alpha 18:13:19 nirik: hm, I see the problem 18:13:20 what about a counterproposal of: Lengthen development time for both f19 and f20 to put f20 release in May 18:13:33 mattdm: Except that we wouldn't then have "official" alpha images. 18:13:35 abadger1999: boooo 18:13:40 pjones: :-) 18:13:50 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 sgallagh: right, also. That would be not nearly as nice. 18:14:00 abadger1999: I think may is too soon/short for the number and size of features we have 18:14:06 Proposal: Adjust the proposed schedule out one week to accommodate the cloud image Feature. 18:14:12 abadger1999: I'm all for a longer schedule, but I think that's some irresponsible reasoning 18:14:22 pjones: except... we do know we don't want to be anywhere close to December 18:14:22 oh, f20 18:14:25 * nirik re-reads 18:14:43 * nirik doesn't understand 18:14:57 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 nirik: He's calling for an 11-month F20 schedule. I don't think we should discuss this now 18:15:40 ah, ok. 18:15:51 sgallagh: who is he? /me missed context 18:16:01 abadger1999: you 18:16:02 abadger1999: he == you 18:16:11 well, we have +6 I think on the +1 week schedule... unless we wish to get more feedback before approving. 18:16:18 sgallagh: that's not my proposal then :-) 18:16:20 nirik, +1 from me 18:16:20 paging the anaconda people 18:16:30 erm, "we are paging ..." 18:16:31 abadger1999: can you repeat your proposal? I didn't grok it. 18:16:39 abadger1999: Then I can't parse "put f20 release in May" in any other way 18:16:48 sgallagh: no, he's saying to lengthen both, so he's talking about a 7.5month schedule for each, roundabout. 18:16:52 ahh 18:16:56 * jreznik_n9 is back 18:16:56 Right, what pjones said. 18:16:57 mea culpa 18:17:22 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 clumens: so here's the proposed schedule: https://fedorahosted.org/fesco/ticket/966 18:17:43 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 let me review what we said we were going to do 18:17:54 mitr: no, but the other way was abysmal failure 18:18:01 clumens: Comment 21: https://fedorahosted.org/fesco/ticket/966#comment:21 18:18:05 mitr: so if we're comparing "totally fucked the dog" with "not ideal"... 18:18:13 poor doggie 18:18:19 >_< 18:18:27 do it as early as possible - with f20 planning starting earlier 18:18:53 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 but we really have to sort out f19 today, guys getting nervous 18:19:02 sadly, open source projects are pretty horrible about year ahead+ planning. 18:19:05 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 someone ping me when we're talking about something that we can actual do something about. like f19. 18:19:38 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 mitr, +1 18:20:10 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 the other stuff's just minor 18:20:15 mitr: imho that was (very) bad planning 18:20:34 drago01: yeah, I think mitr knows I strongly disagree with the statement already :) 18:20:37 clumens: additionally we are talking about adding a week before alpha 18:21:15 pjones: ;) 18:22:00 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 F19 is already releasing 3 (!) months after GNOME 3.8, which is pretty bad 18:22:37 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 http://paste.fedoraproject.org/2622/ 18:22:57 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 clumens: see above paste. any better? 18:23:30 did I add a week corrected there for everyone? please check. ;) 18:23:30 clumens: that jives with what I thought, which was roughly: it depends on what we decide "alpha blocker" means this time 18:23:40 kalev: So in other words, we'll end up with 3.8.1 with some of the bugs hammered out? 18:24:00 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 mitr: the alpha coming in april is definitely better than it coming in march 18:24:15 err, nirik 18:24:22 kalev: all the data spot has says the people we're losing aren't going because they want new gnome. 18:24:26 sgallagh: GNOME 3.8.1 is Apr 17. 18:24:53 pjones: right, and hopefully this time blockers will be greatly reduced because we won't be mucking with the fundamentals 18:24:59 proposal: https://fedorahosted.org/fesco/ticket/966#comment:22 18:25:06 kalev: Great, so that will make Beta 18:25:22 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 kalev: Not to start a flame war, but what other prominent distro ships GNOME? 18:25:54 sgallagh: Ubuntu? 18:26:05 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 some of which are already done 18:26:13 nirik, +1 18:26:38 * jreznik_n9_ is trying to open proposal, net sucks on highway even in Netherlands 18:26:41 kalev: Ah, I missed the memo that they were shipping a GNOME respin. Ok, fair point. 18:26:46 nirik: he said f20 though 18:26:48 clumens: great 18:26:53 i'm +1 to the amended schedule, then 18:26:53 * nirik is +1 to his own proposal 18:26:54 nirik: alright, I can be +1 to that 18:26:58 nirik: Yeah, I wasn't arguing about f19, too late for that, let's just get back on track with f20. 18:27:01 nirik: +1 18:27:11 +1 to nirik's proposal 18:27:12 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 kalev: ok, understood. 18:27:21 nirik, could you paste it here 18:27:21 nirik: -1. I'd prefer the one week addon. 18:27:29 sure. 18:27:42 sgallagh: that _is_ the one week addon, unless I messed up something. 18:27:50 nirik: Sorry, I was misreading Trac 18:27:51 sgallagh, but nirik's schedule is with the one week add on 18:28:06 sure, paste coming for jreznik_n9_: 18:28:09 nirik: It's kind of stupid that "comment: 22" looks like it belongs to the above comment. 18:28:09 2013-04-02 Alpha Change Deadline/Software?? String Freeze 18:28:09 2013-04-16 Alpha Public Availability 18:28:09 2013-05-07 Features 100% Complete Deadline / Beta Change Deadline 18:28:09 2013-05-21 Beta Release Public Availability 18:28:09 2013-06-10 Final Change Deadline 18:28:10 2013-06-25 Final (GA) release 18:28:16 yeah, thanks trac. ;) 18:28:19 nirik: I am +1 18:28:57 thats +7? 18:29:16 * abadger1999 anticipates a July 4th release :-) 18:29:36 #agreed schedule as in https://fedorahosted.org/fesco/ticket/966#comment:22 18:29:49 abadger1999: Yay! Fireworks at the release parties :-D 18:30:04 the downside of that schedule is, as usual, that slippage means we're in a holiday weekend 18:30:19 yeah, typical. ok, moving on then? 18:30:21 abadger1999: katy perry for everyone? oh wait, horrible idea 18:30:25 * jreznik_n9_ is back again, sorry 18:30:26 at least it's not a holiday week? 18:30:29 #topic #1008 F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages 18:30:29 .fesco 1008 18:30:29 https://fedorahosted.org/fesco/ticket/1008 18:30:31 nirik: #1008 (F19 Feature: First-Class Cloud Images - https://fedoraproject.org/wiki/Features/FirstClassCloudImages) – FESCo - https://fedorahosted.org/fesco/ticket/1008 18:30:32 and US only :-) 18:30:53 ok, I'm +1 for this. Not sure it will all happen, but I'm happy for mattdm to try. 18:31:02 +1 18:31:04 thanks :) 18:31:30 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 i'm +1 18:31:44 nirik: I'll volunteer the help if he needs it 18:31:52 cool 18:32:09 +1 18:32:19 +1 18:32:49 +1 18:32:56 +1 18:33:01 +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 s/feel/felt/ 18:33:20 mitr: likewise 18:33:28 abadger1999: ? 18:33:34 +1 to shoot for doing it. 18:33:43 #agreed Feature is approved (+9, 0, 0) 18:33:51 #topic #1076 2013-02-06 meeting feature voting 18:33:51 .fesco 1076 18:33:51 https://fedorahosted.org/fesco/ticket/1076 18:33:53 nirik: #1076 (2013-02-06 meeting feature voting) – FESCo - https://fedorahosted.org/fesco/ticket/1076 18:34:04 may vote to do a contingency plan later in the cycle. 18:34:11 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 hurrah 18:34:34 I can ask again at the end to make sure we didn't miss any... 18:34:52 There were a few where people had questions, but said it wouldn't cause them to vote differently. 18:35:11 nirik: that's... the list of ones we'll talk about? 18:35:21 notting: did your cups questions get answered? or would you prefer to discuss here. 18:35:34 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 There was also some anaconda newui question that I updated the ticket with 18:35:44 nirik: whatever is easiest 18:35:56 nirik: it got answered - i had wondered if "no browsing" qualified for enacting the contingency plan 18:35:58 pjones: at the end yeah, 18 of them. ;) 18:36:02 nirik: so i'm ok with it 18:36:07 notting: so, we drop cups from discussion? 18:36:12 nirik: sure, fine with me 18:36:19 ok. 18:36:24 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 abadger1999, +1 18:36:39 abadger1999: yeah, sorry. 18:37:14 ok then, shall we start the marathon? 18:37:33 #topic #1035 F19 Feature: Dracut HostOnly - https://fedoraproject.org/wiki/Features/DracutHostOnly 18:37:33 .fesco 1035 18:37:33 https://fedorahosted.org/fesco/ticket/1035 18:37:35 nirik: #1035 (F19 Feature: Dracut HostOnly - https://fedoraproject.org/wiki/Features/DracutHostOnly) – FESCo - https://fedorahosted.org/fesco/ticket/1035 18:37:55 haraldh: you happen to be around? ;) 18:38:06 I really don't like this even if it is just returning back to situation we had before 18:38:17 nirik, yep 18:38:25 I think it's fine and beneficial to have this feature; having it enabled by default is not a good tradeoff. 18:38:29 i'm ok with it. RHEL 5 compatibility! 18:38:29 As noted on the list, I don't like sacrificing stability for speed, especially when the latter hasn't been benchmarked. 18:38:43 notting: I thought we were against bug-for-bug compatibility? 18:38:51 sgallagh, :) 18:39:10 this one I'm a little worried about - couple of issues. 18:39:32 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 hah: so when I introduced the generic image, everyone was concerned about size :-) 18:39:45 sgallagh: Chris Murphy did soime tests - ~1 second speedup on SSD, 4 seconds on rotating 18:39:47 can't make it right, it seems 18:40:12 mitr: Ok, and that's considered significant because...? 18:40:19 haraldh: no, I like the idea, but there are some implementation details I'm worried aren't scoped out 18:40:20 sgallagh: I'm not saying it is. 18:40:21 mitr, which to me seems very well not worth it 18:40:46 sgallagh: 1 second would be ~17% here ;) 18:41:13 mitr: it saves a lot of size on /boot, which is a problem we've been having 18:41:22 nirik, well, it's not the same as the rescue mode, but we could install such a script also 18:41:28 drago01: Sure, but in the grand scheme of things, 1-4s is *nothing* at boot time. 18:41:40 haraldh: is there any docs on what it is/can do? 18:41:43 sgallagh: uh, what are you on? 18:42:01 pjones, IBM pSeries H server apparently 18:42:12 jwb: if so, my deepest sympathies 18:42:13 pjones, does it really with the rescue mode? 18:42:21 pjones: even with the larger default /boot size? 18:42:23 pjones: Sorry, allow me to rephrase. 18:42:29 notting, high on the list of things i do not miss 18:42:43 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 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 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 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 haraldh: network? ssh? 18:42:55 nirik, yep 18:42:58 But it should *not* be default operation. 18:43:10 sgallagh: that's some ideal world awesomeness you're dreaming of there 18:43:14 nirik, we can install all we want in it 18:43:42 nirik, of course only what is installed on the system :) 18:43:47 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 pjones: I've always stuck with the policy of "do things correctly first, fast later" 18:44:18 drago01, in a perfect world you don't have to boot 18:44:22 sgallagh: correctly is still "we don't need everything to be generic most of the time" 18:44:30 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 t8m: well, we can fix anaconda to ensure that happens. wait. 18:44:42 heh 18:44:59 t8m: notting: reminds me of what the statisticians have said: 93% of people die. 18:45:01 mitr: I guess it depends on how we merge the two things... 18:45:14 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 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 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 notting: now that almost all of the (desktop/laptop) uses ahci and it is built in 18:46:00 notting: that does not matter much in practice 18:46:01 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 i.e just works 18:46:15 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 haraldh: so the first time you install, we create a generic image, and after that we create host-only 18:46:41 pjones, right 18:46:47 mitr: if anaconda switches to just calling/booting the dracut one, it could be much smaller. 18:46:49 pjones, no objections 18:46:52 okay. 18:47:05 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 nirik: you mean anaconda could be much smaller, right? 18:47:43 mitr: yeah, since it wouldn't need to carry that extra path/code... 18:48:05 pjones, i think you mean "grubby" when you say kernel.spec 18:48:05 nirik: I was thinking about the size of things put in /boot, since pjones brought that up as a limitation 18:48:45 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 nirik: right, that's unclear 18:49:11 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 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 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 [yes it might be too crazy because the fallback path wouldn't get tested] 18:50:12 notting, meaning: if the machine couldn't be installed without a anaconda update, the rescue image might also not work 18:50:44 300MB? omg.. no, I was thinking in the range of < 50MB 18:51:06 so, we are getting close to 15min here. 18:51:45 anyone care to vote, propose changes to the feature or ask to defer? 18:51:53 jwb: well, I'd assumed new-kernel-package would be being told, but it could go either way 18:51:56 mitr, good point with the fallback path not getting tested 18:52:02 i'm +1 to defaulting to hostonly as-is 18:52:15 pjones, i would prefer it to go the grubby way 18:52:20 jwb: sure whatever ;) 18:52:25 I guess I am a weak +1, but I would like to see the rescue mode more sorted out. ;) 18:52:25 please and thank you 18:52:30 I'm -1 to making this default 18:52:39 I am -1 in the current form of the feature 18:53:05 t8m, what needs tweaking? 18:53:08 +2/-2 18:53:09 notting: I strongly object to doing this outside of packaging 18:53:21 haraldh, the rescue mode should be clarified and it should not be default 18:53:23 -1 to making it default, +1 to making it optional/configurable 18:53:30 it = host only 18:53:41 sgallagh: it already is configureable 18:53:42 -1 to default 18:53:48 +2/-4 18:53:53 sgallagh: edit dracut.conf and rebuild the initrd 18:54:00 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 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 i'm a +1 i guess 18:54:23 ooh. a tie 18:54:25 +4/-4 18:54:27 who's the tie breaker? 18:54:28 Heh 18:54:29 sgallagh: the default case should be the fast not the "bloated" one 18:54:31 abadger1999 is. 18:54:35 * abadger1999 hasn't voted yet. 18:54:41 it's all up to you abadger1999 18:54:42 I was going to vote +0 though ;-) 18:54:46 abadger1999: I don't see any way there's a legal objection since we're building on a user's machine 18:54:47 ha ha 18:54:49 drago01: We'll agree to disagree on that point. 18:55:01 pjones: Just didn't see that wrapped up in the thread. 18:55:06 do we need a vice president to come vote? ;) 18:55:25 sgallagh: yeah not the right time / place for having this discussion 18:55:29 abadger1999: they've clearly got everything going into it already, so we're in gplv2 section 3a AFAICS 18:55:47 I mean, the admin can turn it off/on anyway 18:55:50 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 (modulo the fact that we're probably in 3b/3c for the code that /made/ those things) 18:56:12 abadger1999, I think if it was not default it would get enough votes 18:56:27 it's already the case tho. 18:56:28 -- but isn't that basically where we are now? 18:56:32 yes. 18:56:36 then the feature would be 'rescue mode' I guess? 18:56:56 yes, "rescue mode" is crucial, if you have it on 18:57:02 it = host-only 18:57:06 nirik: as I see it now, it's "the first time we create a generic one, thereafter we create a hostonly" 18:57:06 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 mitr: but that feature's been there for 6 releases or so 18:57:26 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 er 18:57:30 notting: hm 18:57:32 s/hostonly/generic/ 18:57:48 #agreed Feature is approved, (+5, -4, 0) 18:57:54 pjones, rephrase please :) 18:58:04 feature passed 18:58:34 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 er 18:58:44 dammit, generate a new generic one 18:58:50 Actually - how about always building both? That would cost us in space and upgrade time, but remove some reliability concerns. 18:58:50 so we've always got 1 generic + n hostonlys 18:59:13 mitr: then we use _more_ space in /boot 18:59:18 nirik: yes 18:59:25 mitr: that would probably blow the size limitation we've bumped users up to pretty badly 18:59:49 anyhow, I would like to ask folks to work with haraldh on any changes in #fedora-devel... 18:59:53 and we can move on. ;) 18:59:56 right now with a 500MB /boot we're using ~350MB for 3 kernels. 18:59:56 ok 19:00:00 * abadger1999 likes pjones' tweak 19:00:21 #topic #1036 F19 Feature: Enterprise / distributed two-factor authentication - https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication 19:00:23 .fesco 1036 19:00:23 https://fedorahosted.org/fesco/ticket/1036 19:00:26 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 I don't like the name of this feature. ;) 19:01:03 I dislike nearly everything about this, not least that the Feature owners aren't replying to queries. 19:01:24 man, FI's 2FA isn't enterprisey enough? 19:01:34 sgallagh: Could you elaborate? AFAICS it's just an unfortunately-named "new package added" feature 19:02:05 sgallagh, same question as mitr 19:02:18 or they did not define the scope correctly 19:02:35 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 They've ignored my emails asking for detail and potential involvement with the authhub project. 19:03:07 so -1 for now? 19:03:28 I'm pretty firmly -1 on this. 19:03:44 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 I don't care if they add the packages, but I don't want us advertising untested auth stuff 19:04:19 notting, +1 19:04:32 sgallagh: well it's an OpenID web service and a PAM module... not that much of an authentication system 19:04:45 so, yeah, I'm -1 now, if they rescope, rename and start working with everyone we can revisit. ;) 19:05:03 notting: yeah, I think the problem here is mostly descriptive, and they could rephrase it and I'd be for it. 19:05:15 -1 same as nirik 19:05:18 Proposal: Defer for renamed feature that addresses the above 19:05:22 nirik: Are we proposing to allow them to resubmit after Feature Submission Freeze? 19:05:36 (deferring both gives a chance to redeem, and auto-rejects the feature if the owner is really nonresponsive) 19:05:43 well, they can retitle, or we can arbitrarily retitle it for them 19:05:51 sure, I'm fine with defering... 19:05:51 but i'd be +1 to mitr's proposal too 19:05:59 sgallagh: we're not considering it "unsubmitted", I think. 19:06:07 sgallagh: I'd say sure, since I don't really see this having any impact on anything. 19:06:34 but sure, +1 defer and ask feature owners to address issues. 19:06:47 +1 defer 19:06:49 DItto: +1 defer and ask feature owners to address issues. 19:06:55 sure 19:07:14 +1 defer 19:07:40 +1 19:07:44 (to defer) 19:08:08 pjones: ? 19:08:36 I'm +1 to deferring, as I said above. 19:08:40 #agreed Feature is defered. Feature owners are asked to address concerns. (+9, 0, 0) 19:08:45 ok, moving on 19:08:49 #topic #1038 F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice 19:08:50 .fesco 1038 19:08:50 https://fedorahosted.org/fesco/ticket/1038 19:08:52 nirik: #1038 (F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice) – FESCo - https://fedorahosted.org/fesco/ticket/1038 19:08:55 [Andrea Pescetti, feature owner, here if needed] 19:09:08 ...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 My only concern is with the size impact on mirrors. 19:09:43 pescetti: welcome. Thanks for stopping by. 19:09:53 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 We may need to sort out 1) soffice 2) unopkg 3) swriter 4) oowriter 19:10:28 (and of course Libreoffice should be still preferred as default which implicates it keeps the soffice, ooffice binaries) 19:10:40 mitr: oocalc ? ooimpress? ... 19:10:47 my biggest concern here really is doubling the size of updates. 19:10:55 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 I think the size argument seems odd here. 19:11:05 drago01: taking 3) and 4) as a class of names 19:11:23 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 we ship all kinds of crazy big things. 19:11:41 pjones: If at all possible, I'd rather they not conflict in the long-term. 19:11:47 pjones: Using Conflicts in this case would be contrary to packaging guidelines 19:11:52 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 pjones: alternatives is kind of weird for gui apps imo 19:11:54 I can potentially see a lab environment where students might want a choice. 19:11:55 sgallagh, +1 19:12:01 because systems may very well want both of these installed. 19:12:03 As long as AOO isn't installed by default, I'm fine with alternatives 19:12:10 (different than the mariadb vs mysql use case) 19:12:11 drago01: yeah, doesn't work very well since desktop stuff ignores it 19:12:21 notting, +1 19:12:25 abadger1999: I continue to not care ;) We get to ask FPC for things if we need to. 19:12:43 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 notting: I agree 19:13:13 pjones: But I don't think a case could be made that this is a worthwhile use of conflicts there. 19:13:14 notting: yeah, that's a pretty good point. 19:13:15 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 I hope we can work out the conflicting packages nicely 19:13:27 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 sgallagh: right 19:13:41 but I'm not sure fesco needs to do that... I hope LO and AOO people can do that. ;) 19:13:56 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 (well we still need to get the MIME priority _by default_ to point to the preferred implementation) 19:14:12 alternatives would be the wrong technology... if they want to explore using environment-modules, they could go that route though. 19:14:15 pjones: fair point :) 19:14:34 abadger1999: +1 19:14:35 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 sgallagh: definitely Is that even a question? 19:15:18 pjones, +1 19:15:23 mitr: Yes, a loaded one :) 19:15:43 (more a straw-man) 19:15:48 so, where are we? 19:15:53 The proposal does not (obviously) ask to alter defaults. 19:16:20 * nirik is +1 for the feature 19:16:30 did anyone want to propose changes to the feature? 19:16:33 Yeah, the proposal only mentions the conflict without resolving it currently. 19:16:39 I'm inclined to stick with my original proposal and trust that these two communities can sort the details out. 19:16:41 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 So a mere "+1" is ambiguous 19:16:52 pjones: I'm -1 on alternatives. 19:16:58 nirik: oh, why? 19:17:13 * pjones scans back but doesn't see... 19:17:17 +1 with the conflict resolved somehow (I would not allow the conflict to stay explicit) 19:17:20 because thats a per machine default. Not a per user one. 19:17:32 o_O 19:17:43 nirik: Sure, but desktop files can point at the real binary, rather than the alternatives representation 19:17:45 surely most machines that run *OO at all are single-user machines. 19:17:50 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 +1 but solve the conflict before and prefer LO 19:18:01 right, the desktop files won't care. alternatives is *just* for people running it on the command line. 19:18:12 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 mitr: right, so I would prefer a solution to the conflicts that does not involve alternatives. 19:18:20 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 nirik, +1 19:18:29 mitr: true 19:18:41 mitr: but those are still mostly invoking from desktop, I wold think 19:18:52 pjones: yes 19:19:01 mitr: also those are situations where the institution running the machine has picked one or the other and not installed both 19:19:11 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 which means that if AOO just use binaries like aoofice aoowriter etc. would be fine 19:19:28 mitr: because those are "we support this one only for our users" cases 19:19:42 pjones: Most likely, but not guaranteed. I remember my college labs having both StarOffice, MSOffice (in WINE) and one other installed. 19:19:42 nirik: Definitely available, (firendly) discussion already started. 19:19:48 yeah, alternatives isn't necessary, just kind of nice. just making them take different file names is fine 19:19:51 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 there could be cases where someone love librecalc, but prefers aoowriter. ;) 19:20:12 abadger1999: +1 19:20:16 nirik: dooon't care .... (about that case) 19:20:32 nirik: awfully hard to care about that. that person knows how to run whichever they want on purpose. 19:20:35 pescetti: excellent. :) 19:20:36 abadger1999: I don't care about the last sentence but +1 19:20:41 abadger1999: yeah, +1 19:20:42 +1 19:20:47 abadger1999: I'm +1 to that proposal 19:20:51 abadger1999, +1 19:20:57 abadger1999: i could be +1 to that. i'd be fine with Conflicts: if it came to that, so... *shrug* 19:21:26 thats +7? 19:21:30 Let's support doing things right even in cases where it doesn't matter :) 19:21:40 t8m / mmaslano ? 19:21:42 notting: I guess we can revisit that if the LO and OO packagers can't work out a compromise. 19:21:48 I said +1 19:21:55 oh, sorry. 19:21:56 +1 19:22:01 * nirik looks back to see who he missed. 19:22:08 (I actuall said it as well) 19:22:29 #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 #topic #1040 F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown .fesco 1040 19:22:37 https://fedorahosted.org/fesco/ticket/1040 19:22:48 mitr: you had questions here? 19:23:01 .fesco 1040 19:23:04 nirik: #1040 (F19 Feature: firewalld Lockdown - https://fedoraproject.org/wiki/Features/FirewalldLockdown) – FESCo - https://fedorahosted.org/fesco/ticket/1040 19:23:17 The devel discussion today arrived at a point where it is, at least to me, completely unclear what the feature does 19:23:27 But it doesn't impact the release overall and it's off by default, so I can be +1 anyway :) 19:23:47 I htink the lockdown applies to dbus sending apps 19:23:51 my understanding is that it locks local *applications* from changing the firewall (not users) 19:24:14 but i'm +1 19:24:16 yeah, so system-config-printers couldn't tell it to open cups ports 19:24:19 notting: We don't have "application" as a security concept at all 19:24:21 for example 19:24:58 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 mitr, +1 19:25:37 yeah, it seems like it's the interface perhaps? or is it looking at names? 19:25:51 Does anyone want to -1 or ask for deferral? 19:26:03 If not, we can get this figured out on the mailing list later 19:26:18 I guess I would like to defer now... given I am not clear how it acts. 19:26:41 proposal: defer for now, ask feature owner for more details. 19:26:52 Let's send it back to discussion and ask for the Feature page to add details. 19:27:05 defer 19:27:07 +1 defer 19:27:14 OK, +1 defer 19:27:27 +1 defer 19:27:28 If we're confused, users who read the release notes will be confused too 19:27:36 #agreed Feature is deferred for now, feature owner to provide more details. 19:27:39 abadger1999: good point about the relnotes 19:27:49 #topic #1042 F19 Feature: GNOME 3.8 - https://fedoraproject.org/wiki/Features/Gnome3.8 19:27:49 .fesco 1042 19:27:49 https://fedorahosted.org/fesco/ticket/1042 19:27:51 nirik: #1042 (F19 Feature: GNOME 3.8 - https://fedoraproject.org/wiki/Features/Gnome3.8) – FESCo - https://fedorahosted.org/fesco/ticket/1042 19:28:00 This feature has no contingency plan. 19:28:05 do we care? 19:28:05 * notting was -1 to defer. whatevs. 19:28:22 Historically GNOME was never a problem, but, well, lessons learned from F18 and all 19:28:27 or was it added. 19:28:40 https://fedoraproject.org/wiki/Features/Gnome3.8#Contingency_Plan 19:28:54 that's kind of laughable 19:29:00 it's not a contingency plan 19:29:11 it's basically saying "we'll ship whatever we wind up with" 19:29:16 That reads as "If 3.8 isn't ready, ship it anyway" 19:29:22 sure. 19:29:28 anyway, i don't care. i don't think we have a choice. so +1 19:29:32 given our schedule tho, I'm not too worried. 19:29:44 it's roughly the same as the KDE contingency plan 19:29:46 nirik: was about to say the same 19:29:49 except we always did that in regards to Gnome 19:29:55 i'm fine with it. +1 19:29:56 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 anyhow, +1 to the feature. 19:29:59 since it'll land months before the beta even if it slips... 19:30:00 +1 19:30:02 Too big to fail? ;-) [ /me agrees with nirik about schedule though] 19:30:12 +1 to the feature 19:30:14 Yeah, I'm fine with it. +1 19:30:15 +1 19:30:18 I'm not sure what kind of plan things like this could have... 19:30:20 +1 whatever 19:30:27 "Apply Epoch and ship previous version"? 19:30:31 The GNOME guys always come through in the end. 19:31:09 nirik: That wouldn't likely work anyway. GNOME 3 will likely pull along changes underneath it as well. 19:31:31 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 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 abadger1999: that's what we said about anaconda. of course we also said the schedule was insufficient. 19:32:02 so we know if we'll need to watch it closely right from the start. 19:32:06 +1 to the feature (who cares) 19:32:10 #agreed Feature is approved (+9, 0, 0) 19:32:23 #topic #1045 F19 Feature: Cinnamon as Default Desktop - https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop 19:32:23 .fesco 1045 19:32:23 https://fedorahosted.org/fesco/ticket/1045 19:32:25 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 yeah... -1 19:32:48 0, why do we need default again? 19:32:51 * notting is -1 19:32:58 I don't necessarily like how we do default desktop but I do not think this feature is the answer. 19:33:00 -1 19:33:09 strong -1 19:33:23 (same as what abadger1999 said) 19:33:25 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 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 same as abadger1999 -1 19:33:50 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 -1, for basically all of the same reasons as mitr 19:34:17 I guess he responded, but anyway I'm afraid they don't have enough manpower 19:34:19 mmaslano: well, it's hard to present people with "what would you like to download? sakjhsdf [ ] sakjhdaywhgdad [ ] or akjsgsads [ ] 19:34:31 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 mitr: I think both of your comments there are fair, sure. 19:34:43 mitr: all our docs, all our wiki pages, all our websites 19:34:48 nirik, mmaslano, NOT GOING TO FIX THIS TODAY 19:34:53 right. 19:35:21 Now *KDE as Default* on the other hand... No, let's not discuss this now :) 19:35:29 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 #agreed Feature is declined. (0, 8, 1) 19:35:58 #topic #1055 F19 Feature: New firstboot - https://fedoraproject.org/wiki/Features/NewFirstboot 19:35:58 .fesco 1055 19:35:58 https://fedorahosted.org/fesco/ticket/1055 19:36:00 nirik: #1055 (F19 Feature: New firstboot - https://fedoraproject.org/wiki/Features/NewFirstboot) – FESCo - https://fedorahosted.org/fesco/ticket/1055 19:36:10 sgallagh: you had some questions/concerns here I think? 19:37:01 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 the feature does include: "Anaconda, initial-setup and Gnome Inital Experience will communicate..." 19:37:51 so, hopefully everyone is talking to each other. 19:37:53 This includes dealing with the situation where KDM is selected as the display manager, rather than GDM 19:38:22 nirik: That language assumes GDM (which is where GIE runs). I want to be assured that KDM is addressed. 19:38:29 and hopefully lightdm too. ;) 19:38:35 it's there and as far as I know there should not be conflict 19:38:37 Sure, but who uses that? ;-) 19:38:43 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 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 and for kdm/lightdm it's like with old firstboot 19:39:33 sgallagh: would you like us to defer to try and answer those questions? or ? 19:39:37 sgallagh, I do 19:39:47 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 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 unless they want implement kie/lie ;-) 19:40:11 notting: true. 19:40:31 I 19:40:36 Can't type, apparently. 19:40:42 But nevertheless I'm +1 to the feature. 19:40:47 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 +1 19:40:52 so +1 - I think the current situation with firstboot is a mess anyway 19:40:54 With that in mind, I'm +1 here 19:40:57 * nirik is +1 too 19:41:07 +1 with sgallagh comment 19:41:21 +1 19:41:43 (and +1 to the comment about system-wide things belonging to firstboot) 19:42:29 abadger1999: ? 19:42:40 +1 19:42:43 #agreed Feature is approved (+9, 0, 0) 19:42:49 #topic #1056 F19 Feature: OpenAttestation - https://fedoraproject.org/wiki/Features/OpenAttestation 19:42:49 .fesco 1056 19:42:49 https://fedorahosted.org/fesco/ticket/1056 19:42:51 nirik: #1056 (F19 Feature: OpenAttestation - https://fedoraproject.org/wiki/Features/OpenAttestation) – FESCo - https://fedorahosted.org/fesco/ticket/1056 19:43:16 notting: you had questions here? 19:43:32 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 if it's only measuring the kernel & initramfs it's not actually attesting about the security/non-tamperedness of the system 19:44:07 but hey, if they want it even in that state... i guess? 19:45:06 mclasen: https://fedoraproject.org/wiki/Features/InitialExperience ? or https://fedoraproject.org/wiki/Features/NewFirstboot ? 19:45:22 notting: yeah, it's not clear to me either actually. 19:45:44 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 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 mitr, +1 19:46:18 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 mclasen: ok, if you can be more specific I can try and help... 19:46:24 (well, globbing still pulls it in) 19:46:34 nirik: I'll read the logs, thanks 19:46:35 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 I'm +1 19:46:43 sure, +1 I guess. 19:46:46 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 mclasen: I don't think we've discussed it yet... 19:46:55 +1, echoing notting 19:46:55 compared to like dm-verirty, or something 19:47:05 +1 anyway 19:47:07 +1 19:47:33 abadger1999: ? :) 19:47:37 notting: I thought that went without saying TBH 19:47:56 +1 same as notes notting 19:48:01 #agreed Feature is approved (+9, 0, 0) 19:48:06 * abadger1999 butchered that sentence 19:48:07 i didn't vote 19:48:07 #topic #1064 F19 Feature: Simplify Java/Maven Packaging using XMvn - https://fedoraproject.org/wiki/Features/Simplified_Maven_Packaging 19:48:07 .fesco 1064 19:48:07 https://fedorahosted.org/fesco/ticket/1064 19:48:09 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 jwb: oops. ;( 19:48:16 * nirik checks his eyes. 19:48:25 it's ok. i would have been +1 anyway 19:48:29 jwb: you want to vote +1? or shall I roll back? 19:48:31 ok 19:48:41 abadger1999: any news on guidelines here? 19:48:47 +1 19:48:54 nirik: We approved them today :-) 19:48:56 they started commits already 19:49:03 +1 19:49:05 cool. +1 then. 19:49:19 +1 19:49:21 so, I assume they are just commiting and the mass rebuild will pick them up? or are they building too? 19:49:22 +1 19:49:38 sochotni: You still around to answer questions? 19:49:46 +5 so far 19:49:47 +1 from me regardless 19:50:05 +1 19:50:06 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 +1 19:52:39 * pjones +1 19:52:46 #agreed Feature is approved (+9, 0, 0) 19:52:58 #topic #1066: F19 Feature: Network Team driver - Update for new features - https://fedoraproject.org/wiki/Features/TeamDriverUpdate 19:52:59 .fesco 1066 19:52:59 https://fedorahosted.org/fesco/ticket/1066 19:53:01 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 i don't think this is really a feature 19:53:19 that was my concern as well 19:53:26 I looked at this to make sure it was enabled in the kernel, and it has been for ages? 19:53:39 we took some extra patches in the f18 timeframe 19:53:46 basically backports of stuff in net-next 19:53:51 but that's all it was 19:54:02 It would be nice if there was any language in here about NM integration 19:54:03 so, perhaps they want press for their driver existing? 19:54:11 but that seems yeah... 19:54:12 because they can "improve experience" all day long without anybody seeing it. 19:54:45 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 it's not a version bump 19:55:34 yeah, without anything higher level using it, this is pretty dry. 19:55:38 mitr: the version bump features are usually all for much large components, or collections of components 19:55:41 mitr: I was thinking about that today but... most were either "must coordinate with others (a la boost) 19:55:57 or "Visible to a lot of end user desktops" 19:56:30 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 nirik: quick, 0xp * 100 = ? 19:56:51 yeah, still no users experiencing anything. 19:57:21 sgallagh, +1 19:57:43 +1 to sgallagh 19:57:51 +1 sgallagh 19:57:57 * pjones +1 to that as well 19:58:07 +1 19:58:10 sure, +1 to that proposal too. 19:58:25 thats -7 19:58:31 (I think) 19:58:35 +1 to the proposal 19:58:53 Matches my count. (With one more from jwb since I started typing) 20:00:08 #agreed The feature is declined. (0, -8, 0) 20:00:11 #topic #1068: F19 Feature: Trusted Network Connect (TNC) - https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29 20:00:11 .fesco 1068 20:00:11 https://fedorahosted.org/fesco/ticket/1068 20:00:15 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 #info go ahead and land team driver enhancements without fanfare 20:01:25 I'd like to see this resubmitted with a summary and / or detailed description in english. 20:02:09 (instead of this bizarre blend of marketting copy and security speak) 20:02:14 marketing 20:02:39 and a glossary. ;) 20:03:07 the questions about integration with NM did get answered some on devel@ 20:03:10 I guess they have NM integration also in scope now? 20:03:50 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 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 nirik: +1 20:04:31 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 nirik: Or at least the Release Notes 20:04:36 the submitter is non-native, so i'd prefer we phrase that better 20:04:45 but I'm wondering if we're losing something in translation 20:04:55 * nirik tries again. 20:05:38 abadger1999: not exactly, no 20:05:41 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 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 and I don't think "clients' posture" means anything to anybody not working on the feature. 20:07:08 nirik: +1 20:07:10 nirik: +1 20:07:13 nirik: +1 20:07:17 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 ? 20:07:23 (if I could speel) 20:07:51 +1 to your second version, once you respell it 20:07:54 nirik, +1 20:07:59 +1 to nirik 20:08:20 +1 20:09:46 #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 #topic #1069: F19 Feature: Add LVM Thin provisioning support to the yum-fs-snapshot #plugin - https://fedoraproject.org/wiki/Features/YumFsSnapshotThinpSupport 20:09:55 .fesco 1069 20:09:55 https://fedorahosted.org/fesco/ticket/1069 20:09:56 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 i asked a bunch of questions, but i'm ok with this. +1 20:11:04 ok, +1 from me. 20:11:11 +1 20:11:43 +1 20:11:45 +1 20:11:51 +1 20:12:02 +1 20:12:03 +1 20:12:16 +1 20:12:18 #agreed Feature is approved (+9, 0, 0) 20:12:25 #topic #1070: F19 Feature: Yum Groups as Objects - https://fedoraproject.org/wiki/Features/YumGroupsAsObjects 20:12:25 .fesco 1070 20:12:25 https://fedorahosted.org/fesco/ticket/1070 20:12:27 nirik: #1070 (F19 Feature: Yum Groups as Objects - https://fedoraproject.org/wiki/Features/YumGroupsAsObjects) – FESCo - https://fedorahosted.org/fesco/ticket/1070 20:13:17 -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 +1 20:13:40 (To be clear, that's a +1 to feature) 20:13:55 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 +1 20:14:20 so, -2/+4 so far 20:14:21 +1 as a feature, if only to relnote the behavior change 20:14:28 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 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 +1 20:14:37 Since now it's also order-dependenty 20:14:39 *dependent 20:15:15 so, thats -2/+6... 20:15:36 pjones: ? 20:15:55 sorry, got distracted here 20:16:06 I'm not sure it needs to be a feature, but hey, sure, +1, go ahead. 20:16:22 #agreed Feature is approved (+7, -2, 0) 20:16:29 #topic #1071: F19 Feature: systemd Calendar Timers - https://fedoraproject.org/wiki/Features/SystemdCalendarTimers 20:16:29 .fesco 1071 20:16:29 https://fedorahosted.org/fesco/ticket/1071 20:16:32 nirik: #1071 (F19 Feature: systemd Calendar Timers - https://fedoraproject.org/wiki/Features/SystemdCalendarTimers) – FESCo - https://fedorahosted.org/fesco/ticket/1071 20:17:35 +1 20:17:48 There was a long discussion but it all seemed to aim at things other than the feature? 20:17:58 yeah. i don't understand the discussion 20:17:58 so, the feature itself doesn't want to convert or change anything. 20:18:05 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 simply to make the feature known to users. 20:18:16 Yeah, so I think I'm +1 to the feature 20:18:21 notting, sure, which the feature doesn't even attempt to address 20:18:28 * nirik is +1 for the feature. 20:18:44 +1 20:18:58 thats +5 so far. 20:19:02 Agreed, +1 to the feature itself. 20:19:15 um I abstain 0 20:19:15 +1 if "#info Do not hurry up converting your cron jobs to timers" is added 20:19:22 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 nirik, I think it should be F20 material 20:20:06 sure, so should we say: "no packages should convert to using this yet" ? 20:20:14 * pjones is +1 20:20:14 nirik, please +1 20:20:33 nirik: Yes, +1 to that rider 20:20:37 * abadger1999 is fine with that addition 20:20:37 t8m: Do you have a specific concern? 20:20:46 yeah, that's reasonable. 20:20:47 mitr, confusion of users/admins? 20:20:55 t8m: ok 20:21:07 I'll note that systemd itself does use them already. ;) 2 timer units 20:21:22 nirik, I think use within systemd itself is OK 20:21:22 oh, those are old style I think 20:21:24 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 yeah. 20:21:52 so, final proposal: Feature is approved. No packages should convert to using this feature yet" 20:21:53 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 seems excessive, but whatever 20:22:18 +1 to nirik's wording (which doesn't have the "upstream" problem) 20:22:25 nirik, +1 20:22:25 Can we rephrase that to "There is no *requirement* to convert packages to use this feature" 20:22:35 sgallagh, that's too weak 20:22:47 i'm ok with the rider. i'd like to work more on where we want to end up 20:22:51 ok 20:22:53 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 but that's unrelated to the tech being there 20:23:00 Fair enough 20:23:07 I withdraw my suggestion 20:23:21 * nirik is +1 to his own proposal. 20:23:30 thats +3 so far. 20:23:43 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 +1 to nirik 20:24:43 anybody else? 20:24:50 +4 so far... 20:24:50 nirik: +1, for lack of a better way to put it 20:24:52 +1, if I forgot to do so 20:25:16 * notting is getting close to having to leave 20:25:44 any other votes? thats +6 20:25:56 +1 20:26:08 we are getting toward the end. ;) 20:26:31 #agreed Feature is approved. No packages should convert to using this feature yet. (7, 0, 0) 20:26:36 #topic #1072: F19 Feature: systemd/udev Hardware Database - https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase 20:26:36 .fesco 1072 20:26:36 https://fedorahosted.org/fesco/ticket/1072 20:26:37 nirik: +1 to your wording 20:26:38 nirik: #1072 (F19 Feature: systemd/udev Hardware Database - https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase) – FESCo - https://fedorahosted.org/fesco/ticket/1072 20:27:28 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 me as well 20:28:15 i'm going to defer to whatever notting thinks here. 20:28:18 Same here 20:28:20 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 yep. I agree. 20:28:47 it looks like you can update it on the fly. 20:28:55 but it would be nice to be a seperate package. 20:29:05 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 -r--r--r--. 1 root root 5.3M Feb 6 13:28 /etc/udev/hwdb.bin 20:29:18 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 I'd be ok to just +1 the feature, but I'm worried if we do packaging concerns will be forgotten. 20:30:37 we never really update hwdata in fedora, so it's unlikely to be a huge concern there 20:30:38 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 Proposal: Feature is approved conditional on notting's concerns about how we ship the data being addressed 20:32:05 abadger1999: +1 20:32:08 * pjones doesn't care, he's +1 to it in general 20:32:08 sure, +1 on that 20:32:31 That works for me, +1 20:32:39 +1 20:32:42 +1 20:32:47 +1 20:33:03 that's probably stronger than i would put it... but sure 20:33:24 well, "being addressed" is vague enough that "no" covers it. 20:33:25 the packaging is suboptimal, IMO. its' not *wrong* 20:34:09 * nirik sees +8. 20:34:20 #agreed Feature is approved conditional on notting's concerns about how we ship the data being addressed (+8, 0, 0) 20:34:30 notting: 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 ok, so thats the last feature I had. 20:35:01 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 More mobile Broadband -- I had a small thing 20:35:24 ok, just a sec, let me prep topic. ;) 20:35:41 Can we also return to Apache OpenOffice for a very small moment? 20:35:55 mitr: sure, after mobilebroadband? 20:36:01 nirik: of course 20:36:04 #topic #1051 F19 Feature: More Mobile Broadband - https://fedoraproject.org/wiki/Features/MoreMobileBroadband 20:36:04 .fesco 1051 20:36:04 https://fedorahosted.org/fesco/ticket/1051 20:36:06 nirik: #1051 (F19 Feature: More Mobile Broadband - https://fedoraproject.org/wiki/Features/MoreMobileBroadband) – FESCo - https://fedorahosted.org/fesco/ticket/1051 20:36:19 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 #info Feature owners should notify any people/packages that need to be modified for the new API 20:37:16 cool. Do you want to defer until that happens? or just approve and revisit? 20:37:28 I'm okay to approve and revisit. 20:37:43 ok. 20:37:50 The mmeaty portion of the feature seems great. It's just the coordination portion that I want to see addressed. 20:38:01 anything else on this feature from anyone? 20:38:35 #topic #1038 F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice 20:38:36 .fesco 1038 20:38:36 https://fedorahosted.org/fesco/ticket/1038 20:38:38 mitr: ? 20:38:39 nirik: #1038 (F19 Feature: Apache OpenOffice - https://fedoraproject.org/wiki/Features/ApacheOpenOffice) – FESCo - https://fedorahosted.org/fesco/ticket/1038 20:38:57 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 (that is /usr/bin/openoffice.org, to provide context) 20:39:29 no 20:39:31 Well, it's not that urgent, I hope I got it right. 20:39:43 I would very much doubt that anyone uses that alias from command line 20:39:44 installing both should not conflict 20:39:51 if the packagers are talking, they can continue to talk 20:40:00 * nirik nods. 20:40:18 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 ok 20:40:52 yeah, I'd really prefer if everyone tries to talk and be reasonable... (sometimes it happens! ) 20:41:19 OK for me too. We will definitely try to talk and clarify it together. 20:42:23 #info maintainers to continue to talk and try and work out solutions to the overlapping files. 20:42:29 anything else on this? 20:42:39 does anyone have any further features they want to discuss? 20:42:43 i didn't see glibc-2.17 discussed... i thought it was ready for voting... 20:43:06 law, it was approved without discussion 20:43:11 ah, works for me 20:43:17 didn't figure you'd complain ;) 20:43:19 better than discussion without approval 20:43:36 * nirik looks over the list one last time. 20:43:50 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 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 ooh, 2.17 added clock_gettime to libc finally. 20:44:00 thanks! 20:44:05 it is working somewhat better than the old method. 20:44:14 #topic Next week chair 20:44:21 who wants the gavel next week? 20:44:35 I won't be around next week. 20:44:54 I can do it 20:45:00 mmaslano: thanks! 20:45:05 #action mmaslano to chair next week 20:45:09 #topic Open Floor 20:45:18 I will not be around for next week 20:45:24 sorry, have to head out now 20:45:34 any items for open floor? or any last minute calls for feature rediscussion? ;) 20:45:40 Just an fyi from fpc. 20:46:02 on banning sysinit scripts in subpackages: https://fedorahosted.org/fpc/ticket/243#comment:2 20:46:24 vote for the ban failed, +1: 4, 0: 4, -1: 0 20:46:26 ok, so the existing ones will just linger? 20:46:52 So we decided that by and large we considered the current guidelines sufficient 20:46:53 I guess at the packagers discretion ? 20:47:00 nirik: Yeah, at packager discretion... 20:47:01 so, we should communicate that with the people who are still riding that horse. 20:47:15 (the "everything must change" horse, that is.) 20:47:32 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 pjones: note -- this is different than converting to ship a systemd unit file 20:48:03 pjones: That's still in the guidelines as a must. 20:48:48 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 it's these: http://paste.fedoraproject.org/2627/ 20:49:09 abadger1999: yeah, I got that. 20:49:12 k 20:49:14 cool. 20:49:14 * nirik finds them a complete waste, but whatever. 20:49:28 nirik: like oh so many whole packages ;) 20:49:50 well, a more deliberate waste. going out of the way to be a waste... but sure. 20:50:27 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 we need to come up with something for 9 more minutes 20:51:47 jwb: No. No we don't 20:51:51 haha 20:51:52 jwb: no we don't 20:51:52 jwb: I don't think this is like budgets, where it's "use it or lose it" 20:51:58 let's go home 20:52:20 more like use it and lose it ;-) 20:52:35 ha. 20:52:40 ok, thanks for coming everyone. :) 20:52:45 #endmeeting