15:30:00 #startmeeting Pre-M4 Developer Meeting 15:30:00 Meeting started Wed Jul 30 15:30:00 2014 UTC. The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html. 15:30:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:30:00 The meeting name has been set to 'pre_m4_developer_meeting' 15:30:22 #topic Project Contacts Please #info in with the Project you are representing 15:30:30 #info edwarnicke controller 15:30:33 #info goldavberg for lispflowmapping 15:30:36 #info Madhu ovsdb 15:30:42 #info rovarga for bgpcep 15:30:44 #info colindixon for ttp 15:30:49 #info tbachman for groupbasedpolicy 15:30:52 #info oflibMichal for openflowjava 15:30:53 #info Hideyuki for VTN 15:31:07 #info Liem for AAA 15:31:28 #chair edwarnicke colindixon dbainbri 15:31:28 Current chairs: colindixon dbainbri edwarnicke phrobb 15:31:30 #info harman for dlux 15:31:30 #info sheena for south plugin for opencontrail 15:31:40 * edwarnicke wonders why #chair always picks on him :( 15:31:47 #chair Madhu 15:31:47 Current chairs: Madhu colindixon dbainbri edwarnicke phrobb 15:32:11 * regXboi notes because he is a fortunate son 15:32:23 #info mlemay for reservation 15:32:43 #info abhijitkumbhare for OpenFlow plugin 15:32:48 @phrobb: it’s IRC only meeting right? 15:32:51 We'll give folks a couple more minutes to join.... 15:33:04 #info paulz for documentation 15:33:08 * edwarnicke thinks maybe meetingbot needs an ongoing attendance tracker ;) 15:33:24 mlemay: yes this meeting is irc only unless there is quorum to add a webex now or in the future 15:33:32 #info LuisGomez for integration 15:33:56 @phrobb: ok sorry just making sure 15:34:37 We will be starting in just a minute. For those joining late, if you are representing a project in the meeting please #info in with that information 15:35:09 #info ChristineH and Chilung for SNMP4SDN project 15:35:34 OK lets get started. Do we have any particular agenda topics that folks would like to make sure we talk about today? 15:35:35 phrobb: my take is we’re missing: Defense4All, L2 Switch, ODL-SDNi App, OpFlex Protocol Agent, PacketCable PCMM, Secure Ntwk Bootstrap Infra, Service Function Chaining, Toolkit, VTN Project, YANG Tools 15:35:38 nm 15:35:40 see vtn 15:36:17 Thanks for the roll call colindixon. Can we get folks to ping those on that absentee list? 15:36:41 #info Rafat for ODL-SDNi 15:36:48 I just pinged Alex Fan... l2switch will be here shortly 15:37:06 #topic Agenda Bashing - Please bring forth any agenda topics you want us to cover today 15:37:14 @edwarnicke thanks! 15:37:32 #info Paul Quinn for SFC 15:38:04 Madhu: I’m guessing you or I can be part of toolkit for today? 15:38:27 ttkacik: are you here for yangtools? 15:38:52 colindixon: yep. 15:38:53 phrobb: so the biggest thing going on is API freeze 15:39:01 #info colindixon and Madhu for toolkit 15:39:03 #info ttkacik for yangtools 15:39:16 #info brockners for snbi 15:39:35 we’re down to only missing 4: Defense4All, L2 Switch, OpFlex Protocol Agent, PacketCable PCMM, 15:39:53 colindixon: API Freeze is a very large requirement of M4, yes 15:40:49 not sure if we have to hash it out here. I took an action item for testopia replacement that LuisGomez requested for 15:41:08 LuisGomez: i believe that is one of your asks on the projects ? 15:41:11 I think we should go over the global M4 expectations 15:41:20 @Madhu… right.. testing is important here... 15:41:33 Madhu: yes 15:41:36 colindixon: I second that :) 15:41:41 LuisGomez: is that for M4 ? 15:41:45 if not. we can skip that here 15:41:49 for example (related to what Madhu is talking about) we have the M4 requirement “Latest possible Continuous System Test Start” 15:42:18 Projects should start reporing and documenting test by M4 15:42:29 it is in the check list 15:42:39 I think LuisGomez wanted to make sure we are less chatty on the OSGI console - so he can get to errors faster 15:42:44 LuisGomez: okay then we have to add this to the agenda as well 15:42:49 LuisGomez: I guess that implies that all the system tests have been defined by M4? 15:42:49 so, unless we’re expecting somebody from D4A, opflex, or packetcable we should start and we’ll nab Alex Fan from l2switch when he gets here 15:42:50 colindixon: and edwarnicke Shall we go through the M4 Status Report Out template I sent yesterday? 15:43:01 phrobb: sounds good 15:43:08 * edwarnicke also thinks meetbot needs a #agendapush #agendapop ;) 15:43:34 edwarnicke: maybe better as a list ;) 15:43:46 #agendarearrange 15:43:56 tbachman:for system test means start working in test plan by M4 15:43:57 #info we’re currently still missing: Defense4All, L2 Switch, OpFlex Protocol Agent, PacketCable PCMM (we are expecting a representative from L2 Switch soon) 15:43:59 tbachman: We could just copy what git stash does ;) #agendastash ... 15:44:03 @all: I’m just wondering if all the demands are realistic for having gone trhought the projects for the feature files I am finding that we might be asking quite a bit in our “checklist” just saying 15:44:11 phrobb: you want to move the topic to the template you sent out 15:44:35 #topic M4 Status Report Template Discussion 15:44:46 #link https://lists.opendaylight.org/pipermail/release/2014-July/000127.html M4 open daylight Helium update 15:45:13 thanks Madhu 15:45:21 #info The first section is to declare/ensure all projects are able to be at API Freeze at this point. Any questions on that one? 15:45:22 do we want to pull out the high-order bits here? 15:45:42 colindixon: elaborate? 15:45:54 nm, that’s what you’re doing :p 15:45:59 :) 15:46:03 phrobb: I’m curious if API freeze means that the YANG file, Java interface file, etc. can’t change? 15:46:26 or if the functions that are present and public need to stay the same with the same signature 15:46:49 i.e., I’m assuming we can add documentation to yang files or java calls 15:47:04 but can we add new functions as long as we don’t change what’s there? 15:47:11 or is this intentionally left vague? 15:47:12 colindixon: I tend to think of the yang files for the MD-SAL stuff as being APIs 15:47:21 edwarnicke: agreed 15:47:26 * ChrisPriceAB I assume you mean Yang files that are only referenced internally within a project. 15:47:39 colindixon: are you saying that out of concern that we still need changes there? 15:47:40 Would others like to weigh in on their expectation? I don't think we want to be intentially vague 15:47:48 colindixon: I would advocate for continuing to allow improvements to comments in yang and java api files 15:47:52 ChrisPriceAB: currently, there’s no way to enforce that, so all YANG files are APIs I think 15:48:18 to be clear — an API needs changing? 15:48:22 #info At the end of this discussion let's document our definition of what "API Freeze" means 15:48:23 edwarnicke: I would also advocate for allowing people to add/change Javadoc in Java and description values YANG 15:48:23 To be clear... I am open to robust discussion on all points :) 15:48:28 to give some flexibility, we should consider API freeze only to make sure it doesn't affect the dependent projects 15:48:47 internal project APIs (that is only consumed within a project) 15:48:56 Madhu: So are you suggesting API freeze only if the API is used by dependent projects? 15:48:58 or adding new interfaces, etc... should not impact anyone else 15:49:00 * tbachman agrees with Madhu 15:49:03 * ChrisPriceAB is a change that affects another project then a bug that needs to be reversed? 15:49:09 +1 to Madhu’s point on dependent projects 15:49:10 * liemmn +1 Madhu 15:49:21 +1 on Madhu's proposal 15:49:28 Madhu: does that mean that leaf projects do not actually have API freeze until code freeze? I would tend to think that is a bad idea 15:49:30 my question was can I change “interface Foo{ int bar(); }” to “interface Foo{ int bar(); int baz(); }” or the moral equivalent since I’m not changing what people were told they could count on 15:49:45 * tbachman jumps on the bandwagon +1 Madhu 15:49:48 or do we want to enforce more rigor than that 15:49:57 +1 on Madhu 15:50:16 rovarga: can u pls explain why it is a bad idea ? 15:50:22 rovarga: I think we’re talking internal APIs only here 15:50:29 @phroob it’s important for level 2 priority projects mainly.. we have many “leaf” projects in our upcoming release 15:50:34 I’d +1 what Madhu suggests, but we don’t have a way to define that currently that I think everyone would agree about 15:50:37 Madhu: One other question though... how do we know if an API is used by a dependent project, and in terms of 'adding' to interfaces... does that mean they don't change once added? 15:50:47 Madhu: because that means project-internal churn up until the very last moment 15:50:48 API's generally indicate behaviour, if I am extending API's I also need to ensure the behaviour is consistent for frozen calls. 15:51:00 ChrisPriceAB: yeah, I agree 15:51:02 rovarga: project internal is going to churn till code-freeze 15:51:15 sorry, APIs mean internal code organization churn 15:51:17 we are talking only about API-freeze here to make sure project dependencies are not affected till last minute 15:51:19 ChrisPriceAB: I am not necessarily objecting there... but I'm curious at what point these added APIs freeze? 15:51:39 edwarnicke: today in OSGi world 15:51:47 rovarga: if there isn’t internal code churn, what’s the difference between that definition of API freeze and code freez? 15:51:49 only those exported interfaces can be imported 15:51:51 Madhu: I think its a good idea to, as you've started to, ask ourselves *why* we are API freezing 15:51:58 so, I see two things we need to nail down quickly: (1) what does it mean for an API to be external and (2) do we want to allow behavior-preserving addition of functions 15:52:22 for (1) I think the only way we can do it is that it’s anything with public scope and all YANG files 15:52:34 tbachman: I would expect that by API freeze, for internal things the project has figured out its internal organization and contracts 15:52:34 colindixon: And for (2) when do those additions freeze 15:52:35 because anyone can use those and we don’t have a good way to track if they are or arent' 15:52:38 colindixon: yes. 15:52:46 @edwarnicke good question, I was reacting to a statement we may be able to extend API's after freeze. (which maybe a grey area, but one to avoid) 15:52:51 please note that 'leaf' projects does not mean they do not have dependencies outside of ODL 15:53:11 ChrisPriceAB: I am really not yet arguing either way on the question... just raising something we need to think through 15:53:11 * ChrisPriceAB good point 15:53:12 so, the question really is: what does the public release plan tell outside entities? 15:53:14 on (1) - note that not all external APIs need to be MD-SAL APIs.. In SNBI we have the somewhat special situation that we also create APIs for the forwarding element 15:53:24 as an example 15:53:35 ovsdb project was waiting on extensibility support 15:53:35 A question: if a project thinks API is frozen - but the dependent project needs the API to change - does this get handled on a case by case basis or is it no. In my opinion this may need to be case by case basis 15:53:40 with the benefit for now, that we don't rely on anyone so far (nor does anyone rely on us) 15:53:43 since it is not available till M4... 15:53:52 how can we add extensions to Yang once the API is frozen ? 15:54:13 rovarga: since the extensions that we will be writing will be consumed within the project, it should not affect anyone else 15:54:36 Madhu: are you sure noone in the world is be writing extensions? 15:54:43 Madhu: Mechanically... that's easy... the extensions are via augmentations 15:55:02 rovarga: don't get your question 15:55:04 I can see rovarga’s point — behavior is changing, even tho the API is the same 15:55:16 (earlier point, that is) 15:55:23 rovarga: oh ya. to me API means syntax and semantics and behaviour 15:55:34 behavior cannot change for external API contract. agreed 15:55:56 yes, I think everyone agrees on that, ChrisPriceAB brought that up (API = syntax + behavior not just type signatures) 15:56:04 so, are we converging 15:56:19 Madhu: 'leaf' projects really says 'leaf within ODL ecosystem as we see it right now'. it does not say anything about people trying to do early integration before the release is out. to those, we are saying that for projects who do not have direct ODL users, the APIs are not frozen until code freeze 15:56:21 Madhu: So no bug fixes to API implementations? Fixing a bug changes behavior ;) 15:56:35 I think everyone agrees that any java field labeled “public” is part of the API that needs to be frozen 15:56:52 edwarnicke: is this API freeze or code freeze ? :) 15:57:00 +1 Madhu, API Freeze should mean (IMHO) that the interface both syntactically and semanticly does not change.. unless for a bug fix… which is similar to "code freeze" 15:57:04 Madhu: I do think rovarga has a point... it is reasonable for those in the extended ecosystem, if we said API freeze at M4 to expect to be able to consume APIs without them changing 15:57:14 @colin: I acutally disagree that API = syntax + behavior.. as a “blackbox” behavior can change.. API never garanteed behaviors 15:57:19 It sounds like currently existing YANG files should be frozen, but there’s some debate as to whether or we can add new YANG files (or augmentations) 15:57:29 +1 Madhu & probb, API Freeze should mean (IMHO) that the interface both syntactically and semanticly does not change.. unless for a bug fix… which is similar to "code freeze" 15:57:40 mlemay: I tend to distinguish API (which is the signatures) from contract (which runs much deeper) 15:58:03 rovarga: edwarnicke on the external ecosystem.... we should really care and cherish that post SNAPSHOT... 15:58:04 Madhu: Also... what about folks who have their APIs at API freeze, but not yet their implementations? 15:58:21 I would propose that you can add behavior-preserving functionality, e.g.., an extra function that doesn’t change existing functions or a YANG augmentation until code freeze 15:58:26 @ed: yes.. and in a world without side-effects it can be contained but here we are talking about projects with side-effects which means that API crawls into behavior 15:58:35 Madhu: Which is quite reasonable given our API Freeze/ Code Freeze split 15:58:51 edwarnicke: let's not go into that particular rathole, please. we do not have resources to describe contracts :) 15:58:53 edwarnicke: we should not confuse API/Code Freeze yes 15:59:11 rovarga: I agree... contracts run much much deeprer 15:59:12 rovarga: edwarnicke both the points are valid for Code Freeze deadline 15:59:23 but for API freeze, it is an API contract between projects 15:59:28 Madhu: so what we are saying is that API freeze really does not say anything, except for infrastructure projects 15:59:29 and honor what is already implemented 15:59:34 freeze what is agreed upon 15:59:36 Madhu: Yep 15:59:44 @Madhu: +1 15:59:49 in that case I think we should've taken this into account during the draft of release plan a categorize the project as such 16:00:01 not 4 days before a freeze is supposed to set in 16:00:02 rovarga: Second not changing the rules at the last minute 16:00:09 ok, do we feel like we’ve converged enough to #info a summary 16:00:15 rovarga: yes. 16:00:25 So... lets look at the minimum shell we can agree on 16:00:30 but am still trying to think what the rules are :) before even anyone trying to change. lol 16:00:30 I might propose (if I didn't miss it) that API's should be able to be bug-reported by users and providers both. This may be due to limitations on the provider or consumer side that are not yet identified. Needs to be agreed by both sides though... 16:00:35 I know that there are folks who want more... 16:00:39 so at this point I would suggest we identify the project who are not able to make API freeze 16:00:51 rovarga: can u define API freeze ? 16:00:57 @colindixon Can you give us a first draft and see how well it sticks? 16:01:00 For example, can we all agree that a java file defining and interface should not change except in its comments? 16:01:24 phrobb: let me try 16:01:27 yes. all public interfaces in place, all yang models structuraly frozen 16:01:35 Madhu: I am suggesting we do an accretive approach... start at the bottom (as my interface file definition does) and march up 16:01:36 rovarga: also. the extensibility support for OFPlugin/OFJava has not fully working yet. 16:01:50 * ChrisPriceAB pushed and in review 16:01:54 By API, I assume only those interfaces exposed by the bundle for external use? Internal interfaces can change. Right? 16:01:59 Madhu: I hear you there... been working on it all morning with the guys 16:02:03 rovarga: does that also mean yang extensions ? 16:02:18 ragbhat: thats my hope as well :) 16:02:25 Hear you Madhu as does edwarnicke 16:02:43 +1 ragbhat, Madhu 16:02:48 Madhu: do you ask about defining new models or modifying existing ones? 16:03:01 rovarga: new extensions 16:03:04 "yang extension" does not parse for me 16:03:08 I am kind of disinclined to count internal only files that happen to be interfaces as APIs... it feels a bit like penalizing folks making good choices 16:03:12 yang augmentation 16:03:20 so a new yang model, which augments an existing model 16:03:25 and thanks edwarnicke (for the extensibility) 16:03:26 rovarga: yes. 16:03:54 Edwarnicke: Agree. Internal interfaces should not count as APIs 16:03:59 There is a lot of discussion about what constitutes API Freeze. Everyone agrees that the type signatures of things "public" in Java should not have any changes and that the high-level behavior should remain the same. For YANG files, a similar rule applies with no structural changes being made. It's not clear if adding new functions, fields, etc. (that don't change the existing ones) should be allowed until M5 or frozen he 16:03:59 those would fall under 'compatible API change", and I would like to see them reviewed and understand why they are late in coming .... 16:04:00 I think we're leaning toward allowed until M5. 16:04:08 that’s my draft 16:04:52 colindixon: +1 16:05:01 * colindixon also notes that we probably want to have a way to declare that a YANG file is meant to be internal and not used by others 16:05:03 rovarga: as for coming in late... u can check with abhijitkumbhare and edwarnicke 16:05:10 colindixon: How do we decide when API additions are frozen then? 16:05:21 M5 16:05:23 code freeze 16:05:24 that’s my take 16:05:26 OK 16:05:45 well - so far its not late Madhu (we can say on M4) 16:05:51 So if we have an API edition that comes in after M4 then it can change in anyway till M5? Not objecting... just want clarity 16:06:01 * ChrisPriceAB late would be after M4 I assume... 16:06:03 API freeze ~= we won’t change or take away what we gave you 16:06:08 abhijitkumbhare: sorry. i meant we have to add extensions only after M4. thats what i meant 16:06:20 OK 16:06:26 code freeze ~= we’re going to stop changing the implementation (or adding other things that we didn’t promise) 16:06:49 edwarnicke: that would be my take 16:07:13 colindixon: +1 16:07:14 colindixon: +1 16:07:14 colindixon: I tend to think of code freeze as 'only bug fixes from here' 16:07:27 colindixon: fair enough, that’s broader than what I said 16:07:39 +1 edwarnicke 16:07:40 edwarnicke: but I agree 16:07:52 colindixon: edwarnicke +1 16:08:00 colindixon: From the Simultaneous Release Plan "Code Freeze (bug fixes only from here)" 16:08:27 edwarnicke: +1 16:08:37 edwarnicke: +1 16:08:50 There is a lot of discussion about what constitutes API Freeze. Everyone agrees that the type signatures of things "public" in Java should not have any changes and that the high-level behavior should remain the same. For YANG files, a similar rule applies with no structural changes being made. Adding new functions, fields, etc. (that don't change the existing ones) will be allowed until code freeze (M5). After that point 16:08:51 bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces. 16:09:07 I clarified and added a last sentence 16:09:20 if people feel happy we can #agreed it and I think this was pretty helpful 16:09:25 I would acutally further qualify code freeze as “Critical/High bug fixes only”. There needs to be some kind of throttling on which bug fixes go in 16:09:28 colindixon: I'm not sure we have complete agreement there (note: I am not disagreeing)... I think some folks would like to allow backward compatible additions 16:10:01 edwarnicke: I’d read those as being allowed 16:10:04 Can we hear the arguments for, if any on "backward compatible additions"? 16:10:10 * edwarnicke is currently trying not to take a position, just get all card on the table 16:10:24 edwarnicke: absolutely 16:10:32 I vote for allowing backward compatible API changes 16:10:44 is that not covered by “Adding new functions, fields, etc.” 16:10:46 ? 16:10:53 ragbhat: How are we defining backward compatible API changes... and when do *those* changes freeze? 16:11:14 because you can only add, remove, and change fields and functions 16:11:16 Anything that does not break existing code is backward compatible 16:11:17 +1 colindixon I read your defintion of API freeze as allowing backward compatible additions 16:11:19 Is there a “code-freeze-freeze” date, post “code-freeze”? 16:11:28 Those freeze at M5 (Code Freeze) 16:11:31 removing and changing is not backward compatible 16:11:34 colindixon: Apologies... I read your definition to fast 16:11:35 so only adding 16:11:45 I would still like to understand when the additions themselves freeze 16:11:49 M5 16:11:51 code freeze 16:12:02 I also thought I had said that “ will be allowed until code freeze (M5).” 16:12:06 OK... so if I add an API to a public interface I can change it in anyway from M4 to M5? 16:12:09 and “After that point only bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces." 16:12:10 But if I add it before M4 I can't? 16:12:17 edwarnicke: yes 16:12:21 that’s my take 16:12:25 Does that feel odd to anyone else? 16:12:35 because we don’t have a formal way to tell people “this is pubilc, but don’t count on it” yet 16:12:40 * edwarnicke still not arguing either way... just trying to make sure he understands 16:12:40 we’d need to add that 16:12:41 Excuse me. SNMP4SDN will report the M4 plan by 8/4. Need to quit the meeting now... 16:12:51 ChristineH: understood 16:12:53 edwarnicke: it sure does, but for projects I care about we will use stricter rules anyway 16:13:03 Can we consider API extentions for "planned functionality only" 16:13:07 ChristineH: minutes will be sent out that you can review 16:13:14 ChrisPriceAB: Planned where? 16:13:19 @ChristineH Thanks very much for joining Christine! 16:13:24 in the SRP as expected fiunctionality 16:13:30 ChrisPriceAB: I’d like to endorse that in spirit, but I don’t think we can enforce it 16:13:33 * ChrisPriceAB implied in the SRP? 16:13:44 SRP doesn't express expected functionality... Proejct Release Plans *might* 16:13:49 colindixon: thanks! I'll review 16:14:05 But the contract on Project Release Plans has always been that they are not proscriptive (meaning they don't forbid work not listed) 16:14:22 ok, so, I’m feeling like we’ve made the progress here we’re going to make and we should take some notes about how to use this to be more precise in Lithium 16:14:29 Yes, but do we say work not listed can impact the API's after API reeze? 16:14:31 f 16:14:47 but that we lack the precision to really push things to be more strict in an enforceable manner 16:15:05 we have 15 minutes left 16:15:11 ChrisPriceAB: That would be a massive last minute change on the projects 16:15:32 3 days to API Freeze and suddently you can't work on stuff not in your Release Plan 16:15:33 colindixon: I'd rather document what we can agree to here for API freeze if possible. 16:15:33 ? 16:15:36 to me API freeze is simple :) 16:15:48 1. Don't break what others are dependent on 16:15:53 2. Freeze what is agreed upon 16:16:03 Madhu: +1 16:16:07 phrobb, edwarnicke, ChrisPriceAB, and others, are you OK with the current summary? 16:16:12 projects have already called out their dependencies in M3, right? 16:16:14 (supposedly) 16:16:30 Madhu: Don't break is not the right answer... because we have a long list of bug fixes that reveal bugs downstream 16:16:33 Madhu: sure, it’s just different people have different ideas about what “break” and “freeze” mean 16:16:39 Madhu: where "others" is strictly limited to OpenDaylight-hosted projects, right? 16:16:47 So we allow new functionality and associated API's to continue to be developed from M4? 16:16:48 colindixon: I am. it would be nice if we could state it as a definition and see if we can get consensus agreement 16:16:50 I am *not* going to leave a bug because it reveals a downstream bug in someone else 16:16:50 rovarga: yes. 16:17:11 Madhu: for Lithium we have to do better than that :) 16:17:12 reiterating this from above: “There is a lot of discussion about what constitutes API Freeze. Everyone agrees that the type signatures of things "public" in Java should not have any changes and that the high-level behavior should remain the same. For YANG files, a similar rule applies with no structural changes being made. Adding new functions, fields, etc. (that don't change the existing ones) will be allowed until cod 16:17:13 freeze (M5). After that point only bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces.” 16:17:22 rovarga: we are in SNAPSHOT :) 16:17:31 tbachman: I haven’t seen these deps formally stated in M3 16:17:32 rovarga: do u really have a contract for SNAPSHOTs ? 16:17:45 can we agree on that at least as a base level to get some agreement and minimize the number of unexpected shifts? 16:17:48 rovarga: for external parties ? 16:17:53 there is a place between snapshot and release, which is called throttle :) 16:17:53 colindixon: It still feels awfully strange to me that if I can just put off the extension API till Monday... I can change it as much as I want till M5 under your proposal 16:18:02 (not that I'm planning to do that... but still) 16:18:20 colindixon: But if I work day and night to get it to folks by tomorrow... I'm stuck with it 16:18:22 edwarnicke: I know, but my logic is that somebody else could have looked at that API assumed it would be there and started working with it 16:18:34 Edwarnicke: What is the issue with that? The point is not to impact other projects 16:18:34 And if they look at it on Tuesday? 16:18:53 edwarnicke: so what is your proposal ? 16:18:57 edwarnicke: fair enough 16:19:03 So if someone brings an API next Tueday, and someone else starts using it next Wednesday... they are just SOL? 16:19:08 Madhu, edwarnicke, colindixon: I am relatively happy with allowing extensibility, as long as any impact on existing functions receives the sternest of frowns. 16:19:20 * ChrisPriceAB dissalowing is behavior setting 16:19:35 ChrisPriceAB: I think you actually may have hit the right solution 16:19:36 frowning 16:19:45 We can't really rules lawyer this all the way 16:20:22 I would suggest we figure out a good heuristic for folks providing additions after M4 to mark them as 'not baked yet' 16:20:27 However this should be well-documented as an interface in flux and you should make a good faith effort to identify users of the API and work with them. 16:20:30 So consumers can get clarity 16:20:32 I’m going to add this 16:20:34 edwarnicke: when is SOL? :-) 16:20:36 And then just frown at bad behavior 16:20:37 that line above 16:20:47 There is a lot of discussion about what constitutes API Freeze. Everyone agrees that the type signatures of things "public" in Java should not have any changes and that the high-level behavior should remain the same. For YANG files, a similar rule applies with no structural changes being made. Adding new functions, fields, etc. (that don't change the existing ones) will be allowed until code freeze (M5). However this shou 16:20:48 be well-documented as an interface in flux and you should make a good faith effort to identify users of the API and work with them. After that point only bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces. 16:20:50 abhijitkumbhare: SOL (Shit out of Luck) 16:21:00 honestly guys to me that ties in component lifecycles 16:21:03 I think that’s about as good as we can do with out a bit more formalism which we can back get 16:21:16 colindixon: I think so to 16:21:17 can’t go back in time and get 16:21:25 In colindixon's summary, we still need to define what "public" API means... Does it mean an API that is depended on by another project? (versus a private API, which is used only within the project)... To me, there is no point to have a no-change rule on an internal API since that is not enforceable. 16:21:26 ChrisPriceAB: +1 to productive use of frownie face 16:21:29 someone changing API after freeze you be labeled experimental 16:21:40 edwarnicke - I knew (we were just joking about it in the room - ChrisPriceAB, etc.) 16:21:43 or something like that.. wheras others could be categorize unstable or stable 16:21:45 liemmn: I meant the puglic keyword 16:21:51 in java 16:22:02 there is no one-size fits all here 16:22:32 I’m going to #info this and we can #agreed it if people agree in a bit 16:22:45 So, if I have an API (that has the word "public interface" in it) but used only within the project, that need to be frozen too? And how would we enforce that if I change that after M4? 16:22:45 colindixon: +1 16:22:50 * ChrisPriceAB still trying to understand the text... 16:22:58 ChrisPriceAB: waits a bit 16:23:05 Sorry... Just seeing how we enforce rules, since, IMO, rules are useless without the ability to enforce them. 16:23:09 * ChrisPriceAB don't hold your breath :) 16:23:09 liemmn: through frowning :) maybe collective frowning 16:23:17 I’d also like 5 minutes to go over other expectations :p 16:23:28 but I think this is the most important thing about M4 16:23:58 so it’s worth spending some time to make sure people understand the spirit of the law and and have some idea of the expected ramifications 16:24:03 colindixon: Second getting it right 16:24:10 colindixon: +1 16:24:22 * tbachman queues up +1 to colindixon 16:24:33 colindixon: +1 16:24:35 colindixon: yep, please repost and lets see if we have consensus 16:24:37 * ChrisPriceAB has also queued it up but... 16:24:39 I’m going to paste it here one more time: 16:24:44 There is a lot of discussion about what constitutes API Freeze. Everyone agrees that the type signatures of things "public" in Java should not have any changes and that the high-level behavior should remain the same. For YANG files, a similar rule applies with no structural changes being made. Adding new functions, fields, etc. (that don't change the existing ones) will be allowed until code freeze (M5). However this shou 16:24:44 be well-documented as an interface in flux and you should make a good faith effort to identify users of the API and work with them. After that point only bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces. 16:24:55 can’t fit it on one line, eh? 16:25:00 Do we need to be specific about the expected behaviour of a consumer that is impacted by an API change? 16:25:16 I can say (the java keyword) after public if liemmn wants 16:25:18 ChrisPriceAB: Good question... I would also like to see if we can work out a convention of marking an interface in flux 16:25:38 Is there an annotation for that? 16:25:49 tbachman: pre-deprecated? 16:25:53 There's a Guava @Beta 16:26:02 but that would require everyone pulling in Guava 16:26:05 Which seems harsh 16:26:17 @colindixon: nice summary however we treat propers as if they were monolitic pieces of ODL.. true for some but many have different moving parts with different “stability” and lifecycle.. if I publish piece X to the release I should be allow to continue working on piece Y in the meantime 16:26:19 edwarnicke: lets add an ODL @Beta annotation 16:26:20 I would like to close this meeting at the hour mark to be respectful of people's time…. 16:26:21 http://stackoverflow.com/questions/9921715/create-prototype-scoped-spring-bean-with-annotations 16:26:40 spring 16:26:41 I’m going to #agree this and add some of the other notes at the end 16:26:46 edwarnicke: prettymyuch everyone already pulls in guava transitively ... 16:26:51 #agree There is a lot of discussion about what constitutes API Freeze. Everyone agrees that the type signatures of things "public" in Java should not have any changes and that the high-level behavior should remain the same. For YANG files, a similar rule applies with no structural changes being made. Adding new functions, fields, etc. (that don't change the existing ones) will be allowed until code freeze (M5). However th 16:26:52 should be well-documented as an interface in flux and you should make a good faith effort to identify users of the API and work with them. After that point only bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces. 16:26:58 #info a few other notes of the discussion 16:27:11 +1 to Colin’s summary. +2 for the following text: Adding new functions, fields, etc. (that don't change the existing ones) will be allowed until code freeze (M5). 16:27:15 #info we need to work out a way for people to complain or get things resolved if they feel an API has been changed on them 16:27:22 colindixon: +1 16:27:27 Madhu: + 1 on Madhu 16:27:34 -1 on Guava dep by default 16:27:41 (did that come out as a single line on other folks’ IRC clients?) 16:27:42 +1 on support for consumers 16:27:42 colindixon: Could I suggest step 1 is that the parties talk amongst themselves? 16:27:55 #info we really want a way to mark something as “in flux” so people aren’t caught unawares by changes (one idea would be to mark it as @deprecated with an explanation in the comments) 16:28:09 #info Process Check to everyone. We seem to have much to discuss when we get together. I would like to know if the Project Contact folks would like to hold this meeting weekly from now till the release (or in the unlikely event we run out of critical topics to discuss)? 16:28:51 edwarnicke: if I'm down a hole trying to hit my dates others problems don't really get through to me. (maybe it's just me, but protect others from my behaviour) Mediation at least the PTL level shoudl be expected. 16:29:11 #info The general idea of this is the following: don’t break people who depend on you. Stay in that spirit. 16:29:17 * ChrisPriceAB PTL_> project contact 16:29:23 ChrisPriceAB: I have no problem with a 'this guys isnt' responding' exscalation 16:29:30 * ChrisPriceAB :) 16:29:32 But it also gets back to how to communicate as well 16:29:36 I don't know about everyone else 16:29:45 hopefully that was helpful 16:29:49 But right now I do occasionally miss some emails going by 16:29:52 sorry it dragged on for so long 16:29:53 * edwarnicke hangs head in shame 16:30:04 thanks colindixon 16:30:05