15:02:12 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-01-24)
15:02:12 <zodbot> Meeting started Fri Jan 24 15:02:12 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:21 <pknirsch> #meetingname  Fedora Base Design Working Group
15:02:21 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:02:36 <pknirsch> Welcome crazy Friday!
15:02:56 <jreznik> crazy? yes, probably yes
15:02:59 <pknirsch> :)
15:03:06 <pknirsch> #topic Role call
15:03:11 <pknirsch> lets see who we got today
15:03:15 <pknirsch> i see jreznik !
15:03:16 <pknirsch> :)
15:03:26 <jreznik> troubles with dog, I have to call vet and would probably have to leave a bit early
15:03:32 <jreznik> or will send my wife
15:03:44 <pknirsch> yea, i have a hard stop at the end of the hour as i need to jump to a phone call after this
15:03:49 * notting is here
15:03:53 <haraldh> <-
15:04:00 <pingou> jreznik: good luck
15:04:23 <pknirsch> and yea jreznik, hope the dog gets better :/
15:04:29 * pknirsch has been sick the whole week as well
15:04:53 <pknirsch> alright, but lets get going.
15:05:13 <pknirsch> #topic Discussion of WG PRDs and impact on Base
15:05:48 <pknirsch> I hope everyone has read the other WGs PRDs, as we probably won't have time to do that during our meeting him here ;)
15:06:14 <pknirsch> If not i've at least compiled a very brief list of the overlapping this i've seen in all 4 PRDs so far
15:06:32 <pknirsch> i might have obviously missed a few things here and there, but we can extend that at any time i think
15:06:43 <jreznik> that compiled list would be great indeed
15:07:02 <pknirsch> jup, let me add those as an info to the logs:
15:07:40 <pknirsch> and i would propose that i'll add the ones we agree upon to our Base wiki definition so it becomes more clear what Base will be providing for the other products (aka, more details)
15:08:44 <pknirsch> #info Proposed shared requirements of most/all WGs extracted from PRDs:
15:09:06 <pknirsch> #info - Software Collections (SCL) support
15:09:18 <pknirsch> #info - Containers
15:09:49 <pknirsch> #info - RPM
15:10:09 <pknirsch> #info - Installer
15:10:57 <pknirsch> There was a mentioning of Core components, but no clear definition of them in any of the PRDs so far, maybe thats too deep level for a PRD so we'd need to work with the other WGs to get that list i suspect
15:11:09 <pknirsch> Though i don't expect any really odd things in there
15:11:19 <pknirsch> (well, not tooo odd at least...)
15:11:58 <pknirsch> oh, and Containers of course meaning not the actuall apps or anything, but like with SCLs just the execution support.
15:12:16 <pknirsch> e.g. Cloud will maintain and support quite a few on SCLs, same for Env and Stacks
15:12:19 <jreznik> a lot of stuff will clarify with next step - scoping, it's the right part where we should be really involved
15:12:27 * pknirsch nods
15:12:36 <notting> so scls, which are made of rpms, put in containers. oh no, someone's going to say the D word
15:12:48 <pingou> Delta!
15:12:55 <pknirsch> Dorito?
15:13:03 <notting> docker!
15:13:06 <pknirsch> ohhh
15:13:10 <pingou> ah :(
15:13:10 <pknirsch> you said it!
15:13:17 <pingou> pknirsch: we were close
15:13:22 <pknirsch> true :)
15:13:39 <jreznik> notting: something like that as I understand it either
15:14:57 <pknirsch> Ye, but again, same as with the SCLs here, Base should not provide content for either Containers or SCLs but rather as we said in our mission statement provide the platform/tech/support to make them work.
15:15:06 <pknirsch> at least thats my opinion :)
15:15:28 <jreznik> yep
15:15:39 <notting> so we're in charge of rpm? (and yum,and dnf...)
15:15:50 <jreznik> content yes, but is tooling our mission?
15:15:51 <notting> (and packagekit, and ...)
15:16:15 <pknirsch> rpm yes, dnf probably, packagekit probably less so
15:16:23 <pknirsch> again imho
15:17:19 <pknirsch> as basically every product is basing their images/installation on rpm and yum/dnf
15:18:34 <pknirsch> so any comments otherwise on the list? additions, corrections, removals, etc.
15:18:46 * sghosh sorry late to mtg
15:18:54 <pknirsch> hey sghosh, np
15:19:07 <notting> installer becomes a large surface if it's fully dependency solved
15:19:15 <notting> but we knew that
15:19:22 <haraldh> :-(
15:19:34 <pknirsch> yep, thats a worry i had as well
15:19:36 <notting> i assume "product creation tools" was implied? or do WGs want to maintain their own?
15:19:56 <pknirsch> well, Cloud seems to want to write and maintain their own at least
15:20:10 <sghosh> notting: image creation or rcm compose?
15:20:32 <pknirsch> Server and Workstation though are looking to be using standard good ole rcm netinstall and dvds
15:20:59 <pknirsch> and Env doesn't have an installable product :)
15:21:09 <notting> sghosh: 'yes'? in some respects (anaconda install dvd) they both get used
15:21:13 <jreznik> pknirsch: that own tools should be again part of scoping - I'm not sure we can afford this "every product has own tools"
15:21:18 <sghosh> ;)
15:21:47 <pknirsch> jreznik: hm, so you're volunteering to maintain the cloud image generation tools? thanks!
15:21:48 <pknirsch> :)
15:22:01 <jreznik> pknirsch: well, it's rcm thing
15:22:05 <pknirsch> right
15:22:15 <pknirsch> thats i think where notting wants to head to
15:22:24 <pknirsch> belonging to vs. who's maintaining it
15:22:29 <sghosh> images == VM images, docker images... ?
15:22:40 <jreznik> pknirsch: exactly
15:22:45 <pknirsch> it's fine if the tools actively belong to Base but are maintained by respective WGs or teams
15:22:48 <pknirsch> like rcm tools
15:22:56 <pknirsch> they certainly should belong in Base iirc
15:22:59 <jreznik> it belongs to Base but it's developed by othet teams
15:23:04 <pknirsch> but would be maintained by the rcm team
15:23:05 <jreznik> ah, you were faster
15:23:10 <pknirsch> same for Installer
15:23:19 <pknirsch> anaconda team would still take care of it
15:23:41 <jreznik> pknirsch: another question is they would be ok with it
15:23:49 <pknirsch> aye
15:23:50 <sghosh> is imagefactory RCM maintained?
15:24:04 <pknirsch> no clue sghosh
15:24:14 <jreznik> as in such case, Base should have some decision making power and I'm not sure we can do that for installer for example
15:24:19 <notting> sghosh: it's ian-maintained, and mattdm-prodded
15:24:41 <sghosh> it might be good list tools along with general intenet - this way if the choice of tools change, we can revist where it belongs
15:25:02 <jreznik> sghosh: yes
15:25:14 <pknirsch> good idea
15:27:28 <pknirsch> How about till next week everyone collects the tools they see as important and we'll then add them to a subpage on the Base wiki?
15:27:37 <notting> i.e., list what the standard way is for <XYZ>? and (for example) if cloud wants to incubate imagefac when no standard exists, go for it?
15:27:57 <jreznik> notting: works for me this way
15:27:59 <jreznik> we ned
15:28:25 * pknirsch nods
15:28:31 <jreznik> we need some flexibility to allow new ways of doing new stuff, but we should make sure to cooperate/couse existing tools
15:28:59 <jreznik> and image creating is one of that messy part we're now
15:30:16 <pknirsch> mhm
15:30:39 <pknirsch> but there could be other stuff. which is where SCLs and potentially OMG DOCKER comes in
15:32:27 <pknirsch> Ok, so anything i've not spotted as a common item between all WGs PRDs?
15:32:32 <jreznik> so, I think we can do it together, probably asking other teams to contribute, especially rcm
15:33:05 <jreznik> to be honest, I did a quick scan of PRDs, not detailed read
15:33:16 <pknirsch> :)
15:34:18 <pknirsch> yea. i think the most common teams to maintain things which we would like to be available or hosted in Base would be rcm, installer, toolchain, kernel and cloud
15:34:28 <pknirsch> and rpm/yum
15:34:28 <pknirsch> sorry
15:34:38 <notting> the server role stuff is somethng that possibly *could* be expanded to other products, depending how it's done
15:34:46 <pknirsch> hm, true
15:35:13 <pknirsch> didn't dgilmore mention he wanted to do a role like kickstart for Base as well?
15:35:29 <jreznik> for that rcm part of tooling, I just pinged masta to join too :)
15:35:34 <masta> hello
15:35:38 <masta> sry I'm late
15:35:39 <jreznik> hey masta
15:35:49 <pknirsch> np and hey masta :)
15:36:14 <masta> was all caught up in stuff... forgot about this important meeting, my huge apologies
15:37:09 <pknirsch> we've just been talking about the differentiation of maintainership and availability/hosting of tools in Base
15:37:34 <pknirsch> where the maintainership would of course stay the same but we'd want to provide them in Base for all products to use.
15:37:44 <pknirsch> Specifically rcm tooling and cloud ones
15:37:53 <pknirsch> would that work for you guys in rcm?
15:38:38 <masta> so... the tools in Base are going to be the definitive one, the other WGs will be consumers
15:38:57 <masta> pknirsch: sounds good to me
15:39:43 <masta> we own the tools, so they have less complicated easy time of using them
15:39:44 <pknirsch> alright, cool. won't change much to how things are today tbh, but it'll give us a good place to define a list of recommended tooling for Fedora
15:40:42 <pknirsch> and dwa has actually documented quite a lot of how he's been using the rcm tools for secondary arch: http://fedoraproject.org/wiki/User:Dwa
15:41:01 <pknirsch> which might be interesting to a larger audience once we're allowing other products to build stuff
15:41:55 <masta> that being said, if anybody from the WGs wants to join rel-eng... please do! We could use somebody with python-fu to kick-butt on our collection of scripts.
15:42:07 <pknirsch> :)
15:43:00 <pknirsch> alright, lets make a quick note of what we've talked about and an action item for everyone
15:44:23 <pknirsch> #info Maintainership of the various tooling pieces from rcm, cloud and other will stay as they are but will be available in Base for all products to consume easily.
15:45:29 <pknirsch> #action Everyone: Make a list of tools you know of that should be available in Base to provide a recommended tooling for all products. If possible with documentation and/or examples.
15:46:07 <pknirsch> ok, lets quickly move to the next topic as we're running low on time.
15:46:31 <pknirsch> #topic Status update BR cleanup
15:47:21 <pknirsch> Unfortunately i've been sick nearly all week (dragged myself to some work, but that didn't really help)
15:47:47 <pknirsch> I still managed to review and test about 15 of the 65 packages we discussed last week
15:48:16 * jreznik has to leave now to vet
15:48:18 <pknirsch> The results so far are quite good. Some of the BRs can actually be actively dropped without any problem and change to the package
15:48:23 <pknirsch> cya jreznik
15:49:04 <pknirsch> and most of the documentation generation things can be pre created, but i'd like to provide some scripts to make that easier for package maintainers
15:49:44 <pknirsch> Next steps from my side will be to contact the respective maintainers with actual hard facts and info i have now and open BZs to track this with an overall Change tracker for the cleanup
15:49:53 <pknirsch> and of course finish the review
15:50:04 <haraldh> cool
15:50:34 <Viking-Ice> do we have a list somewhere of those all the relevant components
15:51:01 <pknirsch> Interestingly most of these changes could be done as a default without needing to add a %bootstrap macro or anything
15:51:04 <pknirsch> Viking-Ice: http://harald.fedorapeople.org/bootstrap-not-needed-deps.txt
15:53:14 * masta has to run - drop daughter at day care.
15:53:17 <Viking-Ice> I will be working on the future of triaging and reporting so if you got a list of components to test ( like the bootup ) feel free to hand it to me email or whatever so I can build the and proposal around that
15:53:25 <masta> sry for being late and departing early.. bye
15:53:26 <pknirsch> I've also experimented a bit with rwmjones' autobuildrequires tool. quite spiff i have to say, i'll have to fiddle a bit more with it and see how i can easily do some comparisons with the real BRs
15:53:31 <pknirsch> np masta, cya!
15:53:45 <pknirsch> Viking-Ice: thanks, will do!
15:53:48 * haraldh has to leave at 17:00 also..
15:54:18 <pknirsch> ok, lets give do at least a 5 minute open floor as i'll have to leave in 5 minutes, too
15:54:22 <pknirsch> #topic Open Floor
15:54:44 <Viking-Ice> so have you contacted all maintainers for all the components not just those that are affected?
15:59:36 <Viking-Ice> pknirsch,  the reason I have been presuring this so much is pretty much the concern that Thorsten shows here  https://lists.fedoraproject.org/pipermail/devel/2014-January/194318.html
15:59:54 <pknirsch> not yet, no, but it's still on my todo list. As i mentioned already, i wanted to give the maintainers first some more solid meat before contacting them. Just telling them "Hey, we're thinking about cleaning up BRs" isn't likely to get you a big response from anyone. Saying "<same sententence> + And we have a few ideas we'd like to share with you if your interested in how to make that happen" is much better.
16:01:01 <Viking-Ice> pknirsch, basically you need ensure every maintainer that maintains a package on the list is both aware and onboard with any changes
16:01:22 <pknirsch> exactly
16:01:41 <pknirsch> but if i don't provide anything they can work with, what would you expect a maintainer to do?
16:01:52 <pknirsch> I'd personally shrug my shoulders and ignore the email
16:02:12 <pknirsch> sorry, have to afk now
16:02:24 <Viking-Ice> pknirsch, you would be engaging and informing them and hopefully get any feedback in return
16:04:24 <Viking-Ice> pknirsch_afk, after the attack on our foundation people are even more skeptical about the .next and wg efforts  but by all means dictated and decide and surprise people if you think that results in better outcome
16:10:49 <dgilmore> sorry im late
16:14:48 * masta is back
16:19:36 <notting> ... i think we're EOM. probably should make it official
16:19:58 <notting> #endmeeting
16:20:02 <notting> doh.
16:20:30 <dgilmore> looks like only pknirsch_afk is a chair
16:20:37 <pknirsch_afk> #endmeeting
16:21:00 <pknirsch> #endmeeting