15:01:01 <pknirsch> #startmeeting Fedora Base Design Working Group (2013-11-15)
15:01:01 <zodbot> Meeting started Fri Nov 15 15:01:01 2013 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:17 <pknirsch> #meetingname  Fedora Base Design Working Group
15:01:17 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:01:26 <dgilmore> hola
15:01:31 <pknirsch> hello and welcome to our second meeting everyone!
15:01:36 <notting> hey all
15:01:44 * sgallagh lurks
15:02:06 * jreznik is trying to eat something before the meetings fires for real :)
15:02:06 <pknirsch> so we got dgilmore and notting so far (and sgallagh lurking)
15:02:11 <pknirsch> ha jreznik !
15:02:18 <pknirsch> #chair dgilmore notting jreznik
15:02:18 <zodbot> Current chairs: dgilmore jreznik notting pknirsch
15:02:51 * masta looks in
15:02:54 <masta> hello
15:02:56 <pknirsch> lets see, we're missing masta, haraldh, jwb
15:03:03 <pknirsch> and dwalsh
15:03:11 <haraldh> <-
15:03:18 <pknirsch> #chair maste haraldh
15:03:18 <zodbot> Current chairs: dgilmore haraldh jreznik maste notting pknirsch
15:04:03 <pknirsch> oh, and subhendu, but he mentioned he'd be late as he's got a conflict meeting today
15:04:34 <dgilmore> pknirsch: who is maste?
15:04:43 <pknirsch> erh
15:04:52 <pknirsch> darn autocomplete
15:04:56 <pknirsch> #chair masta
15:04:56 <zodbot> Current chairs: dgilmore haraldh jreznik masta maste notting pknirsch
15:05:04 <pknirsch> can i dechair someone? ;)
15:05:13 <pknirsch> #chair maste
15:05:13 <zodbot> Current chairs: dgilmore haraldh jreznik masta maste notting pknirsch
15:05:19 <pknirsch> #chair -maste
15:05:19 <zodbot> Current chairs: -maste dgilmore haraldh jreznik masta maste notting pknirsch
15:05:23 <pknirsch> doh
15:05:26 <pknirsch> ah well
15:05:36 <dgilmore> #help
15:05:40 <pknirsch> #help
15:05:46 <dgilmore> bahh
15:06:32 <pknirsch> lets get started
15:06:58 <pknirsch> meeting agenda for today: https://lists.fedoraproject.org/pipermail/devel/2013-November/192007.html
15:07:05 <pknirsch> #info Meeting agenda: https://lists.fedoraproject.org/pipermail/devel/2013-November/192007.html
15:07:35 <pknirsch> As we got an open floor today, if you have anything to add we can cover that at the end then
15:07:54 <pknirsch> or if you have something that should be discussed earlier, just chime in and we'll cover that
15:08:18 <pknirsch> ok, so lets start with the first topic for today then:
15:08:26 <pknirsch> #topic QE representation
15:08:44 <pknirsch> i already wanted to bring that up last week, but it slipped my mind before i sent out the agenda
15:09:20 <pknirsch> We do have a quite diverse committee i think, but i'd personally would love some official representative on our weekly meetings from QE
15:09:23 <dgilmore> we should see if tflink adamw want to be involved
15:09:29 * pknirsch nods
15:09:36 <dgilmore> of if they would rather one of use go to them when needed
15:09:38 <notting> i'm all for having QE around
15:09:57 <dgilmore> id rather have someone from QA involved
15:09:59 <Viking-Ice> why them
15:10:08 <masta> would be great to have more lurkers
15:10:14 <dgilmore> Viking-Ice: because they are who i thought of off teh top of my head
15:10:22 <dgilmore> and were in here
15:10:24 <jreznik> it would be nice to have QA around, just it's a bad time for everyone from QA due to ongoing release
15:10:35 <dgilmore> i also thought of robitno but he is not here
15:10:38 <pknirsch> it's always a bad time for QA then, jreznik :)
15:11:03 <pknirsch> but ye, i'm open to any suggestions here. Who would be on your mind, Viking-Ice ?
15:11:29 <Viking-Ice> pknirsch, beside me you mean ;)
15:11:31 <jreznik> also we talked last time how to coordinate WGs itself, with other teams (QA) and sounds like they would be able to jump into a meeting or other sort of coop - just not regularly when I talked about it at QA meeting
15:11:33 <pknirsch> ;)
15:12:06 <masta> #info To all QA team members: please feel free to participate in the Base WG discussion on IRC  :-)
15:12:36 <masta> looks like we have some here
15:12:41 <pknirsch> yea, but as i said, i'd rather have someone be willing and available to most if not all of our meetings here.
15:12:45 <Viking-Ice> in anycase this is far from involving qa at this point
15:12:53 <pknirsch> true
15:12:56 <dgilmore> pknirsch: indeed
15:13:03 <Viking-Ice> WG's are still trying to find mutual ground to work on
15:13:17 <jreznik> Viking-Ice: well, I'm not sure it's too far...
15:13:44 <jreznik> but you're right, no immediate action is needed
15:13:44 <pknirsch> aye, but that can already be a point where QE has very valid points why some things are good or bad
15:13:53 <pknirsch> even without real actions to act on
15:13:57 <dgilmore> Viking-Ice: just like releng needs to be involved now so does QA
15:13:58 * jreznik is experiencing network issues...
15:14:09 <dgilmore> there is not things to be done
15:14:16 <Viking-Ice> pknirsch, in Fedora we have QA in RH you have QE's
15:14:19 <dgilmore> but they need to know whats coming to make plans
15:14:35 <masta> Are we looking for a semi-formal liaison type thing from QA?
15:14:40 <pknirsch> but the input of potential issues that need to be addressed for potential actions from a QE perspective e.g. would be something
15:14:44 <pknirsch> exactly dgilmore
15:14:49 <Viking-Ice> dgilmore, not really one release cycle means things stay the same
15:14:53 <Viking-Ice> for WG's
15:15:02 <dgilmore> Viking-Ice: wrong attitude sorry
15:15:21 <dgilmore> we need active planning and working towards the change
15:16:11 * jreznik would still like see a bit higher level cooperation, not only with QA but also the rest of Fedora/WGs as outlined above/in the fesco ticket
15:16:14 <dgilmore> Viking-Ice: maybe things wont change much for F21  but if we are not on top of it now it wont change for F22 either
15:16:25 <dgilmore> jreznik: indeed
15:16:25 <Viking-Ice> QA' s first and foremost function is and always has been to take care of the installer and the core/baseOS and what will happen now is we will push things outside to the outer working group to handle this by their respective communities
15:16:45 <Viking-Ice> and try to assist them in the process
15:16:46 <pknirsch> which will have QA people
15:16:48 <pknirsch> right?
15:16:56 <pknirsch> from the overall QA body i suspect
15:17:09 <Viking-Ice> pknirsch, not unless someone volunteers to do that from the QA community
15:17:28 <jreznik> Viking-Ice: well, it was only because installer took so much time from QA there was mostly on QA except base system
15:17:40 * satellit listening but only volunteerin qa
15:17:49 <pknirsch> good points, ye
15:18:05 <jreznik> what I talked to guys, they would like to work on more stuff in fedora, just they are blocked on this level
15:18:30 <sghosh> jreznik who is blocked?
15:18:30 <pknirsch> but QA would still probably want to provide testing for installer and core systems, right? And thats what Base is to some degree all about
15:18:31 * sgallagh reminds folks that part of this process is to determine how much time to allocate for certain tasks. Automating QA is one example that keeps coming up
15:18:33 <Viking-Ice> jreznik, anaconda guys are unwilling to alter their own release cycle and while that is we cannot support multiple products anyway so people can just forget any expectation in that regard
15:18:40 <jreznik> but let's move on - I'll talk to guys on Monday on QA meeting how much time they can spend time with us
15:19:06 <tflink> jreznik: that came up this week already
15:19:08 <jreznik> (sorry for that double time :D)
15:19:28 <dgilmore> tflink: :) welcome
15:19:32 <pknirsch> welcome ;)
15:19:37 <dgilmore> tflink: so whats the thoughts?
15:19:59 <jreznik> tflink: I stated above that it's the worst time for QA now but last time I was talking about that higher level meeting, seems like guys would like to see more involvement even here
15:20:15 <tflink> IIRC, the conclusion was that right now isn't a good time for us to be splitting up into all the WGs and were hoping to have a semi-centralized "meeting" to figure some of this out
15:20:24 <pknirsch> mhm
15:20:28 <pknirsch> fair enough
15:20:43 <pknirsch> so shall we postpone this then to a later date, tflink ?
15:20:53 <pknirsch> like, post F20 GA?
15:21:10 <Viking-Ice> post F20 GA sounds fine
15:21:13 <dwalsh> I have been sitting on #fedora-base  sorry for being late.
15:21:22 <pknirsch> #chair dwalsh
15:21:22 <zodbot> Current chairs: -maste dgilmore dwalsh haraldh jreznik masta maste notting pknirsch
15:21:22 <tflink> I suspect that we'd all rather figure this out before the WG output is due
15:21:31 <pknirsch> jep
15:21:41 <Viking-Ice> tflink, we need to figure out the direction first
15:21:45 <tflink> but I think post F20 GA is more likely
15:22:09 <Viking-Ice> we also need to figure out what can be done about Anaconda ( our most time consuming customer )
15:22:37 <jreznik> Viking-Ice: it's what's other WGs are working too
15:22:49 <Viking-Ice> jreznik, what do you mean
15:23:08 <pknirsch> my reasoning was just that especially for Base i could see a tighter work beneficial. If some outer product (not meant to be devaluing that, sorry not a native speaker) doesn't have QA representation i'd be less worried about that. But for Base i just see that if we're going to be used as a platform for all/most products, testing becomes more valuable and efficient
15:23:16 <pknirsch> but thats just my $0.02 to this
15:23:17 <jreznik> Viking-Ice: for example Workstation WG would like to define their's own installer...
15:23:35 <mclasen> Viking-Ice: to put it bluntly, if fedora-qa is not testing the products that fedora produces, it is not fedora qa
15:23:54 <Viking-Ice> jreznik, well that aint going to happen ( anaconda devs made it clear to me that wg's aren't going to get their own installer maybe spokes maybe )
15:24:16 <Viking-Ice> mclasen, we dont have resources to do sub community qa stuff
15:24:18 <masta> I think some of the QA can be compartmentalized into base, with a reduced surface area or scope... the QA for other WGs can be more specific and hopefully not overlap.
15:24:19 <sghosh> jreznik agree with Viking-Ice - one anacaonda
15:25:02 <Viking-Ice> base and the installer dont have to worry about QA it comes with our territory to take care of that
15:25:03 <pknirsch> masta: exactly my thoughts but better formulated ;)
15:25:24 <jreznik> mclasen: right
15:25:25 <tflink> I'm still not clear on what the base WG is looking for from QA?
15:25:36 <sgallagh> Yes, one anaconda, please.
15:25:41 <sgallagh> Different spokes and maybe a fresh coat of paint on the GUI, but same tools under the hood, please.
15:25:51 <jreznik> sgallagh: it was just example
15:26:13 <sghosh> jreznik painful example
15:26:15 <pknirsch> sgallagh: isn't that up to the WGs though? not saying it is or should
15:26:21 <Viking-Ice> tflink, from the sound of it QA their outcome for them
15:26:24 <pknirsch> and sghosh
15:26:28 <tflink> someone to show up and participate in the process?
15:26:31 <Viking-Ice> tflink, blank check on QA resources
15:26:44 <tflink> Viking-Ice: I could be missing something, but that's not how I'm reading it
15:26:44 <Viking-Ice> to dedicate to the outcomes of the WG's
15:26:54 <jreznik> pknirsch: we want some autonomy for WGs but we're really limited in what can we do - so yes to flexibility but in some constraints
15:27:00 <sgallagh> pknirsch: I think anaconda is pretty clearly in your Base camp
15:27:18 <Viking-Ice> sgallagh, yep I think so ot
15:27:18 <sghosh> pknirsch I would rather see requirements from other WG on base, than independent toolsets
15:27:19 <Viking-Ice> mean to
15:27:26 <sgallagh> The overhead of not sharing it would likely be insurmountable
15:27:45 <sgallagh> At that point we might as well just launch separate distros and give up
15:27:53 <pknirsch> sure, and without going too much on a tangent, what if a downstream fedora product would want to use a different installer and do all the work and testing on it? would we, aka FESCO then deny that? If there's a community/group who would want to do that?
15:28:19 <Viking-Ice> pknirsch, alternative installer option means just more works for QA ;)
15:28:30 <Viking-Ice> but anaconda does now own Fedora
15:28:34 <pknirsch> Viking-Ice: sure, but if that group would do all the QA itself?
15:28:38 <mclasen> sgallagh: how it gets installed is an integral part of the product
15:28:45 <jreznik> sgallagh: actually I would not be agains separate distro sharing some parts of infra but it's really really distance future, not possible now
15:28:56 <sghosh> pknirsch downstream - as in respins - are indepedent of fesco
15:28:58 <Viking-Ice> pknirsch, we take care of the installer same way as we take care of networking etc
15:29:04 <sgallagh> pknirsch: I think at that point, it's a downstream *distro* and shouldn't be using our infrastructure
15:29:04 <Viking-Ice> basic networking that is
15:29:05 <pknirsch> Viking-Ice: right
15:29:33 <notting> (brb, moving dishwasher)
15:29:33 <pknirsch> sghosh: but what if they'd want to be called something Fedora-ish? Is anaconda == Fedora then?
15:29:52 <pknirsch> as thats what it sounds like right now
15:29:56 <sgallagh> pknirsch: That becomes a trademark issue for the Board to deal with
15:30:04 <pknirsch> (getting a bit off topic here *bit*) ;)
15:30:08 <pknirsch> true
15:30:09 <sghosh> pknirsch what sgallagh  said
15:30:32 <Viking-Ice> pknirsch, think of it this way installing the distribution, booting the distribution and ensure that it provides login prompt and working network connection are what we do, what it's called is irrelevant
15:30:34 <pknirsch> ok, lets get back to topic then
15:30:37 <sgallagh> anaconda is a dependency of Fedora. It's not Fedora
15:30:37 <sgallagh> Anaconda can be used by other distros (and *is*)
15:30:48 <Viking-Ice> pknirsch, our release criteria is non spesific for that reason
15:30:48 <sgallagh> Viking-Ice: +1
15:30:49 <masta> I sense that Anaconda is a pain point for QA and if we can isolate (or eliminate) the volatility of Anaconda, QA would be free to expand into more tasks (for the WGs)
15:31:26 <masta> perhaps we should invite the Anaconda people to this meeting and have a chat about things?
15:31:33 <mclasen> sgallagh: I don't think a 'there can only be one installer' rule is compatible with defining multiple products
15:31:33 <pknirsch> Viking-Ice: good summary, +1
15:31:49 <Viking-Ice> masta, and to do so you need to put coreOS and Anaconda on the same release cycle different one then rest of the moving parts
15:32:07 <tflink> masta: true, we spend a lot of time testing anaconda but it's one of the few packages which don't get upstream testing elsewhere
15:32:07 <masta> Viking-Ice: seems logical
15:32:31 <pknirsch> tflink: yea. if installation doesn't work, you got nothing ;)
15:32:53 <masta> seems like anaconda needs continuous QA, separate from the release cycle.
15:32:53 <mclasen> sgallagh: it perpetuates the broken situation we have now, where anaconda needs to serve every crazy use case, and ends up serving none
15:32:56 <tflink> so comparing the amount of time that Fedora QA spends on Anaconda vs ... the kernel (for example), isn't quite an apples-to-apples comparison
15:33:02 <sgallagh> mclasen: Can you state an example where a different installer would be necessary? (Also I was thinking "one installer per deployment need", since cloud images or ARM64 images might not use it at all)
15:33:10 <sghosh> mclasen think of it as a constraint while the new procesess are being matured. we can always revisit it
15:33:25 <sgallagh> mclasen: I'm not saying we can't have *layered* installers, though
15:33:33 <Viking-Ice> what amazes me most about anaconda how is much churnover the installer takes for an installer it's quite frankly unbelivable it's like they get paid to rewrite the thing every 3 release cycles
15:33:45 <sgallagh> as in "Anaconda puts the basic system on the disk, now use the GNOMEInstaller to add those bits atop it"
15:33:46 <jreznik> tflink: I hope that anaconda testing part is going to change soon
15:33:55 <mclasen> sghosh: you can't build something new on broken foundations and say 'we'll redo the foundations later'
15:34:10 <tflink> Viking-Ice: that's a bit hyperbolic, no?
15:34:12 <pknirsch> mclasen: i strongly object to anaconda being broken, sorry
15:34:17 <sghosh> mclasen I would rather see a set of needs for the installer, and see if the common tools - anaconda currently, can support them
15:34:22 <sgallagh> mclasen: Or in the Server group we're talking about a potential API to deploy server roles atop the base system
15:34:34 <Viking-Ice> sgallagh, your assuming the community will settle on Gnome as the ( one and only ) workstation desktop
15:34:39 <Viking-Ice> I think that's a bit premature
15:34:42 <mclasen> pknirsch: whats broken is the idea that a single install UX will work for clients and servers
15:34:47 <sgallagh> Viking-Ice: It was an example, not an exclusive statement
15:34:55 <jreznik> we're bit OT now and spent quite a lot of time now...
15:35:03 * notting is not sure that discussing the mechanisms or function of anaconda development is the best use of the time righ tnow
15:35:16 <jreznik> notting: yep
15:35:17 <tflink> notting: agreed
15:35:18 <pknirsch> mclasen: whats why anaconda now provides the possibility to have different spokes and UI elements
15:35:22 <pknirsch> aye
15:35:25 <Viking-Ice> mclasen, +1
15:35:29 <pknirsch> lets get back to our original topic
15:35:36 <pknirsch> QA involvement
15:35:56 <pknirsch> so can we agree that QE will revisit this post Fedora 20 GA
15:35:56 <sghosh> mclasen single install UX vs single tool set - may be solvable without different installers
15:35:56 <pknirsch> ?
15:36:05 <mclasen> pknirsch: I'd rather replace the whole frontend, but I will back off now, lets discuss this when anaconda people are actually in the room
15:36:06 <tflink> pknirsch: what exactly are you looking for? someone to show up for meetings ang generally be involved in discussions?
15:36:43 <pknirsch> tflink: yep, something like that. just someone from QA who's here and can give input or join the discussion when they see the need for it
15:37:05 <tflink> have you guys settled on this time as a regular meeting time?
15:37:16 <sghosh> pknirsch  ok - lets defer the QA participation till after F20GA
15:37:17 <pknirsch> as i don't know much about the constraints and processes of QA this might become more relevant in the weeks to come
15:37:26 <pknirsch> tflink: yes
15:37:33 <jreznik> tflink: yep
15:37:50 <masta> #info QA representatives have expressed some frustration, particularly around the Anaconda installer, and the ever expanding scope of QA.
15:38:02 <jreznik> and we can always ping qa guys when needed
15:38:03 <masta> ok I say we move on
15:38:26 <tflink> I'll try to make it but I suspect that the time is going to be a minor problem for the rest of the year
15:38:31 <jreznik> there's just one warning - let's don't forget about other team than just devel (as we used to do so ;-)
15:38:33 <pknirsch> alright
15:38:33 <tflink> time for other regular qa folks
15:38:36 <sghosh> Regarding the base features - is anyone looking to document what features are included in the base, or presented by the base for use by other teams?
15:38:38 <mclasen> sgosh: I would be more than happy if we could have a frontend/backend separation in anaconda that could be used here
15:38:50 <pknirsch> sghosh: not the topic right now, thats later
15:39:11 <pknirsch> #info QE will revisit and discuss more involvement post Fedora 20 GA
15:39:17 <sghosh> mclasen agree - lets discuss that and write up a proposal for the base team
15:39:27 <masta> sghosh: I think that is one of the on going tasks, to define the deliverable of Base.
15:39:39 <pknirsch> next topic:
15:39:51 <pknirsch> #topic Liaison for FESCO? Volunteers?
15:39:54 <jreznik> masta: and we also need input from other WGs to do so... chicken egg problem
15:39:57 <pknirsch> seems that was already decided :)
15:39:59 <masta> we are all still forming opinions of the base idea, and persuading others what the idea should be.
15:40:21 <pknirsch> #info pknirsch official FESCO liason for the time being
15:40:24 <masta> I liked the idea of providing APIs
15:40:27 <pknirsch> at least thats what jwb told me ;P
15:40:38 <pknirsch> masta: we're getting to that topic soon
15:40:38 <sghosh> masta - anything being written up so we can track feedback?
15:41:09 <jreznik> pknirsch: that was that deal with fesco :) but of course, I think every one here can help you
15:41:11 <pknirsch> can we please stay on the topics at hand?
15:41:19 <pknirsch> thank you
15:41:29 <masta> sghosh: good idea, these irc logs are a good start, but we probably need a wiki or something.... anything
15:41:45 <pknirsch> next up:
15:41:56 <pknirsch> #topic Mission statement
15:42:15 <pknirsch> based on our last weeks meeting i've tried to put something together:
15:42:32 <pknirsch> https://fedoraproject.org/wiki/Base
15:42:38 <pknirsch> The goal of Fedora Base is to provide a standard platform with common technologies, frameworks and APIs for all Fedora products.
15:42:49 <pknirsch> it's a bit brief and wishy washy
15:43:00 <pknirsch> so any improvements without overblowing it are very welcome
15:43:44 <halfline> i'd suggest the mission of the base design working group should be to deduplicate effort between the other working groups. extract the commonality
15:43:46 <pknirsch> i've added a 2 more sections there as well with what Base is and what Base is not.
15:43:46 <dwalsh> Maybe add the word minimal
15:43:51 <halfline> but not set the direction of the other working groups
15:43:59 <halfline> or enforce a required platform
15:44:00 <sghosh> -- to provide a core runtime platform  and a foundation for platform level services
15:44:42 <pknirsch> halfie: thats what i mean with common technologies, frameworks and APIs
15:44:53 <pknirsch> just differently worded
15:44:59 <halfline> great
15:45:00 <pknirsch> halfline: ^^
15:45:04 <notting> pknirsch: disagree some on the 'is not'. it makes an implication that base *might* even be something that can be installed. i would argue it probably isn't, at least not by end users
15:45:10 <masta> halfie: while I like the deduplicate  idea... there has to be a boundary, I'd like base to be reasonably small enough for the embedded case.
15:45:22 <pknirsch> notting: good point. feel free to add that
15:45:29 <tflink> if base isn't a full product, will it include the/an installation mechanism?
15:45:43 <Viking-Ice> I would think not
15:45:57 <jreznik> notting: I'm not sure we decided it's installeble or not last time but I recall it was more towards installable minimal system
15:46:01 <notting> i.e., if the idea is that there are three products (cloud, workstation*, and server), i'm not sure having base as a product/installable thing makes sense
15:46:09 <sgallagh> tflink: I've been saying that it should *provide* the installation mechanism, but not necessarily inherently consume it
15:46:21 <pknirsch> ye, thats why i was heavily arguing about anaconda earlier
15:46:28 <Viking-Ice> sgallagh, +1
15:46:42 * pknirsch nods
15:47:13 * notting does have a stop at the top of the hour
15:47:16 <tflink> I guess I'm a little confused as to the scope of what would need to be tested for base
15:47:42 <Viking-Ice> tflink, ?
15:47:43 <jreznik> another question - what everything belongs to Base - everything that could be common for other products? or is it limited, and if limited - where this stuff in-between belongs?
15:47:47 <sgallagh> tflink: I would think that you'd probably test Base in the context of the other three products.
15:48:04 <sgallagh> i.e. have a set of Base tests that all three products have to pass
15:48:14 <Viking-Ice> we need to test kernel,dracut,systemd etc and them as a group
15:48:26 <tflink> ok, that makes sense. I was thinking of the WG as more of a separate product
15:48:30 <sghosh> note: we should look to include different runtime prossibilites under installation capability - NFS root, stateless, image, etc
15:48:36 * tflink has some reading and thread catching-up to do
15:48:36 <haraldh> well you could test Base with only Base
15:48:43 <Viking-Ice> right
15:48:55 <masta> sghosh: +1
15:48:56 <pknirsch> but that would mean Base is installable
15:49:00 <sgallagh> haraldh: That assumes Base is installable
15:49:03 <pknirsch> haha
15:49:08 <notting> to maybe phrase i differently - the initial description of the WG was base *design* - would be leery about framing it about a base product. so, the things provided by systemd is part of the base design, and ssystemd can be the blessed implementation of the design, and built on a schedule... but i wouldn't treat systemd as a product, more as a deliverable to the other products?
15:49:08 <haraldh> isn't it?
15:49:21 <haraldh> anaconda + base should give an install
15:49:26 <sgallagh> haraldh: That's not yet decided. Some of us argue that it doesn't necessarily have to be
15:49:30 <haraldh> and should boot to console
15:49:33 <Viking-Ice> sghosh, I dont think both iscsi and nfs belong with the core/baseOS
15:49:40 <sgallagh> haraldh: That's not settled yet
15:49:45 <Viking-Ice> it's something that more likely belongs with serverWG
15:49:47 <pknirsch> notting: right, thats why i specified technologies, frameworks and APIs there
15:49:57 <haraldh> so, you mean, the minimal install does not give a tty?
15:49:58 <sghosh> Viking-Ice clients should
15:50:00 <halfline> i mean anaconda shouldn't be part of base if anaconda isn't going to be used by cloud or some future embedded working group
15:50:06 <wwoods> the installer can install a "base" image without that image needing to include the installer
15:50:19 <Viking-Ice> sghosh, in the case of nfs the server as well
15:50:34 <halfline> if parts of anaconda are used by all of them, then the parts that are would be a good example of what should go into base
15:50:36 <jreznik> wwoods: yep
15:50:39 <tflink> and you can do stuff like chroot "installs" w/ yum/dnf
15:50:45 <halfline> (say cloud image uses kickstart libraries or something)
15:50:46 <wwoods> don't confuse "installable" with "contains the installer and its dependencies"
15:50:57 <wwoods> the installer is a specialized Live image
15:50:59 <haraldh> wwoods, exactly
15:51:03 <wwoods> that's used for installing *other* images
15:51:07 <pknirsch> mhm
15:51:11 <pknirsch> good point wwoods
15:51:19 <wwoods> it's basically its own 'spin'
15:51:34 <notting> halfline: to describe it differently - anaconda includes a thing that takes a system definition (kickstart) and turns that into a runnable object (image). i'm fine with 'a mechanism to take a system definition and turn it into a runnable image' being part of a base design
15:52:00 <Viking-Ice> notting, +1 sounds good
15:52:16 <haraldh> installing Base should boot successfully... like with dnf groupinstall base in a chroot and then call systemd-nspawn
15:52:17 <wwoods> ...so does that mean that devel stuff (gcc etc.) is also in Base?
15:52:23 <pknirsch> notting: with out current choice being anaconda for Base?
15:52:47 <notting> (and i could have sworn i saw patches float by the anaconda list that more clearly separate the packaging and delivery re: TUI, GUI, and <part that does stuff>'
15:53:00 <Viking-Ice> pknirsch, I read as notting put it not limited to Anaconda ;)
15:53:06 <wwoods> because you need the development tools to *build* base, so by the same logic, you'd need them *in* base, right?
15:53:11 <sgallagh> notting: +1 to that definition.
15:53:12 <pknirsch> Viking-Ice: thats why i said "current choice"
15:53:37 <wwoods> I really think "the installer" is a separate clump of things (which also builds on Base)
15:53:40 <Viking-Ice> pknirsch, at this point in time there is but one choice
15:53:42 <sgallagh> wwoods: That's a different question: "Is Base self-hosting?"
15:53:58 <wwoods> yes. and my assumption is that you've already decided it isn't?
15:54:05 <sgallagh> It's arguable that Base should be built by a toolkit provided elsewhere
15:54:06 <wwoods> and if it's not self-hosting, why does it need to be self-installing?
15:54:19 <wwoods> then it can also be installed by a toolkit provided elsewhere.
15:54:21 <sgallagh> wwoods: No, I haven't decided that
15:54:32 <pknirsch> s/i/we/
15:54:33 <pknirsch> :)
15:54:35 <pknirsch> nitpicker
15:54:39 <sgallagh> fair
15:54:49 <wwoods> I'm saying that these are parallel questions; your answers to those two questions should probably be the same thing
15:55:04 <masta> I would argue base should include the iscsi initiator utils, and be able to boot nfs roots. (have a complete storage stack)
15:55:08 <pknirsch> not necessarily, wwoods
15:55:16 <pknirsch> both are in a larger sense tools
15:55:18 <sgallagh> wwoods: Well, my suggestion above was that Base shouldn't be directly installable, only as part of one of the Products
15:55:29 <sgallagh> Otherwise, it's effectively a fourth product on its own
15:55:29 <wwoods> sgallagh: you're conflating "installable" and "contains the installer"
15:55:32 <pknirsch> you can use different hammers just as you can use different screwdrivers
15:55:35 <masta> I'd say we should pick one of the process containment things... maybe nspawn
15:55:40 <notting> sgallagh: anything is arguable. :)   but i'd be curious whether having (as an example) different major versions of gcc to build different products makes sense
15:55:40 <haraldh> the most minimal install without anaconda can be to just install the rpms in a chroot and start a systemd-nspawn container on that :-) ... and that would be self-installing :)
15:55:41 <sgallagh> wwoods: Ok
15:56:01 <pknirsch> #info Drifting into PRD right now ;)
15:56:06 <pknirsch> #topic PRD
15:56:29 <Viking-Ice> masta, that means it would be installed *everywhere*
15:56:31 <pknirsch> notting: or LLVM :)
15:56:46 <pknirsch> Fedora built with LLVM
15:56:47 <wwoods> sgallagh: you're saying that otherwise the installer is a fourth product on its own?
15:57:08 <wwoods> because the installer is (and has always been) a separate, embedded mini-distro
15:57:20 <pknirsch> mkinitrd hell
15:57:20 <pknirsch> :)
15:57:35 <pjones> pffft.
15:57:40 <pknirsch> sorry pjones ;)
15:57:41 <masta> Viking-Ice: yep, is that bad thing?
15:57:51 <Viking-Ice> masta, yes
15:58:09 <sgallagh> wwoods: Ok, perhaps we can agree that "capable of being installable" and "publicized and shipped as installable" are different things?
15:58:21 <pjones> sgallagh: that would be better, yes.
15:58:37 <notting> the fedora product construction set
15:58:48 <jreznik> sgallagh: yep
15:58:51 <sgallagh> notting: Isn't that pretty much Fedora today?
15:58:58 <pknirsch> no
16:00:05 <sgallagh> pknirsch: To what are you replying?
16:00:12 * jreznik has to end
16:00:20 <wwoods> sgallagh: anyway, I don't want to derail the conversation any further, just trying to point out that the installer *is* a separate tool/spin/group, which includes the traditional base/core stuff
16:00:47 <wwoods> you can define "base" to include the installer, but I wouldn't recommend it.
16:00:53 <sghosh> q - process beyond the irc mtg for documenting?
16:00:57 <masta> wwoods: I kinda like the idea of the installer as a spin, which happens to include base
16:01:13 <pknirsch> sgallagh: i don't belive fedora to be that much of a construction kit today. otherwise much more people and/or communities or projects would have picked it up as flexible easy and usable for their own products
16:01:28 <Viking-Ice> core and base are not the same thing right or are you guys viewing it as one?
16:01:39 <sgallagh> pknirsch: I didn't say it was a "good" construction kit. It's a box full of legos without an instruction manual.
16:01:56 <pknirsch> sghosh, jreznik: as usually we're logging the meeting and will post the minutes and logs after the end to fedora-devel
16:01:59 <masta> Viking-Ice: It seems that base > minimal
16:02:21 <jreznik> pknirsch: let's try to take a look on other projects that do similar job as base aka mer (I don't follow it much anymore...)
16:02:32 <Viking-Ice> masta, ok for me minimal equals core and WG' s provide their own base on top of it
16:02:47 <wwoods> masta: that's what it is. an installer "image" (e.g. DVD) contains the installer LiveOS image; the purpose of the spin is to find the RPM payload (on the DVD, on a mirror, etc.) and install it to the local system
16:03:31 <pknirsch> wwoods: but that rightfully brings up the question of a own "product" for Anaconda then
16:04:17 <Viking-Ice> pknirsch, which in turns means own product for every installer that Fedora might use in the near or distant future
16:04:24 <wwoods> indeed. but I said I didn't want to derail this further.
16:04:39 <masta> wwoods: alright, then I will hence forth consider anaconda a spin
16:05:06 <pknirsch> which would pave the way to having other installer products...
16:05:14 <pknirsch> but i'm derailing here
16:05:27 <wwoods> it's a conversation worth having.. another time, though
16:05:32 <pknirsch> right
16:05:37 <haraldh> +1
16:05:52 <pknirsch> ok, lets go to the last topic quickly, release schedules
16:06:01 <pknirsch> #topic Schedule and alignment with other WGs
16:06:01 <pknirsch> (https://fedorahosted.org/fesco/ticket/1202)
16:06:25 <pknirsch> thats the FESCO ticket that is currently open where this is being discussed
16:07:41 <pknirsch> Especially as quite a few WGs have already started discussing that on their own but having global consenquences for Base and other WGs and teams (e.g. QA)
16:08:05 <Viking-Ice> I dont know why people say thatś problem for QA
16:08:40 <jreznik> Viking-Ice: wouldn't it be a problem for QA in case release would happen every single month?
16:08:57 <pknirsch> and if every release had to be tested?
16:08:59 <masta> I would imagine that Base is the lowest common denominator in terms of release, and there should be a cadence ... perhaps align on 3, 6, 12, 18 month cycles... stuff like that
16:09:01 <tflink> not to mention the current concept of a blocker process
16:09:06 * pknirsch nods
16:09:12 <sghosh> pknirsch would be good for the wg fesco reps to meet and sync back to the teams
16:09:23 <Viking-Ice> jreznik,  before the latest RH QA got hired we there was one vision to start managing and test things on comps group level
16:09:27 <haraldh> here is proposal: one release every 9 months: https://fedoraproject.org/wiki/User:Harald/base-schedule
16:09:27 <pknirsch> sghosh: i was planing on doing that, yes
16:09:41 <pknirsch> haraldh: add it to the ticket ;)
16:09:53 <haraldh> we can talk about it before
16:10:12 <haraldh> it could be improved, discussed first
16:10:16 <masta> meaning if the Workstation group wants to stay at 6 months, server goes with 18 months, and cloud goes with 3 months... then Base needs to be on a 3 month cycle. The lowest common denominator
16:10:22 <jreznik> masta: yep, defined windows we can release, on demand
16:10:26 <Viking-Ice> haraldh, why this route why not rebasable platform based on the kernel release cycle?
16:10:53 <haraldh> because "rebasing" means mostly change
16:10:59 <pknirsch> masta: yep, which might be a huge Pain in your back :)
16:11:06 <masta> pknirsch: yes
16:11:07 <jreznik> it's the question if in 3 month any development that makes sense can happen...
16:11:08 <haraldh> not everything has such a stable API/ABI as the kernel
16:11:09 <sghosh> masta not necessarily  -a relase will always exist - it can be used.
16:11:54 <jreznik> so cloud can release every three months but using older base + newer cloud stuff
16:11:59 <dwalsh> Multiple other releases could happen on the same base.
16:12:09 <sghosh> jreznik - yes
16:12:21 <Viking-Ice> haraldh, yes I know that however we can manage QA the entire FOS platform as such and longer release cycle can be maintained based on the kernel stable release
16:12:32 <pknirsch> so
16:12:57 <pknirsch> who is going to support multiple base releases every 3 months then for 24 months for some products?
16:13:17 <pknirsch> (which would be 8 releases in parallel)
16:13:36 <masta> for now a 6 month cycle is survivable, if base is easily release & QA... it can perhaps be more rapid
16:13:36 <pknirsch> if every WG would be allowed to choose their lifetime & base release they want
16:14:00 <sghosh> pknirsch idont think we have any consensus for 3 month cycle
16:14:08 <pknirsch> even if it's 6
16:14:15 <jreznik> masta: six months is pretty good compromise to get things done and if not done, there are only 6 months delay (to finish it)
16:14:19 <pknirsch> thats still 4 parallel supported releases
16:14:36 <jreznik> pknirsch: does not have to be
16:14:54 <sghosh> pknrish - might b better to first discuss devel and release and see if we can separate those - and then rlease and support cadence
16:15:24 <tflink> depending on the scope of base, it is something that could likely be mostly automated from a qa perspective
16:15:39 <masta> tflink: that would be great
16:15:40 <Viking-Ice> serverWG release cycle is depended on each role I would say with the exception of FOSSP the server base itself which we could decide
16:15:43 <jreznik> sghosh: agreed
16:15:46 <pknirsch> sure, i just wanted to make sure that everyone understands we can't realistically support more than 1 release at the same time. we neither have the time nor people to do so
16:16:04 <pknirsch> especially the later actually
16:16:18 <sghosh> 15 after the hr
16:16:31 * pknirsch nods
16:16:51 <pknirsch> feel free to share your thoughts and ideas in the FESCO ticket.
16:16:57 <Viking-Ice> pknirsch, so short rebasable platform makes sense right which in turn make sense basing that platform on the kernel release cycle...
16:17:33 <Viking-Ice> one "active" at a time
16:17:39 <pknirsch> Viking-Ice: it's something i proposed to be investigated: If it's reasonable to do Base releases based on kernel releases
16:17:46 <tflink> well, what is a release? is it a set of APIs and ABIs which are guaranteed stable for X period of time? what about doing something like an LTS strategy where only some releases were supported for longer than 3 months (assuming 3month cadence)?
16:18:12 <pknirsch> tflink: and anything else would be good will?
16:18:22 <pknirsch> or best effort?
16:18:26 <sghosh> tflink agree - schedule without content definitions is backwards
16:18:54 <masta> I kinda like the idea of following kernel release cycle
16:18:56 <tflink> pknirsch: cherry pick the releases that were supported for use in server/workstation/etc and supported longer
16:19:16 <tflink> just an idea to reduce the number of concurrently supported "releases"
16:19:31 <pknirsch> tflink: thats already 2 products which might want different Base release to be "long term"
16:20:13 <tflink> so take it a bit farther and say that specific releases will be supported for X period of time and force them to choose
16:20:19 * pknirsch nods
16:20:28 <pknirsch> that would be some suggestion for the ticket imho
16:20:43 <pknirsch> a bit like spot's idea of 20.0 20.1 20.2 20.3 21.0 etc
16:21:08 <pknirsch> and iirc haraldh's proposal is quite similar
16:21:53 <pknirsch> #info Participation in https://fedorahosted.org/fesco/ticket/1202 for further release cycle discussion
16:22:05 <pknirsch> lets do a quick open floor
16:22:08 <pknirsch> #topic Open Floor
16:22:23 <pknirsch> ok, anything else to bring up?
16:22:32 <sghosh> online collab space for proposls and comments
16:22:43 <dwalsh> What about docker containers?  Should base define what goes into a docker container?
16:22:44 <pknirsch> fedora wiki?
16:22:53 <dwalsh> docker container base.
16:23:19 <pknirsch> i don't think base should decide about content, rather about technology
16:23:20 <dwalsh> Or can we tell packagers to stop requiring things like the kernel or systemd?
16:23:45 <dwalsh> Right now httpd requires systemd in order to install its unit file.
16:23:51 <sghosh> dwalsh lets put that on the list/wiki
16:23:58 * pknirsch nods
16:24:01 <dwalsh> This sucks in systemd. which is not needed in a docker container.
16:24:14 <pknirsch> feel free to add those to the https://fedoraproject.org/wiki/Base
16:24:19 <pknirsch> just add a secion there
16:24:22 <pknirsch> or make a sub dir
16:24:24 <dwalsh> rpm -q --whatrequires kernel
16:24:25 <dwalsh> lldpad-0.9.46-3.fc20.x86_64
16:24:25 <dwalsh> sysprof-1.2.0-4.fc20.x86_64
16:24:25 <dwalsh> pulseaudio-4.0-8.gitf81e3.fc21.x86_64
16:24:25 <dwalsh> libseccomp-2.1.1-0.fc21.x86_64
16:24:25 <dwalsh> libguestfs-1.25.7-1.fc21.x86_64
16:24:27 <dwalsh> systemtap-devel-2.4-1.fc21.x86_64
16:24:29 <dwalsh> autofs-5.0.8-3.fc21.x86_64
16:24:31 <dwalsh> systemtap-runtime-2.4-1.fc21.x86_64
16:24:37 <pknirsch> mhm
16:24:42 <dwalsh> I don't think these packages actually require the kernel.
16:24:47 <mclasen> dwalsh: sounds like packaging guideline material
16:24:49 <pknirsch> feels a bit backward to require kernel anywhere
16:24:54 * mclasen will have additions for that from the workstation side as well
16:25:04 <haraldh> we should remove the rule "require the package, which owns the directory"
16:25:19 <haraldh> perhaps it was resulting from this
16:25:50 <haraldh> and of course %post and %pre scripts
16:26:05 <pknirsch> volunteers for that cleanup welcome :)
16:26:51 <dwalsh> Another idea is should base require a minimal language and then require rpm to be able to install new languages.
16:26:54 <mclasen> may be worthwhile to make a distinction here between packages that are part of a product and the wider universe
16:27:27 <mclasen> that vastly reduces the amount of needed volunteer time
16:27:44 <dwalsh> Can we get requirements into rpm/yum to handle this in a sane way.
16:27:50 <pknirsch> thats why i'd love to have Base as small as possible to be honest
16:28:06 <pknirsch> which would make it much easier to clean that up
16:28:07 <sghosh> mclasen absolutely
16:28:18 * pknirsch nods
16:28:57 <pknirsch> and as masta already mentioned, if we envision an embedded product they probably wouldn't want X11 or anything like that in base :)
16:29:02 <pknirsch> or in their minimal system
16:29:30 <haraldh> you want to swap X11 for wayland anyway :)
16:29:45 <pknirsch> no graphics kkthxbye ;)
16:29:50 <pknirsch> text console!
16:29:56 <haraldh> kmscon
16:30:09 <pknirsch> s/kmscon/con/ ;)
16:30:16 <rwmjones> dwalsh: libguestfs does require the kernel
16:30:55 <masta> =)
16:31:23 <sghosh> need to run to another mtg
16:31:31 <dwalsh> rwmjones, You will get a kernel, not sure why it is required at the package level.
16:32:02 <pknirsch> ok, lets close the official part of the meeting then for today with people drifting away.
16:32:09 <rwmjones> not sure what the problem is, but the Requires: kernel is expressing an actual need of the libguestfs package, so ..
16:32:18 <pknirsch> Thanks everyone for joining today, next meeting same place/time/day next week!
16:32:20 <masta> pknirsch: +1 close
16:32:25 <masta> thanks pknirsch
16:32:27 <masta> thanks all
16:32:29 <pknirsch> #endmeeting