15:00:30 <pknirsch> #startmeeting Fedora Base Design Working Group (2013-11-22)
15:00:30 <zodbot> Meeting started Fri Nov 22 15:00:30 2013 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:42 <pknirsch> #meetingname  Fedora Base Design Working Group
15:00:42 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:00:55 <pknirsch> hello and welcome everyone to our weekly meeting!
15:01:04 <jwb> hi
15:01:05 <pknirsch> who do we have today?
15:01:11 <pknirsch> #chair jwb
15:01:11 <zodbot> Current chairs: jwb pknirsch
15:01:16 <pknirsch> heya jwb :)
15:01:19 <jreznik> hi guys!
15:01:20 * notting is here
15:01:31 <pknirsch> #chair jreznik notting sghosh_
15:01:31 <zodbot> Current chairs: jreznik jwb notting pknirsch sghosh_
15:02:24 <pknirsch> haraldh, dgilmore, masta ?
15:02:49 <pknirsch> dwalsh: ?
15:02:58 <dgilmore> pknirsch: im here
15:03:01 <pknirsch> okidokie
15:03:08 <pknirsch> #chair dgilmore
15:03:08 <zodbot> Current chairs: dgilmore jreznik jwb notting pknirsch sghosh_
15:03:24 <pknirsch> we got 6, so lets get started
15:04:21 <pknirsch> i've sent out the meeting agenda yesterday with just a few topics today as i wanted to give us a bit more time to talk about what Base is and it's relation to other products
15:04:49 <pknirsch> and as sghosh mentioned last week, talking about the specifics more first will be key to defining the release cycle and lifetime
15:04:53 <pknirsch> not the other way round :)
15:04:59 <pknirsch> but first topic:
15:05:04 <pknirsch> #topic - FESCO release cycle decision (common release cylce for all products, need justification and resources to deviate): https://fedorahosted.org/fesco/ticket/1202#comment:12
15:05:05 * masta looks in
15:05:08 <masta> hello
15:05:11 <pknirsch> #chair masta
15:05:11 <zodbot> Current chairs: dgilmore jreznik jwb masta notting pknirsch sghosh_
15:05:14 <pknirsch> hey masta :)
15:05:31 <masta> sry for being late
15:05:31 <dgilmore> pknirsch: i put my thoughts on it into the ticket
15:05:35 <pknirsch> I hope i summarized that relatively correctly, jwb ?
15:05:52 <pknirsch> dgilmore: ok, let me check
15:06:05 <dgilmore> pknirsch: im all for changing the supported length, but products really can not have different releases and support cycles
15:06:24 <jwb> pknirsch, i think so.
15:07:01 * jreznik likes fesco agreement - it let open possibility for the future but based on realistic expectations
15:07:01 <notting> dgilmore: hm. i could see if we commit to support cycle X, a product could chose < X.
15:08:27 <notting> dgilmore: but that still causes update push issues, and implies separate repos (if not exactly streams)
15:08:27 <sgallagh> Product release cycle could also be N * Base Release Cycle.
15:09:07 <dgilmore> notting: right
15:09:08 <sgallagh> I.e. Server might only want to release on ever fourth Base release.
15:09:09 * pknirsch finished reading
15:09:09 <dwalsh> Can N be a fraction?
15:09:15 <dgilmore> notting: its doable but messy and confusing
15:09:17 <jreznik> sgallagh: and if you want shorter, you can release several times with same base platform as we talked last time
15:09:18 <sgallagh> dwalsh: Let's assume integers :)
15:09:26 <sgallagh> jreznik: True enough
15:09:31 <jreznik> dwalsh: last time we said yes
15:09:55 <jreznik> (if I understand what you mean aka 3 month cloud so N=1/2)
15:10:03 <notting> my base (argh) assumption is that we're likely to end up with separate *repos* for the different products, even if they may be sharing separate builds. but i'm willing to see other proposals
15:10:19 <notting> (oof, that's 'sharing the same builds')
15:10:46 <jwb> so Base repo, Server repo, Workstation repo, etc?
15:10:56 <dgilmore> notting: there will be differet repos for each product, with different installer images
15:11:07 <notting> jwb: not convinced base needs a end-user repo
15:11:07 <pknirsch> that brings us back to dgilmores point though, how DO we envision the builds/products to look like in relation to one another?
15:11:08 <sghosh> notting - perhaps a virtual repo, but the package content is one
15:11:12 <sgallagh> Suggestions came up in other forums that base might want to consider a release cycle triggered around the Linux kernel release cycle.
15:11:17 <pknirsch> mhm
15:11:34 <jwb> notting, i'm concerned how we'd do any form of testing on Base without a repo
15:11:39 <sgallagh> jwb: I need to write up a full response on your email about that, but I haven't had a chance yet.
15:11:47 <jreznik> sgallagh: but you should be able to override the content with your custom packages that diverges from base
15:11:48 <sghosh> agree base does not need its own enduser repo
15:11:54 <Viking-Ice> 3 core release per year is what's doable since the kernel is on a 3month-is release cycle and we in QA + other teams ( marketing docs etc ) would have an month to prepare each release
15:11:55 <jwb> sgallagh, about what?  (which email)
15:11:58 <pknirsch> jwb: couldn;t we provide a repo for base, too?
15:12:00 <sgallagh> jreznik: I'm not sure about that
15:12:15 <dgilmore> Viking-Ice: that would be 4 a year
15:12:16 <jwb> pknirsch, that's what i just said and notting said not sure it needs one
15:12:16 <sgallagh> jreznik: If we're overriding Base, then I think we have poorly-identified what "Base" means
15:12:23 <pknirsch> oh
15:12:30 * pknirsch needs to read faster
15:12:33 <jreznik> sgallagh: I understood it as part of that rings plan
15:12:40 <dgilmore> Viking-Ice: which would require we double or tripple resources in releng and QA
15:12:44 <notting> jwb: what i mean is i doubt it needs one that's publicized, on the web site, listed as an instalable thing that someone would run. it may still be a repo somewhere
15:12:52 <sghosh> sgallagh: one case - the installer UI is customized for each product
15:12:53 <sgallagh> jreznik: I've never been fond of that particular part of the plan...
15:12:57 <Viking-Ice> dgilmore, no we utilize the resources better
15:13:18 <dgilmore> Viking-Ice: we do but we have to get there and we have to have constant development
15:13:21 <notting> jwb: but it does depend a lot on how we decide the products fit together
15:13:22 <jwb> notting, oh, sure.  i don't care about that.  i do care about having a repo that people can test with or even base a product on
15:13:23 <sgallagh> sghosh: It's arguable if the installer actually needs to be in Base, since I doubt very much that Fedora Cloud will use it...
15:13:26 <dgilmore> Viking-Ice: which means we need more resources
15:13:43 <jwb> for the record, i'm still not convinced basing a release on the kernel cycle is a great idea
15:13:46 <sgallagh> A good first question might be: is it necessary for Base to be independently installable?
15:13:51 <Viking-Ice> dgilmore, or free resources ( think Anaconda here in QA  )
15:14:09 <dgilmore> sgallagh: its an option
15:14:36 <Southern_Gentlem> ?? why can not base be the common stuff for all three
15:14:37 <Viking-Ice> jwb, expand explain why that would be a bad idea?
15:14:43 <jreznik> sgallagh: that's the problem - first we should agree on what actually we want - completely separate products, spins like products, rings as I think at least now, everyone thinks we are doing something different and someone should clearly state that (the same question was raised on the last fesco meetings - how much rings? how much products?)
15:14:48 <jwb> we've got like 3 parallel conversations going on right now
15:14:49 <sghosh> sgallagh: without Anaconda in Base - it will be bad.
15:14:51 <jwb> it's confusing
15:14:55 <dgilmore> sgallagh: if it was i would imagine its a pxe tree and boot.iso
15:15:08 <dgilmore> sgallagh: anaconda is in base
15:15:21 <dgilmore> sghosh: ^
15:15:21 <Viking-Ice> anaconda and core need to be on same but seperated release cycle then the rest
15:16:03 <jwb> Viking-Ice, because it's actually closer to 2 months for the kernel, and everything else i'd think would be in base is using a 6mo cycle
15:16:04 <jreznik> it's hard to follow all wgs - do we have initial PRDs ready for all products so we can try to get the info from there first?
15:16:19 <jwb> so it seems basing it on the kernel release cycle just introduces a lot of unncessary churn
15:16:24 <Viking-Ice> core = something like comps minimal ( from my point of view )
15:16:25 <jwb> i'd rather focus on glibc or something
15:16:48 <Viking-Ice> jwb, I'm thinking core here not base from my point of view base is something each WG decide for themselves
15:17:08 <jwb> i can't even follow what you just said because there's too many conversations happening
15:17:26 <jwb> and people are bringing in ideas discussed elsewhere that i haven't been able to follow so i have no context
15:17:38 <jwb> let me know when we get organized again
15:17:42 <pknirsch> so lets focus on one topic at a time
15:18:04 <pknirsch> First up: Should anaconda be in base, yes or no?
15:18:04 <jreznik> yes please
15:18:22 <jreznik> (yes for focus on one topic)
15:18:31 <jwb> pknirsch, for some version of anaconda, probably.  like the common backend
15:18:38 <jwb> but i can be convinced it doesn't need to be
15:18:45 <pknirsch> mhm
15:18:46 <masta> I thought anaconda installer is to be considered a spin? why should it be in Base?
15:19:29 <dgilmore> pknirsch: anaconda needs to be in base
15:19:35 <pknirsch> thats the question here, masta. there are pros and cons for having anaconda in Base, so lets get them all together
15:19:39 <jwb> i'm not concerned as much about anaconda the program itself.  i am concerned about all the things that program uses
15:19:48 <notting> pknirsch: i think that base should likely at least extend to cover both the installer backend and the image compose tools
15:19:56 <jwb> notting, agreed
15:19:57 <sghosh> need anaconda core logic in base. Need to work with anaconda folks to split up UI to allow other to customize UI
15:19:57 <dgilmore> the definition of what the base was was settled two weeks ago
15:20:24 <dgilmore> minimal install, anaconda and deps, and compose tolling, along with things the majority of Working groups wanted
15:20:24 <notting> or image/distro compose tools, if you prefer
15:20:26 <sghosh> dgilmore: was that written down?
15:20:30 <dgilmore> i could drop off teh last bit
15:20:39 <dgilmore> sghosh: it was, in the first meeting
15:20:53 <jreznik> dgilmore: +1 for that minimal install, anaconda and deps
15:21:20 <pknirsch> ok, lets make a proposal from all that, i like the points notting and sghosh bought up, too
15:21:23 <dgilmore> all products have to have an install tree
15:21:26 <pknirsch> so how about:
15:22:07 <jreznik> at least as current anaconda works, it should be part of base as it's pretty tied to base too... but maybe standalone installer that would not depend so much on base would be preferable, flexible enough to install anything served to it
15:22:35 <pknirsch> Base needs to cover installer backend and image compose tools + the already defined minimal install and deps along with the components the majority of the other products need
15:22:46 <jwb> jreznik, i think anaconda tried that in the past and it didn't work out very well because it leads to duplication of the very things it's trying to depend on
15:23:25 <notting> pknirsch: that seems like a good start. what about build chain?
15:23:36 <dwalsh> pknirsch, Sounds good to me.
15:23:37 <jwb> i'd really like to include the toolchain
15:23:37 <notting> i.e., do we want to be standardizing on gcc version?
15:23:48 <pknirsch> notting: you mean self hosting?
15:24:19 <pknirsch> i think it would be very hard if we didn't include them
15:24:20 <notting> pknirsch: i'm not sure about self-hosting -self-hosting explodes the dependency tree
15:24:35 <notting> but... i'm also not sure how we get away with not having the base be self-hosting
15:24:42 <pknirsch> so votes on my proposal?
15:24:49 <pknirsch> aye
15:24:55 <jwb> pknirsch, your proposal doesn't include toolchain
15:25:02 <pknirsch> good point
15:25:21 <pknirsch> toolchain for now would be binutils, gcc and maybe python?
15:25:27 <jwb> from this point of view, i kind of see Base as the minimal SDK you need to develop other things/products.  you can't really do that without a toolchain
15:25:33 <pknirsch> with python hopefully going away with dnf in C at some later point
15:25:40 <pknirsch> aye
15:25:41 <sghosh> I would rather start without the the following: components the majority of the other products need
15:25:45 <jreznik> could we have base + "base plus" with toolchain and stuff like that makes together base self hosting?
15:25:51 <jwb> pknirsch, if we're including the anaconda backend, python is already there
15:25:54 <sgallagh> pknirsch: I have a separate proposal I'd like to make about Python, but that's off-topic for this question
15:25:57 <jwb> and it isnt' going away
15:26:11 <pknirsch> true
15:26:12 <notting> jwb: hm. i could see a handwavy future where base is self-hosting, but the things used to build base aren't necessarily provided to the other products
15:26:24 <dgilmore> jwb: well glibc gcc and python fall into base
15:26:27 <notting> jwb: that obviously gets complex
15:26:32 <jwb> notting, er... what?
15:26:37 <dgilmore> jwb: as they are needed in a minimla install
15:26:53 <pknirsch> sghosh: reason being to keep base as small as possible?
15:26:54 <jwb> notting, let's keep it simple...
15:27:21 <sghosh> pknirsch: yes, and avoid dumping ;)
15:27:25 <pknirsch> which would give other producs more freedom in what they choose to do
15:27:28 <pknirsch> aye
15:27:46 <masta> my fear is the kitchen sink approach here is too bulky.
15:27:48 <pknirsch> ok, new proposa;l then:
15:28:00 <masta> but at least the idea preserves the minimal install
15:28:11 <pknirsch> Base needs to cover installer backend and image compose tools + the already defined minimal install and deps and toolchain in form of binutils, gcc and python
15:28:15 <jwb> masta, it's not bulky.  we talking about the things we care about in Base, not what gets installed
15:28:36 <sghosh> pknirsch: agree
15:28:36 * notting deletes and just says 'what jwb said'
15:29:03 <jwb> pknirsch, sure +1
15:29:16 <pknirsch> #Proposal Base needs to cover installer backend and image compose tools + the already defined minimal install and deps and toolchain in form of binutils, gcc and python
15:29:19 <notting> pknirsch: is 'needs to' implying 'not limited to'?
15:29:50 <dgilmore> pknirsch: indeed, which we already had in the proposal from 2 weeks ago
15:29:55 <dwalsh> dgilmore, glibc gcc and python (Eventually) should not be required for minimal install.
15:30:16 <dgilmore> pknirsch: though we didnt explictly call out "toolchain in form of binutils, gcc and python"
15:30:24 <notting> dwalsh: i think what jwb and i are saying is the 'Base' design should cover more than just 'the minimal install'
15:30:31 <jwb> correct
15:30:33 <dwalsh> notting, I agree
15:30:39 <sghosh> dwalsh: minimal install is different that whats included in the scope of base
15:30:39 <pknirsch> right
15:30:40 <dwalsh> dgilmore, Asked above.
15:30:41 <jwb> though i don't see how you get away without having glibc in the minimal install
15:30:44 <dgilmore> dwalsh: thats irrelevant to what we want to be covered in the base product
15:31:00 <sgallagh> Are we differentiating base install vs. "offered by base"?
15:31:03 <dgilmore> dwalsh: whats in the product and whats in an install are two different things
15:31:16 <jwb> sgallagh, we've not even decided if there's a "Base install"
15:31:31 <jwb> sgallagh, so yes, we're talking about "Things we care about in Base"
15:31:35 <jwb> completely separate from install
15:31:44 <dgilmore> jwb: indeed
15:31:52 * pknirsch nods
15:31:56 <sgallagh> Well, my thought is that we probably want to have a runtime environment (glibc/libstdc++, etc), but that the compiler and toolchain should be part of Stacks/Envs
15:32:08 <jwb> i disagree
15:32:12 <dgilmore> sgallagh: base compiler no
15:32:21 <dgilmore> sgallagh: but add on ones yes
15:32:29 <pknirsch> env/stacks can provide different versions of the toolchain
15:32:32 <jwb> alternative compilers and toolchains can be
15:32:36 <dgilmore> compat-gcc-34 belongs in stacks/env
15:32:37 <sgallagh> dgilmore: Well, I was more thinking that Base could just define which Stack was the one it used.
15:32:44 <dgilmore> sgallagh: no
15:32:45 <sgallagh> Rather than necessarily offering it directly
15:32:45 <pknirsch> but i'd much prefer base to provide it
15:32:48 <dgilmore> seriously no
15:32:52 <jwb> base is the root of the proverbial tree
15:33:15 <pknirsch> sgallagh: then every product would have to include env/stack product for development
15:33:24 <pknirsch> that sounds complicated
15:33:25 <sgallagh> env/stack isn't a producy...
15:33:28 <sgallagh> *product
15:33:37 <sgallagh> It's a toolbox.
15:34:10 <pknirsch> sure, but so is base :)
15:34:11 <jreznik> how are env/stacks defined in fedora now?
15:34:15 <jwb> they aren't
15:34:21 <jwb> WELCOME TO DEFINING THE FUTURE
15:34:26 <pknirsch> heh
15:34:47 <notting> hm. i could see pushing the SDK to env&stacks. creates a circular dep loop, of course
15:34:58 <pknirsch> aye
15:35:12 <pknirsch> base needs env which needs base which needs env which...
15:35:25 <sgallagh> notting: This would be the same approach taken by the other major operating systems, I would note.
15:35:52 <jwb> i really think we need to have a base defined toolchain here.  alternatives can be handled by env/stacks
15:35:59 <notting> sgallagh: but i think in that case that what the system uses is not necessarily what the end user is provided
15:36:06 <sghosh> another way to look at it is base always contributes the build toolcahin as one env - remove the circular dep
15:36:44 <sgallagh> sghosh: Thanks; that's kind of what I was trying to say.
15:37:05 <pknirsch> so you mean that Base defines and provides the default toolchain as a Env/Stack toolbox?
15:37:23 <sghosh> yes
15:37:24 <jwb> i'm confused as to how that isn't "base defines the toolchain base uses"
15:37:42 <sghosh> jwb - it is
15:37:45 <pknirsch> ye, thats what i was trying to get to, jwb
15:37:54 <jwb> then why with just extra words on the end that don't actually change anything?
15:38:23 <jwb> it leaves the toolchain choice in the Base group, and alternativs can be done by env/stacks
15:38:29 * pknirsch nods
15:39:10 <dwalsh> When base updates its version of GCC requiring a rebuild, does that require products to rebuild to use the base?
15:39:46 <sghosh> dwalsh not if don't want to,
15:39:57 <dgilmore> sghosh: disagree
15:40:03 <dgilmore> dwalsh: i think so
15:40:24 <pknirsch> that depends on the change that the new version of GCC comes with
15:40:26 <notting> dwalsh: well that's the whole 'coordinated release or not' question
15:40:32 <pknirsch> if it's incompatible, there is no way around it
15:40:54 <pknirsch> and changing the version of GCC for a released version of base is a nogo imho
15:41:13 <dwalsh> I am also thinking of security changes like the one being proposed in changes right now.
15:41:19 <pknirsch> and for a new version of base, i'd agree with dgilmore to require rebuilding
15:41:29 <jwb> dwalsh, i don't think that specific one would require products to rebase, no
15:41:48 <dgilmore> pknirsch: right we bump gcc and set flags in rawhide and rebuild the world there
15:41:52 <jwb> it's adding compile-time build error flags.  not impacting the output of the binaries
15:42:04 <notting> for reference, a self-hosting tree of @core + anaconda + @anaconda-tools + gcc + binutils  + python + kernel is 2240 source packages, from a test pungi run.
15:42:05 <dwalsh> Might not but it would make it harder to claim that "Fedora" has new security feature if only base was compiled that way.
15:42:14 <pknirsch> notting: O_O le fu?
15:42:34 <dgilmore> notting: thats about what i expected
15:42:36 <pknirsch> notting: so much for a self hosting small base then :/
15:42:40 <pknirsch> ye
15:43:14 <dgilmore> systemd and other parts of the core have huge deps
15:44:03 <jreznik> that's bigger than I thought but not much bigger
15:44:06 <pknirsch> anaconda itself, too
15:44:36 <notting> including, but not limited to... kdelibs, gnome-bluetooth, texlive...
15:44:56 * pknirsch nods
15:45:11 <jwb> anaconda depends on NM.  NM depends on lots of stuff.  plus there's weird stuff like kernel having a BR on asciidoc and ncurses for tools and documentation
15:46:17 <pknirsch> jup. can someone put this info together please and add it to the Wiki? so we can refer to it for other WGs as well
15:47:01 <pknirsch> if no volunteers i'll try to get to it next week
15:47:11 <jreznik> could be one part of WG job to triage deps for base?
15:47:20 <pknirsch> good idea
15:47:21 <jwb> triage?
15:47:34 <notting> jwb: 'figure out if things can be made simpler'
15:47:40 <jwb> oh, ok
15:48:04 <notting> i.e., "i'm sure buildrequiring inkscape is nice and all, but..."
15:48:24 <pknirsch> #action pknirsch to summarize in wiki info about self-hosting tree of @core + anaconda + @anaconda-tools + gcc + binutils  + python + kernel is 2240 source packages, from a test pungi run.
15:48:54 <pknirsch> #info jreznik idea about  WG job to triage deps for base?
15:49:19 <jwb> notting, i'd love to drop some of the kernel BRs, but to do that would mean splitting those packages out into separate SRPMs.  that's a lot of duplicate source for relatively minor things, plus extra maintenance burden
15:49:26 <pknirsch> alright, that got us drifting off from the FESCO ticket to the definition again
15:49:31 <jwb> i'd think we'd run into a lot of those cases
15:49:43 <dwalsh> Does splitting apart anaconda help with this, or are all these dependencies in the back end?
15:49:49 <dgilmore> jwb: indeed
15:49:57 <dgilmore> dwalsh: I dont think so
15:50:14 <jreznik> also fesco touched soft deps...
15:50:21 <pknirsch> jwb, dwalsh: But i think it's still worth looking into it for someone of our team
15:50:32 <dgilmore> dwalsh: you could say enterprise storage support belongs in server but i dont think spliting that off gives us much
15:51:03 <pknirsch> true
15:51:17 <dwalsh> I would figure gnome-bluez and kde stuff belong in workstation.
15:51:37 <notting> dwalsh: as an example: gcc (build) -> dblatex (bin) -> texlive (bin), ImageMagick (bin) -> djvulibre (bin) -> inkscape (build) -> a-bunch-of-desktop-stuff (bin)
15:51:38 <dwalsh> What about sshd? Does that belong in base?
15:51:39 <pknirsch> I'll see if i can manage to get a dep tree of the set that notting created
15:51:42 <dgilmore> we would need to talk to anaconda devs
15:51:53 <dgilmore> the pain to split that support out may be huge
15:52:11 <Southern_Gentlem> anaconda has a long history of breakage over time so maybe a separate anaconda would help (anaconda can be constantly updated)
15:53:14 <pknirsch> #topic Continued discussion of Base Design
15:53:30 <pknirsch> #info previous 40 minutes :)
15:53:32 <haraldh> meh
15:53:48 <pknirsch> good morning haraldh ;)
15:53:51 <haraldh> :)
15:54:19 <pknirsch> there was one subtopic in the discussion i quickly wanted to get addressed: PRD for Base
15:54:25 <pknirsch> #topic PRD for Base?
15:54:40 <pknirsch> I would personally say not needed. We need a definition, but it's not a product per se
15:54:54 <pknirsch> and we've defined quite a lot of it already
15:55:35 <pknirsch> any comments?
15:55:51 <pknirsch> I'd especially like to hear sghosh and sgallagh on this
15:56:09 <notting> hm. our statement of purpose is "provide the common basis so the other products can exists" . that leads to either a really short meta-PRD, or a frighteningly exhaustive specific one
15:56:14 <jwb> i think it really depends on what "PRD" was intended to mean
15:56:16 <sghosh> agree - no PRD - but scope and definitions
15:56:44 <jwb> scope, definitions, maybe some goals.  but we don't need e.g. user stories, or branding, etc
15:56:49 <pknirsch> aye
15:56:50 <sgallagh> sghosh: I was typing that exact phrase.
15:56:54 <pknirsch> heheh
15:56:55 <pknirsch> ok
15:57:05 <jwb> i think we can just point the the base wiki page and call it good.
15:57:20 <pknirsch> #Proposal Base doesn't need a classic PRD, but rather scope and definitions and goals
15:57:23 <sgallagh> Probably a definition of interdependencies on the other groups as well
15:57:40 <notting> in terms of 'user stories' - do we want to ask the other WGs what they want from us?
15:57:54 * sgallagh likes action-adventure stories.
15:57:58 <pknirsch> good point notting
15:58:12 <pknirsch> I'll reach out to other WGs about that
15:58:15 * pknirsch makes a note
15:58:25 <sgallagh> Yes, we in the Server group are trying to come up with a list of requirements we have on the base.
15:58:38 <pknirsch> #action pknirsch to reach out to other WGs to collect input of what they want from Base
15:58:55 <jwb> the Workstation group is more interested in the APIs the base is going to provide
15:59:06 * jreznik has to end now
15:59:15 <pknirsch> aye
15:59:30 <pknirsch> #topic Open Floor
15:59:41 <pknirsch> one last question for open floor that came to me just this morning:
16:00:02 <pknirsch> Next week is Thanksgiving in the US, so i expect a lot of the US folks will be away on Friday
16:00:28 <pknirsch> I'd still like to hold the meeting, but with lighter topics and info sharing mainly
16:00:45 <pknirsch> which would then be recorded in the meeting minutes
16:01:36 <pknirsch> Anything else for today?
16:01:55 <jwb> we didn't really decide anything on release cycle, right?
16:01:58 <dgilmore> pknirsch: reminder ill be in oz for the next 4 meetings, will attempt to particiate. meetings ar 1-2am friday night sat morning
16:02:00 * dwalsh will be decorating for Chrismas and drinking Pina Coladas.
16:02:08 <dgilmore> jwb: we decided nothing
16:02:31 <jwb> sounds like a typical meeting
16:02:36 <pknirsch> dgilmore: right. Shall i send you the meeting agenda separately or do you read the ones on fedora-devel?
16:02:49 <dgilmore> pknirsch: devel@ is fine
16:02:53 <pknirsch> dgilmore: alright
16:03:03 <dwalsh> I got to go.
16:03:56 <pknirsch> jwb: Let me kick of a release cycle discussion then on fedora-devel for Base. I think this 1h here is too short with as you mentioned too many tangents going on at the same time
16:05:51 <jwb> pknirsch, sure
16:06:09 <notting> that sounds good
16:06:59 <pknirsch> alright. if nothing else, lets close the meeting for today. Thanks everyone! and for the US folks if i don't see/hear you till then, happy thanksgiving!
16:07:41 <pknirsch> #endmeeting