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