01:06:18 <phrobb> #startmeeting Karaf Mtg #2 01:06:18 <odl_meetbot> Meeting started Thu Jul 24 01:06:18 2014 UTC. The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html. 01:06:18 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 01:06:18 <odl_meetbot> The meeting name has been set to 'karaf_mtg__2' 01:06:43 <colindixon> hey phrobb 01:06:52 <phrobb> hey there colindixon 01:07:42 <phrobb> #topic Project Contacts please #info in with the Project you are representing 01:09:05 <colindixon> #info colindixon for TTP 01:11:22 <colindixon> #info Christine is here for SNMP4SDN (I think) 01:12:15 <phrobb> #chair colindixon 01:12:15 <odl_meetbot> Current chairs: colindixon phrobb 01:12:27 <colindixon> #topic project expectations 01:13:15 <colindixon> #info at a high level, we need some information about projects like a description, etc. 01:14:18 <colindixon> #link https://wiki.opendaylight.org/view/Simultaneous_Release:Project_Expectations the page descripbing expectations (including an example of the metadata in the line above) 01:14:55 <colindixon> #info just to be clear, this is *not* a pom.xml flie, it’s a metadata file to descibe key things about a project 01:16:36 <colindixon> #info also to be clear, the version in this file has no semantic impact or relation to bundles 01:19:02 <colindixon> #info the key element in this is the <component> tag 01:20:30 <colindixon> #Info the version here does have *some* meaning because it’s used for very high level dependency tracking 01:21:24 <colindixon> #info lifecycle here is *not* the lifecycle stage of the project, but it is the stability/lifecycle stage of the component 01:23:18 <colindixon> #info colindixon suggests that there should be a lifecycle type at the <project> level that is the project’s lifecycle stage and maybe name lifecycle in a component something else (or at least document it well) 01:24:10 <colindixon> #info colindixon asks how many components a project will typically have 01:24:28 <colindixon> #info answer is 3-4 max except the controller, for example, the MD-SAL would be a component 01:25:17 <colindixon> #info going forward, we’re going to need to define the possible values for things like <type> or <category> , but we wanted to get the idea out first 01:27:05 <colindixon> #info phrobb asks if component is *the* level at which users can install and uninstall things, not features, not projects 01:27:30 <colindixon> #info mathieu says yes, that’s his idea, it’s up to the community to pick it or not 01:28:32 <colindixon> #info LuisGomez adds that this is useful because we can’t have O(100) features, which we do 01:29:32 <colindixon> #info at a technical level, features are the unit which can be installed and activated individually, but we’re going to provide extra tooling around it at the component level 01:30:07 <colindixon> #topic packaging 01:30:50 <colindixon> #Info the suggestion is to allow for a variety of packaging approaches, one of which is karaf 01:31:11 <colindixon> #link https://wiki.opendaylight.org/view/Runtime:Karaf_Features_Guidelines guidelines for creating karaf features 01:32:37 <colindixon> #info features are basically a way to group a set of OSGi bundles to make them easier to manage and easier for others to depend on 01:34:19 <colindixon> #info there’s a lot of description of guidelines about how to craft features, naming, granularity, versioning, etc. 01:35:00 <colindixon> #topic documentation 01:35:16 <colindixon> #info proposal is to use maven sites to make this somewhat easier to deal with 01:35:56 <colindixon> #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:How_To:_Site_Deploy this has documentation on how to do that 01:37:43 <colindixon> #info colindixon asks about the <documentation> tag in the <component> tag and how it relates to this because it has a <site> tag and an <apiLocation> tag 01:38:54 <colindixon> #info response is that the <apiLocation> is for more traditional REST APIs we used in the AD-SAL (not clear if RESTCONF will fit in here yet) 01:39:05 <colindixon> #info the site is the maven site and will include javadoc 01:43:25 <colindixon> #info some discussion on RESTCONF and ways we could proceed. Mathieu asks if there’s a way to get a wadl from the stuff. colindixon doesn’t know if this is possible to do that. 01:43:42 <colindixon> #action colindixon will think about this a bit and get back in touch with people 01:47:14 <colindixon> #topic testing 01:47:29 <colindixon> #info testing will be covered in a similar set of meetings next week at the same time 01:47:45 <colindixon> #action phrobb to send out meeting invites to cover testing next week 01:52:06 <xsited> #info Thomas Kee packetcable equally useful meeting 01:54:36 <colindixon> #topic other things going forward 01:55:16 <colindixon> #info some discussion about how/when we should advertise what a component is and how we’re going to use them 01:55:55 <colindixon> #info phrobb says probably tomorrow’s TSC is too soon to do this and we probably do want the TSC to bless this 01:57:24 <colindixon> #info maybe take until *next* week’s thing is to get a list of components that we expect in the Helium release 01:57:51 <colindixon> #info it seems like something like 1-2 components per project on average is about right, so that means ~50 total in Helium 01:58:28 <colindixon> #info part of making that sane to show to the user is using categorization so components that are libraries should *not* be shown to a user 02:02:25 <colindixon> #enduser 02:04:11 <colindixon> #endmeeting