17:01:49 #startmeeting FESCO (2012-06-04) 17:01:49 Meeting started Mon Jun 4 17:01:49 2012 UTC. The chair is mjg59. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:49 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:54 #meetingname fesco 17:01:54 The meeting name has been set to 'fesco' 17:01:54 #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 17:01:54 Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 17:02:03 * mitr waves 17:02:05 * nirik waves. 17:02:07 * limburgher here 17:02:09 #topic init process 17:02:39 hi 17:02:52 Hello 17:03:01 morning, party people. 17:03:32 Vague recollection that notting may have said he wouldn't be here? 17:03:43 Ditto sgallagh 17:03:53 mjg59, I think so 17:03:55 yeah, they voted in tickets. 17:04:01 Ok 17:04:07 So let's get on with it 17:04:12 #topic #857 F18 Feature: Initial Experience 17:04:17 .fesco 857 17:04:18 mjg59: #857 (F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience) – FESCo - https://fedorahosted.org/fesco/ticket/857 17:04:24 * mitr points at the talk page, recently updated 17:05:11 mclasen: Hi, around? 17:05:11 * mclasen is still working on answering and updating 17:05:25 sorry for not getting that done in time 17:05:32 mclasen: No problem 17:05:47 mclasen: Ok discussing in real time a little? 17:05:50 then should we postpone? 17:05:57 * nirik is fine with waiting a week. 17:06:00 Or yeah we could postpone to next week 17:06:16 I can wait. 17:06:24 * t8m as well 17:06:33 mclasen: I'd like to see a description of how this fits with Anaconda plans 17:06:34 sure, I'm fine with answering questions 17:06:51 But if you're working on answering stuff there then I've no problem waiting a week 17:06:54 (although I might not be reelected) 17:07:00 firstboot maintainer is generally fine with the plan, FWIW 17:07:25 My primary concern is non-GNOME spins, and the talk page already says that this feature doesn't concern tnem. 17:07:29 ... them 17:07:30 mitr, will he continue to maintain firstboot for non-gnome install? 17:08:02 t8m: I haven't asked - I assume that $somebody would take care of it, but do we in general want the duplication? 17:08:07 #proposal postpone discussion on this feature until next week? 17:08:20 mjg59, +1 17:08:22 +1 17:08:26 +1, probably 17:08:28 +1 17:08:31 +1 17:08:36 Ok 17:08:39 +1 17:09:01 #agreed postpone feature discussion until next week so mclasen can provide further feedback on the page 17:09:04 mclasen: Thanks! 17:09:11 #topic #859 F18 Feature: Active Directory 17:09:16 .fesco 859 17:09:17 mjg59: #859 (F18 Feature: Active Directory - https://fedoraproject.org/wiki/Features/ActiveDirectory) – FESCo - https://fedorahosted.org/fesco/ticket/859 17:09:19 (sorry, pulled away for a family emergency) 17:09:23 ok, I'll have a better page next week, but please feel free to add concerns to the talk page in the meantime 17:09:48 _1 17:09:50 okay fwiw I was also +1 to that. 17:09:50 Er 17:09:54 mclasen: No problem 17:09:56 mclasen: thanks! 17:09:58 (delaying a week) 17:10:04 Er, what I meant to say was: 17:10:08 +1 (for Active Directory) 17:10:24 stefw: just in time :) 17:10:27 * mclasen lures stefw over 17:10:30 hey guys 17:10:31 yeah, +1 from me... sounds nice. 17:10:37 +1 to the feature 17:10:39 stefw, what does 'Fix authconfig so it doesn't break config files.' mean? 17:10:40 +1 AD 17:10:46 otherwise +1 17:11:13 stefw: You should be able to setup domain logins from Firstboot or Initial Setup. 17:11:31 t8m: it currently breaks krb5.conf's dns defaults, need to file a bug... 17:11:37 is it Initial setup the previous feature? 17:11:42 yes 17:11:42 yes 17:11:46 think firstboot for now... 17:11:57 ok 17:12:01 the thing that creates the first user account 17:12:03 stefw, OK, please file it, we'll discuss/solve it there 17:12:08 could even be anaconda, I believe ? 17:12:37 anaconda sets just root password IMHO 17:12:41 I'm +1 for this feature 17:12:49 mclasen: anaconda doesn't create user accounts; firstboot does that. 17:13:17 oh, I thought the ui rewrite made that an option in anaconda 17:14:15 Ok who hasn't voted for this feature 17:14:23 mclasen: oh, hrm. I'm not 100% sure on that. 17:14:33 mclasen: been paying attention to other things more :/ 17:14:53 +1 17:15:13 #agreed Active Directory is accepted as an F18 feature 17:15:20 #topic #860 F18 Feature: Boost 1.50 Uplift 17:15:25 .fesco 860 17:15:27 mjg59: #860 (F18 Feature: Boost 1.50 Uplift - https://fedoraproject.org/wiki/Features/F18Boost150) – FESCo - https://fedorahosted.org/fesco/ticket/860 17:15:37 +1 from me 17:15:50 +1 with the regular feature process improvements disclaimer 17:15:53 sure, +1 17:15:55 +1 17:16:01 +1 17:16:56 as much as I think you'd have to be crazy to use boost, +1 17:16:58 t8m: actually, this has a scope wide enough that it should go through some kind of notification in any cases - but it's true that the maintainers do a great job of it 17:17:25 mitr, notification sure, if there is anything for FESCo to decide? not sure so 17:17:54 mitr, so I think some more lightweight process should be fine for such feature 17:17:55 limburgher: ? 17:17:57 t8m: "not this time, we are moving to LLVM" or something 17:18:01 +1. 17:18:07 Sorry, distracted. . . 17:18:16 #agreed Boost 1.50 accepted as an F18 feature 17:18:22 $topic #856 Request to be made admin of the packager group 17:18:28 Oopens 17:18:35 #topic #856 Request to be made admin of the packager group 17:18:38 .fesco 856 17:18:39 mjg59: #856 (Request to be made admin of the packager group) – FESCo - https://fedorahosted.org/fesco/ticket/856 17:18:43 * limburgher voted already. 17:18:54 +1 17:19:02 * mitr voted +1 17:19:03 +1 too 17:19:06 I think this is fine. 17:19:15 I already voted, +1 17:19:31 So, did we want to talk about criteria? 17:20:17 * pjones is also +1 on that. 17:20:46 Are there any criteria proposed? 17:20:50 I'm fine with these requests coming to fesco 17:21:18 No obvious proposals at th emoment 17:21:31 I don't see there being that many... and we can revisit if there is any kind of bottleneck 17:21:38 nirik: And us just evaluating them on individual merit, rather than something concrete? 17:21:42 I think asking fesco is fine for this process, since it's the only request we've had for it ever AFAIK 17:21:56 +1 to having asking FESCO be the process for now. 17:21:58 limburgher: yeah. Possibly with recommendation from the sponsors? 17:22:04 Yeah, it's infrequent enough that status quo seems fine 17:22:05 I didn't intend to propose any, but it did seem odd to me that we have people with privileges who are not really involved with the project. 17:22:23 And also anybody deserving of the status bump would be somebody we're already quite familiar with 17:22:23 nirik: Certainly wouldn't hurt. 17:22:27 tibbs|w: Think it might be worth checking on the status of the existing sponsors? 17:22:43 s/sponsors/admins/ you mean? 17:22:48 Er, sorry, yes 17:23:01 I was referring specifically to admins, though I think this is a general problem through the project. 17:23:04 Given that decisions in the new the sponsorship process are done by voting, the direct FAS access is more of an administrative role, I'm not sure that criteria there should be... 17:23:21 Do all of the existing admins have active FAS accounts? 17:23:30 I think some kind of expiration of elevated privileges should help. 17:23:32 * nirik sees 3 admins that are not really involved with the project at all anymore. 17:23:51 If any of them didn't reset their passwords then I think we should probably remove the privileges 17:24:09 mjg59, +1 17:24:14 mjg59: +1 to that, yes 17:24:30 (Who can check that easily?) 17:24:34 no, they are all active. 17:24:39 Ok 17:24:42 but resetting a password is pretty easy... 17:24:45 Active, just not active? 17:24:51 even if you otherwise have not much to do with Fedora anymore. ;) 17:25:08 Ok, anyone want to volunteer to ping them to see if they still want this access? 17:25:23 I can do that. 17:25:28 tibbs|w: thanks 17:25:39 yeah, and then remove those who no longer wish it, and/or don't answer. 17:25:48 tibbs|w: Thanks! 17:26:22 #agreed tibbs made an admin of the packager group, will ping other admins to check on status 17:26:34 Ok, that's everything I had on the list 17:27:06 So open floor? 17:27:09 #topic Open floor 17:27:38 chairman for the next week? 17:27:40 so, there's been 2 long threads on the devel list over the last week. Do we wish to discuss or vist them? 17:28:03 Just now caught up with them, AFK most of the weekend. 17:28:06 Wow. 17:28:25 * mitr hasn't managed to read it all yet 17:28:27 yeah, so we talked quite a bit about stuff. 17:28:28 pjones has written up secure boot as a feature proposal, but I didn't want to tag it in at this short notice 17:28:29 I didn't read it yet. Could we revisit next week? 17:28:36 mmaslano: we may need a new chair, since elections will be over and we have a new fesco next week. ;) 17:28:43 mjg59: It isn't fully ready yet really 17:28:44 nirik: true 17:28:48 I can take it, I'll still be here. 17:28:55 I assume. 17:29:00 I'll be off-line next week 17:29:05 $_DEITY willing. 17:29:10 * nirik nods to limburgher. Sounds good to me. 17:29:11 https://fedoraproject.org/wiki/User:Pjones/Features/SecureBoot is what I've got right now FYI 17:29:23 but as you could guess from its url, it's still considered a work in progress. 17:29:25 pjones :thx. 17:29:37 Yeah, I'm in taiwan next week 17:29:45 So I suspect the schedule is not going to work well 17:30:04 pjones / mjg59: aside from the feature, perhaps we need a wiki/SecureBoot page that explains background, faq, etc... and also we can use that as a landing point to tell people how to disable or enroll their own keys? 17:30:06 I may be in Raleigh on family business next week, not sure. 17:30:43 nirik: yeah, FAQs for key enrollment and whatnot are on my TODO right after finishing writing tools to help with key enrollment and whatnot. 17:31:05 if you want I can whip up a skeleton wiki page with what I know and you can correct/add to it. 17:31:58 The other thread was about /tmp... do we want to revisit that feature? perhaps in a few weeks? 17:32:28 nirik: Yeah, I'm curious to see what people experiences with it are on rawhide. 17:32:41 nirik: sure, we could use all the help we can get :) 17:33:00 nirik: I'd like to see some of the testing that people keep talking about being done in a rigorous way 17:33:21 But I'm finding it hard to get emotionally invested the way some people in that thread seem to be 17:33:30 yeah. 17:34:05 mjg59: Well put. 17:34:10 I have the problem that once apps start to switch over to /var/tmp it will be extra work to switch them back if we revert this feature 17:34:36 t8m: yeah. I wonder if ~/.tmp/ or something would be a better goal there. 17:35:12 and that's probably biggest problem of the feature - that it requires not-yet-upstream changes in packages 17:35:26 I voted -1 on that, but 1) I think FESCo turning back and refusing an approved feature is rather bad form, 2) even given that, I haven't seen new arguments against the feature, so there's not an obvious reason to revisit . So I think we should just let someone file the FESCo ticket if they want to. 17:35:39 nirik, not sure about that unless some way to regularly purge it is established 17:35:40 Seems fair to me 17:35:49 t8m: only for really rare corner cases 17:35:49 nirik: network home directories ... 17:36:01 t8m: I have been running with such a setup for *years* just fine 17:36:11 yeah, there's no solid answer I agree. 17:36:13 t8m: people are overreatcting 17:36:50 mitr: I agree with you 17:36:51 drago01, not really, perhaps they just use different apps in different ways than you 17:37:30 t8m: maybe .. maybe not as long as the concerns are "what if ..." and not "I did xyz and it broke in way foo" 17:37:46 t8m: it sounds like overreacting to me 17:37:57 drago01, I think we have to conclude that we disagree on this topic 17:38:02 t8m: fine 17:38:06 drago01: That's the trouble with this feature - it is more or less mathematically impossible to get it right and have a level of assurance that you got it right. ("mathematically" = by counting the man-years necessary) 17:39:01 mitr: my point is "just test the apps in question and not try to come up with theoretical cases" 17:39:44 drago01: Hence my desire for rawhide experiences. If it blows up for major things, we'll know. If it blows up for one obscure app. . .patch. 17:40:03 drago01: The sort problem is real, even though it probably wouldn't come up in testing. And our QA is stretched enough with installation testing already. 17:40:17 And it ought to be well known that I certainly care about obsure apps. My pkgdb list will bear that out. 17:40:28 Anyway, I'm not filing that FESCo ticket, so... 17:40:43 mitr: well then fix sort and try to find the next app that breaks 17:40:47 t8m: I'm not sure I buy that /var/tmp problem. If we're switching things to /var/tmp, it should be because that's what they should be using regardless. 17:41:01 t8m: which means if we revert the feature, they should still be correct 17:41:10 limburgher, I am afraid that currently rawhide is not really in state where any blowup can be attributed to anything particular 17:41:37 pjones: As of now, the only reliable differences between /tmp and /var/tmp are 1) /var/tmp has a retention time longer by 20 days, and 2) /tmp is required to exist by POSIX. 17:41:42 pjones, not true - the difference in /tmp and /var/tmp was in the persistence on reboot and the length of the persistence period 17:41:58 pjones, and not in fits in memory/does not fit in memory 17:41:59 t8m: and will those not still be true? 17:42:00 Scratch that, 1) isn't reliable 17:42:24 The idea that "large things belong in /var/tmp" just hasn't existed 17:42:28 pjones, basically with tmp on tmpfs you're losing non-persistent but doesn't fit in memory space 17:42:34 yeah, okay, I see your point. Still not terribly compelling to me, but it's there. 17:43:21 t8m: Often true. :) 17:43:43 drago01: I've run that way as well -- but I've also had to set TMPDIR=/var/tmp in my .profile and occassionally (mutt is one I remember) set up non-default directories in individual programs. 17:43:45 so, sounds like "we would like some more concrete data" 17:44:01 nirik, +1 17:44:09 drago01: so... just a caveat to your data point :-) 17:45:03 abadger1999: yeah such data points are fine .. i.e "I tried it and foo broke" not "what if the sun moves to position x and the moon to position z and ..." kind of cases ;) 17:45:12 17:46:34 Ok, so did anyone have anything concrete to do on this? 17:46:42 Not currently. 17:46:55 If not I guess we just try to ensure that discussion stays reasonable and revisit if anyone brings it up 17:47:04 fine with me 17:48:07 * nirik nods. 17:48:17 OK 17:48:20 Cool. Anyone got anything else? If not I'll close out in a couple of minutes. 17:49:21 mjg59, the next week chair will not be chosen? 17:49:36 Oh! Good point. 17:49:42 limburgher: Did you volunteer? 17:49:45 limburgher offered 17:51:29 Well unless he appears again in the next 30 seconds he's going to be stuck with it 17:51:37 heh 17:51:37 :) 17:51:58 Ok 17:52:05 #agreed limburgher to chair next meeting 17:52:12 And with that, I guess we're done 17:52:15 Thanks everyone! 17:52:16 #endmeeting