01:06:18 #startmeeting Karaf Mtg #2 01:06:18 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 01:06:18 The meeting name has been set to 'karaf_mtg__2' 01:06:43 hey phrobb 01:06:52 hey there colindixon 01:07:42 #topic Project Contacts please #info in with the Project you are representing 01:09:05 #info colindixon for TTP 01:11:22 #info Christine is here for SNMP4SDN (I think) 01:12:15 #chair colindixon 01:12:15 Current chairs: colindixon phrobb 01:12:27 #topic project expectations 01:13:15 #info at a high level, we need some information about projects like a description, etc. 01:14:18 #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 #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 #info also to be clear, the version in this file has no semantic impact or relation to bundles 01:19:02 #info the key element in this is the tag 01:20:30 #Info the version here does have *some* meaning because it’s used for very high level dependency tracking 01:21:24 #info lifecycle here is *not* the lifecycle stage of the project, but it is the stability/lifecycle stage of the component 01:23:18 #info colindixon suggests that there should be a lifecycle type at the 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 #info colindixon asks how many components a project will typically have 01:24:28 #info answer is 3-4 max except the controller, for example, the MD-SAL would be a component 01:25:17 #info going forward, we’re going to need to define the possible values for things like or , but we wanted to get the idea out first 01:27:05 #info phrobb asks if component is *the* level at which users can install and uninstall things, not features, not projects 01:27:30 #info mathieu says yes, that’s his idea, it’s up to the community to pick it or not 01:28:32 #info LuisGomez adds that this is useful because we can’t have O(100) features, which we do 01:29:32 #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 #topic packaging 01:30:50 #Info the suggestion is to allow for a variety of packaging approaches, one of which is karaf 01:31:11 #link https://wiki.opendaylight.org/view/Runtime:Karaf_Features_Guidelines guidelines for creating karaf features 01:32:37 #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 #info there’s a lot of description of guidelines about how to craft features, naming, granularity, versioning, etc. 01:35:00 #topic documentation 01:35:16 #info proposal is to use maven sites to make this somewhat easier to deal with 01:35:56 #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:How_To:_Site_Deploy this has documentation on how to do that 01:37:43 #info colindixon asks about the tag in the tag and how it relates to this because it has a tag and an tag 01:38:54 #info response is that the is for more traditional REST APIs we used in the AD-SAL (not clear if RESTCONF will fit in here yet) 01:39:05 #info the site is the maven site and will include javadoc 01:43:25 #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 #action colindixon will think about this a bit and get back in touch with people 01:47:14 #topic testing 01:47:29 #info testing will be covered in a similar set of meetings next week at the same time 01:47:45 #action phrobb to send out meeting invites to cover testing next week 01:52:06 #info Thomas Kee packetcable equally useful meeting 01:54:36 #topic other things going forward 01:55:16 #info some discussion about how/when we should advertise what a component is and how we’re going to use them 01:55:55 #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 #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 #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 #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 #enduser 02:04:11 #endmeeting