15:01:01 #startmeeting Fedora Base Design Working Group (2013-11-15) 15:01:01 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:17 #meetingname Fedora Base Design Working Group 15:01:17 The meeting name has been set to 'fedora_base_design_working_group' 15:01:26 hola 15:01:31 hello and welcome to our second meeting everyone! 15:01:36 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 so we got dgilmore and notting so far (and sgallagh lurking) 15:02:11 ha jreznik ! 15:02:18 #chair dgilmore notting jreznik 15:02:18 Current chairs: dgilmore jreznik notting pknirsch 15:02:51 * masta looks in 15:02:54 hello 15:02:56 lets see, we're missing masta, haraldh, jwb 15:03:03 and dwalsh 15:03:11 <- 15:03:18 #chair maste haraldh 15:03:18 Current chairs: dgilmore haraldh jreznik maste notting pknirsch 15:04:03 oh, and subhendu, but he mentioned he'd be late as he's got a conflict meeting today 15:04:34 pknirsch: who is maste? 15:04:43 erh 15:04:52 darn autocomplete 15:04:56 #chair masta 15:04:56 Current chairs: dgilmore haraldh jreznik masta maste notting pknirsch 15:05:04 can i dechair someone? ;) 15:05:13 #chair maste 15:05:13 Current chairs: dgilmore haraldh jreznik masta maste notting pknirsch 15:05:19 #chair -maste 15:05:19 Current chairs: -maste dgilmore haraldh jreznik masta maste notting pknirsch 15:05:23 doh 15:05:26 ah well 15:05:36 #help 15:05:40 #help 15:05:46 bahh 15:06:32 lets get started 15:06:58 meeting agenda for today: https://lists.fedoraproject.org/pipermail/devel/2013-November/192007.html 15:07:05 #info Meeting agenda: https://lists.fedoraproject.org/pipermail/devel/2013-November/192007.html 15:07:35 As we got an open floor today, if you have anything to add we can cover that at the end then 15:07:54 or if you have something that should be discussed earlier, just chime in and we'll cover that 15:08:18 ok, so lets start with the first topic for today then: 15:08:26 #topic QE representation 15:08:44 i already wanted to bring that up last week, but it slipped my mind before i sent out the agenda 15:09:20 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 we should see if tflink adamw want to be involved 15:09:29 * pknirsch nods 15:09:36 of if they would rather one of use go to them when needed 15:09:38 i'm all for having QE around 15:09:57 id rather have someone from QA involved 15:09:59 why them 15:10:08 would be great to have more lurkers 15:10:14 Viking-Ice: because they are who i thought of off teh top of my head 15:10:22 and were in here 15:10:24 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 i also thought of robitno but he is not here 15:10:38 it's always a bad time for QA then, jreznik :) 15:11:03 but ye, i'm open to any suggestions here. Who would be on your mind, Viking-Ice ? 15:11:29 pknirsch, beside me you mean ;) 15:11:31 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 ;) 15:12:06 #info To all QA team members: please feel free to participate in the Base WG discussion on IRC :-) 15:12:36 looks like we have some here 15:12:41 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 in anycase this is far from involving qa at this point 15:12:53 true 15:12:56 pknirsch: indeed 15:13:03 WG's are still trying to find mutual ground to work on 15:13:17 Viking-Ice: well, I'm not sure it's too far... 15:13:44 but you're right, no immediate action is needed 15:13:44 aye, but that can already be a point where QE has very valid points why some things are good or bad 15:13:53 even without real actions to act on 15:13:57 Viking-Ice: just like releng needs to be involved now so does QA 15:13:58 * jreznik is experiencing network issues... 15:14:09 there is not things to be done 15:14:16 pknirsch, in Fedora we have QA in RH you have QE's 15:14:19 but they need to know whats coming to make plans 15:14:35 Are we looking for a semi-formal liaison type thing from QA? 15:14:40 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 exactly dgilmore 15:14:49 dgilmore, not really one release cycle means things stay the same 15:14:53 for WG's 15:15:02 Viking-Ice: wrong attitude sorry 15:15:21 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 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 jreznik: indeed 15:16:25 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 and try to assist them in the process 15:16:46 which will have QA people 15:16:48 right? 15:16:56 from the overall QA body i suspect 15:17:09 pknirsch, not unless someone volunteers to do that from the QA community 15:17:28 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 good points, ye 15:18:05 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 jreznik who is blocked? 15:18:30 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 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 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 jreznik: that came up this week already 15:19:08 (sorry for that double time :D) 15:19:28 tflink: :) welcome 15:19:32 welcome ;) 15:19:37 tflink: so whats the thoughts? 15:19:59 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 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 mhm 15:20:28 fair enough 15:20:43 so shall we postpone this then to a later date, tflink ? 15:20:53 like, post F20 GA? 15:21:10 post F20 GA sounds fine 15:21:13 I have been sitting on #fedora-base sorry for being late. 15:21:22 #chair dwalsh 15:21:22 Current chairs: -maste dgilmore dwalsh haraldh jreznik masta maste notting pknirsch 15:21:22 I suspect that we'd all rather figure this out before the WG output is due 15:21:31 jep 15:21:41 tflink, we need to figure out the direction first 15:21:45 but I think post F20 GA is more likely 15:22:09 we also need to figure out what can be done about Anaconda ( our most time consuming customer ) 15:22:37 Viking-Ice: it's what's other WGs are working too 15:22:49 jreznik, what do you mean 15:23:08 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 but thats just my $0.02 to this 15:23:17 Viking-Ice: for example Workstation WG would like to define their's own installer... 15:23:35 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 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 mclasen, we dont have resources to do sub community qa stuff 15:24:18 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 jreznik agree with Viking-Ice - one anacaonda 15:25:02 base and the installer dont have to worry about QA it comes with our territory to take care of that 15:25:03 masta: exactly my thoughts but better formulated ;) 15:25:24 mclasen: right 15:25:25 I'm still not clear on what the base WG is looking for from QA? 15:25:36 Yes, one anaconda, please. 15:25:41 Different spokes and maybe a fresh coat of paint on the GUI, but same tools under the hood, please. 15:25:51 sgallagh: it was just example 15:26:13 jreznik painful example 15:26:15 sgallagh: isn't that up to the WGs though? not saying it is or should 15:26:21 tflink, from the sound of it QA their outcome for them 15:26:24 and sghosh 15:26:28 someone to show up and participate in the process? 15:26:31 tflink, blank check on QA resources 15:26:44 Viking-Ice: I could be missing something, but that's not how I'm reading it 15:26:44 to dedicate to the outcomes of the WG's 15:26:54 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 pknirsch: I think anaconda is pretty clearly in your Base camp 15:27:18 sgallagh, yep I think so ot 15:27:18 pknirsch I would rather see requirements from other WG on base, than independent toolsets 15:27:19 mean to 15:27:26 The overhead of not sharing it would likely be insurmountable 15:27:45 At that point we might as well just launch separate distros and give up 15:27:53 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 pknirsch, alternative installer option means just more works for QA ;) 15:28:30 but anaconda does now own Fedora 15:28:34 Viking-Ice: sure, but if that group would do all the QA itself? 15:28:38 sgallagh: how it gets installed is an integral part of the product 15:28:45 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 pknirsch downstream - as in respins - are indepedent of fesco 15:28:58 pknirsch, we take care of the installer same way as we take care of networking etc 15:29:04 pknirsch: I think at that point, it's a downstream *distro* and shouldn't be using our infrastructure 15:29:04 basic networking that is 15:29:05 Viking-Ice: right 15:29:33 (brb, moving dishwasher) 15:29:33 sghosh: but what if they'd want to be called something Fedora-ish? Is anaconda == Fedora then? 15:29:52 as thats what it sounds like right now 15:29:56 pknirsch: That becomes a trademark issue for the Board to deal with 15:30:04 (getting a bit off topic here *bit*) ;) 15:30:08 true 15:30:09 pknirsch what sgallagh said 15:30:32 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 ok, lets get back to topic then 15:30:37 anaconda is a dependency of Fedora. It's not Fedora 15:30:37 Anaconda can be used by other distros (and *is*) 15:30:48 pknirsch, our release criteria is non spesific for that reason 15:30:48 Viking-Ice: +1 15:30:49 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 perhaps we should invite the Anaconda people to this meeting and have a chat about things? 15:31:33 sgallagh: I don't think a 'there can only be one installer' rule is compatible with defining multiple products 15:31:33 Viking-Ice: good summary, +1 15:31:49 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 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 Viking-Ice: seems logical 15:32:31 tflink: yea. if installation doesn't work, you got nothing ;) 15:32:53 seems like anaconda needs continuous QA, separate from the release cycle. 15:32:53 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 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 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 mclasen think of it as a constraint while the new procesess are being matured. we can always revisit it 15:33:25 mclasen: I'm not saying we can't have *layered* installers, though 15:33:33 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 as in "Anaconda puts the basic system on the disk, now use the GNOMEInstaller to add those bits atop it" 15:33:46 tflink: I hope that anaconda testing part is going to change soon 15:33:55 sghosh: you can't build something new on broken foundations and say 'we'll redo the foundations later' 15:34:10 Viking-Ice: that's a bit hyperbolic, no? 15:34:12 mclasen: i strongly object to anaconda being broken, sorry 15:34:17 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 mclasen: Or in the Server group we're talking about a potential API to deploy server roles atop the base system 15:34:34 sgallagh, your assuming the community will settle on Gnome as the ( one and only ) workstation desktop 15:34:39 I think that's a bit premature 15:34:42 pknirsch: whats broken is the idea that a single install UX will work for clients and servers 15:34:47 Viking-Ice: It was an example, not an exclusive statement 15:34:55 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 notting: yep 15:35:17 notting: agreed 15:35:18 mclasen: whats why anaconda now provides the possibility to have different spokes and UI elements 15:35:22 aye 15:35:25 mclasen, +1 15:35:29 lets get back to our original topic 15:35:36 QA involvement 15:35:56 so can we agree that QE will revisit this post Fedora 20 GA 15:35:56 mclasen single install UX vs single tool set - may be solvable without different installers 15:35:56 ? 15:36:05 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 pknirsch: what exactly are you looking for? someone to show up for meetings ang generally be involved in discussions? 15:36:43 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 have you guys settled on this time as a regular meeting time? 15:37:16 pknirsch ok - lets defer the QA participation till after F20GA 15:37:17 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 tflink: yes 15:37:33 tflink: yep 15:37:50 #info QA representatives have expressed some frustration, particularly around the Anaconda installer, and the ever expanding scope of QA. 15:38:02 and we can always ping qa guys when needed 15:38:03 ok I say we move on 15:38:26 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 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 alright 15:38:33 time for other regular qa folks 15:38:36 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 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 sghosh: not the topic right now, thats later 15:39:11 #info QE will revisit and discuss more involvement post Fedora 20 GA 15:39:17 mclasen agree - lets discuss that and write up a proposal for the base team 15:39:27 sghosh: I think that is one of the on going tasks, to define the deliverable of Base. 15:39:39 next topic: 15:39:51 #topic Liaison for FESCO? Volunteers? 15:39:54 masta: and we also need input from other WGs to do so... chicken egg problem 15:39:57 seems that was already decided :) 15:39:59 we are all still forming opinions of the base idea, and persuading others what the idea should be. 15:40:21 #info pknirsch official FESCO liason for the time being 15:40:24 I liked the idea of providing APIs 15:40:27 at least thats what jwb told me ;P 15:40:38 masta: we're getting to that topic soon 15:40:38 masta - anything being written up so we can track feedback? 15:41:09 pknirsch: that was that deal with fesco :) but of course, I think every one here can help you 15:41:11 can we please stay on the topics at hand? 15:41:19 thank you 15:41:29 sghosh: good idea, these irc logs are a good start, but we probably need a wiki or something.... anything 15:41:45 next up: 15:41:56 #topic Mission statement 15:42:15 based on our last weeks meeting i've tried to put something together: 15:42:32 https://fedoraproject.org/wiki/Base 15:42:38 The goal of Fedora Base is to provide a standard platform with common technologies, frameworks and APIs for all Fedora products. 15:42:49 it's a bit brief and wishy washy 15:43:00 so any improvements without overblowing it are very welcome 15:43:44 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 i've added a 2 more sections there as well with what Base is and what Base is not. 15:43:46 Maybe add the word minimal 15:43:51 but not set the direction of the other working groups 15:43:59 or enforce a required platform 15:44:00 -- to provide a core runtime platform and a foundation for platform level services 15:44:42 halfie: thats what i mean with common technologies, frameworks and APIs 15:44:53 just differently worded 15:44:59 great 15:45:00 halfline: ^^ 15:45:04 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 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 notting: good point. feel free to add that 15:45:29 if base isn't a full product, will it include the/an installation mechanism? 15:45:43 I would think not 15:45:57 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 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 tflink: I've been saying that it should *provide* the installation mechanism, but not necessarily inherently consume it 15:46:21 ye, thats why i was heavily arguing about anaconda earlier 15:46:28 sgallagh, +1 15:46:42 * pknirsch nods 15:47:13 * notting does have a stop at the top of the hour 15:47:16 I guess I'm a little confused as to the scope of what would need to be tested for base 15:47:42 tflink, ? 15:47:43 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 tflink: I would think that you'd probably test Base in the context of the other three products. 15:48:04 i.e. have a set of Base tests that all three products have to pass 15:48:14 we need to test kernel,dracut,systemd etc and them as a group 15:48:26 ok, that makes sense. I was thinking of the WG as more of a separate product 15:48:30 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 well you could test Base with only Base 15:48:43 right 15:48:55 sghosh: +1 15:48:56 but that would mean Base is installable 15:49:00 haraldh: That assumes Base is installable 15:49:03 haha 15:49:08 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 isn't it? 15:49:21 anaconda + base should give an install 15:49:26 haraldh: That's not yet decided. Some of us argue that it doesn't necessarily have to be 15:49:30 and should boot to console 15:49:33 sghosh, I dont think both iscsi and nfs belong with the core/baseOS 15:49:40 haraldh: That's not settled yet 15:49:45 it's something that more likely belongs with serverWG 15:49:47 notting: right, thats why i specified technologies, frameworks and APIs there 15:49:57 so, you mean, the minimal install does not give a tty? 15:49:58 Viking-Ice clients should 15:50:00 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 the installer can install a "base" image without that image needing to include the installer 15:50:19 sghosh, in the case of nfs the server as well 15:50:34 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 wwoods: yep 15:50:39 and you can do stuff like chroot "installs" w/ yum/dnf 15:50:45 (say cloud image uses kickstart libraries or something) 15:50:46 don't confuse "installable" with "contains the installer and its dependencies" 15:50:57 the installer is a specialized Live image 15:50:59 wwoods, exactly 15:51:03 that's used for installing *other* images 15:51:07 mhm 15:51:11 good point wwoods 15:51:19 it's basically its own 'spin' 15:51:34 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 notting, +1 sounds good 15:52:16 installing Base should boot successfully... like with dnf groupinstall base in a chroot and then call systemd-nspawn 15:52:17 ...so does that mean that devel stuff (gcc etc.) is also in Base? 15:52:23 notting: with out current choice being anaconda for Base? 15:52:47 (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 ' 15:53:00 pknirsch, I read as notting put it not limited to Anaconda ;) 15:53:06 because you need the development tools to *build* base, so by the same logic, you'd need them *in* base, right? 15:53:11 notting: +1 to that definition. 15:53:12 Viking-Ice: thats why i said "current choice" 15:53:37 I really think "the installer" is a separate clump of things (which also builds on Base) 15:53:40 pknirsch, at this point in time there is but one choice 15:53:42 wwoods: That's a different question: "Is Base self-hosting?" 15:53:58 yes. and my assumption is that you've already decided it isn't? 15:54:05 It's arguable that Base should be built by a toolkit provided elsewhere 15:54:06 and if it's not self-hosting, why does it need to be self-installing? 15:54:19 then it can also be installed by a toolkit provided elsewhere. 15:54:21 wwoods: No, I haven't decided that 15:54:32 s/i/we/ 15:54:33 :) 15:54:35 nitpicker 15:54:39 fair 15:54:49 I'm saying that these are parallel questions; your answers to those two questions should probably be the same thing 15:55:04 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 not necessarily, wwoods 15:55:16 both are in a larger sense tools 15:55:18 wwoods: Well, my suggestion above was that Base shouldn't be directly installable, only as part of one of the Products 15:55:29 Otherwise, it's effectively a fourth product on its own 15:55:29 sgallagh: you're conflating "installable" and "contains the installer" 15:55:32 you can use different hammers just as you can use different screwdrivers 15:55:35 I'd say we should pick one of the process containment things... maybe nspawn 15:55:40 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 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 wwoods: Ok 15:56:01 #info Drifting into PRD right now ;) 15:56:06 #topic PRD 15:56:29 masta, that means it would be installed *everywhere* 15:56:31 notting: or LLVM :) 15:56:46 Fedora built with LLVM 15:56:47 sgallagh: you're saying that otherwise the installer is a fourth product on its own? 15:57:08 because the installer is (and has always been) a separate, embedded mini-distro 15:57:20 mkinitrd hell 15:57:20 :) 15:57:35 pffft. 15:57:40 sorry pjones ;) 15:57:41 Viking-Ice: yep, is that bad thing? 15:57:51 masta, yes 15:58:09 wwoods: Ok, perhaps we can agree that "capable of being installable" and "publicized and shipped as installable" are different things? 15:58:21 sgallagh: that would be better, yes. 15:58:37 the fedora product construction set 15:58:48 sgallagh: yep 15:58:51 notting: Isn't that pretty much Fedora today? 15:58:58 no 16:00:05 pknirsch: To what are you replying? 16:00:12 * jreznik has to end 16:00:20 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 you can define "base" to include the installer, but I wouldn't recommend it. 16:00:53 q - process beyond the irc mtg for documenting? 16:00:57 wwoods: I kinda like the idea of the installer as a spin, which happens to include base 16:01:13 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 core and base are not the same thing right or are you guys viewing it as one? 16:01:39 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 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 Viking-Ice: It seems that base > minimal 16:02:21 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 masta, ok for me minimal equals core and WG' s provide their own base on top of it 16:02:47 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 wwoods: but that rightfully brings up the question of a own "product" for Anaconda then 16:04:17 pknirsch, which in turns means own product for every installer that Fedora might use in the near or distant future 16:04:24 indeed. but I said I didn't want to derail this further. 16:04:39 wwoods: alright, then I will hence forth consider anaconda a spin 16:05:06 which would pave the way to having other installer products... 16:05:14 but i'm derailing here 16:05:27 it's a conversation worth having.. another time, though 16:05:32 right 16:05:37 +1 16:05:52 ok, lets go to the last topic quickly, release schedules 16:06:01 #topic Schedule and alignment with other WGs 16:06:01 (https://fedorahosted.org/fesco/ticket/1202) 16:06:25 thats the FESCO ticket that is currently open where this is being discussed 16:07:41 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 I dont know why people say thatś problem for QA 16:08:40 Viking-Ice: wouldn't it be a problem for QA in case release would happen every single month? 16:08:57 and if every release had to be tested? 16:08:59 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 not to mention the current concept of a blocker process 16:09:06 * pknirsch nods 16:09:12 pknirsch would be good for the wg fesco reps to meet and sync back to the teams 16:09:23 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 here is proposal: one release every 9 months: https://fedoraproject.org/wiki/User:Harald/base-schedule 16:09:27 sghosh: i was planing on doing that, yes 16:09:41 haraldh: add it to the ticket ;) 16:09:53