17:05:01 #startmeeting 17:05:01 Meeting started Mon Apr 7 17:05:01 2014 UTC. The chair is colindixon. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:05:01 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:05:39 * regXboi really wants #sand 17:05:57 #chair regXboi 17:05:57 Current chairs: colindixon regXboi 17:06:10 colindixon: oh thanks much 17:06:32 #topic Versioning and Automated Weekly Releases 17:06:59 regXboi: you're welcome 17:08:20 #info slides will follow the meeting 17:08:27 #info also were apparently sent to the mailing list 17:09:41 #link http://lists.opendaylight.org/pipermail/discuss/attachments/20140401/db9039f6/attachment-0001.ppt this is the link for the slides that were sent to the mailing list 17:10:10 #topic parent pom 17:11:14 #info edwarnicke___ points out that variables in parent poms are annoying because they play badly with the version change plugin if they are not used in the parent pom itself 17:11:32 #info surekha replies that it's worked for her so far 17:13:28 #info edwarnicke___ asks why we went with versions instead of dependency management 17:13:43 we needs to record 17:13:49 who is host? 17:15:36 #info the answer is that there are two ways to do versioning: either properties or dependency management 17:15:45 recording 17:15:51 thanks networkstatic 17:16:02 glad Madhu_ remembered lol 17:16:17 #info by using properties it is possible to target the version plugin to only update the properties section of the pom 17:16:51 thanks regXboi, I think you get this stuff much more so than I do 17:17:22 #info edwarnicke__ continues to ask about the dependency management versions 17:20:02 #info the idea is to define the versions at the project level and keeping dependency management at the bundle level 17:20:29 it's just this: 17:20:37 dependency mgmt is where you define version 17:20:46 cdub: yeppas 17:20:53 why to you need to use a property to re-define version in dependency section 17:21:14 cdub: it's just have them all at the same place 17:21:31 yes, and put it in dependcy mgmt 17:21:33 mlemay, cdub: though it's not clear how we enforce that 17:21:38 cdub: usually you will use properties at the beginning of the file for each dep.. so that you don't have to scroll trhough dep management 17:21:41 that's the whole point 17:22:07 mlemay: sure...then put properties in dependcy mgmt 17:22:50 cdub: yup.. that's how most projects do it 17:23:44 mlemay: right 17:24:09 #info regXboi asks "why weekly?" 17:24:22 mlemay: what i heard (that i don't like) is: 17:24:42 properties, depmgmt, and dep (w/ properties specified here) 17:27:27 personally, i'd say s/weekly/per-milestone/ 17:27:38 #agree weekly cadence makes more sense than daily 17:27:46 cdub: I agree 17:27:48 +1 17:27:52 +1 17:27:54 #agree I think weekly builds with milestone releases 17:28:03 hey if it doesnt work we can always 17:28:09 adjust 17:28:15 cat ran across keyboard 17:29:34 cat was chasing the mouse? 17:30:15 heh 17:32:13 #info edwarnkice__ is concerned about how to tell versioning and release plugins are working or not when semantic versioning is used 17:34:34 #topic semantic versioning 17:35:28 #info edwarnicke___ points out that we've had bugs in how the versions plugin worked which has made it difficult to tell if we were skewed 17:35:53 #info edwarnicke___ says that semantic versioning at the bundle-level makes it hard to tell if this happens by human visual inspection 17:39:09 #info the answer is to have exactly one variable (for version) per-bundle in the parent pom (with one parent pom per project) 17:40:49 #info regXboi ok w/ version per project 17:40:53 #info regXboi and edwarnicke___ point out that life might be much easier with the idea of one version per project 17:41:02 * cdub notes this quickly before ryan changes mind ;) 17:42:36 * edwarnicke___ switches to making sure that the semantic version voices get heard... 17:43:24 cdub: nice :) 17:43:34 ;) 17:45:07 #info mlemay says that you probably want project-level versioning *and* bundle-level versioning and we don't have to change 17:46:25 omg 17:46:47 :) 17:46:59 regXboi: omg why ? 17:47:57 Madhu_: are you proposing to allow bundles to be imported at run-time willi-nilli? 17:48:12 with the comment that "there is no project"? 17:48:20 regXboi: no sir. 17:48:28 i mean project exists purely from an admin standpoint 17:48:29 check out karaf-based features: http://fusesource.com/docs/esb/4.2/deploy_osgi/DeployFeatures-Create.html 17:48:58 Madhu_: Well put and true I believe 17:49:04 Madhu_: (would that it were not) 17:49:21 p2 feature : http://wiki.eclipse.org/Equinoxc/p2/FAQ 17:50:31 #link that previous link is http://wiki.eclipse.org/Equinox/p2/FAQ 17:52:20 #link karaf-based features: http://fusesource.com/docs/esb/4.2/deploy_osgi/DeployFeatures-Create.html 17:52:39 the link needs to immediately follow the #link command or it doesn't work (fixigin) 17:52:48 #link http://fusesource.com/docs/esb/4.2/deploy_osgi/DeployFeatures-Create.html karaf-based features 17:53:10 #link http://wiki.eclipse.org/Equinox/p2/FAQ p2 feature 17:53:17 #info both links from mlemay 17:54:39 Documentation of which versions of "projects/bundles" have been tested by Luis' team is going to be key 17:55:01 yes, what integration team validates is the key 17:55:29 I that needs to be part of release notes 17:58:50 alagalah: Agreed 17:58:53 #topic general ideas around federation vs. centralization of versioning 17:59:00 can somebody try to summarize things? 17:59:17 sorry colindixon, I'm not sure where we are 17:59:24 colindixon: consensus algo failing... 17:59:34 cdub: lol 17:59:40 #info there is a large debate about where versions for bundles (or projects) should be maintained 18:00:43 to me as long as I can work properly with ranges [0.0.0, 1.0.0) I'm happy 18:02:56 #agree summary (via edwarnicke__): 1. each project should have one and only one parent pom hierarchy. 2. the root parent pom of a project should have a version variable for each external bundle a project depends on (the version string can be a range). 3. Any place a dependency version is used in the project, it should use the version defined in the root parent pom 18:05:55 #chair cdub 18:05:55 Current chairs: cdub colindixon regXboi 18:06:00 I need to drop 18:06:09 but regXboi or cdub should be able to do the endmeeting command now 18:06:19 ok... cdub and/or I will handle things - thanks colindixon 18:06:24 thanks! 18:09:16 #info rovarga can we speed up the verify (not further choke the existing verify queue) 18:09:34 #info answer: ... maybe ... 18:11:33 #info in hydrogen integration project pulled different bundles than within projects 18:11:57 #info a cross project audit should catch this 18:12:41 #info and this audit should be report only 18:14:32 #info report inconsistencies at regular builds (aka weekly) 18:15:20 #info patches coming...need some coordination to start from leaf and move to root projects 18:15:27 #endmeeting