15:00:55 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-02-21) 15:00:55 <zodbot> Meeting started Fri Feb 21 15:00:55 2014 UTC. The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:01 <pknirsch> #meetingname Fedora Base Design Working Group 15:01:01 <zodbot> The meeting name has been set to 'fedora_base_design_working_group' 15:01:34 <pknirsch> #topic Rolecall 15:01:58 * jreznik is here 15:02:08 <pknirsch> hi everyone! 15:02:15 <haraldh> <- 15:02:23 * dgilmore is here 15:03:08 <pknirsch> #chair jreznik haraldh dgilmore 15:03:08 <zodbot> Current chairs: dgilmore haraldh jreznik pknirsch 15:03:38 * mclasen sits between the chairs 15:03:44 <pknirsch> :) 15:04:21 <pknirsch> don't think you do, but i'm glad you're here in case there are any specific questions or unclarities regarding the Workstation tech spec and their requirements on Base 15:04:28 <pknirsch> so lets jump right into that: 15:04:43 <pknirsch> #topic Discussion of Workstation Tech Spec[1][2] and define action items for Base from it 15:04:53 <pknirsch> #info https://lists.fedoraproject.org/pipermail/desktop/2014-February/009136.html 15:05:04 <pknirsch> #info https://fedoraproject.org/wiki/Workstation/Technical_Specification 15:05:47 <pknirsch> So i've looked at it prior to my sick leave and after DevConf but didn't get a chance to see whether there were any updates over the past week, sorry 15:06:35 <mclasen> I've done a round of edits of the tech spec yesterday evening 15:06:41 <mclasen> incorporating feedback from the desktop list 15:06:43 <pknirsch> looking at Core Services and Features that was extended quite a bit lately, right? 15:07:02 <mclasen> right, I tried to make it reasonably complete 15:07:53 * pknirsch nods 15:08:00 <pknirsch> it's very detailed and explicit, thanks! 15:08:10 <pknirsch> thats exactly what i've hoped for from the tech specs 15:08:31 <mclasen> and just to state that upfront: none of this is set in stone, and some of it is pretty aspirational 15:08:43 <pknirsch> would you consider all of the Core Services and Features to be something Base should provide? 15:08:46 <pknirsch> sure 15:09:45 <mclasen> not sure how to answer that :-) I guess if you install the workstation, you don't first install base, and then add the workstation bits as a second step 15:09:54 <pknirsch> right 15:09:59 <mclasen> so from my perspective, it is just characteristics of the product you've installed 15:10:03 <pknirsch> true 15:10:20 <mclasen> that underneath we are sharing base infrastructure with multiple products is an implementation detail 15:10:25 <mclasen> an important one, of course 15:10:30 <jreznik> I think the question was more what are the commons for products? 15:10:46 <mclasen> right, I can't really answer that without seeing a similar list for the other products 15:10:47 <jreznik> mclasen: that's that details base should look to :) 15:11:03 <pknirsch> I personally can spot already quite a few of those. 15:11:05 <mclasen> but I would certainly hope that e.g. systemd is an agreed upon commonality 15:11:53 <pknirsch> and just as a reminder, we've made the distinction between being in available and being maintained in Base 15:11:54 <mclasen> it might be interesting to just ask the other wgs where they would want to deviate from the workstation spec 15:11:54 <jreznik> mclasen: systemd, sure but now the question is how much it will overlap? for workstation/server, we could see quite a lot, for cloud, that's pretty minimal, aiming on different things, less 15:12:36 <pknirsch> jreznik: right, same for the Software updates. dnf & friends are certainly part of Base, but gnome-software most likely not 15:13:28 <mclasen> you probably wouldn't want qt, gtk, gstreamer in the core package list for the cloud, either 15:13:33 <pknirsch> right 15:13:40 <mclasen> ...or gedit 15:14:30 <dgilmore> initsystem, firewall, fall into base 15:15:11 <dgilmore> just becauses a package is in base doesnt mean its something that is regullary installed 15:15:21 <dgilmore> go back to the definition of base 15:15:28 * pknirsch nods 15:15:59 <Viking-Ice> was it not already decided that baseWG would only deal with already decided components and anything outside those components falls out of base scope? 15:16:20 <pknirsch> The goal of Fedora Base is to provide a standard platform with common technologies, frameworks and APIs for all Fedora products. 15:16:25 <jreznik> and another example is installer - we agreed it's part of base but different products can have different requirements - take a look on ws and it's going to be different to what's in server 15:16:25 <pknirsch> to repeat our mission 15:16:46 <pknirsch> so if anything is shared between all products that should be made available via Base 15:17:03 <pknirsch> leading to 15:17:05 <pknirsch> => Keep Base as small as possible while still providing functionality most of the products would use 15:17:11 <Viking-Ice> right 15:17:13 <jreznik> pknirsch: that's the question - all? it's probably too strict (look on cloud) 15:17:18 <pknirsch> right 15:17:35 <Viking-Ice> then cloud defines it for the rest 15:17:38 <mclasen> the installer part of the workstation tech spec is probably the most aspirational 15:17:40 <pknirsch> thats one of the things i wanted to get cleared today, i'd like to propose to change that to most products 15:18:20 <jreznik> but I agree with mclasen - it would be nice to see such list from other groups, also that way to ask them how they will diverge from ws is a good question and then we can merge/split it as needed to create base tech spec 15:18:20 <dgilmore> mclasen: you will be sharing anaconda with server and cloud 15:18:45 <jreznik> dgilmore: share anaconda backend only? 15:18:46 <mclasen> I could see a future where anaconda has a backend that can be shared 15:19:02 <jreznik> (so kickstarts) 15:19:09 <mclasen> with different 'kickstart generator' frontends 15:19:17 <pknirsch> mhm 15:19:19 <dgilmore> if anaconda provides you a way to do some things differently we can work out how to get that in 15:19:32 <dgilmore> but installer will be shared across all products 15:19:34 <mclasen> but, as I said, pretty aspirational, and very much dependent on finding resources to realize it 15:19:39 <pknirsch> right 15:20:03 <mclasen> dgilmore: I have a pretty hard time accepting categorical 'there shall be only one' edicts 15:20:43 <dgilmore> mclasen: we are not going to fork the distro, so you would need resources to have a second installer team 15:21:12 <dgilmore> mclasen: but anaconda could provide ways to give different experiences 15:21:18 <dgilmore> but its one installer 15:21:25 <jreznik> mclasen, dgilmore: there will be one installer backend, it's the thing we can agree on now 15:21:39 * mclasen happily agrees 15:21:43 <jreznik> dgilmore: yes, one installer with different frontends 15:22:11 <jreznik> so backend would be something base specifies 15:22:11 <dgilmore> jreznik: its still one installer 15:22:34 <jreznik> dgilmore: could be 15:23:04 * haraldh wants a kickstart installer without python.. 15:23:39 <pknirsch> i mean, looking at the 3 current "modes" of anaconda there are already different frontends, so i see no reason why there couldn't be a product specific 4th 15:23:43 <dgilmore> anyway its nothing to sort out now 15:23:49 <pknirsch> right 15:24:01 <jreznik> but let's get back to topic - installer is a good example of base backend and frontends defined by products 15:24:14 <pknirsch> aye 15:24:23 <pknirsch> same for the Software updates. dnf & friends backend 15:24:24 <jreznik> and I expect there would be more "on the edge" for other techs 15:24:28 <mclasen> pknirsch: seems more likely that we'd morph the live installer to fit our needs than add an entirely new one 15:24:30 <jreznik> pknirsch: right 15:24:38 <pknirsch> and gnome-software as a frontend for Workstation 15:24:55 <mclasen> I've reworded the section to avoid talking about dnf (the commandline replacement for yum) 15:24:57 <pknirsch> mclasen: sure 15:25:11 <mclasen> and instead talk about gnome-software using the hawkey stack (via packagekit) 15:25:17 <pknirsch> aye, right 15:26:06 <mclasen> (which is already the case in rawhide, and seems to be working pretty well) 15:26:13 <pknirsch> nice! 15:27:00 <pknirsch> so far i see most of the parts of Core Service up to the "Miscellaneous system information" as either closely related to or even part of Base 15:27:04 <pknirsch> question now is: 15:27:16 <pknirsch> Is there anything we in Base would have to DO now :) 15:27:43 <pknirsch> e.g. are there any specific requirements on Base that you see at the moment, mclasen ? 15:28:22 <pknirsch> where you'd need e.g. any changes to anything in the rcm processes? 15:28:54 <mclasen> I haven't filled out the 'installation methods and deliverables' section yet, since I didn't see much discussion of that on the list 15:29:18 <pknirsch> alright, fair enough :) 15:29:23 <mclasen> my guess would be 'something that can be put on a usb stick' together with 'a nice tool that does it' 15:29:36 <mclasen> I hope to get that sorted next week 15:30:04 <pknirsch> which is basically the Live-media-creator? or based on? 15:30:26 <mclasen> other than that, would I hope to get from the base wg is proposals for how we can best organize the different needs of the products, avoiding conflict and friction 15:30:35 <mclasen> there was some discussion on the list about presets, and meta packages 15:30:50 <pknirsch> presets? 15:30:56 <mclasen> systemd presets 15:31:19 <mclasen> isn't that what it is called, haraldh ? 15:31:25 <haraldh> yes 15:31:28 <pknirsch> ah 15:31:41 <haraldh> default services to be enabled 15:31:55 <pknirsch> ok, got it, thanks 15:32:39 <jreznik> when I saw that thread last time, I liked that idea of subpackages for different products, not only for presets but overall configuration 15:33:09 <pknirsch> yea, but i agree, the interesting part will come when we see the other products requirements. e.g. if there are overlaps and 2 products want/need different versions, how do we resolve that 15:33:17 <haraldh> installation method for a USB stick: http://people.freedesktop.org/~kay/installer/ :) 15:33:40 <pknirsch> haraldh: thats what we did 12 years ago for s390x :) 15:33:50 <pknirsch> and that was pretty back then either :P 15:33:54 <mjg59> haraldh: Won't work properly on Macs 15:33:54 <jreznik> pknirsch: different versions - not something for shorterm 15:34:00 <haraldh> hey, it's as simple as it can get :) 15:34:11 <haraldh> mjg59, go away with your MAC :) 15:34:27 <pknirsch> dd if=disk.img of=/dev/mapper/mypart is the most simple :) 15:34:45 <mjg59> Just reminding people that installers tend to end up complicated for a reason 15:34:54 * pknirsch nods 15:35:12 <haraldh> # btrfs send 15:35:39 * dgilmore needs to run to catch his bus. see y'all later 15:35:44 <pknirsch> cya dgilmore ! 15:36:37 <nphilipp> pknirsch: wouldn't that (different version requirements between products) fall into a "we'll cross that bridge when we come to it" category? 15:36:41 <jreznik> dgilmore: bye and see you next time! 15:37:01 <nphilipp> pknirsch: rather state "please avoid yadda yadda" 15:37:14 <pknirsch> nphilipp: kinda, but like with most things, it's usually better to think about something before you hit the brick wall 15:37:20 <nphilipp> sure 15:37:37 <nphilipp> pknirsch: but this needs to be done in a way which doesn't encourage it :) 15:37:52 <pknirsch> but ye, getting back to the presets and configuration, those can surely be just packaged in product specific packages i suppose 15:38:00 <pknirsch> so that should be easily resolvable 15:38:16 <nphilipp> pknirsch: I don't want to end up in a ruby-on-rails-esque ecosystem were everyone thinks they can require a random version of a component and not deal with updates 15:38:27 <pknirsch> :) 15:38:51 <pknirsch> docker.io will solve everything, no worries! 15:39:19 <haraldh> pff 15:39:37 <nphilipp> pknirsch: I'd rather take aqua regia for solving (nearly) anything any time :D 15:40:14 <pknirsch> and regarding the installer, i don't think we can come to any final statement on that, but i think FESCO already was pretty clear about that last time they discussed the topic that there should be a consistency between the different products for that, too 15:40:26 <pknirsch> i wonder how that will work for cloud already though 15:40:32 <nphilipp> at least the consequences of using it are clearly understood *runs* 15:40:44 <pknirsch> :) 15:42:18 <pknirsch> but coming back full turn to the tech spec, i don't see anything in there that at this time would require any changes or actions from the Base group. Do you agree, mclasen ? 15:43:17 <mclasen> yes, I think so 15:43:59 <pknirsch> great! 15:44:26 <pknirsch> #info At this moment Workstation WG tech spec doesn't require any changes or actions from the Base group 15:44:31 * mclasen heads off 15:44:38 <pknirsch> cya mclasen ! 15:44:43 <pknirsch> and thanks again for being here today! 15:45:27 <pknirsch> and i'd say we revisit it once the other WGs have more clearly defined tech specs. then we can identify overlaps and potential action items 15:46:14 <haraldh> yes 15:46:17 <haraldh> agreed 15:48:39 <jreznik> any other topics for todays meeting? /me should leave soon, expecting delivery from tesco later today 15:48:59 <jreznik> btw. the deadline for tech specs is march 3rd if I understood FESCo correctly 15:49:27 <jreznik> do we want to deliver something by that time - at least our vision or wait for others to base it on? 15:49:31 <pknirsch> I think we've covered that topic, i really wanted to use our full time on it today 15:49:36 <pknirsch> which proved to be correct ;) 15:49:56 <pknirsch> #info Revisit once other WGs provide tech specs by March 3rd 15:50:14 <pknirsch> any other open floor topics 15:50:16 <pknirsch> ?" 15:50:41 <haraldh> - 15:57:37 <pknirsch> sounds not 15:57:41 <pknirsch> so lets close the meeting for today 15:57:51 <pknirsch> thanks everyone and have a fantastic weekend! 15:58:03 * pknirsch hopes to finally get rid of the remains of his DevConf plauge 15:58:11 <pknirsch> #endmeeting