13:59:54 <mattdm> #startmeeting Council (2019-10-16)
13:59:54 <zodbot> Meeting started Wed Oct 16 13:59:54 2019 UTC.
13:59:54 <zodbot> This meeting is logged and archived in a public location.
13:59:54 <zodbot> The chair is mattdm. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:59:54 <zodbot> The meeting name has been set to 'council_(2019-10-16)'
13:59:57 <mattdm> #meetingname council
13:59:57 <zodbot> The meeting name has been set to 'council'
13:59:59 <mattdm> #chair jonatoni bex contyk dgilmore dperpeet langdon mattdm sumantrom tyll bcotton pbrobinson asamalik
13:59:59 <zodbot> Current chairs: asamalik bcotton bex contyk dgilmore dperpeet jonatoni langdon mattdm pbrobinson sumantrom tyll
14:00:01 <mattdm> #topic Introductions, Welcomes
14:00:04 <asamalik> .hello2
14:00:06 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:00:07 <contyk> .hello psabata
14:00:09 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:00:17 <mattdm> hi adam and petr! fancy seeing you here!
14:00:23 <mattdm> also langdon! :)
14:00:34 <dgilmore> hi
14:00:45 <langdon> .hello2
14:00:46 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:00:47 <langdon> im here!
14:00:50 <bexelbie> .hello bex
14:00:53 <zodbot> bexelbie: bex 'Brian (bex) Exelbierd' <bexelbie@redhat.com>
14:00:57 <langdon> although.. im going to refill my coffee .. so brb
14:01:33 <asamalik> hi mattdm! haven't seen you for tens of seconds!
14:01:48 <mattdm> I know, weird :)
14:02:07 <dgilmore> is this where we come to talk about OCP?
14:02:20 <mattdm> dgilmore: do you want to? :)
14:02:30 * pbrobinson is notionally hree
14:02:37 <dgilmore> mattdm: no, it consumes every other aspect of my working life
14:02:40 <mattdm> ha.
14:02:48 <mattdm> okay, so, let's figure out what we _are_ talking about :)
14:02:52 <mattdm> #topic Agenda
14:03:08 <jonatoni> .hello2
14:03:10 <mattdm> Our trusty FPgM is not here today, so it falls on us to build our own agenda
14:03:10 <zodbot> jonatoni: jonatoni 'Jona Azizaj' <jonaazizaj@gmail.com>
14:03:25 <mattdm> here are the tickets tagged as next meeting....
14:03:33 <mattdm> 1. Fedora IoT Edition Promotion
14:03:39 <mattdm> 2. Status of CI objective
14:03:47 <mattdm> 3. Next phase of Minimization Objective
14:03:54 <mattdm> 4.  Websites team needs revitalizing
14:04:00 <mattdm> 5. Planning Hackfest 2019
14:04:01 <langdon> back
14:04:02 * sgallagh lurks
14:04:09 <mattdm> some of those things may be no-ops
14:04:32 <mattdm> also, I kind of think given devel list discussion we should insert "council guidance on modularity" at the beginning
14:04:53 <mattdm> Because I'd like to affirm that, yes, we really do care about and want this thing :)
14:05:09 <mattdm> Is there anything anyone would like to add?
14:05:33 * asamalik is happy with that agenda and has nothing more
14:05:47 <langdon> what are you trying to accomplish with that statement? or are you waiting to put that in an agenda item?
14:05:58 <langdon> cause it needs a #info or agreed or some such
14:06:13 * langdon notes not asamalik's stmt ;)
14:06:23 <mattdm> agenda item :)
14:06:26 <bexelbie> I think part of our affirmaton should come in the form of getting the modularity objective renewed which is currently blocked
14:06:27 <asamalik> :(
14:06:34 <mattdm> first item :)
14:06:49 <mattdm> #topic Modularity, tigers, and bears, oh my
14:07:15 * contyk blames langdon
14:07:43 <langdon> hey... im not the one that made us take bears out of the story.. that was ian
14:07:45 <mattdm> Do we want to start by looking at the objective renewal?
14:08:03 <mattdm> https://pagure.io/Fedora-Council/council-docs/pull-request/61#c-2dc769431c5b71550fea82a68956b8769b4d4051-11
14:08:38 <mattdm> not sure in the Pagure interface how to go to see an applied version of that diff
14:08:40 <mattdm> anyone?
14:08:48 <dgilmore> seems reasonable
14:08:53 <mattdm> oh, here
14:08:56 <mattdm> https://pagure.io/fork/langdon/Fedora-Council/council-docs/raw/1c3614baad6e761983e6df91f76da21541ee376c/f/project/modules/ROOT/pages/objectives.adoc
14:09:06 <langdon> and the little icon next to the arrow
14:09:20 <mattdm> wait no
14:09:22 <mattdm> not that file
14:09:39 <bexelbie> https://pagure.io/fork/langdon/Fedora-Council/council-docs/raw/a806658036f0372de50785dca84123bc5598fefe/f/project/modules/ROOT/pages/objectives/objective-modularity-f30-f33.adoc
14:09:41 <pbrobinson> I do have some technical details with some of that new proposal but I'm not sure council is the best spot to rat hole on those
14:09:50 <mattdm> #link https://pagure.io/fork/langdon/Fedora-Council/council-docs/blob/a806658036f0372de50785dca84123bc5598fefe/f/project/modules/ROOT/pages/objectives/objective-modularity-f30-f33.adoc
14:09:57 <bexelbie> pbrobinson, have they been filed in the PR for response?
14:10:04 <mattdm> yeah let's stay away from details :)
14:10:16 <langdon> i thought people would come to the modularity meeting to talk about those.. but that hasn't happened
14:10:39 <mattdm> meetings can be hard
14:11:36 <mattdm> One of the comments is: "There must be strong restrictions to create modules, because each module will increase demands for release engineering, infrastructure and testing."
14:11:53 <mattdm> Which gets back to the big picture problem.
14:12:04 <contyk> I'm not sure ow that differs from regular packages, though
14:12:08 <mattdm> The _assumption_ of that statement should be made untrue
14:12:47 <mattdm> The rest of the statement is
14:12:51 <mattdm> "At present there are multiple reports about broken dependencies between nonmodular content and enabled modules and their dependencies on systems that never used dnf module commands (consequence of enablement of defaults and their dependencies).
14:12:51 <contyk> well, it is true, just like it's true for any other component of the distribution :)
14:12:54 <mattdm> Wee need to focus on QE and testing all module streams combinations to ensure integrity of distribution (modular repoclosure).
14:13:11 <mattdm> I think there's a concern about exponential growth of conflicting modules
14:13:29 <mattdm> In the RPM world, "everything must puzzle-piece together" is one of the basic constraints
14:13:53 <langdon> well.. it does in the single repo of the the distro
14:14:19 <contyk> well, even there we have conflicts and alternatives
14:15:02 <mattdm> Anyway, I want to take this back to the big picture.
14:15:19 <mattdm> We have EPEL 8 with modularity hopefully coming soon.
14:15:27 <langdon> yeah.. i am not sure what the next step is
14:15:44 <mattdm> There is CentOS Stream, and I want CentOS people to participate in Fedora and EPEL rather than building a new thing
14:16:01 <contyk> yes but that will take a while
14:16:15 <mattdm> So, I want it to be very easy for those SIGs to be able to build modules to enable their use cases
14:16:27 <mattdm> This goes right back to the Fedora mission
14:16:34 <langdon> i am not sure centos stream has anything to do with that .... or at least any more or less than general centos..
14:16:50 <langdon> we need to be sure we can, in fedora, still build for centos (or centos stream)
14:17:04 <langdon> including modules
14:17:08 <mattdm> langdon: people in CentOS Stream are asking how they can build alternate versions of packages
14:17:08 <contyk> well, that's an entirely separate topic
14:17:18 <mattdm> I want the answer to be "use modularity in EPEL!"
14:17:20 <asamalik> is this "broken dependencies" mattdm is citing about upgrades of systems only consuming default content? because that's broken, yes, and that's what sgallagh is proposing a fix for on the devel list
14:17:38 <mattdm> but if that's too hard for people to do, they won't.
14:18:43 <contyk> so
14:18:45 <langdon> mattdm: whta i am confused about is .. why is that a different answer than general centos?
14:19:04 <contyk> stream is kinda like centos rawhide
14:19:09 <contyk> or will be
14:19:15 <mattdm> langdon: general centos is _right now_ going off and doing their own thing. this is a chance to do something different
14:19:23 <contyk> but anyway; the goal is to make modularity invisible to people who don't care
14:19:27 <mattdm> we probably won't get that chance again for a long time
14:19:42 <contyk> ursa prime and recording the intent of module enablement solve that; #1 is almost here, #2 has a proposal
14:20:00 <contyk> the worry about exponential growth is valid; that's a feature, however
14:20:15 <langdon> e.g. copr
14:20:16 <mattdm> I don't super care about making it invisible. In fact, there are cases where I think invisibile is bad.
14:20:23 <contyk> I think the answer there is CI and shifting the mindset a little -- e.g. not being okay with random test failures but going and fixing such things
14:20:46 <dgilmore> I think a big focus of the new proposal has to be CI/CD and QE
14:21:04 <langdon> dgilmore: which proposal?
14:21:13 <mattdm> new objective?
14:21:15 <dgilmore> Yes
14:21:24 <langdon> we have a ci/cd objective, no?
14:21:25 <dgilmore> The new objective
14:21:33 <dgilmore> We do
14:21:58 <dgilmore> But the modularity objective needs to build on and leverage the CI/CD one
14:22:32 <dgilmore> What are the unique issues modularity faces in the CI world
14:22:35 <bexelbie> I am a bit confused ... I keep hearing Person A: Challenge Statement; Person B: That is <in progress/fixed/proposal fix exists>.  This makes me wonder if modularity needs an objective or just some BZs
14:22:43 <dgilmore> And how do we go about solving them
14:22:58 <langdon> bexelbie: in many ways that is true
14:23:21 <contyk> I think the reason for the objective is similar to the reasons behind the minimization objective
14:23:34 <contyk> to emphasize this is our priority and something we still want
14:23:36 <bexelbie> I think the packager concerns are real - but I don't hear those getting worked ... or I don't understand them
14:23:41 <langdon> contyk: +1
14:23:42 <mattdm> So, here's what I beleive the high level goals to be:
14:24:02 <mattdm> 1. Users should have alternate streams of software available
14:24:03 <langdon> bexelbie: i think there is a difference between having bzs and having people to implement them
14:24:17 <mattdm> 2. Those alternate streams should be able to have different lifecycles
14:24:23 <bexelbie> langdon, I agree.  I also don't think an objective magically creates people
14:24:30 <mattdm> 3. Packaging for multiple streams should reduce work, not increase it
14:24:42 <mattdm> Do we as the Council agree with that?
14:24:59 <bexelbie> +1 to the three items articulated by mattdm
14:24:59 <langdon> not sure on 3..
14:25:15 <langdon> it may be more work to have multiple streams, no?
14:25:53 <bexelbie> I agree with langdon but only in the sense that 3 versions is more work than 1.  But an individual version shouldn't be harder than before, it should be easier
14:25:57 <langdon> perhaps 3 could be "the effort to package multiple streams should be flat in comparison to packaging one stream" or something?
14:26:09 <mattdm> rephrase...
14:26:17 <asamalik> +1 to those three with the clarification from bexelbie
14:26:57 <tmoney> Would it make sense to define that strategy vision for how you want Fedora developed?  Such as:  1. How many modules Fedora want to maintain?  2.  Will Fedora have "default" modules or always assume a rolling forward module reset matching previous Fedora experiences?  3.  If you want defaults, how you want them maintained and how you want the upgrade tooling assessment/guidance to do to guide users on dealing with modules during an upgrade?
14:26:58 <mattdm> 3. Packaging an individual stream for multiple outputs should be easier than before
14:27:19 <pbrobinson> yes I agree with those with mattdm's last #3
14:27:33 <mattdm> tmoney: hold that thought :)
14:27:39 <tmoney> ack :) sorry
14:27:43 * bexelbie is still +1 based on the revised #3
14:27:49 <mattdm> does anyone _disagree_?
14:27:52 * asamalik is still +1
14:28:00 <contyk> well, I prefer langdon's #3 :)
14:28:10 <contyk> it shouldn't be worse, at least
14:28:32 <langdon> yeah... i am not sure how the effort would go *down* if i add streams
14:28:36 <contyk> but there is only so much benefit you can get if you repackage your single package as a module
14:28:37 <mattdm> I have aspirational goals, here. We do want to make things better.
14:28:55 <bexelbie> I have always been lead to believe modularity came with automation to help us
14:29:05 <mattdm> I totally expect repackging my single package that is the same across all fedora releases and EPEL to be less work
14:29:14 <mattdm> I think that's fair.
14:29:29 <contyk> there are other ways to achieve that
14:29:29 <langdon> mattdm: i think your "better" is a comparison of two things but i am not sure all of us are using the same two things in the comparison.. because you aren't stating which things they are
14:29:32 <pbrobinson> yes, that was my understanding of modularity too
14:29:54 <langdon> mattdm: like "less work" than what?
14:29:57 <bexelbie> I mean, even eliminating "git checkout f29; git merge f30" is a savings
14:29:59 <asamalik> we have things like stream branches (one for all outputs), build orchestration, ... so yes, that was my believe, too, that it's supposed to be all simpler
14:30:01 <pbrobinson> package one version of a package and have it built against all versions etc
14:30:05 <langdon> it is today? than just having one stream?
14:30:32 <asamalik> pbrobinson: yes, this
14:30:48 <langdon> yeah.. i think contyk and i are reading the comparison to "one stream" and some (all?) of you are reading it as a comparison to "before modularity"
14:31:06 <bexelbie> I definitely read it as "before modularity"
14:31:11 <contyk> you can build for multiple targets even without modules
14:31:14 <bexelbie> I read modularity with a single stream as a net-win for packagers
14:31:20 <bexelbie> and easy onboarding to multiple streams
14:31:21 <contyk> for a single package this isn't the main benefit
14:31:34 <bexelbie> it might just be a small win, but a net-win
14:31:54 <langdon> well.. i think the f2 changes forced by modularity will result in a lot of these benefits but they are only sorta/kinda a result of modularity
14:32:05 <bexelbie> f2?
14:32:12 <langdon> factory-2.. sorry
14:32:39 <bexelbie> if the benefits are the result of using modularity -then modularity gets the credit, imho
14:32:54 <bexelbie> if you just make "ursine" rpms easier - that's nice and good, but wasnt' a goal of modularity
14:33:04 <langdon> bexelbie: yeah... but i am an engineer.. so i am quibbling over the details (really, confused by the details)
14:33:04 <bexelbie> also, the "ursine" in-joke is terrible :P
14:33:11 <mattdm> contyk, langdon do you *object* to my #3 as a goal?
14:33:28 <langdon> i think you need to add "better than what"  .. like the comparison is not obvious
14:33:37 <langdon> bexelbie: we have tried very hard to ban it
14:33:51 <bexelbie> it just won't stay hibernated :P
14:33:51 <langdon> that was my joke at the very begining of the meeting
14:33:55 <bexelbie> *rimshot*
14:34:06 <langdon> bexelbie: sqlalchemy-ied maybe?
14:34:08 <mattdm> (it was also my joke with the topic. i'm sorry)
14:34:41 <asamalik> just bear with us
14:34:42 <contyk> well, there are situations (single package, single stream) where modularity adds work and doesn't bring any tangible benefits
14:34:49 <langdon> asamalik: --
14:34:53 <contyk> so if you evaluate it in that context, we will always fail #3
14:35:07 <contyk> so not super happy with it but I won't object :)
14:35:40 <mattdm> Ok, I'm going to #agreed these things
14:35:58 <mattdm> #agreed council goals for modularity
14:36:09 <mattdm> #agreed 1. Users should have alternate streams of software available
14:36:11 <bexelbie> contyk, why?  single stream across all versions should be easier than single package across all version
14:36:19 <mattdm> #agreed 2. Those alternate streams should be able to have different lifecycles
14:36:32 <mattdm> #agreed 3. Packaging an individual stream for multiple outputs should be easier than before
14:36:39 <contyk> bexelbie: you can build a regular package for multiple targets even without modularity, from one branch
14:36:58 <contyk> bexelbie: if you have a single package AND just one stream, you're not getting anything new -- you just need to maintain one more file (modulemd) to make it work
14:37:08 <bexelbie> I'd love to have the docs that keep me from having to maintain f29, f30, fXX branches
14:37:30 <mattdm> yes. let's not get stuck on this though, because there's a clock on this meeting :)
14:38:17 <mattdm> Right now, there is what I can see as an entirely reasonable proposal from some Fedora packagers: there should be *no* default modules
14:38:36 <mattdm> that is, modules can only be used to provide alternate streams.
14:38:49 <contyk> what benefit does that bring?
14:39:34 <mattdm> there's no need for an ursa major or minor. base versions of packages continue to exist in the traditional repo
14:39:50 <langdon> yeah.. why would you want that?
14:40:02 <contyk> mattdm: as long as someone maintains those versions
14:40:09 <bexelbie> I suggest we restate this as an goal, not as an engineering problem
14:40:37 <bexelbie> I trust the modularity engineering contributors to make good engineering chocies - we need to help with guidance if that is what is lacking
14:40:56 <mattdm> What I'm saying is: a version of modularity with that restriction meets goal #1, doesn't do any worse on #2 than currently, and only fails #3.
14:41:28 <langdon> it completely misses the goal of modularity being adopted or useful though :/
14:41:30 <bexelbie> as a packager who doesn't use modularity, modularized content shouldn't block me or increase my work.  Engineering can answer how that should happen, imho
14:42:03 <contyk> bexelbie: +1
14:42:24 <mattdm> langdon: Let's say I want to provide an alternate version of ImageMagick in EPEL. I can do that without worrying about a default stream
14:42:27 <contyk> let's not decide whether default streams as a technology are allowed in Fedora on the Council level
14:42:40 <langdon> that has nothing to do wiht an arbitrary "no defaults" rule.. that is just someone proposing a rule that has serrious side effects that they assume will solve bex's point
14:43:06 <bexelbie> langdon, then the modularity engineering contributors need to help us realize this goal, assuming the statement I made is worthwhile
14:43:15 <langdon> yeah.. i can't imagine why we (or the modularity team) would adopt that reule
14:43:19 <bexelbie> I'd add, that my statement plus a goal of modularity is a net-win should lead to adoption
14:43:50 <langdon> right.. this was my point about "not enough engineers" ... for some reason people assume mailicious intent whne we don't have enough bodies to do all the work fast enough
14:44:24 <bexelbie> I believe the challenge is that we seem to have, in effect, shipped half-finished work, as production
14:44:34 <langdon> like gnome 3?
14:44:42 <langdon> arguably systemd?
14:44:42 <bexelbie> half is a english statement, not a statemetn on percentage of complete
14:44:54 <langdon> lots of other things?
14:44:58 <mattdm> langdon: and I think we can all agree that that had detrimental effects we would not like to repeat
14:45:02 <langdon> i thought we were a "first distro"
14:45:10 <bexelbie> langdon, not saying it wasn't a goal - just pointing out the source of pain
14:45:22 <mattdm> But I also don't want to be a "lose half of our users" distro
14:45:32 <bexelbie> and we do pride, perhaps overly much, our stability
14:45:37 <langdon> yes.. and i get it.. but i don't always understand why the belief seems to be that we are trying to cause pain..
14:45:42 <bexelbie> and some of the upgrade challenges in particular have been bad, aiui
14:46:06 <bexelbie> langdon, I don't think that attitude has been present int his meeting or from anyone except those with the most "extreme" opinions
14:46:13 <bexelbie> opinions council is not, aiui, validating
14:46:32 <bexelbie> I am not denying the lived experience
14:46:56 <langdon> bexelbie: sorry... that was not what i meant to imply.. nor the vast majority of feedback.. just sometimes it can be frustrating to say over and over "we are trying"
14:47:12 <langdon> and people hearing "you must do this by fiat"
14:47:19 <pbrobinson> there's been issues with procedures where things like mass rebuilds of modules weren't done
14:47:27 <bexelbie> absolutely - and that is part of the reason I reiterated the trust of the contributors in my earlier comment :) trying to provide some balance
14:47:58 <pbrobinson> and I feel that things like this make it hard to justify putting it into core build process if the edge bits aren't working well enough with associated processes
14:48:50 <langdon> well.. it isn't like that is limited to modularity.. we seem to be all in on containers and silverblue and both of those have that problem all the time.. i think fedora-minimal is still f27
14:48:54 <bexelbie> and that may also be part of the challenge.  A rough UI is one thing (and often a bad one) - but this is seeming to drive at the heart of our ability to produce the distro
14:49:23 <bexelbie> also, containers, silverblue, etc. are avoidable if desired
14:49:25 <bexelbie> aiui
14:49:34 * bexelbie considers the gnome3 and systemd comments here as well
14:50:08 <bexelbie> I am wondering how the council can help here further - we clearly believe in modularity.  If we do an objective, what is it going to solve to get us to the next level?
14:50:17 <langdon> lots and lots of stuff is rough around the edges ..
14:50:19 <bexelbie> if we are really just stuck on contribution volume - do we need an objective?
14:50:21 <mattdm> +1 bexelbie
14:50:39 <bexelbie> can we request a better roadmap and wait it out?
14:50:40 <langdon> bexelbie: what??
14:50:53 <langdon> doens't an objective *add* contribution level?
14:51:05 <bexelbie> objectives do not magically create contributors, afaik
14:51:11 <bexelbie> if it does, we are getting a budget one NOW :D
14:51:34 <mattdm> lol
14:51:38 <langdon> well.. there is a chicken and egg problem.. always with an objective..
14:51:40 <bexelbie> I was under the impression from your statemetns we were short of engineering contributions to get modularity done
14:51:57 <mattdm> I think an objective is useful, because I think there's still some big project-wide change that needs suport
14:51:58 <langdon> you can't both say it is a priority but also not have it be a focus at the same time
14:52:27 <langdon> bexelbie: have you ever seen a software project fullly staffed?
14:52:39 <bexelbie> yes, but that project got canceled :D
14:52:42 <langdon> ha
14:52:58 <pbrobinson> an objective adds spotlights but not necessarily focus I have found
14:52:59 <mattdm> And I was pretty happy with the objective refresh when I read it before, but this last week's devel discussion does kind of make me think it should address some other things
14:53:26 <mattdm> First, it should re-iterate the high-level goals.
14:53:28 <bexelbie> I remain concerned by the unaddressed comments on the refresh
14:53:32 <asamalik> pbrobinson: I could agree with that, yes
14:53:34 <bexelbie> and concur with mattdm
14:54:08 <mattdm> Because people keep bringing up "solution in search of a problem", which is frustrating, but the only way I know to counter is to state the goals clearly again anad again
14:54:08 <langdon> bexelbie: can you clarify what you mean by "unaddressed comments"?
14:54:08 <bexelbie> asamalik, you have done an amazing job with status updates - it'd be nice to have you talk about how that has affected focus, not in this meeting at this moment :D
14:54:14 <langdon> like in email? the pr? something else?
14:54:22 <mattdm> asamalik++
14:54:26 <mattdm> in the pr, yes
14:54:57 <mattdm> Second, I think this objective should include solving the lifecycle and upgrade uncertainties
14:55:02 <bexelbie> yes, in the PR
14:55:18 <mattdm> which I know is a big thing to throw in, but as I'm looking at What's on Fire, that's a big part
14:56:07 <bexelbie> which follows from the priority part of objectives
14:56:07 <langdon> mattdm: but is that "objective language" or "docs"?
14:56:20 <mattdm> langdon: which part?
14:56:55 <langdon> the bulk of what you an bexelbie just said we should add to the objective
14:57:21 <bexelbie> unless we have proposed fixes and just need to point at a roadmap and wait
14:57:27 <bexelbie> I am not hearing that is well communicated
14:57:34 <langdon> i guess the q for me is "is the objective the documentation about the why" or "it is a transitive document that has a lifespan"
14:57:55 <mattdm> langdon: I think it should document the why
14:58:04 <bexelbie> I see it as success criteria and goal setting as well
14:58:17 <langdon> i am not saying the content should appear somewhere i just wasn't thinking it would land in the objective doc
14:58:33 <bexelbie> which drives back to are we in a BZ situation or a program situation here (probably not the best choices of words but I ahve drop momentarily)
14:58:57 <langdon> i wonder if it needs some more restructuring.. like the *objective* and then one or moree attachments of "roadmap" and "status" and "whatever else"
14:59:03 <mattdm> I think it's going to be helpful for everyone if the objective doc starts with the overall problem tatement. it can point to other docs for further reading.
14:59:28 <mattdm> And the upgrade/lifecycle thing isn't a documentation problem -- it's work
14:59:28 <langdon> right... i wonder if that should all be the same doc for all the phases.. with  a set of attached roadmaps.. or whatnot
14:59:36 <bexelbie> I also think it is fair for you to pull engineering conversations to the working group in your objective
14:59:54 <bexelbie> the objective doesn't have to say how - just what will happen
14:59:56 * bexelbie has to drop
15:00:16 <mattdm> I'm not asking for a big doc. Just start with big picture why
15:00:20 <mattdm> I also have to go
15:00:24 <mattdm> thanks everyone
15:00:29 <mattdm> more on other topics later I guess :)
15:00:35 <mattdm> #endmeeting