15:30:00 <phrobb> #startmeeting Pre-M4 Developer Meeting
15:30:00 <odl_meetbot> 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 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:00 <odl_meetbot> The meeting name has been set to 'pre_m4_developer_meeting'
15:30:22 <phrobb> #topic Project Contacts Please #info in with the Project you are representing
15:30:30 <edwarnicke> #info edwarnicke controller
15:30:33 <goldavberg> #info goldavberg for lispflowmapping
15:30:36 <Madhu> #info Madhu ovsdb
15:30:42 <rovarga> #info rovarga for bgpcep
15:30:44 <colindixon> #info colindixon for ttp
15:30:49 <tbachman> #info tbachman for groupbasedpolicy
15:30:52 <oflibMichal> #info oflibMichal for openflowjava
15:30:53 <hideyuki> #info Hideyuki for VTN
15:31:07 <liemmn> #info Liem for AAA
15:31:28 <phrobb> #chair edwarnicke colindixon dbainbri
15:31:28 <odl_meetbot> Current chairs: colindixon dbainbri edwarnicke phrobb
15:31:30 <harman_> #info harman for dlux
15:31:30 <sheena_> #info sheena  for south plugin for opencontrail
15:31:40 * edwarnicke wonders why #chair always picks on him :(
15:31:47 <phrobb> #chair Madhu
15:31:47 <odl_meetbot> Current chairs: Madhu colindixon dbainbri edwarnicke phrobb
15:32:11 * regXboi notes because he is a fortunate son
15:32:23 <mlemay> #info mlemay for reservation
15:32:43 <abhijitkumbhare> #info abhijitkumbhare for OpenFlow plugin
15:32:48 <mlemay> @phrobb: it’s IRC only meeting right?
15:32:51 <phrobb> We'll give folks a couple more minutes to join....
15:33:04 <paulz> #info paulz for documentation
15:33:08 * edwarnicke thinks maybe meetingbot needs an ongoing attendance tracker ;)
15:33:24 <phrobb> mlemay:  yes this meeting is irc only unless there is quorum to add a webex now or in the future
15:33:32 <LuisGomez> #info LuisGomez for integration
15:33:56 <mlemay> @phrobb: ok sorry just making sure
15:34:37 <phrobb> 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 <ChristineH> #info ChristineH and Chilung for SNMP4SDN project
15:35:34 <phrobb> 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 <colindixon> 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 <colindixon> nm
15:35:40 <colindixon> see vtn
15:36:17 <phrobb> Thanks for the roll call colindixon.  Can we get folks to ping those on that absentee list?
15:36:41 <Rafat> #info Rafat for ODL-SDNi
15:36:48 <edwarnicke> I just pinged Alex Fan... l2switch will be here shortly
15:37:06 <phrobb> #topic Agenda Bashing - Please bring forth any agenda topics you want us to cover today
15:37:14 <phrobb> @edwarnicke thanks!
15:37:32 <paulq> #info Paul Quinn for SFC
15:38:04 <colindixon> Madhu: I’m guessing you or I can be part of toolkit for today?
15:38:27 <colindixon> ttkacik: are you here for yangtools?
15:38:52 <Madhu> colindixon: yep.
15:38:53 <colindixon> phrobb: so the biggest thing going on is API freeze
15:39:01 <colindixon> #info colindixon and Madhu for toolkit
15:39:03 <ttkacik> #info ttkacik for yangtools
15:39:16 <brockners> #info brockners for snbi
15:39:35 <colindixon> we’re down to only missing 4: Defense4All, L2 Switch, OpFlex Protocol Agent, PacketCable PCMM,
15:39:53 <phrobb> colindixon:  API Freeze is a very large requirement of M4, yes
15:40:49 <Madhu> 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 <Madhu> LuisGomez: i believe that is one of your asks on the projects ?
15:41:11 <colindixon> I think we should go over the global M4 expectations
15:41:20 <mlemay> @Madhu… right.. testing is important here...
15:41:33 <LuisGomez> Madhu: yes
15:41:36 <edwarnicke> colindixon: I second that :)
15:41:41 <Madhu> LuisGomez: is that for M4 ?
15:41:45 <Madhu> if not. we can skip that here
15:41:49 <colindixon> for example (related to what Madhu is talking about) we have the M4 requirement “Latest possible Continuous System Test Start”
15:42:18 <LuisGomez> Projects should start reporing and documenting test by M4
15:42:29 <LuisGomez> it is in the check list
15:42:39 <abhijitkumbhare> 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 <Madhu> LuisGomez: okay then we have to add this to the agenda as well
15:42:49 <tbachman> LuisGomez: I guess that implies that all the system tests have been defined by M4?
15:42:49 <colindixon> 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 <phrobb> colindixon:  and edwarnicke Shall we go through the M4 Status Report Out template I sent yesterday?
15:43:01 <colindixon> phrobb: sounds good
15:43:08 * edwarnicke also thinks meetbot needs a #agendapush #agendapop ;)
15:43:34 <tbachman> edwarnicke: maybe better as a list ;)
15:43:46 <tbachman> #agendarearrange
15:43:56 <LuisGomez> tbachman:for system test means start working in test plan by M4
15:43:57 <colindixon> #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 <edwarnicke> tbachman: We could just copy what git stash does ;) #agendastash ...
15:44:03 <mlemay> @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 <colindixon> phrobb: you want to move the topic to the template you sent out
15:44:35 <phrobb> #topic M4 Status Report Template Discussion
15:44:46 <Madhu> #link https://lists.opendaylight.org/pipermail/release/2014-July/000127.html M4 open daylight Helium update
15:45:13 <colindixon> thanks Madhu
15:45:21 <phrobb> #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 <colindixon> do we want to pull out the high-order bits here?
15:45:42 <phrobb> colindixon:  elaborate?
15:45:54 <colindixon> nm, that’s what you’re doing :p
15:45:59 <phrobb> :)
15:46:03 <colindixon> phrobb: I’m curious if API freeze means that the YANG file, Java interface file, etc. can’t change?
15:46:26 <colindixon> or if the functions that are present and public need to stay the same with the same signature
15:46:49 <colindixon> i.e., I’m assuming we can add documentation to yang files or java calls
15:47:04 <colindixon> but can we add new functions as long as we don’t change what’s there?
15:47:11 <colindixon> or is this intentionally left vague?
15:47:12 <edwarnicke> colindixon: I tend to think of the yang files for the MD-SAL stuff as being APIs
15:47:21 <colindixon> edwarnicke: agreed
15:47:26 * ChrisPriceAB I assume you mean Yang files that are only referenced internally within a project.
15:47:39 <tbachman> colindixon: are you saying that out of concern that we still need changes there?
15:47:40 <phrobb> Would others like to weigh in on their expectation?  I don't think we want to be intentially vague
15:47:48 <edwarnicke> colindixon: I would advocate for continuing to allow improvements to comments in yang and java api files
15:47:52 <colindixon> ChrisPriceAB: currently, there’s no way to enforce that, so all YANG files are APIs I think
15:48:18 <tbachman> to be clear — an API needs changing?
15:48:22 <phrobb> #info At the end of this discussion let's document our definition of what "API Freeze" means
15:48:23 <colindixon> edwarnicke: I would also advocate for allowing people to add/change Javadoc in Java and description values YANG
15:48:23 <edwarnicke> To be clear... I am open to robust discussion on all points :)
15:48:28 <Madhu> to give some flexibility, we should consider API freeze only to make sure it doesn't affect the dependent projects
15:48:47 <Madhu> internal project APIs (that is only consumed within a project)
15:48:56 <edwarnicke> Madhu: So are you suggesting API freeze only if the API is used by dependent projects?
15:48:58 <Madhu> 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 <abhijitkumbhare> +1 to Madhu’s point on dependent projects
15:49:10 * liemmn +1 Madhu
15:49:21 <brockners> +1 on Madhu's proposal
15:49:28 <rovarga> 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 <colindixon> 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 <colindixon> or do we want to enforce more rigor than that
15:49:57 <mlemay> +1 on Madhu
15:50:16 <Madhu> rovarga: can u pls explain why it is a bad idea ?
15:50:22 <tbachman> rovarga: I think we’re talking internal APIs only here
15:50:29 <mlemay> @phroob it’s important for level 2 priority projects mainly.. we have many “leaf” projects in our upcoming release
15:50:34 <colindixon> 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 <edwarnicke> 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 <rovarga> Madhu: because that means project-internal churn up until the very last moment
15:50:48 <ChrisPriceAB> 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 <colindixon> ChrisPriceAB: yeah, I agree
15:51:02 <Madhu> rovarga: project internal is going to churn till code-freeze
15:51:15 <rovarga> sorry, APIs mean internal code organization churn
15:51:17 <Madhu> we are talking only about API-freeze here to make sure project dependencies are not affected till last minute
15:51:19 <edwarnicke> ChrisPriceAB: I am not necessarily objecting there... but I'm curious at what point these added APIs freeze?
15:51:39 <Madhu> edwarnicke: today in OSGi world
15:51:47 <tbachman> rovarga: if there isn’t internal code churn, what’s the difference between that definition of API freeze and code freez?
15:51:49 <Madhu> only those exported interfaces can be imported
15:51:51 <edwarnicke> Madhu: I think its a good idea to, as you've started to, ask ourselves *why* we are API freezing
15:51:58 <colindixon> 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 <colindixon> 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 <rovarga> tbachman: I would expect that by API freeze, for internal things the project has figured out its internal organization and contracts
15:52:34 <edwarnicke> colindixon: And for (2) when do those additions freeze
15:52:35 <colindixon> because anyone can use those and we don’t have a good way to track if they are or arent'
15:52:38 <Madhu> colindixon: yes.
15:52:46 <ChrisPriceAB> @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 <rovarga> please note that 'leaf' projects does not mean they do not have dependencies outside of ODL
15:53:11 <edwarnicke> 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 <rovarga> so, the question really is: what does the public release plan tell outside entities?
15:53:14 <brockners> 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 <Madhu> as an example
15:53:35 <Madhu> ovsdb project was waiting on extensibility support
15:53:35 <abhijitkumbhare> 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 <brockners> with the benefit for now, that we don't rely on anyone so far (nor does anyone rely on us)
15:53:43 <Madhu> since it is not available till M4...
15:53:52 <Madhu> how can we add extensions to Yang once the API is frozen ?
15:54:13 <Madhu> rovarga: since the extensions that we will be writing will be consumed within the project, it should not affect anyone else
15:54:36 <rovarga> Madhu: are you sure noone in the world is be writing extensions?
15:54:43 <edwarnicke> Madhu: Mechanically... that's easy...  the extensions are via augmentations
15:55:02 <Madhu> rovarga: don't get your question
15:55:04 <tbachman> I can see rovarga’s point — behavior is changing, even tho the API is the same
15:55:16 <tbachman> (earlier point, that is)
15:55:23 <Madhu> rovarga: oh ya. to me API means syntax and semantics and behaviour
15:55:34 <Madhu> behavior cannot change for external API contract. agreed
15:55:56 <colindixon> yes, I think everyone agrees on that, ChrisPriceAB brought that up (API = syntax + behavior not just type signatures)
15:56:04 <colindixon> so, are we converging
15:56:19 <rovarga> 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 <edwarnicke> Madhu: So no bug fixes to API implementations?  Fixing a bug changes behavior ;)
15:56:35 <colindixon> I think everyone agrees that any java field labeled “public” is part of the API that needs to be frozen
15:56:52 <Madhu> edwarnicke: is this API freeze or code freeze ? :)
15:57:00 <phrobb> +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 <edwarnicke> 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 <mlemay> @colin: I acutally disagree that API = syntax + behavior.. as a “blackbox” behavior can change.. API never garanteed behaviors
15:57:19 <colindixon> 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 <ChrisPriceAB> +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 <edwarnicke> mlemay: I tend to distinguish API (which is the signatures) from contract (which runs much deeper)
15:58:03 <Madhu> rovarga: edwarnicke on the external ecosystem.... we should really care and cherish that post SNAPSHOT...
15:58:04 <edwarnicke> Madhu: Also... what about folks who have their APIs at API freeze, but not yet their implementations?
15:58:21 <colindixon> 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 <mlemay> @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 <edwarnicke> Madhu: Which is quite reasonable given our API Freeze/ Code Freeze split
15:58:51 <rovarga> edwarnicke: let's not go into that particular rathole, please. we do not have resources to describe contracts :)
15:58:53 <Madhu> edwarnicke: we should not confuse API/Code Freeze yes
15:59:11 <edwarnicke> rovarga: I agree... contracts run much much deeprer
15:59:12 <Madhu> rovarga: edwarnicke both the points are valid for Code Freeze deadline
15:59:23 <Madhu> but for API freeze, it is an API contract between projects
15:59:28 <rovarga> Madhu: so what we are saying is that API freeze really does not say anything, except for infrastructure projects
15:59:29 <Madhu> and honor what is already implemented
15:59:34 <Madhu> freeze what is agreed upon
15:59:36 <edwarnicke> Madhu: Yep
15:59:44 <mlemay> @Madhu: +1
15:59:49 <rovarga> 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 <rovarga> not 4 days before a freeze is supposed to set in
16:00:02 <edwarnicke> rovarga: Second not changing the rules at the last minute
16:00:09 <colindixon> ok, do we feel like we’ve converged enough to #info a summary
16:00:15 <Madhu> rovarga: yes.
16:00:25 <edwarnicke> So... lets look at the minimum shell we can agree on
16:00:30 <Madhu> but am still trying to think what the rules are :) before even anyone trying to change. lol
16:00:30 <ChrisPriceAB> 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 <edwarnicke> I know that there are folks who want more...
16:00:39 <rovarga> so at this point I would suggest we identify the project who are not able to make API freeze
16:00:51 <Madhu> rovarga: can u define API freeze ?
16:00:57 <phrobb> @colindixon Can you give us a first draft and see how well it sticks?
16:01:00 <edwarnicke> For example, can we all agree that a java file defining and interface should not change except in its comments?
16:01:24 <colindixon> phrobb: let me try
16:01:27 <rovarga> yes. all public interfaces in place, all yang models structuraly frozen
16:01:35 <edwarnicke> 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 <Madhu> rovarga: also. the extensibility support for OFPlugin/OFJava has not fully working yet.
16:01:50 * ChrisPriceAB pushed and in review
16:01:54 <ragbhat> By API, I assume only those interfaces exposed by the bundle for external use? Internal interfaces can change. Right?
16:01:59 <edwarnicke> Madhu: I hear you there... been working on it all morning with the guys
16:02:03 <Madhu> rovarga: does that also mean yang extensions ?
16:02:18 <Madhu> ragbhat: thats my hope as well :)
16:02:25 <abhijitkumbhare> Hear you Madhu as does edwarnicke
16:02:43 <phrobb> +1 ragbhat, Madhu
16:02:48 <rovarga> Madhu: do you ask about defining new models or modifying existing ones?
16:03:01 <Madhu> rovarga: new extensions
16:03:04 <rovarga> "yang extension" does not parse for me
16:03:08 <edwarnicke> 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 <Madhu> yang augmentation
16:03:20 <rovarga> so a new yang model, which augments an existing model
16:03:25 <abhijitkumbhare> and thanks edwarnicke (for the extensibility)
16:03:26 <Madhu> rovarga: yes.
16:03:54 <ragbhat> Edwarnicke: Agree. Internal interfaces should not count as APIs
16:03:59 <colindixon> 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 <rovarga> 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 <colindixon> I think we're leaning toward allowed until M5.
16:04:08 <colindixon> that’s my draft
16:04:52 <ragbhat> 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 <Madhu> rovarga: as for coming in late... u can check with abhijitkumbhare and edwarnicke
16:05:10 <edwarnicke> colindixon: How do we decide when API additions are frozen then?
16:05:21 <colindixon> M5
16:05:23 <colindixon> code freeze
16:05:24 <colindixon> that’s my take
16:05:26 <edwarnicke> OK
16:05:45 <abhijitkumbhare> well - so far its not late Madhu (we can say on M4)
16:05:51 <edwarnicke> 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 <colindixon> API freeze ~= we won’t change or take away what we gave you
16:06:08 <Madhu> abhijitkumbhare: sorry. i meant we have to add extensions only after M4. thats what i meant
16:06:20 <abhijitkumbhare> OK
16:06:26 <colindixon> code freeze ~= we’re going to stop changing the implementation (or adding other things that we didn’t promise)
16:06:49 <colindixon> edwarnicke: that would be my take
16:07:13 <tbachman> colindixon: +1
16:07:14 <hideyuki> colindixon: +1
16:07:14 <edwarnicke> colindixon: I tend to think of code freeze as 'only bug fixes from here'
16:07:27 <colindixon> colindixon: fair enough, that’s broader than what I said
16:07:39 <phrobb> +1 edwarnicke
16:07:40 <colindixon> edwarnicke: but I agree
16:07:52 <Madhu> colindixon: edwarnicke +1
16:08:00 <edwarnicke> colindixon: From the Simultaneous Release Plan "Code Freeze (bug fixes only from here)"
16:08:27 <hideyuki> edwarnicke: +1
16:08:37 <tbachman> edwarnicke: +1
16:08:50 <colindixon> 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 <colindixon> bug fixes can be applied, so this would include not adding anything to (or changing anything about) any interfaces.
16:09:07 <colindixon> I clarified and added a last sentence
16:09:20 <colindixon> if people feel happy we can #agreed it and I think this was pretty helpful
16:09:25 <ragbhat> 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 <edwarnicke> 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 <colindixon> edwarnicke: I’d read those as being allowed
16:10:04 <phrobb> 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 <colindixon> edwarnicke: absolutely
16:10:32 <ragbhat> I vote for allowing backward compatible API changes
16:10:44 <colindixon> is that not covered by “Adding new functions, fields, etc.”
16:10:46 <colindixon> ?
16:10:53 <edwarnicke> ragbhat: How are we defining backward compatible API changes... and when do *those* changes freeze?
16:11:14 <colindixon> because you can only add, remove, and change fields and functions
16:11:16 <ragbhat> Anything that does not break existing code is backward compatible
16:11:17 <phrobb> +1 colindixon I read your defintion of API freeze as allowing backward compatible additions
16:11:19 <tbachman> Is there a “code-freeze-freeze” date, post “code-freeze”?
16:11:28 <ragbhat> Those freeze at M5 (Code Freeze)
16:11:31 <colindixon> removing and changing is not backward compatible
16:11:34 <edwarnicke> colindixon: Apologies... I read your definition to fast
16:11:35 <colindixon> so only adding
16:11:45 <edwarnicke> I would still like to understand when the additions themselves freeze
16:11:49 <colindixon> M5
16:11:51 <colindixon> code freeze
16:12:02 <colindixon> I also thought I had said that “ will be allowed until code freeze (M5).”
16:12:06 <edwarnicke> OK... so if I add an API to a public interface I can change it in anyway from M4 to M5?
16:12:09 <colindixon> 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 <edwarnicke> But if I add it before M4 I can't?
16:12:17 <colindixon> edwarnicke: yes
16:12:21 <colindixon> that’s my take
16:12:25 <edwarnicke> Does that feel odd to anyone else?
16:12:35 <colindixon> 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 <colindixon> we’d need to add that
16:12:41 <ChristineH> Excuse me. SNMP4SDN will report the M4 plan by 8/4. Need to quit the meeting now...
16:12:51 <colindixon> ChristineH: understood
16:12:53 <rovarga> edwarnicke: it sure does, but for projects I care about we will use stricter rules anyway
16:13:03 <ChrisPriceAB> Can we consider API extentions for "planned functionality only"
16:13:07 <colindixon> ChristineH: minutes will be sent out that you can review
16:13:14 <edwarnicke> ChrisPriceAB: Planned where?
16:13:19 <phrobb> @ChristineH Thanks very much for joining Christine!
16:13:24 <ChrisPriceAB> in the SRP as expected fiunctionality
16:13:30 <colindixon> 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 <edwarnicke> SRP doesn't express expected functionality... Proejct Release Plans *might*
16:13:49 <ChristineH> colindixon: thanks! I'll review
16:14:05 <edwarnicke> 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 <colindixon> 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 <ChrisPriceAB> Yes, but do we say work not listed can impact the API's after API reeze?
16:14:31 <ChrisPriceAB> f
16:14:47 <colindixon> but that we lack the precision to really push things to be more strict in an enforceable manner
16:15:05 <tbachman> we have 15 minutes left
16:15:11 <edwarnicke> ChrisPriceAB: That would be a massive last minute change on the projects
16:15:32 <edwarnicke> 3 days to API Freeze and suddently you can't work on stuff not in your Release Plan
16:15:33 <phrobb> colindixon:  I'd rather document what we can agree to here for API freeze if possible.
16:15:33 <edwarnicke> ?
16:15:36 <Madhu> to me API freeze is simple :)
16:15:48 <Madhu> 1. Don't break what others are dependent on
16:15:53 <Madhu> 2. Freeze what is agreed upon
16:16:03 <ragbhat> Madhu: +1
16:16:07 <colindixon> phrobb, edwarnicke, ChrisPriceAB, and others, are you OK with the current summary?
16:16:12 <tbachman> projects have already called out their dependencies in M3, right?
16:16:14 <tbachman> (supposedly)
16:16:30 <edwarnicke> 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 <colindixon> Madhu: sure, it’s just different people have different ideas about what “break” and “freeze” mean
16:16:39 <rovarga> Madhu: where "others" is strictly limited to OpenDaylight-hosted projects, right?
16:16:47 <ChrisPriceAB> So we allow new functionality and associated API's to continue to be developed from M4?
16:16:48 <phrobb> 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 <edwarnicke> I am *not* going to leave a bug because it reveals a downstream bug in someone else
16:16:50 <Madhu> rovarga: yes.
16:17:11 <rovarga> Madhu: for Lithium we have to do better than that :)
16:17:12 <colindixon> 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 <colindixon> 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 <Madhu> rovarga: we are in SNAPSHOT :)
16:17:31 <mlemay> tbachman: I haven’t seen these deps formally stated in M3
16:17:32 <Madhu> rovarga: do u really have a contract for SNAPSHOTs ?
16:17:45 <colindixon> 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 <Madhu> rovarga: for external parties ?
16:17:53 <rovarga> there is a place between snapshot and release, which is called throttle :)
16:17:53 <edwarnicke> 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 <edwarnicke> (not that I'm planning to do that... but still)
16:18:20 <edwarnicke> colindixon: But if I work day and night to get it to folks by tomorrow... I'm stuck with it
16:18:22 <colindixon> 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 <ragbhat> Edwarnicke: What is the issue with that? The point is not to impact other projects
16:18:34 <edwarnicke> And if they look at it on Tuesday?
16:18:53 <Madhu> edwarnicke: so what is your proposal ?
16:18:57 <colindixon> edwarnicke: fair enough
16:19:03 <edwarnicke> So if someone brings an API next Tueday, and someone else starts using it next Wednesday... they are just SOL?
16:19:08 <ChrisPriceAB> 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 <edwarnicke> ChrisPriceAB: I think you actually may have hit the right solution
16:19:36 <edwarnicke> frowning
16:19:45 <edwarnicke> We can't really rules lawyer this all the way
16:20:22 <edwarnicke> 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 <colindixon> 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 <edwarnicke> So consumers can get clarity
16:20:32 <colindixon> I’m going to add this
16:20:34 <abhijitkumbhare> edwarnicke: when is SOL? :-)
16:20:36 <edwarnicke> And then just frown at bad behavior
16:20:37 <colindixon> that line above
16:20:47 <colindixon> 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 <colindixon> 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 <edwarnicke> abhijitkumbhare: SOL (Shit out of Luck)
16:21:00 <mlemay> honestly guys to me that ties in component lifecycles
16:21:03 <colindixon> 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 <edwarnicke> colindixon: I think so to
16:21:17 <colindixon> can’t go back in time and get
16:21:25 <liemmn> 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 <edwarnicke> ChrisPriceAB: +1 to productive use of frownie face
16:21:29 <mlemay> someone changing API after freeze you be labeled experimental
16:21:40 <abhijitkumbhare> edwarnicke -  I knew (we were just joking about it in the room - ChrisPriceAB, etc.)
16:21:43 <mlemay> or something like that.. wheras others could be categorize unstable or stable
16:21:45 <colindixon> liemmn: I meant the puglic keyword
16:21:51 <colindixon> in java
16:22:02 <mlemay> there is no one-size fits all here
16:22:32 <colindixon> I’m going to #info this and we can #agreed it if people agree in a bit
16:22:45 <liemmn> 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 <Madhu> colindixon: +1
16:22:50 * ChrisPriceAB still trying to understand the text...
16:22:58 <colindixon> ChrisPriceAB: waits a bit
16:23:05 <liemmn> 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 <Madhu> liemmn: through frowning :) maybe collective frowning
16:23:17 <colindixon> I’d also like 5 minutes to go over other expectations :p
16:23:28 <colindixon> but I think this is the most important thing about M4
16:23:58 <colindixon> 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 <edwarnicke> colindixon: Second getting it right
16:24:10 <hideyuki> colindixon: +1
16:24:22 * tbachman queues up +1 to colindixon
16:24:33 <LuisGomez> colindixon: +1
16:24:35 <phrobb> colindixon:  yep, please repost and lets see if we have consensus
16:24:37 * ChrisPriceAB has also queued it up but...
16:24:39 <colindixon> I’m going to paste it here one more time:
16:24:44 <colindixon> 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 <colindixon> 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 <tbachman> can’t fit it on one line, eh?
16:25:00 <ChrisPriceAB> Do we need to be specific about the expected behaviour of a consumer that is impacted by an API change?
16:25:16 <colindixon> I can say (the java keyword) after public if liemmn wants
16:25:18 <edwarnicke> 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 <tbachman> Is there an annotation for that?
16:25:49 <colindixon> tbachman: pre-deprecated?
16:25:53 <edwarnicke> There's a Guava @Beta
16:26:02 <edwarnicke> but that would require everyone pulling in Guava
16:26:05 <edwarnicke> Which seems harsh
16:26:17 <mlemay> @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 <Madhu> edwarnicke: lets add an ODL @Beta annotation
16:26:20 <phrobb> I would like to close this meeting at the hour mark to be respectful of people's time….
16:26:21 <tbachman> http://stackoverflow.com/questions/9921715/create-prototype-scoped-spring-bean-with-annotations
16:26:40 <tbachman> spring
16:26:41 <colindixon> I’m going to #agree this and add some of the other notes at the end
16:26:46 <rovarga> edwarnicke: prettymyuch everyone already pulls in guava transitively ...
16:26:51 <colindixon> #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 <colindixon> 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 <colindixon> #info a few other notes of the discussion
16:27:11 <abhijitkumbhare> +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 <colindixon> #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 <tbachman> colindixon: +1
16:27:27 <mlemay> Madhu: + 1 on Madhu
16:27:34 <mlemay> -1 on Guava dep by default
16:27:41 <tbachman> (did that come out as a single line on other folks’ IRC clients?)
16:27:42 <ChrisPriceAB> +1 on support for consumers
16:27:42 <edwarnicke> colindixon: Could I suggest step 1 is that the parties talk amongst themselves?
16:27:55 <colindixon> #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 <phrobb> #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 <ChrisPriceAB> 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 <colindixon> #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 <edwarnicke> ChrisPriceAB: I have no problem with a 'this guys isnt' responding' exscalation
16:29:30 * ChrisPriceAB :)
16:29:32 <edwarnicke> But it also gets back to how to communicate as well
16:29:36 <edwarnicke> I don't know about everyone else
16:29:45 <colindixon> hopefully that was helpful
16:29:49 <edwarnicke> But right now I do occasionally miss some emails going by
16:29:52 <colindixon> sorry it dragged on for so long
16:29:53 * edwarnicke hangs head in shame
16:30:04 <Madhu> thanks colindixon
16:30:05 <ChrisPriceAB> thanks colin!
16:30:08 <edwarnicke> ChrisPriceAB: My point being I agree communication is keey
16:30:08 <colindixon> phrobb: do we have time to touch on anything else or do we want to end now and do this again next week?
16:30:09 <tbachman> chin-up edwarnicke ! :)
16:30:21 <tbachman> colindixon: thx for capturing!
16:30:23 <edwarnicke> ChrisPriceAB: Want to make sure we set expectations around how so folks get heard
16:30:26 * ChrisPriceAB huzzah
16:30:32 <LuisGomez> phrobb: +1 to weekly meetings until we all get clear here
16:30:39 <tbachman> phrobb: +1
16:30:44 <mlemay> prhobb: +1
16:30:46 <Madhu> LuisGomez: i will work with you offline on the test documentation and we can send email to the project contacts
16:30:47 <colindixon> #topic wrapping up
16:30:47 <phrobb> @colindixon: That's what I was asking.  we have other topics but it is late in some TZs and we should cut this meeting at an hour
16:30:59 <ragbhat> phrobb: +1
16:31:04 <edwarnicke> I'm fine with holding them... but I don't think changing Simultaneous Release *requirements* this late is fair to folks
16:31:11 <Madhu> phrobb: webex next time ?
16:31:19 <colindixon> #info we didn’t get through everything we wanted here, so please, *please*, PLESE read the status summary e-mail phrobb sent out
16:31:20 <Madhu> phrobb: it will be a bit more faster I believe
16:31:23 <edwarnicke> Madhu: I actually find the IRC meetings more productive for this than webex
16:31:31 <LuisGomez> Madhu: thanks
16:31:31 <phrobb> Yes, I can put up a webex also… I agree it can be faster
16:31:37 <edwarnicke> phrobb: Please don
16:31:38 <edwarnicke> t
16:31:44 * rovarga would like to avoid the Hydrogen release experience as much as possible
16:31:46 <Madhu> edwarnicke: just for speeding things
16:31:48 <edwarnicke> I find the IRC meetings productive
16:31:54 <tbachman> rovarga: +1
16:31:56 <edwarnicke> I'm not sure I'd bother trying to do this with voice
16:31:59 <colindixon> #info phrobb would like to make this meeting time a weekly meeting
16:32:04 <edwarnicke> Madhu: Speed up how
16:32:12 <edwarnicke> It slows things down because only one person can talk at a time
16:32:14 * tbachman has nothing but +1’s for all
16:32:14 <phrobb> at edwarnicke and Madhu: I will do whatever the majority wants to do
16:32:28 <Madhu> phrobb: i don't mind either ways :)
16:32:31 <colindixon> #info Madhu asks for a WebEx in the future edwarnicke does not, and colindixon would tend to fall on edwarnicke’s side here
16:32:35 <Madhu> just a suggestion and am not religious
16:32:38 <edwarnicke> Seriously... a webex for this would be useless
16:33:06 <ChrisPriceAB> I thought this went really well, but am open to improvement.  This fence is very comfortable.
16:33:15 <paulq_> but in webex I could see Ed's cool lights ;)
16:33:16 <colindixon> ChrisPriceAB: :-)
16:33:20 <phrobb> #action phrobb to set up another Release meeting for next wednesday same time.. some one else will chair/start the meeting as phrobb will be on vacation
16:33:30 * edwarnicke switches his internal lighting to orange
16:33:35 <colindixon> phrobb: I’ll let you do the #endmeeting
16:33:40 <rovarga> unless we can get a proper structure, webex will be largely useless
16:33:46 <colindixon> rovarga: +1 to that
16:34:11 <phrobb> It's sounding like we will stay with irc only.  That is what I will set up
16:34:25 <rovarga> and we need to hash out a *simple* set of tests to see what constitutes an API breakage, otherwise we're just going back and forth
16:34:28 <Madhu> phrobb: thanks. fine by me :)
16:34:37 <colindixon> phrobb: I’m not as religious about it as edwarnicke, but I’d lean that way too
16:34:52 <mlemay> rovarga: I’m with you on that.. but how is this going in by monday?
16:35:02 <phrobb> If you have any questions on the M4 report out template, send them to me or to the designated person on the template (Luis G., Mathieu L, Paul Z. etc).
16:35:14 <colindixon> rovarga: really I think we need to have people formally declare “this file is an API I am expecting to formally export and I will not change it”
16:35:23 <rovarga> mlemay: it's not. it has to go in before Lithium opens
16:35:31 <colindixon> #info If you have any questions on the M4 report out template, send them to me or to the designated person on the template (Luis G., Mathieu L, Paul Z. etc).
16:35:38 <rovarga> I would make it an absolute prerequisite to project plannming
16:35:47 <phrobb> OK, I'm calling this meeting over.  Thanks to everyone for a very good discussion!
16:35:49 <ChrisPriceAB> @mlemay:  sersiously monday is only monday if you think it is monday.  relax man!
16:35:52 <colindixon> thanks
16:36:03 <phrobb> #endmeeting