17:01:05 #startmeeting FESCO (2011-06-27) 17:01:05 Meeting started Mon Jun 27 17:01:05 2011 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:21 #meetingname fesco 17:01:21 The meeting name has been set to 'fesco' 17:01:26 #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 17:01:26 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 17:01:36 * nirik waves hello 17:01:36 #topic init process 17:01:38 * notting is here 17:01:43 * sgallagh is here 17:01:44 yo 17:01:48 * t8m too 17:02:07 howdy 17:02:14 * mmaslano says hi 17:03:14 cwickert, mjg59: Are you around? 17:04:20 mjg59 said he'd have to miss today 17:04:29 ok 17:05:13 I should also mention that next week's meeting falls on Independence Day in the USA. I expect this will affect most of the committee. 17:05:26 yeah, shall we cancel next week? 17:05:27 i will be very far from a computer on that day, yes. 17:05:30 * t8m is on vacation 17:05:43 * mmaslano is also on vacation 17:05:45 +1 for cancelling next week 17:05:50 +1 here. 17:05:52 +1 for cancelling 17:05:52 +1 17:05:53 +1 17:06:04 +1 17:06:21 #agreed Cancel FESCo meeting on 2011-07-04 17:06:22 +1 17:06:56 #topic #563 suggested policy: all daemons must set RELRO and PIE flags 17:06:56 .fesco 563 17:06:57 sgallagh: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 17:07:30 nirik: I believe you took an action item last week to draft guidelines? 17:07:33 I've failed to have time to put together a list for the PIE stuff. ;) 17:07:35 sorry. 17:07:43 Will try and get it this week... help welcome. 17:08:04 Do we have any other updates on this issue? 17:08:13 I see ajax just set relro in rawhide. 17:09:03 yeah, not totally happy with doing that in %optflags instead of in binutils proper. 17:09:14 but we'll see how relevant it ends up being. 17:10:30 i'll send out an email about it. 17:11:03 #action ajax to send out an email discussing %optflags vs. binutils 17:11:17 Anything else on this topic? 17:11:36 * nirik has nothing at this time. 17:11:42 ditto 17:11:51 #topic #608 F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot 17:11:51 .fesco 608 17:11:52 sgallagh: #608 (F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/608 17:12:12 So I've seen a lot of... healthy discussion on the list about this. 17:12:32 yeah. 17:12:46 Unfortunately with not much input from the Feature owners? 17:12:49 there's also a competing technology from TCG that IBM likes more. 17:13:12 pjones: that's not strictly true...... 17:13:13 pjones: I'm led to understand that dboot is supposed to be a superset of tboot 17:13:26 sgallagh: oh? 17:13:42 I asked eparis to join us and help disambiguate things 17:13:58 correct, any other 'trusted boot' package will need to do the exact same things as tboot. 17:14:11 so, here's my take FWIW: I am -1 to the feature has it is. If we enable this by default, I would like to see the feature enable/document how this helps Fedora users. At the last it needs a lot more docs, but ideally it would have some easy ways to empower our end users to decide what they want to do with this ability. 17:14:31 nirik: NOONE ask for this to be enabled by default 17:14:52 the request is that it be ABLE to be enabled without manual human intervention. 17:14:57 ok, that wasn't entirely clear from the feature page. 17:15:20 so, enabled on machines that posess the hardware? 17:15:25 eparis: Please rephrase that statement. I assume you meant "minimal" intervention? 17:15:28 the problem is that there's no extension mechanism for grubby that would allow this to be maintained entirely in the tboot package? 17:15:28 eparis, how can QE test this feature ? 17:15:32 nirik: and that embed the interesting bits in the firmware. 17:15:34 The feature page needs improvements, docs need to be added, agreement on the grubby/anaconda changes needs to be reached 17:15:35 I dunno scope section: UI to choose TXT/tboot support during installation. 17:15:41 I am -1 for that as well. 17:15:49 how to test section: If selected during system installation UI, make sure the tboot package is installed and the bootloader config is changed to boot tboot as kernel and linux as module. 17:15:54 seemed clear to me this wasn't default... 17:16:08 ok, so a UI to let the user choose it... still not great. Who would? 17:16:09 notting: grubby probably isn't the right place for that anyway, though I guess maybe it could be. 17:16:23 notting: that is correct, we have no way to handle alternative grub syntax 17:16:26 that's all this is about... 17:16:32 we need some way to handle alternative grub syntax 17:16:37 pjones: the integration is merely changing grub.conf in the presence of tboot, is it not? 17:16:46 notting: that is all it is doing. 17:16:52 I _think_ current grubby should copy the right stuff from old stanzas to new ones, which is really its job 17:17:27 pjones: but the syntax is different, look at his example, grubby will only change one of the two entries on update 17:17:28 notting: sure, but you're talking about generating the module syntax during a fresh install if the package is there. grubby has nothing to do with that. 17:17:40 I think there's cool things we could use this for, but 'enable it now so we can do ~wave hands~ later' seems non ideal. Why not set it up to do something our users care about and _then_ enable it. 17:18:20 pjones: who generates that? anaconda? 17:18:23 eparis: yeah 17:18:43 pjones: if so we need 2 changes, anaconda to install the alternative syntax if tboot selected and grubby to update the alternative syntax if it exists. 17:18:46 that's all this is about. 17:18:54 anaconda generates the original; grubby handles updates by finding a template entry and using it to generate new entries. 17:19:15 pjones: and ideally, something in packaging so that the user can't go 'rpm -e tboot' and have everything explode. but that may be tricky. 17:19:17 pjones: (or make tboot install install the alternative syntax on install instead of anaconda, i don't konw that area to know if that works) 17:20:17 I'm all for not calling this a feature, noone is oging to be able to really make use of this out of the box 17:20:28 eparis, +1 17:20:31 right. 17:20:39 but all this is really aobut it changes to anaconda/tboot %pre/grubby template 17:20:40 eparis, this assumes we can have a tboot package in fedora, is tboot something that can actually be distributed in fedora ? 17:20:49 it's already in. 17:20:52 simo: been in fedora a while now :) 17:20:56 ok 17:20:58 Well, it's probably a feature if we're going to be directing multiple projects to coordinate this 17:21:29 If only because we will want them on a synchronized deliverable schedule 17:21:34 * nirik doesn't think anaconda or grubby should really do anything at this time either, but I guess it's up to those projects to decide. 17:21:47 eparis: I'm trying to think of a cleaner way, but I suspect having anaconda modify the config it generates if tboot is in the install set is the best thing right now :/ 17:21:59 and then just make sure grubby actually works with the alternate stanza format 17:22:16 if this is a small number of machines, and a smaller number of those that wish to enable it for some reason, why not just document how to enable it? 17:22:20 (though tbh I think xen has a sufficiently similar format that updates may just work 17:22:21 ) 17:22:23 Well, could we perhaps extend grubby instead so that it would be run in %post of tboot install to add the new syntax? 17:22:25 pjones: but that doesn't work if tboot is installed after install :-( 17:22:42 no, it means if you install tboot yourself, manually, then its your own thing to do. 17:22:49 honestly I think that's okay, though. 17:23:06 pjones: i'm sure they'll write some %pre attrocity(?sp) 17:23:06 sgallagh: sortof violates "do one thing and do it well" 17:23:11 pjones: was there similar code in the past for xen in anaconda? 17:23:12 * nirik thinks thats ok all the time. 17:23:15 I realize this is not, strictly speaking, Grubby's purpose, but it seems cleaner to me 17:23:29 notting: maybe, but that code has changed a lot since then, so it's probably not a case of reviving it. 17:23:44 * cwickert is here, sorry 17:23:56 sgallagh: I don't want to introduce the idea of writing new stanzas to grubby. I really don't. 17:24:05 sgallagh: I'm going to push back a lot on that. 17:24:34 pjones: so then we'll need to do the new stanzas in tboot scripts 17:24:37 pjones: Ok. Perhaps that should be the goal of a new project then. I can see it being a useful common library 17:24:48 pjones: grub2 doesn't change config format, correct? 17:25:00 oh yes it does. (last I looked) 17:25:20 notting: wrong :/ 17:25:30 xml funtime. :) 17:25:34 oh no 17:25:42 eparis: why? you haven't answered why we need it on manual package install at all. 17:26:13 pjones: is anaconda grub.conf writing pre or post package install? 17:26:30 pjones: because we know people will :) 17:26:36 We're at fifteen minutes. Do we want to continue this discussion for another fifteen or take it offline until the next meeting? 17:27:06 it sounds to me like a technical argument for me pjone intel and IBM :) 17:27:13 * nirik is happy to vote now, continue for a bit, or whatever. 17:27:30 notting: post 17:27:37 nirik: Do you have a proposal to vote on? 17:28:00 eparis: that's not a particularly great answer. 17:28:26 proposal: decline feature as written. Ask feature owner to expand on/rework feature page and resubmit, or just resubmit at another later time. 17:28:35 eparis: I especially don't like the idea of a package install possibly breaking boot of an otherwise already working kernel. to me that's anathema. 17:28:53 nirik: +1 to declining Feature as written. 17:29:08 +1 my own proposal. 17:29:11 nirik: don't like that second part. submitting again later w/o more information, clarification, etc. shouldn't be allowed 17:29:25 pjones, it might not have to be in package post install script, it might be just a script that the admin would want to run 17:29:30 what clarification are people asking for? 17:29:40 t8m: that's completely unlike what eparis is saying, though. 17:30:05 well, I am not asking for clarification. I want this feature to actually be of use to fedora users, which currently, IMHO it is not. 17:30:09 t8m: and honestly - if somebody wants to write such a script and stick it in the tboot package, I'm fine with that. in %post, though, I'm not. 17:30:19 pjones, OK 17:31:22 I think it could be. Setup ways to check the fedora provided kernels. Offer users a way to not boot on problems. Offer users a way to let them attest or decline to attest that it was a valid boot. Allow users to load their policy or change it. etc 17:31:42 the control should be in the users hands, and if this is a feature we should be providing the users those tools. 17:32:56 pjones: I agree that we don't want any automatic-enabling in %post, but we certainly want automatic disabling in %postun or we'll get into trouble... 17:33:08 am i misunderstanding this, or can anyone with root completely disable this feature by editing grub.conf? 17:33:33 notting: they can 17:33:35 I think they can, yes 17:34:50 Proposal: Decline this as a Feature. Work on this will still be acceptable, but must be negotiated by the feature owner, not as a FESCo mandate. 17:35:03 sgallagh, +1 17:36:05 notting: they can "disable this feature" but that wouldn't give them access to the keys stored in the TPM - IOW that doesn't "break" security 17:36:32 I guess +1... really I don't see the need to enable this at all until it has stuff around it for using it/manageing it. 17:37:52 pjones, cwickert, ajax, mmaslano, notting: please vote. 17:38:02 +1 17:38:15 +1 I guess. 17:38:16 +1 (for the record) 17:38:32 +1 decline feature as is 17:38:55 +1, i guess. but mainly just because it's unclear what the integration plan is 17:39:30 yeah, this seems to be 'enable it because we might do something with it someday' 17:39:51 #agreed Trusted Boot is declined as a Feature. Continued work on this will be negotiated by the tboot developers, not by FESCo. 17:40:47 #topic #531 Orphaned package ownership claiming clarification 17:40:48 .fesco 531 17:40:49 sgallagh: #531 (Orphaned package ownership claiming clarification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/531 17:41:48 I added some options/thoughts there. 17:42:41 +1 for nirik's propsal, sorry for beeing late again 17:42:59 cwickert: Is that on the previous issue? 17:43:08 sgallagh: yes 17:43:20 Ok 17:43:51 nirik: I'm wondering if it isn't reasonable to just always require a re-review to remove orphan status. 17:44:19 nirik, I'd say that the a) would be easiest to implement and perhaps it would be acceptable as well 17:44:23 nirik: If nothing else, it would help with the compliance-rot we see in old packages vs. the current policies. 17:44:23 well, we have not many reviewers... 17:44:25 i think a simple policy is 'no re-review for orphans, always re-review for blocked' 17:44:43 sgallagh, to remove orphan status? that's not a good idea 17:45:00 nirik: Perhaps a policy of "You have to do at least one package review per Fedora release to maintain inclusion in the "packagers" group"? 17:45:29 * nirik suspects there would be a bit of pushback from that. ;) 17:45:33 Never mind, I withdraw that 17:45:40 notting: I think you're right 17:45:40 * cwickert thought had to be orphaned for 3 months to require a review 17:45:52 cwickert: thats the current "policy" yeah. 17:45:58 but it's hard to enforce. 17:46:49 nirik: then I don't get what he is proposing, is he describing what he thinks is a problem or is it a propsal? 17:46:54 cwickert: that's why i think tying it to blocked packages is better - it's much more clear 17:47:03 nirik, I am +1 to your a) proposal that I read is the same as notting's proposal 17:47:24 nirik: I am also +1 to the a) proposal. Seems like the most achievable goal 17:47:54 notting: +1 to that 17:48:08 nirik: your proposal sounds reasonable +1 17:48:24 nirik: +1 17:48:45 * nirik is fine with that, as it doesn't really require more implentation, just a policy change. 17:48:48 +1 17:49:12 +1 17:49:42 #agreed Policy will change to ""If a package is in orphan state in pkgdb, feel free to take it and revivie it, no re-review needed. If it's depreciated, you must re-review and get admins to unblock it" 17:49:57 would someone like to announce the new policy and change any wiki pages? ;) 17:50:58 sure, why not 17:51:07 http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers looks like the page to update (at least one of) 17:51:56 #topic #614 Proposed list of packages to drop due to FTBFS prior to F16 branching 17:51:56 .fesco 614 17:51:57 sgallagh: #614 (Proposed list of packages to drop due to FTBFS prior to F16 branching) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/614 17:52:37 First request: could someone with WIKI_ADMIN privilege please add {{{ }}} blocks to this ticket? :) 17:52:51 * nirik can 17:54:19 proposal: do this at the 'normal' time in the cycle where we block orphans, regenerating the list then. 17:54:35 So if I understand this correctly, the proposal is for FTBFS tickets to be dead.package? 17:54:57 If they haven't built from source since before the supported releases 17:54:58 * nirik fails his }}} 17:55:00 sgallagh, only for packages that last built in f12 and f13 17:55:10 notting: +1 17:55:18 sgallagh: looks like a selective list of them, but yeah 17:56:28 I'm happy with blocking the 12/13 ones... or even the 14/15 ones. 17:56:58 The automake ones might hit a lot of packages. 17:57:00 I think we should limit it to 12/13/14 in the F16 timeframe. 17:57:00 the proposal is to just block the ones that haven't built since f12/f13 17:57:03 (I hope not, but...) 17:57:21 i.e. any packages that no longer build in a supported release 17:57:32 And set this as a policy, not a one-time thing for F16 17:58:29 * cwickert is happy with blocking all of them, so do as you like 17:58:45 * cwickert needs to leave now but will read the log later 17:58:49 I should point out that occasionally we do see FTBFS because of FTBFS problems, not because of package problems. 17:59:05 so automatically removing anything that fails FTBFS isn't great. 17:59:26 pjones: I don't know if this needs to be automated 17:59:43 pjones: well, yeah, but this list is things that also haven't built in fedora I think... 18:00:05 nirik: a fair difference. 18:00:15 if it built in fedora at some point in a cycle, it would at least move on to the next release list. ;) 18:00:22 yes 18:00:31 The dist tag would update, of course 18:01:28 proposal: add this as a regular task for rel-eng every cycle at the same time as the orphan purge and drop packages that have failed to build since F(n)-2 18:01:39 nirik, +1 18:01:43 So: Proposal: packages that FTBFS and have a dist tag that pre-dates a supported release, it should be blocked 18:02:00 nirik: +1 to that. 18:02:01 +1 18:02:03 Ok, those look to be the same proposal, though nirik's is more detailed. 18:02:07 So +1 to nirik's proposal 18:02:15 yeah, jinx. ;) 18:03:07 +1 18:03:10 +1 18:03:27 #agreed add this as a regular task for rel-eng every cycle at the same time as the orphan purge and drop packages that have failed to build since F(n)-2 18:03:44 Who wants to write the SOP for this? 18:03:51 hopefully rel-eng won't mind another task. ;) 18:05:41 I guess I could try... not sure how much time I will have... 18:05:45 or we could ask mdomsch to. ;) 18:06:05 He was willing to file a detailed bug. I'm all for that :) 18:06:56 I can ask him, failing that can try to 18:08:14 #action nirik to ask mdomsch to write an SOP for FTBFS package removal, else work on it himself. 18:08:26 #topic 615 Strategy for services that do not have systemd native unit files 18:08:26 .fesco 615 18:08:27 sgallagh: #615 (Strategy for services that do not have systemd native unit files) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/615 18:08:40 Viking-Ice: I believe you had some concerns about this that you wanted to raise? 18:09:05 sgallagh, this is toshio proposal but I aggree with his approach 18:09:18 * abadger1999 here too. 18:09:32 basically block alpha as we discussed earlier then proceed with either of abadger1999 proposal 18:10:10 this is the current status of core + alpha https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd#SysV_to_Systemd_Service_Convertion_in_progress_for_.40Base 18:10:18 s/alpha/base 18:11:17 i prefer option #3, honestly 18:11:19 the green check is that it's done? or just has a unit file thats attached to the bug? 18:11:41 nirik, green is done but may need package fixup.. in core audit is stuck on something ( implementation I guess ) iptables as well openssh 18:11:50 is done in bugzilla 18:11:55 ok 18:12:03 senmdail will be dealt with in this week according to maintainer 18:12:26 psacct is done in bugzilla maintainer will look at it tomorrow 18:12:43 cpuspeed is ? 18:12:52 I prefer option 1, but that's somewhat idealistic. Option 2 seems more realistic, and if we went with option 3, what's the point? 18:13:10 notting: Really? every release, system administrators have to check some subset of services to see if the default on/off state is correct? 18:13:16 I am -1 on option 1 18:13:30 abadger1999: well, i thought the "omg never try to migrate settings" policy was a bad idea too 18:13:34 I prefer option 3, I don't think maintainers can port it so fast 18:13:50 lol.. 18:13:57 they can 18:14:09 average porting time with spec file is ca 15 minutes 18:14:27 Viking-Ice, you wish 18:14:27 Viking-Ice: Well, some groups have much more trouble with porting 18:14:31 Such as 389 18:14:46 yeah I know I've been working with richard on 389 18:14:50 Viking-Ice: if it's only 15 minutes, why they are not done yet? 18:14:53 Even sssd took a couple days of back-and-forth revisions to get right. 18:15:11 still, we're talking about a couple of days, not a whole release cycle. 18:15:48 mmslano we ported ca 100 - 150 during last release cycle mostly 2 of us 18:16:03 the reason i like option #3 is that it's not like we're going to turn off sysv support. given that, i don't see why it's the end of the world if some packages still end up using it 18:16:07 Viking-Ice, with multiple bugs and other problems :D 18:16:17 Proposal: Aim for Option 1) but block Beta, not Release. 18:16:17 notting, +1 18:16:18 how many are left? 18:16:21 * nirik looks for the tracker 18:16:22 ca 400 18:16:22 sgallagh, -1 18:16:45 few of the alpha goal 18:17:04 At beta we can choose to abandon our goal of "all services" if it's unachievable 18:17:15 But we should set our expectation that this is what we're striving for 18:17:49 I'd rather take different approach. I agree with notting and t8m 18:18:55 notting: I don't like taking that approach, because we're basically telling people that even we don't support the systemd conversion 18:18:56 basically the problem here are the maintainers if you got some brilliant idea how to "motivate" them I'm all ears 18:19:14 Well, Option 2 is certainly motivating... 18:19:14 * nirik isn't sure. I suspect we will have a number where the maintainer just isn't motivated, but if we have provenpackagers helping, doing them all might be possible 18:19:45 nirik: Going with Option 3), we might as well say: Proposal: provenpackagers do all the work. 18:19:53 There's no mandate to make the change 18:20:06 Package maintainers will largely choose the path of least effort 18:20:13 sgallagh, I think we are saying that the mandate will be there in F17 18:20:20 sgallagh, in option 3 18:20:23 sgallagh: Additionally, there's no mandate that the packager maintainers have to accept the provenpackager work. 18:20:36 packaging is one thing writing the service files needs at least some feed back from the maintainer 18:20:49 I suspect there will be many that are not motivated no matter what we decide here today. ;) 18:20:51 abadger1999: no, but there's no reason to fearmonger about that either. 18:21:11 We're over the fifteen minutes. Do we want to continue this here or take it to the mailing list until the next meeting? 18:21:20 +1 to continue, -1 for mailing list 18:21:35 +1 to keep going for a bit. 18:21:41 +1 to keep going 18:21:46 so, how many more are there on 'handout media'? 18:22:14 fyi the sysv init legacy support already is broken for the end user since all maintainers arent packaging and shipping the old sysv init script 18:22:31 i also see the case where 1) we get stuck on conversions that require systemd changes 2) we are blocked on upstream package changes. i don't necessarily want to hold the release on either of those if the sysv scripts just work for things that aren't in the core package set 18:23:00 Viking-Ice: wtf are you trying to say there? 18:23:09 nirik, not quite there yet few more + base and core 18:23:21 Viking-Ice: because some packages ship systemd but not sysv scripts that all sysv support is broken? 18:23:47 notting, in the long run yes 18:23:50 I expect as much 18:23:57 Viking-Ice: if that's your goal, then GTFO 18:24:07 notting, that's not my goal so stfu 18:24:24 huh? can we move this back to technical discussion? 18:24:26 guys. be excellent to each other please. 18:24:28 Hey, let's try to stay civil, please 18:24:50 maintainers decide themselves if they want to continue to maintain and ship the old sysv init script so far there has been 50/50 on dropping it and sub packaging it 18:25:08 Viking-Ice: right, but that's a different issue. it doesn't mean that sysv support in the OS is broken - far from it 18:25:15 if we break sysv support, we're just going to have to fix it. 18:25:17 but that doesn't break the packages that ship only the sysvinit script 18:25:26 * tatica sorry, don't know what happen with my irc nick 18:25:31 yeah, I'm really not seeing any way that constitutes sysv support being broken for end users. 18:25:41 the packages still work; sure, it means users have to know both things. 18:25:42 * nirik thinks we are getting sidetracked 18:25:50 which is unfortunate, but not the end of the world. 18:27:05 basically we want to convert as many as possible during this release cycle before beta 18:27:15 yes, and I think we all get that. 18:27:30 how we achieve that makes not difference to me 18:27:35 so, I guess I am a weak + for option 1, with the option to punt to f16 if we don't get far enough or run into too many other issues. 18:27:36 * t8m not 18:27:44 nirik: f17? 18:27:49 sorry, yeah. 18:28:44 I really do not see the "all fedora packages converted from sysv to units" as a goal that should block a release 18:28:52 nirik: So, +1 to my proposal above :) 18:29:06 some ideas to motivate: weekly summary of packages needing to convert to devel list? announce to devel-announce that we want to convert and ask provenpackagers to work on them as time permits. 18:29:13 * nirik reads back up 18:29:46 quite contrary I think that as the sysv support must work, for the packages that are not in the base set, they should be freely allowed to chose the preferred way of init - for example based on the upstream 18:29:49 yeah. So, perhaps folks could vote on which option they are on now so we can see if we can reach any consensus? 18:30:03 t8m: that is contrary to the FPC guidelines. 18:30:11 * notting is -1 - have a goal to convert, but i don't see it as a blocking feature, in the same way that usermode -> PK wasn't, or gtk2 -> gtk3, etc. 18:30:19 +1 to option 1 with a punt to next release if too many problems/too slow to get done before beta. 18:30:29 t8m: eh, I think our users do see some benefit from everything being one particular way 18:30:31 +1 to option 1 with a punt to next release if too many problems/too slow to get done before beta. 18:30:34 +1 to what nirik just said 18:31:04 likewise, I'm +1 to it as a goal with the punt option 18:31:44 if we're stating it with a punting option, then 'block release' as stated isn't really on the table? 18:32:00 yeah. 18:32:23 so basically this is the option 3 18:32:28 It's better to define what set of packages would block release vs what set would not. 18:32:47 t8m: No, we're leaving the decision of what to do with the laggards to Beta 18:33:15 yeah, I guess thats the crux of the issue. 18:33:20 We aren't currently specifying whether they're left alone, dropped, etc. 18:33:36 the problem is if we don't say we are blocking for them, whats the motivation to fix them? 18:33:40 that we could ? 18:34:07 nirik: and if we do, when we may not reasonably be able to block, what's the motivation to fix them? 18:35:01 * nirik guesses he will switch to option 3 then. 18:35:25 I think the only reasonable outcome is to give the provenpackagers the blessing to change the packages. 18:35:36 we've already done that I thought? 18:35:37 t8m: we don't really have to give them that. 18:35:40 * sgallagh doesn't see option 3 as any different from "Eh, people can switch if they want. We don't really care" 18:35:46 pjones: No reason to fearmonger that either? ie: cross the can't port and can't block release for when we come to it? 18:36:37 well, all those packages will be out of compliance with our packaging guidelines... 18:36:46 .fas llaumgui 18:36:47 llaumgui_zhukov: llaumgui 'Guillaume Kulakowski' 18:36:47 what would we do for any other set that was? 18:36:49 abadger1999: no, just saying that we've not really had a big onslaught of provenpackagers work not being accepted AFAIK 18:37:07 abadger1999: it's a bridge we can cross if it happens. 18:37:15 pjones: [11:34:07] nirik: and if we do, when we may not reasonably be able to block, what's the motivation to fix them? 18:37:31 pjones: I'm refering to that --- isn't that also a bridge to cross if we arrive there? 18:37:31 additionally, we are not really setting expectations. 18:37:47 abadger1999: it may well be. 18:38:20 "we might do something to non converted packages by beta, or we might not" beta comes "we are blocking all these packages" "WHAT?" 18:38:50 obviously our instructions to packagers should be: get your work done. 18:38:54 nirik: I agree. We should set the expectation to be "they're blocked" now 18:38:58 We can always reduce that 18:39:00 I'm not sure I see that as being in question 18:39:16 But doing the reverse is only going to engender ill will towards FESCo 18:39:20 I vote for clearly announcing blocking for F17. 18:39:32 blocking the packages that is 18:39:38 sgallagh: and you think telling people their packages are blocked now when we clearly don't mean it *won't* engender ill will? 18:40:04 pjones: I *do* mean it. 18:40:07 * abadger1999 notes that we're at the second 15 minute mark 18:40:36 Proposal: take this to devel@ 18:40:38 sgallagh: uh, that's nice, but I haven't seen consensus here. 18:40:54 pjones: I know. I was expressing my own opinion. 18:41:00 yeah, let's take this to devel@ for discussion there instead of beating it to death more here. 18:41:03 Hence why I said "I" and not "We" 18:41:28 we are still on pair blocking alpha for the core+base+what's on livecd's right? 18:41:44 sgallagh: what do you want to ask on devel? 18:41:55 Viking-Ice: I am at least. 18:42:00 * mmaslano guess it will be same as here 18:42:15 mmaslano: I want to feel out the general packager community for how much push-back we'd get if we declared conversion a blocker for Beta 18:42:21 Viking-Ice: don't see any reason to change that, no. 18:42:33 Viking-Ice: Yes, I don't think that's likely to change. 18:42:39 great ( it's seems to be working as a motivating factor ) 18:42:42 If nothing else, we need those packages as good examples 18:44:37 * nirik shrugs. I think it might be a flamewar, but we can try for thoughts from devel lsit. 18:45:03 Well, can we at least get a formal vote on nirik's proposal? 18:45:09 whoever starts that discussion should make it clear that this is just about porting to unit files, and not about $RANDBUGYOUHATEABOUTSYSTEMD 18:45:30 * sgallagh wishes you could moderate on a per-thread basis 18:45:31 * notting goes back to figure out what nirik's proposal was 18:45:32 I guess I am no longer for my own proposal, but sure, we could vote on it. ;) 18:45:39 sgallagh: you can. 18:45:44 * t8m still does not see any sense in blocking release for the full conversion. If at all blocking the packages would be much more motivational and correct but F16 is too near for that. 18:47:16 Am I to understand that the only option we're likely to accept is Option 3, then? 18:47:51 Proposal: We do as many upgrades as possible, and live with only partial success. 18:48:10 sure, why not. 18:48:15 sounds good 18:48:29 sadly, I think thats the case... 18:48:31 since that's what we're going to wind up doing anyway, +1. 18:48:38 +1 18:48:53 #agreed Option 3: We do as many upgrades as possible, and live with only partial success. 18:49:07 #topic Next week's chair 18:49:31 * sgallagh passes the hot potato 18:50:06 +1 - i'm fine with that. to pick a random example , i don't care if callweaver starts via sysv 18:50:49 Who wants to handle the meeting for two weeks from today? 18:51:17 i can do it again, if nobody else volunteers 18:51:38 there's a chance i may miss that meeting, so i'll pass 18:51:42 I don't know that this is fair. We agreed to all take our turn. 18:51:55 * mmaslano won't be here next two weeks 18:52:13 well, we agreed it should rotate, but i don't think anyone said anything about doing so evenly 18:52:24 not a big deal, i can run it 18:52:27 I'd like to pass once more as I am FESCo novice. 18:52:36 t8m: So am I :) 18:52:48 sounds like i win then 18:52:48 * nirik could do it again, but also is happy to let ajax be a repeat offender. ;) 18:52:58 #action ajax will run the next FESCo meeting 18:53:03 #topic Open Floor 18:53:17 Put on your dancing shoes and come out on the Open Floor... 18:53:17 which, to be clear, is july 11. 18:53:49 oh wait. 18:53:51 I'll be on vacation for the July 18 meeting 18:54:00 I in fact won't likely be around for that one either. ;) 18:54:26 what is "david bowie #1 hit of 1983"? 18:54:28 (the july 11th one). Might be able to get on from the road, we will see. 18:55:14 Does anyone have any open floor items? 18:55:29 If not, I'll end the meeting in two minutes. 18:56:26 * nirik has nothing 18:56:35 not i 18:57:31 #endmeeting