20:07:53 #startmeeting tc 20:07:54 Meeting started Tue Nov 3 20:07:53 2015 UTC and is due to finish in 60 minutes. The chair is lifeless. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:07:56 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:07:58 The meeting name has been set to 'tc' 20:08:07 (hopefully thats the right name) 20:08:17 yup 20:08:32 so, skipping the voting bits for now, we have open discussion with a few starter points 20:08:40 Open discussion 20:08:40 Summit feedback 20:08:40 Reconsidering delayed project team applications 20:08:40 Automating objective tag updates 20:08:40 Should TC require scaling information from projects (lifeless)? 20:08:42 Leadership training for PTL & TC (lifeless) 20:08:45 Stabilisation cycle (lifeless) 20:09:00 is there any general summit feedback ? 20:09:10 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:09:34 lifeless: Other than the usual bits about burnout, it was great seeing folks! And Tokyo was quite pleasant :) 20:09:36 the summit was great- I was very strangely NOT complete toast at the end but was actually excited about stuff 20:09:52 which is typically not my emotional or mental state by friday/saturday 20:10:02 It was great, but my brain had porridged by the last session every day 20:10:06 I think it was great, it was packed. The venues layout was a bit unfortunate but I guess there was nothing we could do about that. 20:10:07 what about talks selection process? 20:10:13 working till 6 when doing such intense stuff is melty 20:10:19 I think the TC + Board meeting was better this time 20:10:25 I heard from one or two folks who might have wanted to participate in design discussions, but are not ATCs, that they feel the design sessions are being more aggressively closed off to new contributors. One of these people is building up a team with the intent of contributing upstream, so that was particularly concerning to me. 20:10:47 dhellmann: what stopped them? 20:10:48 dhellmann: I've heard a similar thing around facilitation of input 20:10:49 dhellmann: oh uh 20:11:03 dhellmann: I tink that's a really good point - and speaks to a conflict I think has been growing 20:11:06 dhellmann: wasn't our experience with puppet-openstack, these were open to lots of new people 20:11:06 dhellmann: which the leadership training thing overlaps with 20:11:19 which is "summit as place for the current cores to plan" vs. "summit as a place to grow community" 20:11:24 jeblair : the separation, in part, but also an impression from the way the sessions were run that they might not be welcome. There was no "hard" blocker. 20:11:30 dhellmann: was it that they couldn't get in the room; couldn't identify the session; couldn't participate once in the room ? 20:11:33 angdraug : good to hear 20:11:47 dhellmann: do we know what projects exactly left them out? What were the exact actions? 20:11:56 This would be great material for the diversity group 20:12:02 lifeless : a bit more of the latter, though I'd need to get more details 20:12:07 flaper87: I don't; the stuff I've heard is second hand 20:12:13 which I happen to have volunteered to help 20:12:20 flaper87: ruagair was telling me; perhaps he can follow up with you with more detail 20:12:22 flaper87: ++ 20:12:29 flaper87: (though also see under leadership training) 20:12:37 flaper87 : I'll poll for more detail and get back to you directly 20:12:46 angdraug: what about the talk selection process? 20:12:47 lifeless: dhellmann awesome, thanks! 20:12:50 well, let's be clear -- we have intentionally tried to make it clear that it is not helpful for everyone in the world to attend a design session. in the past they have been overwhelmed by people showing up requesting features but with no resources to contribute. 20:12:52 lifeless: https://www.mirantis.com/blog/fixing-openstack-summit-submission-process/ 20:13:02 I'd like to argue that growth and depth are different goals for session 20:13:06 (yeah, what jeblair said) 20:13:11 there was a lot of grumbling before the summit that the selection process is not transparent enough 20:13:14 and I think _both_ are valuable 20:13:25 but trying to do both in a single session is almost impossible 20:13:27 disclaimer: my talk wasn't accepted, too :) 20:13:32 jeblair: mordred yeah, that's why I'd like to understand what happened exactly 20:13:33 jeblair : true, but in this case these are folks who do want to become contributors so we may be sending that message too strongly 20:13:33 because in one case it's about growing context 20:13:35 angdraug: that seems to be a foundation thing not tc 20:13:38 i think people with resources to contribute should very much be welcome, but a design session isn't the place for "can you add foo to neutron?" 20:13:44 jeblair: ++ 20:13:46 angdraug : we don't select talks 20:14:09 angdraug: - I agree with the criticism, but I think the most we can do here is resolve that we think it should be open and ask the board/foundation to discuss 20:14:09 well maybe that's part of the problem ) 20:14:19 jeblair : right, this is a company building a new upstream team with the intent of being involved and contributing code, etc. not just "requirements" 20:14:29 angdraug: I don't think the tc *should* own talk selection :) 20:14:49 lifeless: ++ 20:14:49 no, but TC operates in a fairly open manner which can serve as an example 20:15:00 angdraug: ++ 20:15:02 dhellmann: did they talk to the relevant ptls? 20:15:07 angdraug: I will quit the TC if I am forced to review eleventy billion vendor crap talk proposals for the conference. 20:15:23 angdraug: sure; anyhow - I suggest your next step is to start a thread on the foundation list, and if it needs tc support, propose a governance resolution to the effect tat we support openness there 20:15:27 jeblair : I'll have to get more detail about what actually happened, this was a somewhat casual comment dropped when I didn't have time for that 20:15:40 any other summit feedback ? 20:15:43 dhellmann: cool 20:15:51 lifeless: moar robot restaurant at all summits 20:15:57 lifeless: thanks, I'll do that 20:15:58 mordred: ++ 20:16:00 mordred: ++ 20:16:04 mordred: ++ 20:16:14 dhellmann: sounds like we need to tweak teh messaging.. ie ATCs and those who intend to contribute in the upcoming cycle 20:16:31 markmcclain: ++ 20:16:44 markmcclain: technical contributors, present and future 20:16:46 #topic Reconsidering delayed project team applications 20:17:03 ^ next thing from the list 20:17:27 there are 2 projects that need to be reconsidered and from the TC m-l thread, it sounds those will be discussed next week 20:17:28 markmcclain : right 20:17:31 there is no annotation about it; I presume this is saying 'is it time for us to do that yet'? Or perhaps its reconsidering the decision to defer? 20:18:25 At least, jaypipes mentioned Monasca and Fuel on the meeting thread 20:18:30 looks like monasca, fuel, compass are on our calendar for reconsidering "when mitaka is started" 20:18:44 markmcclain: honestly, sounds like a way for people to game the purpose of the design summit to gain entrance when they have no intent to contribute. 20:18:59 they are still in the backlog on the wiki page 20:19:01 markmcclain: see: Paris design summit sessions. 20:19:02 ttx mentioned in that thread that it would be good to have a mentor assigned to each project to pull together details about where they stand before we proceed 20:19:19 I believe ttx was going to play matchmaker 20:19:19 for the record, I've updated https://review.openstack.org/#/c/199232/ with links to reports on current state of what was raised as blockers the last time fuel was discussed 20:19:32 angdraug: excellent work on that, BTW, thank you. 20:19:42 so lets defer this till we have a ttx? 20:20:01 lifeless: yeah, I think a vote on these next week was the general consensus from the ML. 20:20:02 yeah, unless we have volunteers now? 20:20:12 oh, definitely defer the voting 20:20:21 I guess we can add them to the meeting topics anyway 20:20:33 I'll put them in the list for next week after the meeting 20:20:38 #topic Automating objective tag updates 20:20:46 sorry, what's a ttx? 20:20:52 daemontool: the chair of this meeting 20:20:59 ty 20:20:59 daemontool: thierry carrez 20:21:24 I don't know who put this topic up 20:21:29 if you're here, speak up :) 20:22:20 ... deferring to next week 20:22:29 #topic Should TC require scaling information from projects (lifeless) 20:22:32 lifeless: that was ttx 20:22:41 so this came out of one of the cross project sessions 20:22:57 I'll turn it into a governance thing, but I wanted to have some informal discussion first 20:23:13 the basic idea is that we're missing at a governance level: a clear lexicon for talking about scaling 20:23:33 (e.g. request rate vs cloud-size vs workload dynamics) 20:23:33 I will agree that there is no clear lexicon for this currently 20:23:54 and that projects should be responsible for their own scaling destiny but 20:24:12 we can and should require them to document how they scale, and how deployers should scale them 20:24:39 how can you keep something like that objective? 20:24:39 e.g. does $project scale by a single big cluster, or a federation of clusters, or ... 20:24:49 mmh, isn't that part of the deployment docs? 20:24:57 scale has a number of implications on architecture in general, not only deployment architecture 20:25:33 flaper87: certainly you'd expect it there, but it also speaks to the architecture and design 20:25:46 flaper87: e.g. if someone wants to make nova more scalable, what does that mean? Whats the vision there? 20:25:59 (I happen to know, but tribal knowledge vs clear articulation) 20:26:16 [and actually I suspect nova is one of the more clear cases] 20:27:16 sure, I agree that's helpful. But, that's still documentation. I guess I'd rather require having docs than just architectural docs 20:27:43 lifeless: I guess you're thinking to communicate this through a tag 20:27:49 one way to measure scalability objectively is require projects to run specific Rally test scenarios... 20:27:52 flaper87: so you're not against the idea of us requiring that projects figure this out 20:28:02 angdraug: I don't actually care about object here. 20:28:03 bah 20:28:04 objective 20:28:21 okay 20:28:22 angdraug: I care that projects a) own the problem b) know they own it, c) communicate about it 20:28:46 flaper87: I don't know if a tag is the right thing, but perhaps it is 20:28:51 I'm not against the idea this is something projects should figure out 20:28:57 flaper87: I'm entirely fine if we say that this goes in the deploy docs 20:28:59 lifeless: I don't think it is, which is why I mentioned it 20:29:11 deploy docs should be fine 20:29:30 flaper87: but I *do* think this should be a basic thing that we require of everyone 20:29:35 lifeless: perhaps this is something we can have the newly-formed performance working group be responsible for enforcing the documentation requirements in such a tag? 20:30:00 so the proposal is that we just have projects include this kind of information in their docs? what sort of governance change does that require? 20:30:00 jaypipes: ah, good thought 20:30:05 jaypipes: if they wanted to take on following up with each project etc that would be great. 20:30:23 jaypipes: I worry that performance != scaling, and that a centralised WG may not be a good fit for the work needed. 20:30:42 jaypipes: but we can certainly try that as a first iteration. 20:31:55 dhellmann: governance - I'm thinking a resolution that projects must do this, which is then included under "The project meets any policies that the TC requires all projects to meet" on http://governance.openstack.org/reference/new-projects-requirements.html 20:32:15 lifeless: performance group is a subgroup of large deployments team, so it is specifically about performance at scale 20:32:37 angdraug: this just illustrates how performance != scale :) 20:32:51 angdraug: a small deployment doing very dynamic workloads may have huge scaling concerns 20:33:11 lifeless: angdraug knows the difference between scale and performance. he is saying that the perf working group deals with both. 20:33:23 what he said :) 20:33:25 lifeless: ok, I guess that makes sense. We could collect some other basic expectations for documentation at the same time or in another patch. 20:34:08 I honestly don't know if this should be part of the governance enforcement. If we're going to make it so, I'd like to see other docs being required as well 20:34:11 dhellmann: I'd like to make other docs things separate, because each thing we ask for implies a chunk of work 20:34:20 even basic deployment, which in some cases are missing 20:34:41 flaper87: so, for servers, having basic deployment docs seems like a thing we should indeed require 20:34:55 flaper87: much as we require the project testing interface so they can be CI tested 20:35:11 and I'd support that; just suggest it be a series of patches. 20:35:11 lifeless:++ 20:35:21 lifeless: sure 20:35:30 ok, I think there's little disagreement here, so I'll put a proposal up in the near future 20:35:44 #topic Leadership training for PTL & TC (lifeless) 20:36:03 this was suggested to me in a hallway track session :) 20:36:17 basically, we've got 2.5k folk in our technical sub-community 20:36:33 and at the moment a completely adhoc set of skills for doing the leadership 20:36:48 we're voted in and that doesn't imply knowing how to ... lead 20:36:53 lifeless: I'd consider it more tribal knowledge, but we're close 20:37:45 * fungi certainly doesn't know how to lead. recommendations welcome! 20:37:47 so, what do we think of the idea of having a (say) 2-day leadership course before each summit? paid for my the foundation 20:37:53 s/my/by/ 20:38:07 seems like a small amount of investment for an actually very important thing 20:38:22 I like the idea 20:38:26 fwiw, I've brought this up a couple of times from a TC perspective and a PTL perspective. One thing we did to help here was writing the project-team-guide but that's certainly enough. 20:38:40 flaper87: *is enough* or *isn't enough* ? 20:38:42 I'm not sure we want to limit attendance to ptls, maybe all cores could be invited (to grow new ptls for the next cycle, for example) 20:38:56 lifeless: isn't* (sorry) 20:38:56 I like the idea too 20:38:57 concerned that it would make for a very loooong week 20:39:01 dhellmann: ++ 20:39:03 dhellmann: so theres a magnitude thing. Leadership courses in my experience are pretty hands-on for the teachers 20:39:03 i'm not a fan of formalized leadership training 20:39:09 markmcclain: It would be optional, of course 20:39:11 dhellmann: and 200+ cores is a big group 20:39:11 lifeless: true 20:39:16 I like the idea but I'd like us, as a community, to think what else we can do throughout the cycle 20:39:26 lifeless: I wouldn't expect them all to attend, and we could cap it 20:39:26 for example, how can we help folks to run for PTL ? 20:39:35 jeblair: would you object to other people going? Like, is it a negative? Or you don't want to be forced to go? 20:39:39 I think part of the PTL job is to create new PTLs 20:39:49 What can we do to help spreading that knowledge? 20:39:57 flaper87: I think thats a good thing to do too. 20:39:57 leadership isn't something you learn by taking a course 20:39:58 The same thing goes for the TC 20:40:12 my main objection to formal leadership training is that it's usually pretty terrible 20:40:16 anteaya, ++ 20:40:34 lifeless: forced to go? now i don't even like talking about it. 20:40:49 anteaya: there are definitely skills that can be explained, though 20:40:49 erm 20:40:50 jeblair: I'm trying to understand where you are coming from! I had no intention of suggesting mandatory attendance 20:41:02 I'm not sure we could force people to go even if we wanted to 20:41:09 to extend anteaya's comment, leadership isn't something you learn by taking a course, but you may learn it by teaching a course ;) 20:41:11 I'm worried that having only some target people attend the course will create a divide between them and those who couldn't or chose not to attend 20:41:14 ttx: welcome ? 20:41:15 dhellmann: I think mentoring is the best support structure of leadership skills, which yes can be learned 20:41:16 :D 20:41:23 ttx: ola! 20:41:24 sorry had connection trouble 20:41:25 fungi: true 20:41:38 * ttx catches up 20:41:55 anteaya: ++ 20:42:03 anteaya : ok, not everyone learns the same way 20:42:07 anteaya: I think having a mentor is an important thing; courses can be useful too. 20:42:09 dhellmann: yes 20:42:22 What I'm saying is: I'd like us to do something as a community rather than doing it at the summit. If we can get something going, we may as well start thinking how to bring this to the summit 20:42:25 right now we have neither mentors nor courses. 20:42:29 are we at quorum now ? Or should we just defer all topics to next week ? 20:42:44 ttx: we had at least 7 when we started 20:42:47 ttx: if we can make it in 20mins, sure 20:42:54 ttx: I don't know; I've another discussion topic to cover stil... 20:42:58 sure == "lets do it now" 20:43:08 the leadership summits which run before oscon might make an interesting model. how well have those worked (for those who have attended)? 20:43:33 fungi : good question 20:43:35 fungi: I believe they're an unconference, but yes an interesting model 20:44:06 FWIW I suspect I can find a volunteer to research a -good- trainer if we were to have funds 20:44:06 lifeless : do you have a specific course in mind, yet? or are you seeking approval for the general idea at this point? 20:44:07 leadership unconference tends to cause leaders to emerge in ways that leadership lectures do not 20:44:31 Not a big fan of mandatory leadership training. Agree with fungi all the leadership training I've been forced to go through so far has been pretty terrible 20:44:38 so the main thing I want to do is to get enough consensus that we can write a request to the foundation asking for money to put something on 20:44:47 ttx: ++ 20:44:49 ttx: I don't think this was meant to be mandatory 20:44:50 which we'd need for either an unconference or a course 20:44:53 ttx: +1 20:44:55 I advocate for money for a formal mentoring program 20:44:58 dhellmann: it was not meant to be mandatory 20:44:59 i'm more of an unconference person myself, so maybe it's different strokes for different folks 20:45:04 which includes outreachy 20:45:10 I have never taken a leadership training course that has been good. I have taken many leadership training courses 20:45:17 this does not mean that future courses will not be good 20:45:24 merely that my past experience has been rather bad 20:45:27 mordred: so gothicmindfood in particular was interested in this 20:45:35 mordred: then again, see the definition of madness 20:45:39 mordred: I rather suspect she could find a good one, if there is a good one 20:45:42 The only leadership training course that I know to be good involves many months of mud, and is too large a time sacrifice for most folk. 20:45:46 lifeless: do you have a specific training in mind ? 20:45:49 lifeless: I agree with you on that 20:46:05 ttx: not at this point; it sounds like that would be important to a number of the folk here 20:46:13 persia: that is my experience as well 20:46:19 persia: including the mud 20:46:35 fungi: I'm a big fan of the leadership summits and have attended a couple times, they're particularly valuable to me since they also still tend to skew toward open source leadership/communities 20:46:36 ttx: so I'll see if gothicmindfood can lay hands on one. I believe zimmermans do one, for instance 20:46:43 actually, three times 20:46:44 persia: now i'm seeing an opportunity to combine leadership training and the stabilization cycle (if we get the right group of people in 6 month mud-based leadership training) 20:46:50 jeblair: ++ 20:46:53 jeblair: ++ 20:47:02 #topic Stabilisation cycle (lifeless) 20:47:07 speaking of 20:47:12 i have no problem bringing it to the foundation staff if there's a more concrete idea, but keep in mind we've just gotten approval for the 2016 budget so some budget wizardry may be necessary 20:47:32 fungi: we allocated _plenty_ of money for the 2016 budget :) 20:47:37 indeed 20:47:42 mordred: i think that was fungi's point :) 20:47:43 so in the cross project session 20:47:45 I forget which one 20:48:04 lifeless: priorities? 20:48:06 there was lots of support for more effort on stabilisation 20:48:08 jeblair: yes 20:48:08 fungi: maybe the thing to do is encourage folks to attend the leadership summit you and pleia2 mentioned 20:48:09 or 'themes'? 20:48:21 jeblair : themes 20:48:29 dhellmann: so a whole extra trip is a big deal for folk with families/larg travel loads 20:48:40 lifeless : encourage not require 20:48:51 dhellmann: I am talking opportunity 20:49:00 dhellmann: e.g. if they want to go but can't 20:49:07 dhellmann: but could do 2 more days on the summit 20:49:24 leadership work fries your brain 20:49:26 dhellmann: for me, I spend 3 days travelling to get anywhere(and back) 20:49:32 I don't see it mixing well with summit 20:49:44 lifeless : yeah, I get it. Just looking at options. 20:49:51 ok so stabilisation 20:50:09 there was considerable concern that we *can't* do stabilisation work because orgs will push stuff up regardless 20:50:46 or perhaps the concern was that we don't have an effective way to tell them that we'll be ignoring most of their feature patches in favor of bug fixes? 20:50:48 I think we as tc need to lead the way to enable it 20:50:57 e.g specifically I'm thinking that we need to: 20:51:16 1) declare that in our view X% of time should be stabilisation work (whether thats 25%, 50%, whatever) for some cycle. 20:51:41 2) tell the *board* that we've declared this and ask them to communicate back to the member companies to please work with on this 20:52:07 3) act as a point of contact for folk feeling squashed out or whatever 20:52:22 I'm told that some companies tie bonuses to employees getting features into upstream 20:52:25 (3) could be a significant time sink 20:52:27 lifeless: I don't expect that to make a lot of difference 20:52:27 so when we push back on features 20:52:34 folk lose money 20:52:36 and get very stressed 20:52:53 when we ignore languishing bugs, openstack breaks and folk lose money 20:52:53 I've the feeling we've tried this before (or at least some projects did) 20:52:54 I think a declaration in enough advance 20:52:56 Am I wrong? 20:53:01 persia: compared to the time lost across 200+ cores dealing with intransigent contributors? 20:53:05 "telling the board" has never worked to influence priorities or get resources for specific things. 20:53:06 persia: drop in the ocean 20:53:13 sorry i missed the meeting ... i got pwned by DST 20:53:26 I have a hard time seeing how any sort of declaration from the TC could be effective here 20:53:27 lifeless: I'd like to suggest an amendment to your suggestoin 20:53:28 russellb: utc for life! 20:53:38 How many of these orgs actually pay attention to what we're already declaring? 20:53:39 russellb: everyone has their turn, thanks for taking one for the team 20:53:42 fungi: someone tell google calendar to support putting things in UTC time :( 20:53:43 lifeless: Yes which implies that we don't really expect to do (3), so it is perhaps inappropriate to claim it? 20:53:44 We have been "telling the board" about a lot of things. 20:53:47 ttx: ++ 20:53:56 like "infra is important" 20:53:58 which is that in 2, we don't tell the board, we go the board and say "we'd like to take a cycle to do a stabalization cycle, whacha think, y'all on board with us?" 20:54:08 russellb: Tell Google Calendar you live in Reykjavik 20:54:12 mestery: the users are telling us they want it, the product wg is telling us they want very *specific* features, and the product wg is a delegate of the board 20:54:13 or "technical writers could be helpful" 20:54:25 persia: noted 20:54:27 I hear some on the board want an even faster feature velocity :/ 20:54:29 just a thought: how about declaring that if by milestone-2 an objective bugs metric per project doesn't reach a level considered stable, the project has to announce an early feature freeze? 20:54:36 persia: no, it implies that we can save a huge amount of time if we can divert the effort from individuals into an org-to-org discussion 20:54:44 apparently you also told the board the big tent was a thing, and then at the last meeting they were all like "wait, what, that happened?" 20:54:52 stevebaker: indeed, and that was brought up at the meeting on monday 20:54:56 fungi: well, 1/24 of the board 20:54:58 lifeless: Ah, at that level. I retract my concern 20:55:00 heh 20:55:01 fungi : to be fair, only a couple of board members seemed surprised 20:55:01 ttx: I'm proposing a specific ask of the board, not a general 'you should know' statement 20:55:26 mordred: whats your amendment ? 20:55:31 which is that in 2, we don't tell the board, we go the board and say "we'd like to take a cycle to do a stabalization cycle, whacha think, y'all on board with us?" 20:55:41 mordred: fair, sure. 20:55:42 lifeless: well, we did formally ask for a few things in the past, too 20:55:51 ttx: like the dco, which we got... 20:56:06 after asking and asking and asking 20:56:09 I belive we also need to be clearer on this 20:56:13 lifeless: that's different from influencing resources 20:56:14 not "we want to do more stabalization" 20:56:15 persistence pays off, apparently 20:56:16 I know that the board members don't actually control the engingeering at their orgs 20:56:26 but rather "N will be a stabalization release with _no_ features" 20:56:29 lifeless: right, my point 20:56:38 but right now the leaders in various projects believe they can't even *try* 20:56:45 it's doable to switch to DCO, that's a board decision. 20:56:45 and we ask the foundation staff to help us communicate that to all of the orgs out there 20:56:47 so I think it is up to us to find a way to enable them 20:56:56 it's much more difficult to relay that nobody should add features 20:57:04 ttx: yes it is 20:57:08 ttx: however, we should still try 20:57:12 I believe it is worth doing 20:57:19 does anyone here object to trying ? 20:57:20 it turns out that we DO have the ability as a project to not take features 20:57:36 Also not sure we can have a blanket % for stable work for all projects 20:57:37 Many orgs will add features in forks, saving them for the following cycle. 20:57:46 persia: ++ 20:57:50 persia: I could care less if they do that. 20:57:58 same here 20:57:59 lifeless : we'd need to be careful with scheduling. Is N too soon? 20:58:06 persia: if we save the core bandwidth - our bottleneck - duing N, (or O, or whatever) - great 20:58:25 there are projects doing multi-cycle schedules 20:58:28 lifeless: when they use engineering that might otherwise collaborate in reviews? 20:58:29 this would just break that 20:58:39 I don't mind trying/fighting for this 20:58:45 ok so it sounds like 20:58:49 Hmm, just two points I want to salvage from the agenda in the remaining 2 min 20:58:50 0) discuss with the PTLs 20:59:00 1) etc my proposal with mordreds amendment 20:59:04 flaper87: multi-cycle schedules might still work with 50% stabilization effort 20:59:04 I'll put up a thing 20:59:04 flaper87 : maybe rather than declaring that all projects will do this, we build a way for a given project to declare that they will do it, and then let them decide when it's appropriate? 20:59:06 ttx: go 20:59:07 Might be a good cross-project session for the next cycle 20:59:22 flaper87: I think we need to socialise this now 20:59:24 stabilization is a tricky thing because there will likely be some features we'll want in a release so for those that do have long term roadmaps they could select 1-2 important ones 20:59:41 flaper87: its a discussion with 4 or so different constituencies 20:59:46 dhellmann: that would be better. Instead of doing it on every project, we let projects to schedule their own 21:00:07 I really feel like some projects have done this but I might be wrong. I'm saying this because I'd like to hear the feedback 21:00:12 flaper87: I don't think the board is capable of agreeing at that granularity 21:00:15 isn't the real thing that's being asked for is the air cover for projects who want to do it and feel that they cannot make the choice to? 21:00:28 exactly, I'm proposing we put in place the air cover 21:00:34 yah 21:00:36 time is off 21:00:41 mordred: yup 21:00:48 'stabilization' is also vague. We should first identify the instabilities 21:01:09 lifeless: end the meeting 21:01:09 edleafe: ++ 21:01:11 :D 21:01:13 #endmeeting