Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 17:00UTC in #fedora-meeting on irc.freenode.net.
Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9
= Followups =
#topic #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline .fesco 1322 https://fedorahosted.org/fesco/ticket/1322
= New business =
#topic #1350 Updates Policy should require inter-dependent packages be submitted together .fesco 1350 https://fedorahosted.org/fesco/ticket/1350
#topic #1355 Please select Engineering Representiatve for the new Fedora Council .fesco 1355 https://fedorahosted.org/fesco/ticket/1355
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
=================================== #fedora-meeting: FESCO (2014-10-15) ===================================
Meeting started by nirik at 17:00:11 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-15/fesco.2014-10-15-... .
Meeting summary --------------- * init process (nirik, 17:00:11)
* #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline (nirik, 17:01:54) * LINK: https://fedorahosted.org/fesco/ticket/1322 (nirik, 17:01:54) * LINK: https://fedoraproject.org/wiki/Changes/jQuery no contingency; postpone (mitr, 17:04:31) * AGREED: postpone this change. (+6,0,0) (nirik, 17:05:49) * LINK: https://fedoraproject.org/wiki/Changes/FormatSecurity; ignore contingency (reverting the change), get someone to verify status (mitr, 17:06:18) * AGREED: bug 1078901 Format Security - done/approved, will ask for a status update on the bug (+6,0,0) (nirik, 17:10:38) * LINK: https://fedoraproject.org/wiki/Changes/u-boot_syslinux, contingency: “ make sure all supported boards work with arm-boot-config and use it as a fallback. ” (mitr, 17:11:11) * LINK: http://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms (mattdm, 17:36:39) * AGREED: 1078911 u-boot syslinux by default is blocking beta (+5,1,0) (nirik, 17:42:17) * LINK: https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork no contingency needed, no known progress, proposal: propose (mitr, 17:43:19) * AGREED: 1084102 PrivateDevices?=yes and PrivateNetwork?=yes For Long-Running Services is postponed (+6,0,0) (nirik, 17:46:04) * LINK: https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Imag... , no contingency needed (mitr, 17:46:25) * AGREED: 1091299 (A)Periodic Updates to Cloud Images - (+6,0,0) (nirik, 17:56:02) * LINK: https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint , no cintingency needed (mitr, 17:56:49) * change is ready for beta, no action needed. (nirik, 17:57:24) * LINK: https://fedoraproject.org/wiki/Changes/Web_Assets , no contingency needed. (mitr, 17:58:16) * AGREED: 998583 Web Assets - postpone to f22 (+6,0,0) (nirik, 18:00:19) * AGREED: atomic cloud work ongoing this week, still approved to land (+6,0,0) (nirik, 18:12:56) * will ping mariadb and mesos maintainers again since their changes seem done. (nirik, 18:14:22)
* #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37) * LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38) * AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03)
* #1355 Please select Engineering Representiatve for the new Fedora Council (nirik, 18:30:20) * LINK: https://fedorahosted.org/fesco/ticket/1355 (nirik, 18:30:21) * HELP: all this should be added to the fesco elections page or a council page or somewhere better than meeting minutes. (mattdm, 18:43:04) * AGREED: Draft of fedora council represenative selection process to be written up and ratified next week. (+5,0,0) (nirik, 18:46:11) * ACTION: dgilmore-bne to send out announcement of nomination period starting. (nirik, 18:48:57) * ACTION: jwb to write up draft of selection policy document for next week (nirik, 18:49:15)
* Next week's chair (nirik, 18:49:21) * mattdm to chair next week. (nirik, 18:51:50)
* Open Floor (nirik, 18:51:55)
Meeting ended at 18:54:08 UTC.
Action Items ------------ * dgilmore-bne to send out announcement of nomination period starting. * jwb to write up draft of selection policy document for next week
Action Items, by person ----------------------- * dgilmore * dgilmore-bne to send out announcement of nomination period starting. * dgilmore-bne * dgilmore-bne to send out announcement of nomination period starting. * jwb * jwb to write up draft of selection policy document for next week * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * nirik (163) * mattdm (87) * dgilmore-bne (72) * jwb (66) * mitr (55) * kalev (30) * tflink (21) * adamw (17) * zodbot (17) * pjones (8) * halfie (3) * taquilla (1) * misc (1) * mmaslano (0) * sgallagh (0) * t8m (0) * thozza (0) * dgilmore (0) -- 17:00:11 <nirik> #startmeeting FESCO (2014-10-15) 17:00:11 <zodbot> Meeting started Wed Oct 15 17:00:11 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:11 <nirik> #meetingname fesco 17:00:11 <nirik> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:11 <nirik> #topic init process 17:00:11 <zodbot> The meeting name has been set to 'fesco' 17:00:11 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:16 <mitr> Hello 17:00:26 <jwb> hi 17:00:48 <dgilmore-bne> hola 17:00:54 * nirik waits to see if we get quorum today. ;) 17:00:55 <kalev> hello 17:01:27 <mattdm> hi! 17:01:41 <nirik> cool. Seems so. ;) 17:01:54 <nirik> #topic #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline 17:01:54 <nirik> .fesco 1322 17:01:54 <nirik> https://fedorahosted.org/fesco/ticket/1322 17:01:55 <zodbot> nirik: #1322 (F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline) – FESCo - https://fedorahosted.org/fesco/ticket/1322 17:02:13 <nirik> I didn't invite anyone because I wasn't sure what was affected. 17:02:21 <nirik> how do we want to approach this? one by one? 17:02:49 <jwb> yeah 17:03:25 <nirik> or, default to 'punt to next release, do contingency' and then discuss ones we want to except? 17:03:52 * mattdm is okay with crunching through them 17:03:56 <nirik> ok. 17:04:05 <nirik> Here's the system wide ones: 17:04:12 <nirik> .bug 1078903 jQuery 17:04:14 <zodbot> nirik: Bug 1078903 jQuery - https://bugzilla.redhat.com/1078903 jQuery 17:04:22 <jwb> postpone 17:04:31 <mitr> https://fedoraproject.org/wiki/Changes/jQuery no contingency; postpone 17:04:40 <mattdm> +1 17:04:51 <nirik> +1 17:04:53 <kalev> +1 17:05:00 <dgilmore-bne> +1 17:05:49 <nirik> #agreed postpone this change. (+6,0,0) 17:06:09 <nirik> .bug 1078901 Format Security 17:06:12 <zodbot> nirik: Bug 1078901 Format Security - https://bugzilla.redhat.com/1078901 Format Security 17:06:18 <mitr> https://fedoraproject.org/wiki/Changes/FormatSecurity; ignore contingency (reverting the change), get someone to verify status 17:06:34 <mitr> (checking now, it is clearly enabled in redhat-rpm-config) 17:06:47 <nirik> yeah, we enabled it I know, but there may be outlyers. 17:06:58 <jwb> outliers in what form? 17:07:03 <jwb> packages that haven't been rebuilt? 17:07:30 <nirik> jwb: yeah, failed mass rebuild for whatever reason, or the autoconf stuff we did didn't work right and they didn't get the right flags? 17:07:49 <mattdm> ask change owner to check on that and report? 17:08:10 <jwb> i tried poking halfie in #fedora-devel 17:08:41 <jwb> but yeah, basically i agree with mattdm and mitr 17:08:45 * nirik too. 17:08:51 <mitr> mattdm/nirik: AFAICT the scope never was to promise that _everything_ will use -Werror=format-security, only that our default flags will do that. respecting the default flags is basically a general packaging guideline enforcement issue 17:09:01 <nirik> mitr: sure. 17:09:10 <mattdm> mitr: which are area _awesome_ about following up on :) 17:09:23 <mitr> mattdm: Oh yeah :) 17:09:29 <nirik> proposal: call this done/in and ask for a status update on the bug 17:09:37 <mattdm> +1 17:09:37 <jwb> nirik, +1 17:09:39 <kalev> +1 17:09:44 <mitr> nirik: +1 17:09:49 <nirik> +1 17:09:54 <dgilmore-bne> +1 17:10:38 <nirik> #agreed bug 1078901 Format Security - done/approved, will ask for a status update on the bug (+6,0,0) 17:10:55 <nirik> .bug 1078911 u-boot syslinux by default 17:10:58 <zodbot> nirik: Bug 1078911 u-boot syslinux by default - https://bugzilla.redhat.com/1078911 u-boot syslinux by default 17:11:11 <mitr> https://fedoraproject.org/wiki/Changes/u-boot_syslinux, contingency: “ make sure all supported boards work with arm-boot-config and use it as a fallback. ” 17:11:23 <kalev> dgilmore-bne probably knows how far this is? 17:11:36 * nirik nods 17:11:50 <dgilmore-bne> I have patches for grubby waiting review 17:12:08 <dgilmore-bne> and I have a small piece to write for anaconda to call. 17:12:27 <nirik> well, we are in beta freeze... at this point is it better to just punt to f22? 17:12:34 <jwb> i'd think so 17:12:42 <dgilmore-bne> u-boot has an update in updates-testing that adds a bunch of boards 17:13:26 <dgilmore-bne> its going to be working ofr the boards its working for anyway 17:13:46 <kalev> I think the important thing here is to have this in before the beta release so that this gets testing 17:13:47 <jwb> how? you just said you have patches waiting for review 17:13:57 <kalev> or otherwise punt to F22 17:14:01 <jwb> if they're still waiting for review, they aren't going to be in the beta... 17:14:01 <dgilmore-bne> and there is no fallback for a bunch of boards 17:14:01 <nirik> or perhaps to rephrase then: retarget change for f21 to that update and do the rest for 22? 17:14:50 <dgilmore-bne> jwb: extlinux.conf doesnt get updated right without the patrches waiting review 17:14:58 <dgilmore-bne> and the users systems do not boot 17:15:23 <jwb> that sounds fairly bad. shouldn't we punt this all to f22 then? 17:15:40 <dgilmore-bne> jwb: punting to f2 really is not possible 17:15:47 <dgilmore-bne> f22 17:16:00 <dgilmore-bne> jwb: there is no other way to boot many systems 17:16:35 <mitr> 1) would we postpone the release for this? 2) if not, what can /should be done by whom by what date, and how can FESco help? 3) if that fails, what HW are we dropping from F21? 17:16:56 <mitr> (4) Would it be lazy of me to propose to ask the ARM SIG to sort this out?) 17:17:18 <nirik> well, I don't think we have time to do much sorting. ;( 17:18:06 <dgilmore-bne> mitr: all the allwinner systems, utilite, newer tegra systems 17:19:04 <nirik> so, we need pjones to review grubby patches, appy and push update to stable and uboot from testing to stable, and anaconda change applied and moved to stable? 17:19:14 <pjones> on my TODO 17:19:16 <jwb> sounds like a bit much 17:19:24 <nirik> yeah. 17:19:29 <dgilmore-bne> nirik: its not an anaconda change 17:19:36 <pjones> actually bcl already reviewed it, but I'm in the middle of merging some other code, so... 17:19:37 <dgilmore-bne> its code anaconda already changes 17:19:46 <jwb> 13:12 < dgilmore-bne> and I have a small piece to write for anaconda to call. 17:19:48 <dgilmore-bne> calls 17:19:49 <jwb> 13:12 < dgilmore-bne> and I have a small piece to write for anaconda to call. 17:19:57 <jwb> sorry 17:20:01 <nirik> ah, ok, not in anaconda, in grub? 17:20:01 <pjones> Also it'd be nice if the arm team could figure out what they want and /stick with it/. 17:20:15 <dgilmore-bne> nirik: not extlinux-bootloader 17:20:21 <pjones> It's completely absurd that we change this stuff every release. 17:20:31 <dgilmore-bne> it fills in for syslinux-extlinux on arm 17:21:01 <nirik> ok, I'm wanting to release f21 this year... how soon can all this land? 17:21:12 <jwb> ok, i am of the opinion that either this is important enough to block the beta release for (using the FESCo exception process) or it all needs to be dropped. 17:21:19 <dgilmore-bne> pjones: it is and what we are moving to I got upstream and are moving systems over to it 17:21:21 <jwb> so, i think that's the choice in front of us 17:21:22 * mattdm agrees with jwb 17:22:08 <mattdm> I think there's enough going on and I _really_ don't want to risk another slip 17:22:11 <mitr> jwb: I tend to agree. Introducing a different bootloader by Final is extremely risky. 17:22:19 <nirik> well, "punting to f22 really is not possible" 17:22:22 <pjones> nirik: I was hoping to get it in by Friday. Though to be honest we could do it in a package update separate from moving it upstream, because the stuff I've been working on merging (genec's btrfs patchset) isn't release blocking at all. 17:22:23 <dgilmore-bne> at the least with the grubby changes for most users things will just work as they use disk images and not anaconda installed systems 17:23:05 <jwb> nirik, it sounded possible by dropping various bits of HW support 17:23:19 <dgilmore-bne> anaconda will continue to work on the systems we have cared about to date 17:23:39 <jwb> proposal: block beta for this begrudgingly 17:24:00 <dgilmore-bne> we want to expand anaconda just working on more systems and that piece could be punted to f22 17:24:00 <nirik> +1 (and please hurry and land it asap so it can get tested and thru freeze) 17:25:01 <nirik> more votes? more discussion? 17:25:04 <kalev> I'd rather make it so that if the fix doesn't land in time for beta, we punt it to F22 17:25:08 <kalev> and don't hold up the release for it 17:25:14 <mattdm> It's making me feel like ARM isn't really ready to be primary. 17:25:17 <jwb> kalev, apparently "not possible"? 17:25:25 * dgilmore-bne thinks he should abstain 17:25:30 <mitr> jwb: possible by dropping HW? 17:25:37 <kalev> right 17:25:41 <jwb> well, i'm waiting for dgilmore-bne to confirm that 17:25:47 <mattdm> "dropping HW" = "not supporting new hardware we wanted to include"? 17:26:00 <jwb> unclear to me if that's accurate 17:26:02 <dgilmore-bne> jwb: at the least we need the grubby patches 17:26:08 <jwb> dgilmore-bne, or... what? 17:26:56 <dgilmore-bne> jwb: the disk images have long had the fdtdir line added to extlinux.conf 17:27:04 <dgilmore-bne> we need to update them correctly 17:27:11 <mitr> dgilmore-bne: … or what? 17:27:21 <mitr> What is the impact of punting? 17:27:23 <dgilmore-bne> mitr: ? 17:27:28 <jwb> dgilmore-bne, pretend for a moment, that i don't know anything at all about what you're talking about. if we punt on this, what happens? 17:27:40 <jwb> do we lose support for HW we supported in F20? 17:27:51 <dgilmore-bne> mitr: the impact of punting is that a bunch of hardware would be broken. 17:27:51 <jwb> do we lose support for HW we wanted to include in F21 but don't support in F20? 17:28:06 <dgilmore-bne> including hardware we support to date. 17:28:35 <dgilmore-bne> jwb: yes 17:28:49 <adamw> er, isn't this already on the beta blocker list? 17:28:52 <kalev> would it be feasible we go back to what we did in F20 to avoid regressing on HW support? 17:28:59 <jwb> adamw, great question! 17:29:00 <jwb> no idea 17:29:02 <dgilmore-bne> adamw: the grubby change is 17:29:06 <adamw> oh, there's more? 17:29:09 <mitr> jwb: +1 to blocking this for now; sending arm@ a note and asking them whether they would rather do something else would be nice. 17:29:17 <dgilmore-bne> and at the least we need that 17:29:18 <adamw> sorry, we're in blocker meeting right now and just came to discussing the grubby bug 17:29:39 <adamw> aiui, the grubby bug is intended to be more or less a proxy for 'make it boot on arm without requiring manual workarounds'... 17:29:39 <mattdm> ditto what kalev asked... 17:29:48 <jwb> i'm slightly perturbed though. this had a fallback plan listed, but it suddenly isn't feasible 17:29:53 <dgilmore-bne> kalev: not easily 17:29:54 <jwb> which is misleading 17:30:05 <nirik> so thats +3 to blocking on it, 1 abstention. 17:30:07 <mattdm> yeah. to say the least. 17:30:35 <mitr> jwb: Hum, the contingency deadline was for _Alpha_ so it not being feasible by Beta makes some sense. 17:31:07 <jwb> mitr, all of this sounds like it should have landed in Alpha anyway 17:31:15 <mattdm> dgilmore-bne: are the systems that won't work without changes those listed under f20 here: http://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms ? 17:31:35 <dgilmore-bne> jwb: it should have but I was distracted by being able to actually make alpha 17:31:44 <mitr> jwb: Yes; IOW FESCo has dropped the ball on watching this. 17:31:51 <dgilmore-bne> not a great excuse but that is what happened 17:31:58 <jwb> dgilmore-bne, then perhaps it should have been punted back then 17:32:08 <jwb> i'm not looking to place blame. i'm looking to learn from this. 17:32:22 <dgilmore-bne> jwb: perhaps, then people could have worked on the contingency plan 17:32:35 <jwb> ok, so it seems we have no choice other than to block beta for this 17:32:44 * nirik nods. 17:32:58 * jwb watches mattdm have an anuerism 17:33:01 <dgilmore-bne> I really really wanted this done prior to alpha and got sucked into fixing other issues 17:33:05 * mattdm sighs 17:33:24 <nirik> pjones: I'm happy to help push a grub2 if you just need a patch monkey to do so. (or I am sure a few others would be happy to help too if the patches are ready/reviewed) 17:33:34 <kalev> so I guess we have two options then 17:33:35 <pjones> Er, wait, I thought this was just grubby? 17:33:37 <nirik> and we should all test the u-boot in updates-testing 17:33:45 <nirik> sorry, grubby then 17:33:45 <kalev> 1) block on beta until the new thing lands 17:33:46 <pjones> Am I confused? 17:33:46 <dgilmore-bne> jwb: the part ofr anaconda i am okay punting because we are no worse than we were 17:33:52 <nirik> pjones: no, I think I am 17:33:52 <kalev> 2) block on beta until the contingency plan lands 17:34:02 <pjones> eh, I can push it this afternoon. 17:34:09 <nirik> cool. 17:34:17 <dgilmore-bne> pjones: thanks 17:34:21 <kalev> pjones: thanks 17:34:23 <nirik> kalev: right, sounds like 1 will be easier from what I have seen. 17:34:45 <mattdm> dgilmore-bne: could someone from the arm team update the supported ARM platforms list for f21? 17:35:11 <mattdm> maybe mark as "draft until GA" or something? 17:35:11 <dgilmore-bne> mattdm: I thought that pwhalen had done so already . 17:35:17 <adamw> we can roll a TC4 today for testing, there's some other things to pull in i guess. 17:35:25 <dgilmore-bne> mattdm: but sure we can get someone to do it 17:35:45 <mattdm> dgilmore-bne: please. 17:35:48 <nirik> so, more votes? currently +3 to block, 1 abstain... 17:36:22 <mattdm> I'd like to understand the difference between the f20 list and the future f21 supported list with and without blocking on this 17:36:39 <mattdm> http://fedoraproject.org/wiki/Architectures/ARM/Supported_Platforms 17:36:46 <mattdm> ^ referenced in the release criteria 17:37:09 * nirik notes we have been on this one for almost 30min. ;) 17:37:36 <kalev> for the record, I'm voting the same way the that FPL votes, whatever it is :) 17:38:16 <nirik> my understanding (and dgilmore-bne please correct me): if we don't block on this, and just keep what we have now, some f20 supported machines will be broken, and none of the new ones will work. 17:39:04 <mitr> If the grubby bug is #1088933, that is already an accepted blocker so the FESCo vote is immaterial (well, FESCo could override the blocker determination) 17:39:09 <mattdm> Or is it "some machines that aren't on the supported list but work anyway will stop working"? 17:40:04 <dgilmore-bne> nirik: correct, we would need to go undo a bunch of changes in u-boot, some of which are upstream so that the systems do not try and load the extlinux.conf file 17:40:06 <nirik> mitr: I guess the question is if we push for reverting or keep the change. 17:40:15 <dgilmore-bne> they will then fall back to boot.scr 17:40:19 <mitr> nirik: true 17:40:49 <mattdm> Okay, so, I guess I am +1 to block (or not override, or whatever) 17:41:06 <dgilmore-bne> reverting is a lot more work than getting the grubby patches in that are already an accepted blocker 17:41:06 <mattdm> But... wow, this is a big example of what we keep saying we want to be better at. 17:41:26 <nirik> yeah 17:41:41 <nirik> so, thats +5 (if kalev votes with mattdm )? 17:41:53 <mattdm> dgilmore-bne: Yes, that's the sign of an insufficient contingency plan. We paint ourselves into corners with that _every release_ 17:42:02 <kalev> +1 then, eys 17:42:17 <nirik> #agreed 1078911 u-boot syslinux by default is blocking beta (+5,1,0) 17:42:32 <nirik> .bug 1084102 PrivateDevices?=yes and PrivateNetwork?=yes For Long-Running Services 17:42:35 <zodbot> nirik: Bug 1084102 PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services - https://bugzilla.redhat.com/1084102 PrivateDevices?=yes and PrivateNetwork?=yes For Long-Running Services 17:42:45 <nirik> hum that didn't work nicely. ;) 17:42:49 <nirik> .bug 1078911 17:42:52 <zodbot> nirik: Bug 1078911 u-boot syslinux by default - https://bugzilla.redhat.com/1078911 17:43:02 * nirik sighs. 17:43:19 <mitr> https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork no contingency needed, no known progress, proposal: propose 17:43:23 <mitr> proposal: postpone, rather 17:43:47 <nirik> +1 17:44:16 <nirik> I'm sure there's some services using it, but it doesn't seem like a concerted effort. 17:44:22 <dgilmore-bne> +1 17:44:34 <mattdm> +1 17:44:39 <jwb> +1 17:44:55 <mitr> The tracker bug has no other bugs connected to it; it might have been done but there’s no easy way to know. So to the extend the Changes are used for relnotes/advertising… 17:45:29 <nirik> kalev: ? 17:45:37 * mitr is +1 for the record 17:45:39 <kalev> +1, sorry 17:45:54 <kalev> switching between the blocker meeting and here 17:46:04 <nirik> #agreed 1084102 PrivateDevices?=yes and PrivateNetwork?=yes For Long-Running Services is postponed (+6,0,0) 17:46:16 <nirik> .bug 1091299 (A)Periodic Updates to Cloud Images 17:46:19 <zodbot> nirik: Bug 1091299 (A)Periodic Updates to Cloud Images - https://bugzilla.redhat.com/1091299 (A)Periodic Updates to Cloud Images 17:46:25 <mitr> https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Cloud_Imag... , no contingency needed 17:47:02 <nirik> see last comment from mattdm in the tracking bug.... 17:47:15 <nirik> "We're making some progress on this but I don't think we'll have the releng or automatic QA bits in place by F21 release. I think we still want to do this *for F21 during the F21 cycle*, but it probably needs to get dropped from the F21 release list." 17:47:49 <mitr> Seems clear cut enough 17:47:55 <jwb> uh 17:48:11 <nirik> but if we are doing it for f21, wouldn't we want to say that in the f21 changes? 17:48:12 <jwb> everyone is ok with just phasing this in after release? 17:48:21 <mitr> nirik: no 17:48:31 * nirik agrees it's kinda of one of those things thats not as tied to the release cycle 17:48:54 <mitr> jwb: I am perfectly fine with adding more files to the mirrors (if QA is comfortable with it, i guess). As for wider announcements, that’s a new territory. 17:49:20 <nirik> well, it's not just that simple, IMHO. ;) 17:49:32 <dgilmore-bne> mitr: no one complained when we added updated images to the mirrors for heartbleed 17:49:45 <mitr> jwb: (Assuming that the updates wouldn’t replace the official GA images) 17:49:49 <mattdm> I think the mirrors are almost all on autopilot 17:49:53 <nirik> dgilmore-bne: except many of them were broken and we didn't put them up. 17:50:16 * nirik finds that process in need of much improvement. 17:50:26 <mattdm> Anyway, I agree that this needs much coordination and improvement. 17:50:36 <mattdm> I don't think we're going to have that in place by F21 GA 17:51:06 <mattdm> but I can see that we might within the f21 cycle and would want to produce updates in a structured way rather than the adhoc way we did with heartbleed 17:51:16 <dgilmore-bne> nirik: not true. we put up the cloud images 17:51:24 <dgilmore-bne> nirik: which is all this is talking about 17:51:46 <dgilmore-bne> having more structure around when and how we do it is not a bad thing at all 17:51:47 <nirik> dgilmore-bne: true, although AFAIK they didn't get any qa signoff or anything, we just made them and pushed them out... 17:52:11 <dgilmore-bne> nirik: the QA side of things needs some loving 17:52:22 <mattdm> So to answers jwb's "uh"... not "just phasing this in", but... "carefully phasing this in"? 17:52:59 <nirik> proposal: keep change, try and have a process in place by final freeze? or thats unlikely and we should just drop it? 17:53:14 * mattdm looks at calendar 17:53:36 <mattdm> can I bring that to the cloud sig and see if we think that's feasible? 17:53:49 <mattdm> I know I should have done that _before_ this meeting 17:54:07 * nirik is fine with that, since this wouldn't block beta any 17:54:09 <mitr> mattdm: Works for me; there is no contingency decision that would make the FESco decision urgent. 17:54:22 <mattdm> k. doing that right now :) 17:54:35 <nirik> proposal: mattdm to talk to cloud sig and see if process can be in place by final freeze 17:54:57 <jwb> +1 17:55:07 <mitr> +1 17:55:13 * nirik is +1 for the record 17:55:27 <kalev> +1 17:55:32 <dgilmore-bne> +1 17:56:00 <mattdm> +1 :) 17:56:02 <nirik> #agreed 1091299 (A)Periodic Updates to Cloud Images - (+6,0,0) 17:56:15 <nirik> .bug 1091306 Smaller Cloud Image Footprint 17:56:17 <zodbot> nirik: Bug 1091306 Smaller Cloud Image Footprint - https://bugzilla.redhat.com/1091306 Smaller Cloud Image Footprint 17:56:48 <mitr> https://fedoraproject.org/wiki/Changes/Smaller_Cloud_Image_Footprint , no cintingency needed 17:56:49 <nirik> looks like this was updated to show that it's ok/done enough for now. 17:56:55 <nirik> so, move on? 17:57:06 <jwb> yes 17:57:24 <nirik> #info change is ready for beta, no action needed. 17:57:27 <mitr> mattdm: would it make sense to mark it ON_QA if the F21 scope is about done? 17:57:50 <mattdm> mitr sure, WFM 17:57:53 <nirik> .bug 998583 Web Assets 17:57:55 <zodbot> nirik: Bug 998583 Web Assets - https://bugzilla.redhat.com/998583 Web Assets 17:58:16 <mitr> https://fedoraproject.org/wiki/Changes/Web_Assets , no contingency needed. 17:58:31 <nirik> proposal: postpone to f22. 17:58:36 <jwb> +1 17:58:47 <mattdm> +1 17:58:48 <kalev> +1 17:59:16 <dgilmore-bne> +1 18:00:14 <mitr> There seems to have been _some_ progress, but I haven't noticed an indication of a substantial part being done. So +1 18:00:19 <nirik> #agreed 998583 Web Assets - postpone to f22 (+6,0,0) 18:00:30 <nirik> Those are the system wide ones. 18:00:35 <nirik> on to self contained. 18:00:47 <nirik> .bug 1084083 Apache Mesos 18:00:50 <zodbot> nirik: Bug 1084083 Apache Mesos - https://bugzilla.redhat.com/1084083 Apache Mesos 18:01:00 <mitr> Can we default to default to postponing these unless someone wants to bring one up? 18:01:17 <jwb> nirik suggested that at the start :) 18:01:30 <nirik> sure, we can go to that... 18:01:51 <mitr> We treat system-wide/self-contained differently at acceptance, so it might make sense to do it here as well 18:01:54 <halfie> hi 18:02:17 <mattdm> yup 18:02:47 <nirik> halfie: we were wanting an update on format-security... if you could provide one in the bug and/or here. 18:03:08 <nirik> are there any of the not updated self contained changes folks would like to discuss? 18:03:25 <halfie> nirik, I haven't been following it very closely. let me find the link to the ticket. 18:04:30 <nirik> I guess I'd like to bring up the atomic cloud image one... 18:05:13 <halfie> it seems that around 70 packages still FTBFS. I do see packages being fixed every now and then though. 18:05:39 <mitr> AFAICS only the atomic cloud and mariadb have some status update within the bug, neither saying “done“. Remote journal wiki says "implementation part is mostly done, but integration issues remain. See below." and I can’t find anything below. 18:05:42 <nirik> halfie: ok. Thanks for the status update. 18:06:40 <mattdm> nirik: I *think* all of the atomic issues are at least in the process of being ironed out? 18:06:44 <nirik> for atomic cloud we need to add composing it to branched/rawhide scripts... I'm not sure how it's composed, so that would leave it to dgilmore-bne to add. :) 18:06:54 <nirik> dgilmore-bne: is that going to be possible soon? or ? 18:07:13 <dgilmore-bne> nirik: its on my plan to do this week 18:07:24 <dgilmore-bne> nirik: I have a call at 5am tomorrow about it 18:07:27 <nirik> mattdm: we still need to teach mirrormanager about the trees... but without that we could possibly just point people to the master mirrors. I don't know how much load it will be. 18:07:41 <nirik> dgilmore-bne: ok, cool. 18:07:52 <mattdm> nirik: yeah, as I understand it, master mirrors is the plan for f21 and everyone seemed cool with that 18:07:59 <mattdm> we'll see what happens, I guess! 18:08:14 <nirik> so then, shall we allow that change to continue and defer the rest? or is there any others we want to accept? 18:09:23 <nirik> I do see mariadb 10 in f21. 18:09:24 <mattdm> nirik I'm +1 to that. 18:09:40 <mattdm> I'm also going to check in with the big data sig about the state of mesos 18:10:29 <dgilmore-bne> nirik: im +1 to that also 18:10:31 <mitr> Considering we are already in the Beta change freeze, in-package work that hasn’t been done by today is very unlikely to get finished. 18:10:34 <nirik> so I think mariadb is done, they just havent updated the change 18:10:58 <mitr> nirik: i.e. +1 to deferring “the rest”. 18:11:16 <mitr> Also +1 to giving Atomic Cloud images some time 18:11:19 <jwb> +1 18:11:22 <kalev> +1 18:11:49 <mitr> mariadb… I am tempted to defer it just to enforce the process but a gentle ping would be the nicer thing to do 18:11:52 <nirik> so, thats atomic cloud and mariadb ok? or just atomic cloud and we defer mariadb? 18:12:07 <mattdm> gentle ping to mariadb? 18:12:24 <dgilmore-bne> what mattdm said 18:12:28 <mitr> to mariadb maintainers 18:12:56 <nirik> #agreed atomic cloud work ongoing this week, still approved to land (+6,0,0) 18:13:11 <nirik> #agreed will ping mariadb maintainers again since the change seems done. 18:13:11 <mattdm> Also I think mesos is actually _done_ and in the same state 18:13:19 <nirik> mattdm: ok. 18:13:48 <mattdm> because.... http://pkgs.fedoraproject.org/cgit/mesos.git/tree/?h=f21 18:13:50 <mitr> I guess we are really driven by the docs/relnotes/l10n schedule by now. 18:13:56 <nirik> #undo 18:13:56 <zodbot> Removing item from minutes: AGREED by nirik at 18:13:11 : will ping mariadb maintainers again since the change seems done. 18:14:00 <mattdm> mitr yeah. 18:14:05 <mitr> If that is not binding, giving folks a few more days to update status is not an issue. 18:14:17 <mattdm> I just sent out a message to the big data list asking for an update there. 18:14:22 <nirik> #info will ping mariadb and mesos maintainers again since their changes seem done. 18:14:35 <nirik> ok, anything else on changes? or shall we move on? 18:14:56 <nirik> jreznik: can you update changes based on above? or if not, please let me know to do so... 18:15:37 <nirik> #topic #1350 Updates Policy should require inter-dependent packages be submitted together 18:15:38 <nirik> .fesco 1350 18:15:38 <nirik> https://fedorahosted.org/fesco/ticket/1350 18:15:39 <zodbot> nirik: #1350 (Updates Policy should require inter-dependent packages be submitted together) – FESCo - https://fedorahosted.org/fesco/ticket/1350 18:15:42 <nirik> adamw: you around? 18:17:37 <nirik> I wasn't sure if this was ready for meeting or what... but if adamw is not around I guess we should defer? 18:17:40 <jwb> nirik, btw... did i miss an actual agenda being sent? 18:17:48 <nirik> I did send it... 18:17:51 * nirik looks to make sure. 18:17:53 * adamw is around 18:17:55 <jwb> huh 18:17:58 * jwb goes digging 18:18:19 <adamw> so to address jwb's point, taskotron went into production this week; we can keep an eye and see if its depcheck results are sufficiently accurate enough to enforce more strongly than autoqa's 18:18:20 <jwb> nirik, oh, you certainly did. found it 18:18:25 <adamw> (and, of course, make it better if not) 18:18:39 <nirik> cool. 18:18:47 <jwb> yay 18:19:07 <adamw> tflink: do you have any read on how accurate taskotron's depcheck is? 18:19:52 <nirik> it's been right on all my packages, but thats not much datapoints 18:20:25 <tflink> not sure how to quantify that :) 18:20:27 <dgilmore-bne> id be curious as to how it does on fedora-release as it trips up autoqa 18:20:33 * mattdm can submit some broken stuff 18:20:42 <tflink> it doesn't fall over in most situations that gave autoqa problems 18:20:52 <misc> just enable it on rawhide and see if people complain a lot or not ? 18:20:58 <tflink> there is a small issue we're aware of but are working to fix that 18:21:11 <nirik> misc: it's hooked in via updates/bodhi, so no rawhide. 18:21:17 <adamw> tflink: what's the small issue? 18:21:41 <adamw> dgilmore-bne: autoqa trips over oxygen molecules...:P 18:22:03 <dgilmore-bne> adamw: :P well only sometimes 18:22:31 <adamw> tflink: basically the thing that matters most in this context is, how likely is it to report there's a dep problem when there isn't one 18:22:33 <tflink> adamw: it doesn't always detect issues where a new package causes specific problems with an old package 18:22:44 <adamw> tflink: cases where it doesn't detect a problem when it should aren't so bad 18:22:56 <tflink> the use case we're tracking is when a new package drops a 'provides:' that an old package is using and doesn't do 'obsoletes:' properly 18:23:02 <adamw> obviously the closer it comes to catching all errors the better 18:23:39 <tflink> bah, I'm not being 100% precise in my description 18:23:53 <tflink> I can go find the exact package that we noticed it on, though 18:24:12 <nirik> in any case, I am ok with adding the changes to the update-howto (although I think you could just drop all the buildroot override stuff in favor of a link to the buildroot override page). 18:24:20 <adamw> the reason we couldn't enforce the AutoQA check is it frequently threw false failures and would've blocked perfectly good updates 18:24:22 <nirik> and defering enforcement until we have more data. 18:24:40 <adamw> nirik: i'll take a look at that, thanks (i don't recall if i had a reason not to do that) 18:24:41 <nirik> also, if we enforce it, is there a way to override it? 18:24:53 <tflink> no, there's no way to override it right now 18:24:57 <dgilmore-bne> im okay with adding the changes to the update howto, people really should be pushing dependent changes as a single update 18:25:13 <tflink> I'm of the opinion that we should probably wait for bodhi2.0 before moving forward with this 18:25:19 <nirik> I think we want an override before we make it enforcing. Even if that's only for admins or whatever. 18:25:30 <dgilmore-bne> it does mean that we are less likely to get breakage due to partial updates going out 18:25:31 <tflink> nirik: I think that's a requirement 18:25:33 <nirik> yeah, that might be a better time to do so. 18:25:41 <mattdm> making it policy now but not enforcing seems like a good idea. 18:25:44 <tflink> automation will make mistakes at some point 18:26:00 <tflink> we need to be able to override it in those cases so that updates aren't stopped while we work on a fix 18:26:10 <kalev> a middle ground that's doable with Bodhi 1 could be to let taskatron submit negative karma 18:26:28 <mitr> kalev: that would be nice. 18:26:32 <nirik> right, along with: update A is super urgent, breaks package B we don't care too much about, and we want to get A out asap 18:27:37 <tflink> yeah, a human user (who knows what they're doing) needs to be able to override automation and algorithms 18:27:59 <tflink> with the usual stuff about sufficient privileges etc. 18:28:18 <mitr> tflink: Well that rather depends on which one is more likely to be wrong :) 18:28:20 <mitr> I guess policy now, automation later would be fine with me. 18:29:04 <tflink> mitr: it's not always who is wrong, I think. nirik pointed out a use case where the automation may be correct but still needs to be overridden 18:29:16 <nirik> I think thats +4? hard to say... votes for 'update policy now, defer enforcement until later' ? 18:29:26 <jwb> +1 18:29:28 <mitr> +1 again 18:29:29 <nirik> +1 18:29:30 <kalev> +1 18:29:36 <mattdm> +1 18:29:37 <jwb> i just don't want to forget about the enforcement part 18:29:38 <tflink> if that's something that we want to go forward with, we'll need to adjust our development plans 18:29:44 <dgilmore-bne> +1 18:29:48 <tflink> we -> taskotron devs 18:29:56 <mitr> jwb: Same here 18:30:03 <nirik> #agreed Make policy changes now, defer enforcement until later (+6,0,0) 18:30:10 <nirik> thanks adamw / tflink 18:30:20 <nirik> #topic #1355 Please select Engineering Representiatve for the new Fedora Council 18:30:21 <nirik> .fesco 1355 18:30:21 <nirik> https://fedorahosted.org/fesco/ticket/1355 18:30:22 <zodbot> nirik: #1355 (Please select Engineering Representiatve for the new Fedora Council) – FESCo - https://fedorahosted.org/fesco/ticket/1355 18:30:35 <nirik> we now have two folks who have thrown their hat in the ring. ;) 18:30:48 <nirik> (that I know of) 18:30:50 <tflink> one more note: the ability to override taskotron results is not currently planned out. if this is something that is desired, please let us know so we can plan for it 18:31:16 <nirik> tflink: right so the override would come in bodhi? 18:31:19 <mattdm> Yeah so I think we have a basic first choice of "pick someone now or soon" vs. "come up with some sort of basic framework, execute it" 18:31:27 <mitr> tflink: (If that were a choice) I'd much rather make it easier to fix taskotron tests than to make it possible to override them 18:31:45 <mitr> mattdm: What is the overall timeline? 18:31:52 <tflink> nirik: not sure how we decided to do it, the last plan I remember was to do it outside of bodhi 18:32:04 <tflink> actually, I'm not sure if we decided how exactly to do it 18:32:06 <jwb> mitr, asap 18:32:17 <jwb> mitr, so that we can get on with the elections for the elected seats 18:32:27 <mattdm> mitr: asap. We were thinking to do it concurrently with the elections... 18:32:34 * mattdm is not typing as fast as jwb 18:33:00 <tflink> mitr: they are about as easy to fix as we're likely to get right now - that was one of the reasons for switching to taskotron instead of just enhancing autoqa 18:33:30 <mattdm> I'm interested in the taskotron continued discussion but let's move it elsewhere? 18:33:43 <nirik> to the #fedora-qa! :) 18:33:54 * mattdm says, apparently with a candian-style uptalk at the end 18:34:31 <nirik> ok, so how about: 1 week nomination period, fesco picks one person at the end? 18:34:39 <adamw> mattdm: let's move it elsewhere, eh 18:34:42 <dgilmore-bne> nirik: ack 18:34:44 <mattdm> adamw: right! 18:34:47 <mattdm> nirik: +1 18:34:52 <mitr> nirik: yes. And tell devel@ about a clear nomination deadline. 18:34:58 <nirik> I don't think we need to get fancy. 18:35:07 <dgilmore-bne> if no nominations we come up with some people and ask them 18:35:20 <mattdm> dgilmore-bne: we've got two, so no risk :) 18:35:29 <nirik> ...this time. ;) 18:35:36 <kalev> sounds good to me, I was just typing up how I think fesco should pick one candidate, instead of doing a fedora-wide election 18:35:55 <kalev> +1 18:35:56 <jwb> one week starting when? 18:36:00 <mattdm> kalev: yes, that's the basic structure :) 18:36:03 <jwb> the ticket has been open for a while already 18:36:05 <mattdm> jwb starting right before this meeting. 18:36:24 <nirik> yeah. I'd be ok with a week from now and announcing that? 18:36:28 <mattdm> or do we want to give ourselves a "closed" day or two before the meeting? 18:36:38 <mattdm> but in any case, decide next meeting. 18:36:44 <jwb> i don't see why we'd do anything closed here 18:36:55 <mattdm> sorry not as in secret 18:37:00 <mattdm> I meant, closed-to-nominations 18:37:06 <mattdm> that way there's no Last Minute Surprises 18:37:12 <kalev> closed, as in nominations close a day before the meeting here so that we could make up our minds 18:37:16 <mattdm> yeah that 18:37:29 <jwb> so just make the deadline next tuesday at 23:59 UTC 18:37:39 <jwb> (slightly less than 1 week) 18:37:40 <mattdm> jwb works for me 18:37:52 <kalev> sounds good to me too 18:37:58 <mattdm> I guess track nominations in ticket? 18:37:58 <nirik> well, IMHO anyone we select that will be representing us would likely be well known to us and the community... 18:38:04 <nirik> sure, fine with me 18:38:34 <mattdm> and, i guess, self nominations or other nominations + an acceptance of that nomination from the actual person? 18:38:39 <dgilmore-bne> nominations in ticket and the time jwb suggested is good 18:39:21 <nirik> additional questions: how long is the term? if someone wants to step down, I assume we just do another round of selecting a new person? 18:39:21 <mattdm> Who would like the joy of writing and sending out a message? 18:39:44 <mattdm> nirik: it's open ended from the council perspective; intentionally left to fesco 18:40:06 <nirik> ok. So do we want to decide one now? or ? 18:40:45 <mattdm> we could. I guess... no term limit, but fesco can replace the person if need be? 18:41:21 <jwb> i'd suggest fesco and/or the council 18:41:31 <nirik> mattdm: the problem with that is that someone might feel compelled to stay instead of gracefully stepping back... 18:41:48 <dgilmore-bne> perhaps evaluate the person with each new FESCo? 18:42:09 <jwb> nirik, term limits have that same problem 18:42:13 <jwb> just reduced 18:42:14 <mattdm> jwb sure that sounds good to codify 18:42:19 <nirik> jwb: yeah, I suppose so. 18:42:45 <nirik> BTW, all this should be added to the fesco elections page or a council page or somewhere better than meeting minutes. ;) 18:42:47 <kalev> or possibly the FPL could ask fesco to choose a new person if it looks like the current person doesn't work out well in the council or some other need arises to choose a new representative? 18:42:50 <mattdm> we could say "representative will reconfirm interest every year?" 18:42:51 <mitr> And the history of FESCo seems to have enough people able to step down mid-term; I’m not sure that is a big concern. 18:43:04 <mattdm> #help all this should be added to the fesco elections page or a council page or somewhere better than meeting minutes. 18:43:51 <mattdm> proposal: someone $NOTME draft up a basic version of what we just said above and put it on the wiki somewhere and we'll ratify it next week 18:44:12 <dgilmore-bne> +1 18:44:28 <nirik> sure, does that mean we wait until it's ratified to use it? or start nomination period anyhow? ;) 18:44:30 <nirik> +1 18:44:34 <mitr> +1 18:44:35 <kalev> +1 18:44:36 <mattdm> where $NOTME is not _me_, not... not everyone who votes. :) 18:44:41 <dgilmore-bne> nirik: start anyhow 18:44:42 <jwb> i would volunteer, but i don't want to be drafting my own seat limits being a nominee 18:44:42 <mattdm> +1 to my own thing 18:44:56 * mattdm notes that whoo the cold medicine is really kicking in 18:44:57 <jwb> nirik, nomination period starts anyway 18:45:18 <mattdm> I don't think there's any meaningful conflict with being a nominee and drafting the policy 18:46:11 <nirik> #agreed Draft of fedora council represenative selection process to be written up and ratified next week. (+5,0,0) 18:46:38 <mattdm> does anyone have any objection to jwb doing it? 18:46:38 <nirik> who is sending out the nominations announcement? 18:46:47 * nirik doesn't mind jwb doing it at all. 18:47:21 <dgilmore-bne> no objections to jwb drafting it. 18:47:33 <mitr> No objections either 18:47:42 <dgilmore-bne> nirik: I can do so in a few hours when I wake up 18:47:50 <kalev> No objections either :) 18:47:52 <jwb> ok, i'll give it a go tomorrow 18:47:52 <nirik> dgilmore-bne: cool. 18:48:02 <nirik> anything else we need to decide on this? 18:48:32 <mattdm> looks good to me 18:48:57 <nirik> #action dgilmore-bne to send out announcement of nomination period starting. 18:49:15 <nirik> #action jwb to write up draft of selection policy document for next week 18:49:21 <nirik> #topic Next week's chair 18:49:27 <nirik> who wants it? ;) 18:49:37 <taquilla> hi all 18:49:52 <mattdm> taquilla hi! FESCo meeting in progress. 18:49:55 <nirik> BTW, I will be traveling next week and won't make the meeting. I can try and vote in tickets before hand. 18:50:46 <dgilmore-bne> im not 100% sure my availability next week 18:50:58 <mattdm> if no one else is excited to do it, I guess I will 18:50:59 <jwb> i'll do it 18:51:18 <mattdm> jwb rock paper scissors? 18:51:23 <nirik> ...lizard spock. 18:51:27 <mattdm> I already made myself a reminder 18:51:37 <jwb> mattdm wins 18:51:50 <nirik> #info mattdm to chair next week. 18:51:55 <nirik> #topic Open Floor 18:52:02 <nirik> anything for open floor? 18:52:54 <nirik> ok, will close out in a minute if nothing more. 18:52:55 * dgilmore-bne has nothing 18:53:14 <nirik> adamw: how bad does the beta blocker list look? ;) 18:53:21 * nirik guesses he could just look outside the meeting 18:54:05 <nirik> ok, thanks for coming everyone! 18:54:08 <nirik> #endmeeting
On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi kevin@scrye.com wrote:
- #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37)
- LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38)
- AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03)
That ticket has already been closed, so I will comment here. Say that I have a package that I want to update, the update breaks somebody else's package, and I lack the knowledge to fix that other package. How much waiting for the other maintainer am I required to undergo? The discussion on the ticket implies that the answer is "an infinite amount of time". Is that really the intent? Let me present two cases where I think "an infinite amount of time" is the wrong answer.
The first case is when a non-critpath package depends on a critpath package. I've got a concrete example. I maintain the polymake package. It has its hooks buried deeply into the guts of perl, so it depends on the exact perl version it was built with. Every major perl release, without fail, breaks polymake. Sometimes upstream has already noticed and I can update to the latest snapshot to fix the problem. Sometimes upstream has not noticed and I have to ask them to produce a fix, which can sometimes take a little while. If a critical perl update were needed, say to fix a glaring performance or security problem, and the update broke the polymake build, I think the right thing to do would be to push the perl update anyway. That will break things for me and both of the other people who use polymake (hi, guys!), but too bad for us. We can fix polymake as quickly as we can and get things back to normal, but we shouldn't block that update from going out to all of the people who need it.
The second case is hypothetical, although it is loosely based on an actual situation I encountered a couple of years ago. Say that I want to push a non-backwards-compatible update to a library, and that packages A, B, and C depend on that library. I rebuild A and B successfully with the new version of the library, but C fails to rebuild. I try to diagnose the problem, but find that C is such a horrible mass of spaghetti that I can't make heads or tails out of it. So I file a bug against C and wait for the maintainer to respond. And wait. And wait. And wait. At what point am I allowed to push the new version of the library, along with A and B rebuilds, and write C off as a loss, since I can't fix it and the maintainer isn't responding? Does it depend on the severity of the problem the update is intended to fix? If so, who is the judge of degree of severity?
On Wed, 15 Oct 2014 13:32:50 -0600 Jerry James loganjerry@gmail.com wrote:
On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi kevin@scrye.com wrote:
- #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37)
- LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik,
18:15:38)
- AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03)
That ticket has already been closed, so I will comment here. Say that I have a package that I want to update, the update breaks somebody else's package, and I lack the knowledge to fix that other package. How much waiting for the other maintainer am I required to undergo?
Speaking for myself, "A reasonable amount of time".
There are going to be cases where you can't push all interdependent packages at the same time. You should try and avoid that, but it could well happen.
This is one of the reasons we were talking about taskotron and enforcement. There MUST be a way to override any auto enforcement for at least:
* I know this one thing is broken, but it's vastly less important than fixing all these others.
* The test is wrong/broken/bugged.
kevin
On 10/15/2014 09:32 PM, Jerry James wrote:
On Wed, Oct 15, 2014 at 12:54 PM, Kevin Fenzi kevin@scrye.com wrote:
- #1350 Updates Policy should require inter-dependent packages be submitted together (nirik, 18:15:37)
- LINK: https://fedorahosted.org/fesco/ticket/1350 (nirik, 18:15:38)
- AGREED: Make policy changes now, defer enforcement until later (+6,0,0) (nirik, 18:30:03)
That ticket has already been closed, so I will comment here. Say that I have a package that I want to update, the update breaks somebody else's package, and I lack the knowledge to fix that other package. How much waiting for the other maintainer am I required to undergo? The discussion on the ticket implies that the answer is "an infinite amount of time". Is that really the intent? Let me present two cases where I think "an infinite amount of time" is the wrong answer.
One thing that might not have been clear when reading the FESCo discussion is that this only applies to the releases where Bodhi is enabled -- the stable releases (F19, F20) and Branched (F21). It does _not_ apply to rawhide.
The first case is when a non-critpath package depends on a critpath package. I've got a concrete example. I maintain the polymake package. It has its hooks buried deeply into the guts of perl, so it depends on the exact perl version it was built with. Every major perl release, without fail, breaks polymake. Sometimes upstream has already noticed and I can update to the latest snapshot to fix the problem. Sometimes upstream has not noticed and I have to ask them to produce a fix, which can sometimes take a little while. If a critical perl update were needed, say to fix a glaring performance or security problem, and the update broke the polymake build, I think the right thing to do would be to push the perl update anyway. That will break things for me and both of the other people who use polymake (hi, guys!), but too bad for us. We can fix polymake as quickly as we can and get things back to normal, but we shouldn't block that update from going out to all of the people who need it.
We shouldn't get a perl rebase in a a stable Fedora release anyway. Major Perl rebases are always System Wide Changes and land in rawhide before the next release is branched.
The second case is hypothetical, although it is loosely based on an actual situation I encountered a couple of years ago. Say that I want to push a non-backwards-compatible update to a library, and that packages A, B, and C depend on that library. I rebuild A and B successfully with the new version of the library, but C fails to rebuild. I try to diagnose the problem, but find that C is such a horrible mass of spaghetti that I can't make heads or tails out of it. So I file a bug against C and wait for the maintainer to respond. And wait. And wait. And wait. At what point am I allowed to push the new version of the library, along with A and B rebuilds, and write C off as a loss, since I can't fix it and the maintainer isn't responding? Does it depend on the severity of the problem the update is intended to fix? If so, who is the judge of degree of severity?
Pushing out ABI incompatible library versions in a stable Fedora release isn't something one should do anyway. They should either go in the next Fedora (rawhide), or if it's important to backport the ABI change to the current stable release, it's best to introduce a parallel-installable package for the new library. If an ABI change cannot be avoided, it's possible to ask for a FESCo exception: http://fedoraproject.org/wiki/Updates_Policy#Exceptions
On Wed, Oct 15, 2014 at 09:54:23PM +0200, Kalev Lember wrote:
One thing that might not have been clear when reading the FESCo discussion is that this only applies to the releases where Bodhi is enabled -- the stable releases (F19, F20) and Branched (F21). It does _not_ apply to rawhide.
Yes. But also worth noting that _eventually_ I think we want to get to some point where there are gate checks to rawhide, or at least for some subset of what is currently rawhide.
-
Jerry James -
Kalev Lember -
Kevin Fenzi -
Matthew Miller