15:01:14 <pknirsch> #startmeeting Fedora Base Design Working Group (2013-12-20)
15:01:14 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:21 <pknirsch> #meetingname  Fedora Base Design Working Group
15:01:21 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:29 <pknirsch> hello everyone!
15:01:35 <jwb> hi
15:01:46 <sghosh> hi
15:03:02 <pknirsch> 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 <pknirsch> also some folks are already on PTO today
15:03:41 * notting is here
15:03:47 <pknirsch> heya notting :)
15:03:57 <pknirsch> ok, lets start off with it
15:04:02 <notting> pknirsch: bah, we have those meetings all the time. you think there's something important going on there? :)
15:04:07 <pknirsch> #chair jwb sghosh notting
15:04:07 <zodbot> Current chairs: jwb notting pknirsch sghosh
15:04:16 <pknirsch> hahaa notting, true enough
15:04:59 * Viking-Ice is here
15:05:47 <pknirsch> ok, first topic:
15:05:52 <pknirsch> #topic Continue discussion about BR cleanup
15:05:58 <pknirsch> with the following first sub topic
15:06:10 <pknirsch> #topic Discuss ideas and concerns brought up on the f-d ML
15:06:38 <pknirsch> so there has been a lively discussion on f-d about the cleanup idea
15:06:49 <jwb> fwiw, i already cleaned up kernel.spec
15:06:55 <pknirsch> with lots of good ideas and suggestions
15:06:58 <pknirsch> oh, nice!
15:07:00 <pknirsch> thanks jwb !
15:07:19 <jwb> it no longer indirectly BRs wayland to build...
15:07:41 <pknirsch> it needed wayland? O.o
15:07:43 <pknirsch> wow :)
15:07:54 <jwb> asciidoc->graphviz->EXPLOSION OF DEPS
15:07:58 <pknirsch> ohhhh
15:08:00 <pknirsch> yea
15:08:10 <pknirsch> excellent jwb :)
15:08:30 <notting> jwb: was that just shooting the -doc subpackage into the sun, or something else?
15:08:59 <jwb> notting, yep, killing -doc.  i also had to fudge some stuff for the perf man pages, but that worked out OK
15:09:07 <jwb> so basically i only touched the low hanging fruit
15:09:13 <Viking-Ice> jwb, did you "modernize" the kernel spec ( like use macro where applicable  )?
15:09:45 <jwb> kernel.spec already uses a lot of macros, but no i didn't do anything drastic
15:09:54 <Viking-Ice> jwb, ok
15:11:26 <pknirsch> 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 <pknirsch> 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 <pknirsch> and it's less than expected (just a couple dozen of packages)
15:13:17 <pknirsch> so coming to the discussion on the ML, there have been several really good suggestions and warnings
15:14:13 <pknirsch> one key thing proposes was to use rpmdiff and rpmguard to check whether 2 builds are the same
15:16:01 <pknirsch> 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 <notting> pknirsch: were the tools guys interested in pregenerating docs and getting texlive out of their build chain?
15:16:27 <pknirsch> notting: ah, forgot to check that, will make a note
15:17:44 <pknirsch> 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 <Viking-Ice> 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 <pknirsch> Viking-Ice: alright, i'll note that down and check that out, thanks!
15:23:32 <pknirsch> i really liked the overall discussion on the ML
15:24:12 <pknirsch> 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 <pknirsch> which might prove to be helpful for other things as well
15:25:04 <pknirsch> 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 <pknirsch> which kinda leads me to the next subtopic i had:
15:26:43 <pknirsch> #topic Proposal how to automate BR removal checking
15:27:08 <pknirsch> so my idea would be the following:
15:27:33 <pknirsch> take a specific srpm package
15:28:06 <pknirsch> write a script that "parses" the specfile and records the BRs of the package
15:28:24 <pknirsch> then automatically creates new srpms with 1 BR dropped each time and tries a build
15:28:44 <pknirsch> if successfull, run the result through rpmdiff and rpmguard and any other tests we can automate
15:29:11 <pknirsch> and if the results are all green, mark this BR to be a potential real drop
15:29:31 <pknirsch> overall, run that over a small set of packages first to see if this works at all
15:29:55 <pknirsch> 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 <pknirsch> 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 <pknirsch> i know this sounds like a lot of builds
15:31:39 <pknirsch> and it probably is
15:31:49 <pknirsch> but most if not all of it can be automated
15:31:55 <pknirsch> and run in parallel on multiple machines
15:32:02 <pknirsch> anyone sees any flaws in it?
15:32:17 * pknirsch still has the nagging feeling that this sounds too simple
15:32:43 <Viking-Ice> 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 <jwb> 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 <sghosh> pknirsch: any thoughts around policy of not enabling everything upstream does? could reduce the BR
15:33:42 <jwb> drop foo, build with bar and baz.  drop bar, build with foo and baz.  etc
15:35:15 <Viking-Ice> 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 <sgallagh> 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 <sgallagh> So the installed set would have fewer dependencies, at least.
15:38:07 <jwb> that doesn't help
15:38:21 <jwb> because it doesn't reduce the required packages needed for a self-hosting base
15:38:28 <jwb> which is the goal
15:38:41 <Viking-Ice> right
15:38:52 * pknirsch nods
15:39:38 <Viking-Ice> 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 <pknirsch> 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 <pknirsch> Viking-Ice: good point, true
15:40:19 <sgallagh> True enough. I suppose separating out SRPMs could address that, though.
15:40:35 <sgallagh> Leads to extra maintenance effort though
15:41:37 <pknirsch> 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 <jwb> pknirsch, yes, it could.  but that's why it seems simple to you.  because you're avoiding the hard part ;)
15:42:47 <pknirsch> 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 <pknirsch> jwb: maybe :)
15:43:44 <pknirsch> 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 <Viking-Ice> 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 <pknirsch> 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 <Viking-Ice> once the group has received their feed back the actual work can be started and be tailored around that feedback
15:46:00 <pknirsch> 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 <sgallagh> 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 <Viking-Ice> 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 <sgallagh> I can think of at least one example off the top of my head that they wouldn't catch
15:46:57 <pknirsch> 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 <sgallagh> pknirsch: Ok, fair enough.
15:47:21 <pknirsch> sgallagh: oh, what example?
15:47:54 <sgallagh> 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 <sgallagh> In some cases, this won't change the set of binaries or public APIs produced, but may change functionality.
15:48:11 <pknirsch> 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 <sgallagh> pknirsch: Case in point: libnl vs libnl3
15:48:46 <pknirsch> sgallagh: yep, and those are the cases that need to be verified and why working with maintainers will be critical.
15:48:50 <jwb> the two approaches are not mutually exclusive
15:48:53 <pknirsch> once we have some more hard data
15:48:55 <sgallagh> We'll prefer the latter, but use the former if that's what in the buildroot
15:49:02 * pknirsch nods
15:49:41 <sgallagh> Sure, I just want to make sure that such examples are taken into account when telling maintainers what to check for
15:49:45 <pknirsch> aye
15:49:56 <pknirsch> but thats good info to collect and share with maintainers as well
15:50:40 <pknirsch> 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 <pknirsch> that would be rude and very contra to anything we do
15:51:07 <pknirsch> and if a maintainer says he doesn't want to change his package thats of course his choice
15:51:36 <sgallagh> 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 <pknirsch> 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 <pknirsch> sgallagh: true as well, yea
15:53:35 <pknirsch> 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 <pknirsch> 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 <pknirsch> 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 <pknirsch> oki, but thats about it from what i had for today.
15:58:42 <pknirsch> anything else anyone wants to talk about?
15:59:54 <pknirsch> oh, one last topics from me:
16:00:11 <pknirsch> #topic Happy holidays and next meeting date
16:00:53 <pknirsch> 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 <pknirsch> 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 <pknirsch> so opinions on whether we shall recommence our meetings on January 9 or someone wants to volunteer for January 2nd?
16:03:49 <Viking-Ice> I was thinking about trying to put together someform of prd for this
16:04:23 <sghosh> jan 9th
16:05:09 <sgallagh> pknirsch: BTW, the Server and Cloud WGs are planning to do an IRC hackfest on PRD topics on Jan 8th
16:05:24 <sgallagh> Certainly the Base WG is encouraged to also participate
16:05:33 <Viking-Ice> 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 <pknirsch> sgallagh: ah, cool. same place and time?
16:06:07 <sgallagh> 1400-1800 UTC
16:06:18 <sgallagh> Meeting channel not yet determined
16:06:52 <pknirsch> 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 <Viking-Ice> as I said some form of documentation about this effort
16:07:34 <pknirsch> mhm
16:07:54 <pknirsch> We did start some of it in the Base wg wiki: https://fedoraproject.org/wiki/Base
16:08:03 <pknirsch> but it could certainly be improved
16:08:34 <pknirsch> jwb: how about you and next meeting time? Jan 2 or Jan 9?
16:08:57 <Viking-Ice> 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 <pknirsch> mhm
16:09:23 <jwb> pknirsch, 9th would be better
16:09:35 <pknirsch> 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 <pknirsch> i'll definitely be there
16:09:44 <pknirsch> jwb:  alright
16:10:36 <Viking-Ice> ok I'll leave it up to you then to sort it out on that meeting
16:11:07 <pknirsch> #agreed Next official meeting January 9
16:13:08 <pknirsch> thanks Viking-Ice
16:14:00 <pknirsch> 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 <Viking-Ice> 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 <pknirsch> aye
16:14:35 <pknirsch> definitely
16:15:05 <pknirsch> not everyone reads every email on fedora-devel or feels inclined to comment even it it might affect him :)
16:15:38 <Viking-Ice> even if they did the little feedback that has been received is cause for concern
16:16:23 <Viking-Ice> 2k components affect alot of maintainers ( or atleast it should )
16:16:25 <pknirsch> yea. and as i said, this is not a mandated "force down your throat" action but more informational quality
16:17:20 <Viking-Ice> 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 <pknirsch> but one needs to start somewhere and DO something, otherwise nothing will happen, ever.
16:17:38 <Viking-Ice> the first start is saying hi we are thinking about.... ;)
16:17:48 <pknirsch> yep :)
16:18:59 <Viking-Ice> ones "first contact" has been achieved the rest should go smoothly
16:19:18 <Viking-Ice> ( or it become clear it wont and back to the drawing board )
16:19:45 <pknirsch> mhm
16:20:09 <pknirsch> or see which maintainers are really interested and do their own cleanup etc.
16:20:42 <Viking-Ice> there is no point in halfbaking the process as in have half cleanup the other half still a mess
16:20:53 <Viking-Ice> ( or out of sync with that cleanup )
16:21:50 <pknirsch> 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 <pknirsch> 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 <Viking-Ice> 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 <Viking-Ice> at least that's how I'm approaching and thinking as well as solving things
16:25:12 <Viking-Ice> 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 <pknirsch> yup
16:25:39 <pknirsch> thats why i'm proposing this cleanup :)
16:26:08 <Viking-Ice> right but how are you going to prevent us from falling into the same mess again
16:26:30 <Viking-Ice> what process workflow have you thought of that ( new components come in for example )
16:27:21 <pknirsch> 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 <Viking-Ice> ah yeas automation solves everything attitute
16:28:18 <Viking-Ice> gestimation it will only cover maybe 70% which leaves those 30% to deal with
16:28:44 <pknirsch> i'd rather have 80% fixed than 100% not fixed until i find a solution how to fix 95%
16:28:46 <Viking-Ice> anyway first step establish first contact from there things can move forward or not
16:28:50 <pknirsch> aye
16:28:55 <pknirsch> lets leave it at that :)
16:29:06 <Viking-Ice> ;)
16:29:12 <pknirsch> 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 <Viking-Ice> well if you manage to get 80% feedback some of my worries quickly vanishes
16:33:09 <pknirsch> ok, but lets call it for today. thanks everyone again and have a great weekend and holidays!
16:33:12 <pknirsch> #endmeeting