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