18:01:37 #startmeeting FESCO (2013-01-16) 18:01:37 Meeting started Wed Jan 16 18:01:37 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:43 #meetingname fesco 18:01:43 The meeting name has been set to 'fesco' 18:01:49 #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:01:49 Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:01:57 #topic init process 18:01:59 morning everyone. 18:02:02 i'm here 18:02:06 mmaslano: I can't stay for the whole meeting today. I've voted in the tickets for most of the features, but could we move the Node.js and SignatureCheck discussions to the beginning? 18:02:24 sgallagh: sure 18:02:27 Thank you 18:02:57 hello. 18:03:20 * abadger1999 here 18:03:25 Hello all 18:03:47 hello 18:03:56 * notting is here 18:04:06 let's start 18:04:26 last time we said only features will be discussed 18:04:36 we could speak about rest at the end if anyone wants 18:04:42 let's not. 18:04:56 #topic #992 F19 Feature: NodeJS - https://fedoraproject.org/wiki/Features/NodeJS 18:05:03 .fesco 992 18:05:05 mmaslano: #992 (F19 Feature: NodeJS - https://fedoraproject.org/wiki/Features/NodeJS) – FESCo - https://fedorahosted.org/fesco/ticket/992 18:05:49 I proposed this feature, but the budding Node.js community within Fedora has really taken off with it. 18:06:09 A few dozen node packages are in the review queue already, several of them approved. 18:06:19 sgallagh: I know you was working with upstream, so there shouldn't be any serious problems 18:06:20 one sec 18:06:33 * nirik is a bit worried about npm package manager. 18:06:36 last week we decided to vote en bloc for features that have no objections 18:06:47 We need to sort out an official packaging policy, which I'm going to start brainstorming at FUDCon, but the packages that have gone in so far are taking the slightly hackish symlink approach that avoids bundling. 18:07:02 nirik: how does that work exactly? rpm-installed modules are registered in a local npm database too? 18:07:04 jwb, I suppose this one is not such case - I think some discussion about npm is relevant 18:07:20 sgallagh: I am a little afraid of the explosion of js packages without JS guidelines. 18:07:30 t8m, sure. but we could get those without objection out of the way first... otherwise we're just going to go through them all anyway 18:07:38 Yeah, I can understand that. I'm learning as I go here as well. 18:07:48 notting: my understanding is that it's a per user install type of thing... or per app tree. 18:08:06 sgallagh: so how the npm is working? 18:08:09 so, no different than some of the other $lang things. 18:08:34 mmaslano, could you please propose which features are uncontroversial and can be voted together after we close discussing this feature? 18:08:38 We haven't gotten that far yet. We've (Well, mostly T.C. Hollingsworth) been packaging the dependencies for npm 18:08:44 t8m: yes 18:09:01 AFAICS there isn't a local database - but a per-project dependency subtree into which a command can symlink the globally-installed libraries 18:09:03 We're trying to keep things to a common location and we're looking into working with upstream to add a set of search paths rather than the hackish symlinking we're doing in the packages. 18:10:16 * nirik is conditionally +1, but would like guidelines and the packages that meet those guidelines. 18:10:18 sgallagh: k. If we can get to the point of common location, documentation on how to do the symlinking, and naming/versioning that's probably enough to get an initial set of guidelines. 18:10:22 Can we tentatively approve the feature requesting packaging guidelines be finished before some point of time? For example F19 branch point. 18:10:40 nirik: I'm okay with updating the Feature page to require approved guidelines as part of the feature completion criteria 18:10:41 or maybe even earlier 18:11:29 or we can postpone the feature approval until such guide exists 18:11:42 t8m: As I said above, I'm going to try to hammer out the basics of this at FUDCon this week, so I think branch is achievable :) 18:12:03 I can't see that postponing the approval would really change anything - the guidelines are not yet approved and packages are getting into the distribution anyway 18:12:23 I don't think our decision depends on what the guidelines look like exactly, or does it? 18:12:30 unless we want to say: don't add anymore of them until we have basic guidelines? 18:12:31 * abadger1999 would be okay with nodejs as a feature now but would like to avoid having many server-side javascript packages until we have guidelines. 18:12:47 Right 18:13:41 nirik, Yes, that's what I'd like to say by the postponed approval 18:13:46 i'd agree with mitr though - if all we want is approved guidelines before packging, i thik we can still approve the feature 18:14:04 nirik: +1 18:14:34 mitr: Well... in the past FPC + fesco has put freezes on packages getting in that were written in a language that didn't have guidelines yet. 18:15:12 Proposal: NodeJS is approved; for the feature to be considered complete, packaging guidelines must be approved by feature freeze and any preexisting packages modified to comply (if necessary) by beta freeze. Feature owners are strongly encouraged to get the guidelines approved before adding more packages. 18:15:45 +1 18:15:46 mitr: +1 18:15:50 sure +1 18:15:50 mitr: +1 18:15:51 mitr: I'm +1 to that (and speaking as the feature owner, sure) 18:15:55 +1 18:16:12 +1 18:16:28 +1 18:16:35 (that's the FESCo /feature side; given that these are new packages, there's little integration concern. OTOH, perhaps FPC might want to object to adding _any_ node.js packages now when guidelines don't exist) 18:17:12 I'm not sure we have a precedent/established practice WRT new languages 18:17:25 mitr: I think that's a bit of a chicken-and-egg problem. As this is new territory, some of the issues we're discovering will only be possible to document when we have nested deps. 18:17:28 perhaps we should establish one? 18:17:28 with my FPC hat, I do kinda -- but hopefully sgallagh can sit down with enough of us FPC people at fudcon to get something workable by next week. 18:17:35 mitr: I think we just did 18:17:47 pjones: only as long as someone remembers this meeting 18:17:50 #agreed NodeJS is approved; for the feature to be considered complete, packaging guidelines must be approved (+8,-0) 18:18:02 sgallagh: yes 18:18:04 mitr: same as it always was 18:18:29 #info sgallagh will speak about guidelines with FPC 18:18:36 * sgallagh nods 18:18:58 sgallagh: another topic? 18:18:59 mitr: precedent is probably to ban the packages. ruby, mono, and java all had periods of waiting to finish package reviews while the guidelines were approved. 18:19:00 I've added a brainstorming session to the FUDCon hackfest list, so hopefully that will make it onto the schedule 18:19:45 mmaslano: I have to disappear in the next ten minutes, but I wasn't sure if there was going to be any discussion on the other topics, or if they were just headed for the rubber-stamp 18:19:54 but I'm definitely okay with doing our best to figure this out at fudcon. 18:20:07 #topic #993 F19 Feature: NetworkManagerCLIAddConnection - https://fedoraproject.org/wiki/Features/NetworkManagerCLIAddConnection 18:20:09 .fesco 993 18:20:11 mmaslano: #993 (F19 Feature: NetworkManagerCLIAddConnection - https://fedoraproject.org/wiki/Features/NetworkManagerCLIAddConnection) – FESCo - https://fedorahosted.org/fesco/ticket/993 18:20:13 so, wait... 18:20:14 no one comment this one 18:20:21 mmaslano: do an overview of the features first? 18:20:22 did we have any controvesrial ones then? 18:20:48 the only other one that really had discussion was the signature one 18:20:48 [I'd like a bit of disucssion on signature checking, and I'm fine with php and nm-cli] 18:21:13 other had a few replies 18:21:30 i'm fine with this one 18:22:02 Perhaps it's easier to just vote than to figure out which ones to vote on? We have only 3 features left today 18:22:09 yes 18:22:20 +1 to nm-cli 18:22:21 mitr, hehe, yes 18:22:25 +1 18:22:26 * nirik is also fine with nm-cli and php 18:22:27 +1 to nmcli 18:22:31 sure, +1 18:22:32 +1 18:22:36 +1 18:22:37 +1 18:22:48 +1 18:23:17 #agreed NetworkManagerCLIAddConnection was accepted as F19 feature (+8,-0) 18:23:25 #topic #990 F19 Feature: PHP 5.5 - https://fedoraproject.org/wiki/Features/Php55 18:23:30 .fesco 990 18:23:33 mmaslano: #990 (F19 Feature: PHP 5.5 - https://fedoraproject.org/wiki/Features/Php55) – FESCo - https://fedorahosted.org/fesco/ticket/990 18:23:34 +1 18:23:36 +1 18:23:38 * pjones +1 18:23:39 there was only discussion about usage of systemtap 18:23:40 +1 18:23:43 so not controversial 18:23:46 +1 18:23:53 +1 18:24:12 +1 18:24:13 +1 18:24:17 +1 18:24:25 #agreed PHP 5.5 was accepted as F19 feature (+9,-0) 18:24:37 #topic #991 F19 Feature: PackageSignatureCheckingDuringOSInstall - https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall 18:24:42 .fesco 991 18:24:44 mmaslano: #991 (F19 Feature: PackageSignatureCheckingDuringOSInstall - https://fedoraproject.org/wiki/Features/PackageSignatureCheckingDuringOSInstall) – FESCo - https://fedorahosted.org/fesco/ticket/991 18:24:51 * mitr points at https://fedoraproject.org/wiki/Talk:Features/PackageSignatureCheckingDuringOSInstall 18:25:24 I'm going to excuse myself. Sorry, folks. I'll read the logs later. 18:27:06 so, there was also a lot of discussion on list, but about non secure boot case... which isn't really this feature. :) 18:27:52 yeah 18:28:03 nirik, the non secure boot case conflicts with the anaconda subtask: "needs to detect that we're in a secure-boot environment and, if so, enforce signature checking on keys and packages." 18:28:33 how does that conflict? 18:28:33 Unless we have anyone volunteering to write the non-secure boot case, I wouldn't worry too much 18:28:37 I wouldn't say it conflicts... if someone was working on that they would need to coordinate their changes for sure. 18:28:43 mitr: that too. 18:29:19 There was also the question of how this affects remixes and other people building install images on top of fedora. 18:30:00 what would really be the non-secure boot case - just enforce signature checking for keys that are present on the install media? 18:30:06 yeah. pjones, what group of people can own SB keys accepted to sign the repositories? 18:30:25 same as anything else with SB 18:30:25 t8m: either, or ... for the Fedora repositories only 18:30:39 So, "anyone that pays $99"? 18:30:49 if you're in the machine's database or the MOK database shim provides, you can do it. 18:31:10 t8m: I'm not planning on changing the non-secure-boot case. 18:31:14 Is it a separate "OS" namespace, or does it include all driver authors? 18:31:31 what? 18:31:34 mitr: it doesn't include all windows driver authors 18:31:39 it's a separate signer 18:31:50 pjones: as part of that thread I asked what the MoK list was... what is it? It's not listed on the SecureBoot Q&A page 18:32:06 what Q&A page? 18:32:13 https://fedoraproject.org/wiki/Secureboot#Questions_and_Answers 18:32:29 i'll fix that later then 18:32:33 pjones: So, to summarize, remixes can either ignore SecureBoot completely, or get a SB key and use that to both sign the boot image and repositories - IOW no change? 18:32:38 The second to last question lists the db's that are involved in secure boot. 18:33:13 abadger1999, basically, it's a list of keys provided by shim. it was blogged about quite a bit. i'm not surprised at all that this page is out of date. 18:33:16 mitr: IIUC, it's a change to what remixes can change. 18:33:22 mitr: well, I've been pondering on how to handle that - I'm not against adding an "enforcing mode" that won't allow unsigned packages at all when SB is enabled, but I wasn't going to make it default for this release. 18:33:23 hm. "provided by shim" is not correct 18:33:33 abadger1999, anyway, i'll fix it later 18:33:46 pjones: *confused* 18:34:05 What does the feature buy us if unsigned packages are allowed? 18:34:24 on a per repo basis? 18:34:42 i.e. checking for the main fedora repo but not necessarily for every additional repo you've configured 18:34:53 mitr: for instance, in the past they might have been able to change the firefox package and been okay because the shim and kernel were still vanilla Fedora. now that wouldn't be the case because their firefox package wouldn't be signed with the verified fedora key. 18:34:55 Oh, right. 18:34:58 jwb: thanks! 18:35:18 mitr: by which I mean: I'm going to allow you to add a repo that hasn't bought in to the signature scheme 18:35:32 anyhow, I am +1 to the feature. 18:35:43 pjones: perhaps do a warning then if in secure mode? 18:35:57 yeah, probably a manual clickthrough on interactive installs or something along those lines. 18:36:06 makes sense 18:36:10 * nirik nods. 18:36:39 * pjones is obviously +1 to it 18:36:57 though note that it does have a couple of dependencies I'm waiting on, so there's some chance we'd need to bump to F20. 18:37:01 i'm +1 to it 18:37:32 +1 18:37:43 pjones: Please add very precise documentation how to use it securely (e.g. include manual image verification) and what is or isn't verified/guaranteed. 18:37:47 With that, +1 18:37:52 +1 18:38:00 mitr: yeah, definitely a goal. 18:38:16 +1 with the hope someone works on the non secure boot case 18:38:41 pjones: could you add precise documentation on the feature page? 18:38:41 pjones: Would you add the separate repos, separate key policies info to the Feature page? 18:38:51 abadger1999: okay 18:38:56 thanks 18:38:59 sadly the non secure boot case is pretty intractable, but I htink we could perhaps try more and leave only one gaping hole. 18:39:00 mmaslano: I'd think that'd be part of the result, not part of the proposal. 18:40:13 #agreed Package Signature Checking During OS Install was accepted as F19 feature (+7,-0) 18:40:47 #topic Next week's chair 18:41:07 i can do it 18:41:25 #action notting will chair next meeting 18:41:31 #topic Open Floor 18:42:04 there was ticket #986, which was resent for another review on devel list 18:42:11 so I left it for next week 18:42:38 Good. I have pinged the glibc owner directly, I'd really like to see the maintainer's opinion. 18:42:56 some fesco members already voted in ticket #896, so please go and vote 18:43:27 sorry, wrong ticket 18:44:02 ticket #615 18:44:06 .fesco 615 18:44:07 mmaslano: #615 (Strategy for services that do not have systemd native unit files) – FESCo - https://fedorahosted.org/fesco/ticket/615 18:44:24 I'll close the meeting in five minutes... 18:44:30 jreznik: Suggestion on process -- if you could post the devel archive list instead of the devel-announce link, that would be quicker to find the discussions. 18:45:03 I'd like to thank everyone involved in the F18 release: testers, developers, docs, translators, ambassadors, users and anyone I forgot. :) 18:45:18 nirik: For the proposal in 615... is that recommending/requiring that FPC ban sysvinit scripts? Or simply letting them decide? 18:45:25 nirik: +1 18:45:35 nirik: +1 It's been a long road :-) 18:45:35 abadger1999: I'll be ok with that 18:45:45 jreznik: thanks. 18:45:46 abadger1999: I guess let them decide. I see 0 point in shipping them, but perhaps there's some use I haven't thought of. 18:45:57 nirik: k. Thanks. 18:46:00 abadger1999, i suggested that in one of the tickets already 18:46:25 we still ship sysvinit BTW. 18:46:37 I suspect very much it wouldn't be able to boot anything these days tho 18:46:38 abadger1999: depends what the rest of fesco thinks about it - we already discussed it if we want -devel or -devel-announce (at least with some people) - could be topic for the end of mtg 18:47:37 #topic -devel or -devel-announce for discussion of features 18:47:49 jreznik: not about where it's sent; just about which link we out in the ticket :-) 18:48:05 *we put 18:48:18 abadger1999, +1 18:48:38 I guess link to -devel would be more helpful 18:48:45 surely 18:48:52 sure, that makes sense 18:49:34 * nirik nods. 18:50:08 has anyone managed to glance over the https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F19 for packages that might ( or should ) be removed from that list? 18:51:05 #info jreznik will use in ticket link to devel instead of devel-announce 18:51:23 sysklogd was earlier mentioned as highly suspet 18:51:24 #topic Open Floor 18:51:30 Viking-Ice: I talked to fedmsg maintainer about those, he has systemd units, but hasn't pushed them yet. So they should fall off the list soon. 18:52:35 abadger1999: I got you, sorry :) 18:52:40 nirik, ok iscsi- has been socket activated upstream and migrated not sure what's keeping Chris from building those changes in rawhide 18:53:29 and bunch of those components have migrated units to them which have not been packaged yet but that list total was around 177 packages as is 18:54:27 nothing else leaps out at me from the list. 18:54:43 bluez-compat that yum stuff 18:55:18 but we can cross those bridges when we get there 18:55:24 * nirik nods. 18:56:15 on an different subject does it make sense to migrate all those cron scripts to systemd timer units? 18:56:25 what? 18:56:25 all shipped cron scripts I mean 18:56:40 Viking-Ice: what end-user benefit would all that work bring? 18:57:10 * nirik has no opinion on it without looking at it in more detail. 18:57:20 Viking-Ice: as a maintainer, I don't plan to do it, because I don't see any user improvement 18:57:37 is there any? 18:57:40 open floor topic: im on a boat 18:58:11 lets discuss that proposal after it's had discussion on list or detailed proposal sent to us? 18:58:18 dan408_: ahoy 18:58:22 mitr, fewer packages in install have not looked at it further it's just recent that systemd gained "calender" support 18:58:23 nirik: ahoy matey 18:58:40 for those timer units 18:59:31 I'll compile a list of packages that ship cron jobs and look what benefits it might bring 18:59:42 Viking-Ice: could you mention in your proposal what it brings to users? 18:59:44 ok thanks 19:00:14 fpc probably needs to come up with some guidelines with regards to systemd time units 19:00:43 i love systemd 19:00:56 i had to resume my computer twice 19:01:20 dan408_: do you have real issue for Open floor? 19:01:49 hopefully systemd implements a shell soon - that's also usually used for spawning processes 19:02:09 * nirik thinks this meeting is over. 19:02:14 ^ 19:02:18 * mitr gently notes that last week we agreed that today we'll discuss featuers only 19:02:29 mitr, +1 19:02:52 Viking-Ice: so, prepare feature and send it to list 19:03:00 I close the meeting in few minutes 19:03:13 ok 19:03:15 mmaslano, a minute should suffice 19:03:33 mmaslano, technically this is not a feature 19:04:29 Viking-Ice, technically it very is 19:05:05 #endmeeting