15:01:14 #startmeeting Fedora Base Design Working Group (2013-12-20) 15:01:14 Meeting started Fri Dec 20 15:01:14 2013 UTC. The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:14 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:21 #meetingname Fedora Base Design Working Group 15:01:21 The meeting name has been set to 'fedora_base_design_working_group' 15:01:29 hello everyone! 15:01:35 hi 15:01:46 hi 15:03:02 just a quick heads up for todays meeting, unfortunately i've realized too late that i have a meeting that i need to attend at the same time today, so i'll be a bit distracted during our meeting here today and not as engaged as usual. 15:03:12 also some folks are already on PTO today 15:03:41 * notting is here 15:03:47 heya notting :) 15:03:57 ok, lets start off with it 15:04:02 pknirsch: bah, we have those meetings all the time. you think there's something important going on there? :) 15:04:07 #chair jwb sghosh notting 15:04:07 Current chairs: jwb notting pknirsch sghosh 15:04:16 hahaa notting, true enough 15:04:59 * Viking-Ice is here 15:05:47 ok, first topic: 15:05:52 #topic Continue discussion about BR cleanup 15:05:58 with the following first sub topic 15:06:10 #topic Discuss ideas and concerns brought up on the f-d ML 15:06:38 so there has been a lively discussion on f-d about the cleanup idea 15:06:49 fwiw, i already cleaned up kernel.spec 15:06:55 with lots of good ideas and suggestions 15:06:58 oh, nice! 15:07:00 thanks jwb ! 15:07:19 it no longer indirectly BRs wayland to build... 15:07:41 it needed wayland? O.o 15:07:43 wow :) 15:07:54 asciidoc->graphviz->EXPLOSION OF DEPS 15:07:58 ohhhh 15:08:00 yea 15:08:10 excellent jwb :) 15:08:30 jwb: was that just shooting the -doc subpackage into the sun, or something else? 15:08:59 notting, yep, killing -doc. i also had to fudge some stuff for the perf man pages, but that worked out OK 15:09:07 so basically i only touched the low hanging fruit 15:09:13 jwb, did you "modernize" the kernel spec ( like use macro where applicable )? 15:09:45 kernel.spec already uses a lot of macros, but no i didn't do anything drastic 15:09:54 jwb, ok 15:11:26 one of the packages i'd like to tackle with the tools guys will be gcc, especially the nuking part of gcj which they'd already been pretty happy about to be doing 15:11:48 i've done a bit of repo checks about it and so far most of the stuff i quickly looked at can basically just be disabled 15:12:11 and it's less than expected (just a couple dozen of packages) 15:13:17 so coming to the discussion on the ML, there have been several really good suggestions and warnings 15:14:13 one key thing proposes was to use rpmdiff and rpmguard to check whether 2 builds are the same 15:16:01 and one point that is also important is that even if the diffs and checks all say GREEN we'll still need to manually check and ensure that the packages will still provide them same functionality as the original build 15:16:04 pknirsch: were the tools guys interested in pregenerating docs and getting texlive out of their build chain? 15:16:27 notting: ah, forgot to check that, will make a note 15:17:44 Viking-Ice: would you from a QE perspective have a recommendation on how we could ensure that packages are the same after dropped BRs? 15:18:38 pknirsch, got nothing on of my head I've started to map some stuff out for components here https://fedoraproject.org/wiki/User:Johannbg/FOS trying to form somekind of task list all add it to that list 15:19:10 Viking-Ice: alright, i'll note that down and check that out, thanks! 15:23:32 i really liked the overall discussion on the ML 15:24:12 and so one of the things i've posted there as well was a python script to properly do a buildreq depchain topology sort 15:24:25 which might prove to be helpful for other things as well 15:25:04 i haven't yet been able to create some working graphs out of the data i got, but hopefully till next year i'll be able to do that 15:26:11 which kinda leads me to the next subtopic i had: 15:26:43 #topic Proposal how to automate BR removal checking 15:27:08 so my idea would be the following: 15:27:33 take a specific srpm package 15:28:06 write a script that "parses" the specfile and records the BRs of the package 15:28:24 then automatically creates new srpms with 1 BR dropped each time and tries a build 15:28:44 if successfull, run the result through rpmdiff and rpmguard and any other tests we can automate 15:29:11 and if the results are all green, mark this BR to be a potential real drop 15:29:31 overall, run that over a small set of packages first to see if this works at all 15:29:55 or even make a test package with a superficial BR and then see if it detects properly if it could potentially be dropped 15:30:32 at the end of the day then, collect those reported potential BR drops and work with maintainers whether those can really be dropped 15:31:34 i know this sounds like a lot of builds 15:31:39 and it probably is 15:31:49 but most if not all of it can be automated 15:31:55 and run in parallel on multiple machines 15:32:02 anyone sees any flaws in it? 15:32:17 * pknirsch still has the nagging feeling that this sounds too simple 15:32:43 looks like alot of work building a script and output just for this, would it not be simpler just to directly ask the maintainers if they check and see if they could drop BR ? 15:33:19 i think you'd probably get a lot of build fails doing that. plus... you probably need to do the full combinations of BRs 15:33:26 pknirsch: any thoughts around policy of not enabling everything upstream does? could reduce the BR 15:33:42 drop foo, build with bar and baz. drop bar, build with foo and baz. etc 15:35:15 sghosh, policy like that might turn out to be a subscription for disaster if both users and components expect the component in question to have this enabled since upstream does 15:37:21 Viking-Ice: I've seen some packages that do two or more builds from the same sources with different options each time. We could theoretically produce package-minimal/standard and package-complete subpackages that way. 15:37:28 So the installed set would have fewer dependencies, at least. 15:38:07 that doesn't help 15:38:21 because it doesn't reduce the required packages needed for a self-hosting base 15:38:28 which is the goal 15:38:41 right 15:38:52 * pknirsch nods 15:39:38 I would think that first approach before anything else would simply be to email the maintainer of the components and ask them directly to see if and then what to do before creating scripts and tools etc.. 15:39:50 jwb: regarding all combos, ye, i thought about that but it obviously would lead to a exponential # of builds instead of a linear number 15:40:11 Viking-Ice: good point, true 15:40:19 True enough. I suppose separating out SRPMs could address that, though. 15:40:35 Leads to extra maintenance effort though 15:41:37 yep. thats the same side of a different coins as the documentation split out we discussed last week i think (or a similar coin) 15:42:24 pknirsch, yes, it could. but that's why it seems simple to you. because you're avoiding the hard part ;) 15:42:47 and Viking-Ice, writing that script imho shouldn't hard (again, famous last words), so i'll take a peek at it over the holidays 15:43:06 jwb: maybe :) 15:43:44 jwb: ofc once all the potential droppable (is that even a word?) BRs have been discovered i'd fire off a build with all of them dropped and see if the result is still GREEN 15:44:21 pknirsch, first and foremost everybody have to consider the fact that the any maintainer might actually say no to any proposed changes from this group so I propose that we directly contact them as soon as possible since the component list exist and get suggestion and general wipe for changes from those that maintain the components 15:44:39 if not, then we'd at least know some potential candidates and could then open a BZ and work with maintainers to see how we can identify the ones we can truly drop 15:45:32 once the group has received their feed back the actual work can be started and be tailored around that feedback 15:46:00 Viking-Ice: absolutely, sure. Thats why i've sent out that email to f-d to at least send out a heads up about this. 15:46:08 How exactly will you determine if the builds are "the same"? I'm not sure rpmdiff or rpmguard will handle certain cases. 15:46:49 pknirsch, yes but I think the group might be getting a bit ahead of it self discussing the things that are being discussed now 15:46:55 I can think of at least one example off the top of my head that they wouldn't catch 15:46:57 sgallagh: it's just a starting point. any potential candidates and results will still need to be manually checked then, but without any data we don't have much to start with 15:47:13 pknirsch: Ok, fair enough. 15:47:21 sgallagh: oh, what example? 15:47:54 pknirsch: There are several parts of SSSD where the presence of a particular package in the buildroot will determine if certain code paths are compiled in. 15:48:11 In some cases, this won't change the set of binaries or public APIs produced, but may change functionality. 15:48:11 Viking-Ice: ye, but wouldn't you find it great to have at least info about this as a maintainer? i for sure would 15:48:40 pknirsch: Case in point: libnl vs libnl3 15:48:46 sgallagh: yep, and those are the cases that need to be verified and why working with maintainers will be critical. 15:48:50 the two approaches are not mutually exclusive 15:48:53 once we have some more hard data 15:48:55 We'll prefer the latter, but use the former if that's what in the buildroot 15:49:02 * pknirsch nods 15:49:41 Sure, I just want to make sure that such examples are taken into account when telling maintainers what to check for 15:49:45 aye 15:49:56 but thats good info to collect and share with maintainers as well 15:50:40 and Viking-Ice, i didn't want to come across as saying we're now just bulldozering ahead and change tons of packages without working and consulting with maintainers 15:50:47 that would be rude and very contra to anything we do 15:51:07 and if a maintainer says he doesn't want to change his package thats of course his choice 15:51:36 pknirsch: Then of course we have the other situation where there are many maintainers out there who may not really understand the build system of the software they are packaging (beyond having followed an INSTALL file in the source tree) 15:51:42 maybe viewing it as another tool or piece of information we can generate and share with maintainers is a better way of describing it 15:51:57 sgallagh: true as well, yea 15:53:35 and i think focusing on several key packages like gcc, glibc and some others is probably going to be really important as well 15:54:24 not to belittle any package existing in Fedora, but helping clean up the BRs of MYSUPERAPPFOO that no other package needs isn't going to help a lot 15:55:16 so the list that Viking-Ice posted earlier together with the critical path packages or the ones of a yum install kernel rpm yum might be good starting candindates 15:58:28 oki, but thats about it from what i had for today. 15:58:42 anything else anyone wants to talk about? 15:59:54 oh, one last topics from me: 16:00:11 #topic Happy holidays and next meeting date 16:00:53 I'll be on PTO the next two weeks and i'm not sure if i'll make it to any of our regular meeting times 16:01:27 obviously feel free to conduct the meeting with out me (if there is any volunteer to do so) 16:02:41 * notting is out the next two weeks as well 16:03:37 so opinions on whether we shall recommence our meetings on January 9 or someone wants to volunteer for January 2nd? 16:03:49 I was thinking about trying to put together someform of prd for this 16:04:23 jan 9th 16:05:09 pknirsch: BTW, the Server and Cloud WGs are planning to do an IRC hackfest on PRD topics on Jan 8th 16:05:24 Certainly the Base WG is encouraged to also participate 16:05:33 it would be good if someone could write an introduction mail which explains what we are hoping to achieve and send it to all affected maintainers by this process because if people aren't on board with this effort there is no point in proceeding 16:05:35 sgallagh: ah, cool. same place and time? 16:06:07 1400-1800 UTC 16:06:18 Meeting channel not yet determined 16:06:52 Viking-Ice: PRD for Base you mean? i thought we discussed that a few meetings ago and agreed that Base wouldn't be an official product. But you're right, we probably want some more explicit documentation what the goals and objectives are for Base. 16:07:28 as I said some form of documentation about this effort 16:07:34 mhm 16:07:54 We did start some of it in the Base wg wiki: https://fedoraproject.org/wiki/Base 16:08:03 but it could certainly be improved 16:08:34 jwb: how about you and next meeting time? Jan 2 or Jan 9? 16:08:57 yeah but this is not one time effort cleaning it up is but it also needs to be maintained so the role of the baseWG is to meet on regular bases to continue the effort I would think 16:09:13 mhm 16:09:23 pknirsch, 9th would be better 16:09:35 which i think sgallagh's note to join the hackfest on irc on the 8th would be a great idea to join 16:09:39 i'll definitely be there 16:09:44 jwb: alright 16:10:36 ok I'll leave it up to you then to sort it out on that meeting 16:11:07 #agreed Next official meeting January 9 16:13:08 thanks Viking-Ice 16:14:00 ok, with that i'd say we're good. Nothing more on my list than to wish everyone happy holidays and a fantastic new year and see you in 2014! 16:14:09 pknirsch, just remember to send this introduction letter to maintainers of all affected components since I think it might be suffering from the same as the other WG's as in that it might not be full community support behind this 16:14:32 aye 16:14:35 definitely 16:15:05 not everyone reads every email on fedora-devel or feels inclined to comment even it it might affect him :) 16:15:38 even if they did the little feedback that has been received is cause for concern 16:16:23 2k components affect alot of maintainers ( or atleast it should ) 16:16:25 yea. and as i said, this is not a mandated "force down your throat" action but more informational quality 16:17:20 there's alot of assumption being made by the other WG's it's best to avoid that pitfall altogether and just get everyone involved from the start 16:17:22 but one needs to start somewhere and DO something, otherwise nothing will happen, ever. 16:17:38 the first start is saying hi we are thinking about.... ;) 16:17:48 yep :) 16:18:59 ones "first contact" has been achieved the rest should go smoothly 16:19:18 ( or it become clear it wont and back to the drawing board ) 16:19:45 mhm 16:20:09 or see which maintainers are really interested and do their own cleanup etc. 16:20:42 there is no point in halfbaking the process as in have half cleanup the other half still a mess 16:20:53 ( or out of sync with that cleanup ) 16:21:50 i kinda disagree here, as every bit helps. and i'm pretty sure there will be maintainers who don't want to modify it, but those should (hopefully) be the minority 16:22:38 as i said, if back in the days where i worked a lot more on packaging directly someone would have approached me with this and given me some info about which BRs could potentially be dropped i would have loved that idea myself. 16:23:54 right but you are just thinking about $current_problem you have to think 5 to 10 years ahead to advance the core/base and move the distribution forward ( or have it prepped/adabtable for changes ) 16:24:30 at least that's how I'm approaching and thinking as well as solving things 16:25:12 so I ask myself what problem are we trying to solve now, will they still exist tomorrow and what problem might we be faced with 16:25:30 yup 16:25:39 thats why i'm proposing this cleanup :) 16:26:08 right but how are you going to prevent us from falling into the same mess again 16:26:30 what process workflow have you thought of that ( new components come in for example ) 16:27:21 thats why i want to automate this as much as possible so things can get tested and reported, e.g. for regressions (dropped BR reappearing etc). 16:27:47 ah yeas automation solves everything attitute 16:28:18 gestimation it will only cover maybe 70% which leaves those 30% to deal with 16:28:44 i'd rather have 80% fixed than 100% not fixed until i find a solution how to fix 95% 16:28:46 anyway first step establish first contact from there things can move forward or not 16:28:50 aye 16:28:55 lets leave it at that :) 16:29:06 ;) 16:29:12 if 80% of the maintainers call me a stupid idiot i'll back down :) 16:30:12 * pknirsch know hears the Star Trek "First Contact" melody playing in his head... 16:30:15 well if you manage to get 80% feedback some of my worries quickly vanishes 16:33:09 ok, but lets call it for today. thanks everyone again and have a great weekend and holidays! 16:33:12 #endmeeting