17:02:00 #startmeeting FESCO (2014-07-16) 17:02:00 Meeting started Wed Jul 16 17:02:00 2014 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:03 #meetingname fesco 17:02:03 The meeting name has been set to 'fesco' 17:02:03 #chair abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m 17:02:03 Current chairs: abadger1999 dgilmore jwb kylem mattdm mitr mmaslano nirik pjones sgallagh t8m 17:02:15 #topic init process 17:02:16 morning. 17:02:20 Hello 17:02:25 Good morning. 17:02:33 hello. 17:02:35 Good $TIMEOFDAY! 17:02:39 good afternoon, morning, night, everyone :) 17:02:55 hole 17:03:00 hola 17:03:35 sgallagh_afk, ping? 17:03:40 * jreznik is around... 17:04:32 I do not see kylem 17:04:44 t8m: sgallagh_afk is on vacation... 17:04:48 We have a quorum so let's start 17:04:59 i think kylem is on vacation as well 17:05:14 --- [kyle] is away (pto.) 17:05:16 yep 17:05:26 #topic #1322 F21 Changes - Progress on Changes Freeze 17:05:31 .fesco 1322 17:05:32 t8m: #1322 (F21 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1322 17:05:54 Is anyone concerned about any particular change? 17:06:37 I have a change that slipped through the process cracks.... 17:06:39 this is what I was able to collect so far... 17:06:46 mattdm: which one? 17:06:59 The uboot/syslinux one seems like it can use a lot of testing, and has an Alpha deadline - but can we do anything to help besides getting out of the way? 17:07:05 jreznik: docker container image 17:07:20 It's a self-contained change that I asked to skip one week and we never got back to it 17:07:32 aha 17:07:36 https://fedoraproject.org/wiki/Changes/Docker_Container_Image 17:07:50 looks like there's actually a tracker bug... 17:07:54 hmmm, maybe I'm crazy :) 17:08:13 oh yes, i see from the wiki history that i am 17:08:14 and it's accepted f21 17:08:18 :) 17:08:25 hmmm. no idea what I was smoking there. carry on :) 17:08:40 maybe you meant Atomic_Cloud_Image? 17:08:46 I see it stuck in the process 17:08:58 For SCL, the Ruby SCL was pulled by mmaslano. So there won't be scls in fedora main repo for f21. But that doesn't stop them from appearing in the playground repo. 17:08:59 https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image 17:09:07 jreznik: ah yes! That's totally it! 17:09:29 so acks! 17:09:47 I'm +1 to this change. It is furiously in progress. :) 17:10:02 if it is in progress +1 17:10:31 (+ others do not have something like this so good selling point) 17:11:08 I'm +1 to the change, but when do we decide it is going to make it? if there's an image by alpha? 17:11:30 im +1 to this and working to make it happen 17:11:45 I think we nearly have the bits lined up to make it 17:11:52 +1 17:12:01 cool 17:12:02 but there is still issues to be resolved on how to get updates out 17:12:03 nirik: yeah, if we miss alpha we will need to take stock 17:12:30 +1 17:12:35 im +1 17:13:04 +1 17:13:12 #approved Atomic_Cloud_Image Self contained change is accepted for Fedora 21 (+7, -0, 0:0) 17:13:14 mattdm: The "new Fedora product" wording might be worth looking at, so that it is not confused with the 3 major products. (Not sure whether just a s/product/image/ or something more complex) 17:13:26 ... wording in relnotes on the change page, that is. 17:13:41 mitr, +1 17:14:14 * jreznik is going to process it 17:14:40 Anything else to discuss for Changes? 17:14:49 mitr yep good call 17:16:17 It doesn't seem so, so let's go on with a new tickets 17:16:31 thanks guys! 17:16:44 #topic #1323 Deliberate packaging guidelines / compiler flags violation in dpdk 17:16:49 .fesco 1323 17:16:50 t8m: #1323 (Deliberate packaging guidelines / compiler flags violation in dpdk) – FESCo - https://fedorahosted.org/fesco/ticket/1323 17:17:36 So what can we do with this problem? 17:17:40 I think the problem here is that the breakage isn't actually clear... but then if it's going to be fixed in a few weeks I am ok with waiting. 17:18:29 Not that I like ignoring the RPM_OPT_FLAGS, I think that we can wait a few weeks for fix 17:19:06 So... revisit in 4 weeks? (And then what’s our plan?) 17:19:29 Block the package? 17:20:47 pretty sad that they pushed a f20 update. 17:21:09 I'd rather have a provenpackager override the spec if there is one interested (to wade through the non-autotools buildsystem) 17:21:44 I'm sad about the name calling 17:22:14 well, it's unclear to me at least what the breakage is. 17:22:23 I asked in ticket, but didn't see a response. 17:22:25 mitr, I have no problem with that, however if there are build failures it might be nontrivial task 17:22:40 mattdm, +1 17:23:06 t8m: There is some amount of inline asm 17:23:32 anyhow, I am +1 to revisit in 3-4weeks. 17:23:38 Not an obviously prohibitive amount, but enough to make it plausible that the code is a bit iffy and changing compiler settings could break it 17:24:04 eh, worth finding out though. 17:24:57 given "no one will build a product out of the package without a complete rebuild of the libraries anyway. 17:25:05 " it really seems like this is better as a Copr 17:25:11 yeah, probably need to block the package and reprimand the packager if it isn't fixed in 4 weeks. 17:25:12 mattdm, yep 17:25:34 but willing to defer to see what progress is made then. 17:25:34 so.... block the package and suggest that we have a better place for it? 17:25:39 Proposal: Revisit on Aug 13, then default to letting any interested provenpackager to change the flags as they see fit 17:26:08 mitr, I think we can let any interested provenpackager to fix it even before Aug13 17:26:17 mattdm: problem with blocking is that it's out in f20 now... so if people installed it... 17:26:42 i think you guys are over thinking this 17:26:45 proposal: revisit on aug 13th. :) 17:26:53 +! 17:26:55 +1 17:26:59 okay +1 17:27:05 +1 17:27:09 +1 17:27:36 +1 17:27:57 +1 17:29:02 nirik, I suppose you're +1? 17:29:21 yeah 17:29:31 #agreed We will revisit on Aug 13th (+7, -0, 0:0) 17:29:58 #topic #1324 Feature page "outcome" 17:30:02 .fesco 1324 17:30:04 t8m: #1324 (Feature page "outcome") – FESCo - https://fedorahosted.org/fesco/ticket/1324 17:30:13 ping langdon 17:30:37 although there's not much extra to say :) 17:30:44 jreznik what do you think? 17:30:54 I like the idea, but it's mostly on the feature wrangler. ;) 17:30:55 We actually have most of the informaiton in there already, but somewhat invisible as category:xx 17:31:30 So we might only need someone skilled with wiki macros and interested in this to expose it better 17:32:16 mitr: that's a good suggestion. although links to outcome/results/currentstate probably need to be done by hand (should be by the feature owner) 17:32:41 * jreznik is looking 17:32:58 Yeah, ideally we could just link to the relnote snippet (within the Change page or actual relnotes), but those are the parts that tend most to be left stale 17:33:53 and the status and if it was implemented/killed is visible in bugzilla 17:34:22 and in the end it's collected in changeset, what was done 17:34:32 so I really think we already do what's in the ticket 17:34:56 We do, but maybe the visibility of it is not good 17:34:57 maybe we should be more strict on having up to date relnotes part 17:35:13 So maybe making the bugzilla link more prominent? 17:35:24 t8m: well, on the other hand - change/feature pages are internal planning thing, it should not be visible at all 17:35:37 for visibility, we have release announcement etc. 17:35:51 as it always needs some love to be presentable for end users 17:36:15 that's why I put "internal planning tool" to the changeset page 17:36:26 btw. I hope for F22 it will move from wiki completely :) 17:36:38 jreznik: The Change pages do (at least in my bubble) get a fairly good google-fu (due to being linked from the mailing list, and fairly detailed), compared to the final relnotes 17:36:47 with websites guys we plan change tracking application 17:36:55 for end users maybe, but developers might want to look at them 17:37:05 mitr: for F21, from F22+ it's going to be in app (I hope) 17:37:28 jreznik: I don’t think (or at least hope) that won't make a difference 17:37:34 as it's hardly manageable in the wiki... 17:37:35 * randomuser notes that the final relnotes can be updated and other documentation can be linked from Change pages for posterity 17:37:45 Is my impression correct that we would all like easier to use pages, but it needs an interested volunteer? 17:37:52 mitr: then we can do several views on features, generate content etc. 17:38:00 mitr, the double negative in your sentence above is confusing me :) 17:38:37 mitr: I have two volunteers for that app but then they saw how much work it is :) 17:38:53 but I'll add this question to requirements 17:39:00 we're now collecting 17:39:56 as it's my ultimate goal actually to make sure all proposed in the ticket will happen 17:40:47 #proposal Wait for the development of Changes application 17:40:54 meanwhile, we can make some pretty macros to go at the top of the completed pages. or langdon can :) 17:41:20 mattdm, +1 to that as well 17:41:32 if there are volunteers :) 17:41:45 well, it should not be that difficult 17:42:14 jreznik the template/macros should not be? 17:42:28 what's more difficult is to really know change was implemented and it was implemented as described in change 17:42:41 jreznik, yeah :) 17:42:58 qa guys are looking at some, top changes affecting release but we would need twice more qa :( 17:43:16 for many changes, there are test days... 17:43:21 so it's actually becoming better 17:43:25 or we need honest change owners to properly update the changes 17:44:02 t8m: I don't think it's honesty... it's just easy-to-forget-metawork 17:44:29 or the reason why we have qa - you may honestly think it's ok but ... 17:44:53 that's a new word for it. 17:44:55 jreznik, sure 17:45:18 pjones which is a new word? 17:45:23 "metawork" 17:45:24 mattdm: Yeah; I wouldn’t want this ticket end up with adding yet another part to the process (“now that real relnotes are great, make sure to copy them to the wiki”) 17:45:44 so anything to vote about for this ticket? 17:45:47 Automation and links, yes 17:46:06 * mattdm uses that word all the time. perhaps has been in academic environments too long 17:47:03 meta-mphetamine-work 17:47:35 huh. 17:47:47 eh, I think we don't need to spend more time on it. just wanted to get the idea discussed. and now I know about the Changes App plan 17:47:56 by using bugzilla for tracking stuff, we have quite a lot of data available, so it's now about how to present it 17:48:32 I can't promise anything but I can try to do it for F21 even without Change app in place 17:48:50 with that app it's going to be definitely much, much more easier 17:49:06 Ok, that was the last topic on agenda. 17:49:24 jreznik: sounds good. 17:49:52 #info FESCo and Change wrangler will look how to improve the visibility of Change outcome data 17:50:23 #topic Next week's chair 17:50:27 Anyone? 17:50:59 * nirik will likely not be here next week 17:51:44 I can do it 17:52:02 #action mitr to chair then next week's FESCo meeting 17:52:17 #topic Open Floor 17:53:32 Kevin brought up the FESCo blocker bug on the list; should we start using it regularly? 17:53:47 (Or shall I make a ticket so that we can think it over and discuss for next week?) 17:53:50 mitr: if we have things we think are blockers that don't block based on any qa issues. 17:54:02 IMHO thats happened very rarely. 17:54:54 Yeah; it seems to me have many decisions we would rather not see just ignored (which unfortunately does happen), but wouldn’t be willing to block the release over them 17:55:48 yeah. 17:56:38 I am not sure what we should do in such cases. 17:56:43 nirik: that's because adamw is very very clever about making any real problem fit _some_ criteria 17:56:55 :) 17:57:02 So, I suppose, no action and no policy change for now? 17:57:11 I think we should just be aware that we can mark things blocker if we want... 17:57:21 +1 aware :) 17:57:49 fwiw, my take on the 'fesco criterion' is it's mainly intended for use in relation to the change process 17:58:10 if fesco wants to get serious about requiring changes to hit certain states of readiness at certain milestones, that would be a good use for it 17:58:29 adamw makes sense. 17:58:48 Oooh! Have every Change bug block that tracker until the Change owner explicitly updates bug state and drops it from the tracker! NOT 17:59:14 adamw: Having that tool to track Changes that need extra attention is a great idea, though. 18:00:35 yep 18:02:07 Anything else to discuss for Open Floor? 18:03:29 I will close the meeting in a minute then. 18:05:05 #endmeeting