17:01:05 <sgallagh> #startmeeting FESCO (2011-06-27)
17:01:05 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:21 <sgallagh> #meetingname fesco
17:01:21 <zodbot> The meeting name has been set to 'fesco'
17:01:26 <sgallagh> #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh
17:01:26 <zodbot> Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m
17:01:36 * nirik waves hello
17:01:36 <sgallagh> #topic init process
17:01:38 * notting is here
17:01:43 * sgallagh is here
17:01:44 <pjones> yo
17:01:48 * t8m too
17:02:07 <ajax> howdy
17:02:14 * mmaslano says hi
17:03:14 <sgallagh> cwickert, mjg59: Are you around?
17:04:20 <ajax> mjg59 said he'd have to miss today
17:04:29 <sgallagh> ok
17:05:13 <sgallagh> 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 <nirik> yeah, shall we cancel next week?
17:05:27 <ajax> 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 <sgallagh> +1 for cancelling next week
17:05:50 <nirik> +1 here.
17:05:52 <t8m> +1 for cancelling
17:05:52 <ajax> +1
17:05:53 <mmaslano> +1
17:06:04 <pjones> +1
17:06:21 <sgallagh> #agreed Cancel FESCo meeting on 2011-07-04
17:06:22 <notting> +1
17:06:56 <sgallagh> #topic #563 suggested policy: all daemons must set RELRO and PIE flags
17:06:56 <sgallagh> .fesco 563
17:06:57 <zodbot> sgallagh: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563
17:07:30 <sgallagh> nirik: I believe you took an action item last week to draft guidelines?
17:07:33 <nirik> I've failed to have time to put together a list for the PIE stuff. ;)
17:07:35 <nirik> sorry.
17:07:43 <nirik> Will try and get it this week... help welcome.
17:08:04 <sgallagh> Do we have any other updates on this issue?
17:08:13 <nirik> I see ajax just set relro in rawhide.
17:09:03 <ajax> yeah, not totally happy with doing that in %optflags instead of in binutils proper.
17:09:14 <ajax> but we'll see how relevant it ends up being.
17:10:30 <ajax> i'll send out an email about it.
17:11:03 <sgallagh> #action ajax to send out an email discussing %optflags vs. binutils
17:11:17 <sgallagh> Anything else on this topic?
17:11:36 * nirik has nothing at this time.
17:11:42 <ajax> ditto
17:11:51 <sgallagh> #topic #608 F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot
17:11:51 <sgallagh> .fesco 608
17:11:52 <zodbot> sgallagh: #608 (F16Feature: Trusted Boot - http://fedoraproject.org/wiki/Features/Trusted_Boot) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/608
17:12:12 <sgallagh> So I've seen a lot of... healthy discussion on the list about this.
17:12:32 <nirik> yeah.
17:12:46 <t8m> Unfortunately with not much input from the Feature owners?
17:12:49 <pjones> there's also a competing technology from TCG that IBM likes more.
17:13:12 <eparis> pjones: that's not strictly true......
17:13:13 <sgallagh> pjones: I'm led to understand that dboot is supposed to be a superset of tboot
17:13:26 <pjones> sgallagh: oh?
17:13:42 <sgallagh> I asked eparis to join us and help disambiguate things
17:13:58 <eparis> correct, any other 'trusted boot' package will need to do the exact same things as tboot.
17:14:11 <nirik> 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 <eparis> nirik: NOONE ask for this to be enabled by default
17:14:52 <eparis> the request is that it be ABLE to be enabled without manual human intervention.
17:14:57 <nirik> ok, that wasn't entirely clear from the feature page.
17:15:20 <nirik> so, enabled on machines that posess the hardware?
17:15:25 <sgallagh> eparis: Please rephrase that statement. I assume you meant "minimal" intervention?
17:15:28 <notting> 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 <simo> eparis, how can QE test this feature ?
17:15:32 <pjones> nirik: and that embed the interesting bits in the firmware.
17:15:34 <t8m> The feature page needs improvements, docs need to be added, agreement on the grubby/anaconda changes needs to be reached
17:15:35 <eparis> I dunno   scope section: UI to choose TXT/tboot support during installation.
17:15:41 <nirik> I am -1 for that as well.
17:15:49 <eparis> 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 <eparis> seemed clear to me this wasn't default...
17:16:08 <nirik> ok, so a UI to let the user choose it... still not great. Who would?
17:16:09 <pjones> notting: grubby probably isn't the right place for that anyway, though I guess maybe it could be.
17:16:23 <eparis> notting: that is correct, we have no way to handle alternative grub syntax
17:16:26 <eparis> that's all this is about...
17:16:32 <eparis> we need some way to handle alternative grub syntax
17:16:37 <notting> pjones: the integration is merely changing grub.conf in the presence of tboot, is it not?
17:16:46 <eparis> notting: that is all it is doing.
17:16:52 <pjones> I _think_ current grubby should copy the right stuff from old stanzas to new ones, which is really its job
17:17:27 <eparis> pjones: but the syntax is different, look at his example, grubby will only change one of the two entries on update
17:17:28 <pjones> 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 <nirik> 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 <eparis> pjones: who generates that?  anaconda?
17:18:23 <pjones> eparis: yeah
17:18:43 <eparis> 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 <eparis> that's all this is about.
17:18:54 <pjones> anaconda generates the original; grubby handles updates by finding a template entry and using it to generate new entries.
17:19:15 <notting> 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 <eparis> 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 <eparis> 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 <t8m> eparis, +1
17:20:31 <nirik> right.
17:20:39 <eparis> but all this is really aobut it changes to anaconda/tboot %pre/grubby template
17:20:40 <simo> eparis, this assumes we can have a tboot package in fedora, is tboot something that can actually be distributed in fedora ?
17:20:49 <nirik> it's already in.
17:20:52 <eparis> simo: been in fedora a while now   :)
17:20:56 <simo> ok
17:20:58 <sgallagh> Well, it's probably a feature if we're going to be directing multiple projects to coordinate this
17:21:29 <sgallagh> 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 <pjones> 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 <pjones> and then just make sure grubby actually works with the alternate stanza format
17:22:16 <nirik> 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 <pjones> (though tbh I think xen has a sufficiently similar format that updates may just work
17:22:21 <pjones> )
17:22:23 <sgallagh> 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 <eparis> pjones: but that doesn't work if tboot is installed after install    :-(
17:22:42 <pjones> no, it means if you install tboot yourself, manually, then its your own thing to do.
17:22:49 <pjones> honestly I think that's okay, though.
17:23:06 <eparis> pjones: i'm sure they'll write some %pre attrocity(?sp)
17:23:06 <pjones> sgallagh: sortof violates "do one thing and do it well"
17:23:11 <notting> 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 <sgallagh> I realize this is not, strictly speaking, Grubby's purpose, but it seems cleaner to me
17:23:29 <pjones> 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 <pjones> sgallagh: I don't want to introduce the idea of writing new stanzas to grubby.  I really don't.
17:24:05 <pjones> sgallagh: I'm going to push back a lot on that.
17:24:34 <eparis> pjones: so then we'll need to do the new stanzas in tboot scripts
17:24:37 <sgallagh> 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 <notting> pjones: grub2 doesn't change config format, correct?
17:25:00 <nirik> oh yes it does. (last I looked)
17:25:20 <pjones> notting: wrong :/
17:25:30 <nirik> xml funtime. :)
17:25:34 <t8m> oh no
17:25:42 <pjones> eparis: why?  you haven't answered why we need it on manual package install at all.
17:26:13 <notting> pjones: is anaconda grub.conf writing pre or post package install?
17:26:30 <eparis> pjones: because we know people will   :)
17:26:36 <sgallagh> 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 <eparis> 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 <pjones> notting: post
17:27:37 <sgallagh> nirik: Do you have a proposal to vote on?
17:28:00 <pjones> eparis: that's not a particularly great answer.
17:28:26 <nirik> 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 <pjones> 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 <sgallagh> nirik: +1 to declining Feature as written.
17:29:08 <nirik> +1 my own proposal.
17:29:11 <notting> nirik: don't like that second part. submitting again later w/o more information, clarification, etc. shouldn't be allowed
17:29:25 <t8m> 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 <eparis> what clarification are people asking for?
17:29:40 <pjones> t8m: that's completely unlike what eparis is saying, though.
17:30:05 <nirik> 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 <pjones> 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 <t8m> pjones, OK
17:31:22 <nirik> 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 <nirik> 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 <sgallagh> 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 <notting> am i misunderstanding this, or can anyone with root completely disable this feature by editing grub.conf?
17:33:33 <eparis> notting: they can
17:33:35 <nirik> I think they can, yes
17:34:50 <sgallagh> 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 <t8m> sgallagh, +1
17:36:05 <mitr> 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 <nirik> 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 <sgallagh> pjones, cwickert, ajax, mmaslano, notting: please vote.
17:38:02 <ajax> +1
17:38:15 <pjones> +1 I guess.
17:38:16 <sgallagh> +1 (for the record)
17:38:32 <mmaslano> +1 decline feature as is
17:38:55 <notting> +1, i guess. but mainly just because it's unclear what the integration plan is
17:39:30 <nirik> yeah, this seems to be 'enable it because we might do something with it someday'
17:39:51 <sgallagh> #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 <sgallagh> #topic #531 Orphaned package ownership claiming clarification
17:40:48 <sgallagh> .fesco 531
17:40:49 <zodbot> sgallagh: #531 (Orphaned package ownership claiming clarification) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/531
17:41:48 <nirik> I added some options/thoughts there.
17:42:41 <cwickert> +1 for nirik's propsal, sorry for beeing late again
17:42:59 <sgallagh> cwickert: Is that on the previous issue?
17:43:08 <cwickert> sgallagh: yes
17:43:20 <sgallagh> Ok
17:43:51 <sgallagh> nirik: I'm wondering if it isn't reasonable to just always require a re-review to remove orphan status.
17:44:19 <t8m> nirik, I'd say that the a) would be easiest to implement and perhaps it would be acceptable as well
17:44:23 <sgallagh> nirik: If nothing else, it would help with the compliance-rot we see in old packages vs. the current policies.
17:44:23 <nirik> well, we have not many reviewers...
17:44:25 <notting> i think a simple policy is 'no re-review for orphans, always re-review for blocked'
17:44:43 <t8m> sgallagh, to remove orphan status? that's not a good idea
17:45:00 <sgallagh> 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 <sgallagh> Never mind, I withdraw that
17:45:40 <pjones> 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 <nirik> cwickert: thats the current "policy" yeah.
17:45:58 <nirik> but it's hard to enforce.
17:46:49 <cwickert> 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 <notting> cwickert: that's why i think tying it to blocked packages is  better - it's much more clear
17:47:03 <t8m> nirik, I am +1 to your a) proposal that I read is the same as notting's proposal
17:47:24 <sgallagh> nirik: I am also +1 to the a) proposal. Seems like the most achievable goal
17:47:54 <cwickert> notting: +1 to that
17:48:08 <mmaslano> nirik: your proposal sounds reasonable +1
17:48:24 <notting> 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 <pjones> +1
17:49:12 <cwickert> +1
17:49:42 <sgallagh> #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 <nirik> would someone like to announce the new policy and change any wiki pages? ;)
17:50:58 <notting> sure, why not
17:51:07 <nirik> http://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers looks like the page to update (at least one of)
17:51:56 <sgallagh> #topic #614 Proposed list of packages to drop due to FTBFS prior to F16 branching
17:51:56 <sgallagh> .fesco 614
17:51:57 <zodbot> 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 <sgallagh> First request: could someone with WIKI_ADMIN privilege please add {{{ }}} blocks to this ticket? :)
17:52:51 * nirik can
17:54:19 <notting> proposal: do this at the 'normal' time in the cycle where we block orphans, regenerating the list then.
17:54:35 <sgallagh> So if I understand this correctly, the proposal is for FTBFS tickets to be dead.package?
17:54:57 <sgallagh> If they haven't built from source since before the supported releases
17:54:58 * nirik fails his }}}
17:55:00 <t8m> sgallagh, only for packages that last built in f12 and f13
17:55:10 <nirik> notting: +1
17:55:18 <pjones> sgallagh: looks like a selective list of them, but yeah
17:56:28 <nirik> I'm happy with blocking the 12/13 ones... or even the 14/15 ones.
17:56:58 <nirik> The automake ones might hit a lot of packages.
17:57:00 <sgallagh> I think we should limit it to 12/13/14 in the F16 timeframe.
17:57:00 <notting> the proposal is to just block the ones that haven't built since f12/f13
17:57:03 <nirik> (I hope not, but...)
17:57:21 <sgallagh> i.e. any packages that no longer build in a supported release
17:57:32 <sgallagh> 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 <pjones> I should point out that occasionally we do see FTBFS because of FTBFS problems, not because of package problems.
17:59:05 <pjones> so automatically removing anything that fails FTBFS isn't great.
17:59:26 <sgallagh> pjones: I don't know if this needs to be automated
17:59:43 <nirik> pjones: well, yeah, but this list is things that also haven't built in fedora I think...
18:00:05 <pjones> nirik: a fair difference.
18:00:15 <nirik> 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 <sgallagh> yes
18:00:31 <sgallagh> The dist tag would update, of course
18:01:28 <nirik> 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 <t8m> nirik, +1
18:01:43 <sgallagh> So: Proposal: packages that FTBFS and have a dist tag that pre-dates a supported release, it should be blocked
18:02:00 <pjones> nirik: +1 to that.
18:02:01 <mmaslano> +1
18:02:03 <sgallagh> Ok, those look to be the same proposal, though nirik's is more detailed.
18:02:07 <sgallagh> So +1 to nirik's proposal
18:02:15 <nirik> yeah, jinx. ;)
18:03:07 <notting> +1
18:03:10 <ajax> +1
18:03:27 <sgallagh> #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 <sgallagh> Who wants to write the SOP for this?
18:03:51 <nirik> hopefully rel-eng won't mind another task. ;)
18:05:41 <nirik> I guess I could try... not sure how much time I will have...
18:05:45 <nirik> or we could ask mdomsch to. ;)
18:06:05 <sgallagh> He was willing to file a detailed bug. I'm all for that :)
18:06:56 <nirik> I can ask him, failing that can try to
18:08:14 <sgallagh> #action nirik to ask mdomsch to write an SOP for FTBFS package removal, else work on it himself.
18:08:26 <sgallagh> #topic 615 Strategy for services that do not have systemd native unit files
18:08:26 <sgallagh> .fesco 615
18:08:27 <zodbot> sgallagh: #615 (Strategy for services that do not have systemd native unit files) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/615
18:08:40 <sgallagh> Viking-Ice: I believe you had some concerns about this that you wanted to raise?
18:09:05 <Viking-Ice> sgallagh, this is toshio proposal but I aggree with his approach
18:09:18 * abadger1999 here too.
18:09:32 <Viking-Ice> basically block alpha as we discussed earlier then proceed with either of abadger1999 proposal
18:10:10 <Viking-Ice> 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 <Viking-Ice> s/alpha/base
18:11:17 <notting> i prefer option #3, honestly
18:11:19 <nirik> the green check is that it's done? or just has a unit file thats attached to the bug?
18:11:41 <Viking-Ice> 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 <Viking-Ice> is done in bugzilla
18:11:55 <nirik> ok
18:12:03 <Viking-Ice> senmdail will be dealt with in this week according to maintainer
18:12:26 <Viking-Ice> psacct is done in bugzilla maintainer will look at it tomorrow
18:12:43 <Viking-Ice> cpuspeed is ?
18:12:52 <sgallagh> 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 <abadger1999> 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 <t8m> I am -1 on option 1
18:13:30 <notting> abadger1999: well, i thought the "omg never try to migrate settings" policy was a bad idea too
18:13:34 <mmaslano> I prefer option 3, I don't think maintainers can port it so fast
18:13:50 <Viking-Ice> lol..
18:13:57 <Viking-Ice> they can
18:14:09 <Viking-Ice> average porting time with spec file is ca 15 minutes
18:14:27 <t8m> Viking-Ice, you wish
18:14:27 <sgallagh> Viking-Ice: Well, some groups have much more trouble with porting
18:14:31 <sgallagh> Such as 389
18:14:46 <Viking-Ice> yeah I know I've been working with richard on 389
18:14:50 <mmaslano> Viking-Ice: if it's only 15 minutes, why they are not done yet?
18:14:53 <sgallagh> Even sssd took a couple days of back-and-forth revisions to get right.
18:15:11 <pjones> still, we're talking about a couple of days, not a whole release cycle.
18:15:48 <Viking-Ice> mmslano we ported ca 100 - 150 during last release cycle mostly 2 of us
18:16:03 <notting> 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 <t8m> Viking-Ice, with multiple bugs and other problems :D
18:16:17 <sgallagh> Proposal: Aim for Option 1) but block Beta, not Release.
18:16:17 <t8m> notting, +1
18:16:18 <nirik> how many are left?
18:16:21 * nirik looks for the tracker
18:16:22 <Viking-Ice> ca 400
18:16:22 <t8m> sgallagh, -1
18:16:45 <Viking-Ice> few of the alpha goal
18:17:04 <sgallagh> At beta we can choose to abandon our goal of "all services" if it's unachievable
18:17:15 <sgallagh> But we should set our expectation that this is what we're striving for
18:17:49 <mmaslano> I'd rather take different approach. I agree with notting and t8m
18:18:55 <sgallagh> 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 <Viking-Ice> basically the problem here are the maintainers if you got some brilliant idea how to "motivate" them I'm all ears
18:19:14 <sgallagh> 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 <sgallagh> nirik: Going with Option 3), we might as well say: Proposal: provenpackagers do all the work.
18:19:53 <sgallagh> There's no mandate to make the change
18:20:06 <sgallagh> Package maintainers will largely choose the path of least effort
18:20:13 <t8m> sgallagh, I think we are saying that the mandate will be there in F17
18:20:20 <t8m> sgallagh, in option 3
18:20:23 <abadger1999> sgallagh: Additionally, there's no mandate that the packager maintainers have to accept the provenpackager work.
18:20:36 <Viking-Ice> packaging is one thing writing the service files needs at least some feed back from the maintainer
18:20:49 <nirik> I suspect there will be many that are not motivated no matter what we decide here today. ;)
18:20:51 <pjones> abadger1999: no, but there's no reason to fearmonger about that either.
18:21:11 <sgallagh> 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 <sgallagh> +1 to continue, -1 for mailing list
18:21:35 <nirik> +1 to keep going for a bit.
18:21:41 <notting> +1 to keep going
18:21:46 <nirik> so, how many more are there on 'handout media'?
18:22:14 <Viking-Ice> 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 <notting> 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 <notting> Viking-Ice: wtf are you trying to say there?
18:23:09 <Viking-Ice> nirik, not quite there yet few more + base and core
18:23:21 <notting> Viking-Ice: because some packages ship systemd but not sysv scripts that all sysv support is broken?
18:23:47 <Viking-Ice> notting, in the long run yes
18:23:50 <Viking-Ice> I expect as much
18:23:57 <notting> Viking-Ice: if that's your goal, then GTFO
18:24:07 <Viking-Ice> notting, that's not my goal so stfu
18:24:24 <nirik> huh? can we move this back to technical discussion?
18:24:26 <abadger1999> guys.  be excellent to each other please.
18:24:28 <sgallagh> Hey, let's try to stay civil, please
18:24:50 <Viking-Ice> 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 <notting> 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 <notting> if we break sysv support, we're just going to have to fix it.
18:25:17 <t8m> 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 <pjones> yeah, I'm really not seeing any way that constitutes sysv support being broken for end users.
18:25:41 <pjones> 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 <pjones> which is unfortunate, but not the end of the world.
18:27:05 <Viking-Ice> basically we want to convert as many as possible during this release cycle before beta
18:27:15 <pjones> yes, and I think we all get that.
18:27:30 <Viking-Ice> how we achieve that makes not difference to me
18:27:35 <nirik> 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 <notting> nirik: f17?
18:27:49 <nirik> sorry, yeah.
18:28:44 <t8m> 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 <sgallagh> nirik: So, +1 to my proposal above :)
18:29:06 <nirik> 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 <t8m> 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 <nirik> 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 <abadger1999> 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 <nirik> +1 to option 1 with a punt to next release if too many problems/too slow to get done before beta.
18:30:29 <pjones> t8m: eh, I think our users do see some benefit from everything being one particular way
18:30:31 <sgallagh> +1 to option 1 with a punt to next release if too many problems/too slow to get done before beta.
18:30:34 <ajax> +1 to what nirik just said
18:31:04 <pjones> likewise, I'm +1 to it as a goal with the punt option
18:31:44 <notting> if we're stating it with a punting option, then 'block release' as stated isn't really on the table?
18:32:00 <pjones> yeah.
18:32:23 <t8m> so basically this is the option 3
18:32:28 <abadger1999> <nod>  It's better to define what set of packages would block release vs what set would not.
18:32:47 <sgallagh> t8m: No, we're leaving the decision of what to do with the laggards to Beta
18:33:15 <nirik> yeah, I guess thats the crux of the issue.
18:33:20 <sgallagh> We aren't currently specifying whether they're left alone, dropped, etc.
18:33:36 <nirik> the problem is if we don't say we are blocking for them, whats the motivation to fix them?
18:33:40 <nirik> that we could ?
18:34:07 <pjones> 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 <t8m> I think the only reasonable outcome is to give the provenpackagers the blessing to change the packages.
18:35:36 <nirik> we've already done that I thought?
18:35:37 <pjones> 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 <abadger1999> 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 <nirik> well, all those packages will be out of compliance with our packaging guidelines...
18:36:46 <llaumgui_zhukov> .fas llaumgui
18:36:47 <zodbot> llaumgui_zhukov: llaumgui 'Guillaume Kulakowski' <llaumgui@gmail.com>
18:36:47 <nirik> what would we do for any other set that was?
18:36:49 <pjones> abadger1999: no, just saying that we've not really had a big onslaught of provenpackagers work not being accepted AFAIK
18:37:07 <pjones> abadger1999: it's a bridge we can cross if it happens.
18:37:15 <abadger1999> pjones: [11:34:07] <pjones> nirik: and if we do, when we may not reasonably be able to block, what's the motivation to fix them?
18:37:31 <abadger1999> pjones: I'm refering to that --- isn't that also a bridge to cross if we arrive there?
18:37:31 <nirik> additionally, we are not really setting expectations.
18:37:47 <pjones> abadger1999: it may well be.
18:38:20 <nirik> "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 <pjones> obviously our instructions to packagers should be: get your work done.
18:38:54 <sgallagh> nirik: I agree. We should set the expectation to be "they're blocked" now
18:38:58 <sgallagh> We can always reduce that
18:39:00 <pjones> I'm not sure I see that as being in question
18:39:16 <sgallagh> But doing the reverse is only going to engender ill will towards FESCo
18:39:20 <t8m> I vote for clearly announcing blocking for F17.
18:39:32 <t8m> blocking the packages that is
18:39:38 <pjones> 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 <sgallagh> pjones: I *do* mean it.
18:40:07 * abadger1999 notes that we're at the second 15 minute mark
18:40:36 <sgallagh> Proposal: take this to devel@
18:40:38 <pjones> sgallagh: uh, that's nice, but I haven't seen consensus here.
18:40:54 <sgallagh> pjones: I know. I was expressing my own opinion.
18:41:00 <pjones> yeah, let's take this to devel@ for discussion there instead of beating it to death more here.
18:41:03 <sgallagh> Hence why I said "I" and not "We"
18:41:28 <Viking-Ice> we are still on pair blocking alpha for the core+base+what's on livecd's right?
18:41:44 <mmaslano> sgallagh: what do you want to ask on devel?
18:41:55 <nirik> Viking-Ice: I am at least.
18:42:00 * mmaslano guess it will be same as here
18:42:15 <sgallagh> 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 <notting> Viking-Ice: don't see any reason to change that, no.
18:42:33 <sgallagh> Viking-Ice: Yes, I don't think that's likely to change.
18:42:39 <Viking-Ice> great ( it's seems to be working as a motivating factor )
18:42:42 <sgallagh> 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 <sgallagh> Well, can we at least get a formal vote on nirik's proposal?
18:45:09 <nirik> 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 <nirik> I guess I am no longer for my own proposal, but sure, we could vote on it. ;)
18:45:39 <nirik> 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 <sgallagh> Am I to understand that the only option we're likely to accept is Option 3, then?
18:47:51 <sgallagh> Proposal: We do as many upgrades as possible, and live with only partial success.
18:48:10 <ajax> sure, why not.
18:48:15 <mmaslano> sounds good
18:48:29 <nirik> sadly, I think thats the case...
18:48:31 <pjones> since that's what we're going to wind up doing anyway, +1.
18:48:38 <t8m> +1
18:48:53 <sgallagh> #agreed Option 3: We do as many upgrades as possible, and live with only partial success.
18:49:07 <sgallagh> #topic Next week's chair
18:49:31 * sgallagh passes the hot potato
18:50:06 <notting> +1 - i'm  fine with that. to pick a random example , i  don't care if callweaver starts via sysv
18:50:49 <sgallagh> Who wants to handle the meeting for two weeks from today?
18:51:17 <ajax> i can do it again, if nobody else volunteers
18:51:38 <notting> there's a chance i may miss that meeting, so i'll pass
18:51:42 <sgallagh> 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 <ajax> well, we agreed it should rotate, but i don't think anyone said anything about doing so evenly
18:52:24 <ajax> not a big deal, i can run it
18:52:27 <t8m> I'd like to pass once more as I am FESCo novice.
18:52:36 <sgallagh> t8m: So am I :)
18:52:48 <ajax> 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 <sgallagh> #action ajax will run the next FESCo meeting
18:53:03 <sgallagh> #topic Open Floor
18:53:17 <sgallagh> Put on your dancing shoes and come out on the Open Floor...
18:53:17 <ajax> which, to be clear, is july 11.
18:53:49 <nirik> oh wait.
18:53:51 <sgallagh> I'll be on vacation for the July 18 meeting
18:54:00 <nirik> I in fact won't likely be around for that one either. ;)
18:54:26 <pjones> what is "david bowie #1 hit of 1983"?
18:54:28 <nirik> (the july 11th one). Might be able to get on from the road, we will see.
18:55:14 <sgallagh> Does anyone have any open floor items?
18:55:29 <sgallagh> If not, I'll end the meeting in two minutes.
18:56:26 * nirik has nothing
18:56:35 <ajax> not i
18:57:31 <sgallagh> #endmeeting