Summary/Minutes from today's FESCo meeting (2014-10-15 at 17UTC)
Kevin Fenzi
kevin at scrye.com
Wed Oct 15 18:54:54 UTC 2014
===================================
#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-17.00.log.html
.
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_Images
, 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_Images , 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141015/026cb2f6/attachment-0001.sig>
More information about the devel
mailing list