15:31:32 <phrobb> #startmeeting Helium_M3_Developer_Meeting
15:31:32 <odl_meetbot> Meeting started Wed Jul  9 15:31:32 2014 UTC.  The chair is phrobb. Information about MeetBot at http://ci.openstack.org/meetbot.html.
15:31:32 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:31:32 <odl_meetbot> The meeting name has been set to 'helium_m3_developer_meeting'
15:31:36 * edwarnicke looks appropriately innocent
15:32:00 <colindixon> hello all :-)
15:32:03 <phrobb> chair edwarnicke regXboi colindixon
15:32:08 <mlemay> #info Mathieu Lemay is present representing the reservation project
15:32:17 <phrobb> #chair edwarnicke regXboi colindixon
15:32:17 <odl_meetbot> Current chairs: colindixon edwarnicke phrobb regXboi
15:32:28 <paulz> #info Paul Zimmerman here for documentation
15:32:28 <edwarnicke> #info Ed Warnicke - controller
15:32:31 <colindixon> #info colindixon is present representing the TTP project
15:32:43 <regXboi> I'm not going to info in, I'm not representing anybody :)
15:32:43 <edwarnicke> phrobb: Could we start with some agenda bashing?
15:32:50 <brockners> #info Frank Brockners is here representing SNBI (secure network bootstrapping infra)
15:32:54 <edwarnicke> phrobb: I know that for example I'd like to try to understand what to do for docs
15:32:55 <Madhu> #info Madhu Venugopal for ovsdb
15:33:01 <LuisGomez> #info Luis Gomez from Integration
15:33:02 <amit_> #Info Amit Mandke here for L2 Switch
15:33:02 <sarathbg> #info Sarath for VTN
15:33:04 <edwarnicke> phrobb: And we have the question of Release Vehicles etc
15:33:05 <dkehnx1> #info dkehn representing opflex
15:33:05 <phrobb> Yes, let's get everyone to #info in for their projects first
15:33:07 <liemmn> #info Liem for AAA
15:33:09 <hideyuki> #info Hideyuki Tai for VTN project
15:33:09 <Rafat> #info Rafat Jahan for ODL-SDNi App
15:33:13 <edwarnicke> phrobb: Awesome :)
15:33:27 <mlemay> @ed & phrobb can we also talk documentation?
15:33:30 <paulq> #info Paul Quinn is here representing SFC
15:33:37 <ChristineH> #info Christine Hsieh for SNMP4SDN project
15:34:13 <abhijitkumbhare> #info Abhijit Kumbhare OpenFlow Plugin project
15:34:56 <regXboi> is that everybody?
15:35:05 <edwarnicke> mlemay: I want to talk docs badly :)
15:35:16 <edwarnicke> regXboi: Who are we missing?
15:35:16 <harman_> #info Harman Singh dlux project
15:35:23 <oflibMichal> #info oflibMichal for openflowjava
15:35:29 <regXboi> let's go look
15:36:26 <phrobb> so think we are missing BGPCEP, defense4all, GBP, Lisp, PacketCable, plugin2oc, toolkit, and yangtools
15:36:46 <colindixon> do we need to add a feature to the odl_meetbot to have report in with expected strings
15:36:47 <colindixon> ?
15:36:53 <phrobb> did I incorrectly call out someone who is here?
15:36:55 <colindixon> maybe worth seeing if we can
15:37:00 <regXboi> that looks right to me phrobb
15:37:19 <edwarnicke> Pinging folks to round them up
15:37:29 <colindixon> so, let’s #info that and we can move on with them chiming in as we go?
15:37:44 <phrobb> I know that PacketCable can't make it
15:37:50 <dkutenic> #info Dana for bgpcep
15:38:26 <Priyanka> #info Dana for Southbound plugin to the OpenContrail Platform
15:38:47 <Priyanka> #info Priyanka Chopra for Southbound plugin to the OpenContrail Platform
15:39:15 <phrobb> #info missing projects are: defense4all, GBP, Lisp, PacketCable, toolkit, and yangtools
15:39:46 <phrobb> moving on to agenda bashing....
15:39:53 <phrobb> #topic Agenda Bashing
15:40:10 <ttkacik> #info Tony for YANGTools
15:40:10 <phrobb> #info Those that have topics they want to be sure we discuss, please #info them in now
15:40:17 <phrobb> welcome Tony
15:40:28 <regXboi> #info release vehicles (read karaf)
15:40:32 <regXboi> #info documentation production
15:40:41 <regXboi> #info and documentation "ambering"
15:40:57 <readams> is there a call for this?  I've been suddenly told to join this meeting
15:41:18 <abhijitkumbhare> No -its over IRC
15:41:32 <phrobb> No call readams
15:42:00 <readams> OK thanks
15:42:08 <regXboi> readams: info in for GBP :)
15:42:22 <phrobb> Any other agenda topics?
15:42:22 <readams> #info readams for GBP
15:42:55 <edwarnicke> phrobb: What do we have so far for agenda topics?
15:43:13 <edwarnicke> phrobb: I see them now
15:43:20 <edwarnicke> regXboi: please define "ambering"
15:43:28 <phrobb> Do we have someone here form OpenFlow Plugin?
15:43:30 <mlemay> @regXboi.. on documentation there is the question of documentation location (what is in docs project vs what projects should provide) dunno if you want to add that in or it’s part of that discsuion item
15:43:43 <abhijitkumbhare> Yes
15:43:46 <readams> I think that's when they post notices on freeway signs looking for information leading to documentation
15:43:51 <phrobb> thanks abhijitkumbhare
15:43:57 <regXboi> by ambering I mean I want the documentation to be in a place where it is *FIXED* for all time
15:44:05 <regXboi> and subsequent development won't change it
15:44:15 <regXboi> we don't have any such location for Hydrogen docs now
15:44:28 <edwarnicke> regXboi: Understood
15:44:28 <regXboi> and it's going to be part of the fun and frolic of the stable release
15:44:44 <phrobb> #info we are still missing Defense4All, Lisp Flow Mapping Service, and Toolkit
15:45:11 <xsited> #info Thomas Kee for PacketCable
15:45:17 <edwarnicke> #info secondary topic after all others: stable/hydrogen, are we good to go?
15:45:20 <Madhu> akim: can u info in for Toolkit ?
15:45:37 <phrobb> #topic Release Vehicles (aka Karaf)
15:45:40 <akim> #info everything looking good
15:46:11 <tbachman> akim: I think Madhu wanted you to info in about representing the toolkit project
15:46:27 <tbachman> (see what xsited did above)
15:46:27 <Madhu> #info akim for Toolkit :)
15:46:28 <phrobb> #info OK, so everyone is here except Defense4All
15:46:39 <edwarnicke> Just got off the phone with the Lisp Flow Mapping Guys. They are on their way
15:46:40 <colindixon> :-)
15:46:55 <goldavberg> hi
15:46:58 <phrobb> regXboi:  want to kick off Release Vehicle discussion?
15:47:04 <edwarnicke> goldavberg: Could you #info in for Lisp Flow Mapping?
15:47:06 <phrobb> Ah good, thanks edwarnicke
15:47:25 <goldavberg> here for lisp :)
15:47:43 <tbachman> goldavberg: you need a “pound” info
15:47:46 <tbachman> (see above)
15:47:53 <edwarnicke> #info goldavberg for Lisp Flow Mapping
15:47:56 <tbachman> :)
15:47:57 <goldavberg> #info lispflowmapping is on schedule, and everything is green
15:48:05 <tbachman> edwarnicke and Madhu: doing the proxy work :)
15:48:07 <regXboi> ok folks
15:48:21 <regXboi> about the only RV idea I've seen that makes sense is the pure karaf stuff
15:49:04 <edwarnicke> #link https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming - Release Vehicle (RV) ideas to date
15:49:16 <regXboi> but that means we need to define features
15:49:17 <edwarnicke> #link https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf - Pure Karaf Proposal
15:50:27 <edwarnicke> Is there anyone who doesn't know about the Release Vehicle Discussion or the Pure Karaf proposal?
15:50:34 <mlemay> @regXboi: need to define features but also the dependencies between them.. right now most of the controller features are in .. also we have openflow related features ready, ovsdb one in the works.. all other projects don’t have it
15:50:45 <colindixon> edwarnicke: my guess is that most people have not followed this closesly
15:50:59 <mlemay> @colin: I’d + 1 that
15:51:07 <hideyuki> colindixon: +1 that
15:51:24 <edwarnicke> mlemay: Would you like to explain Pure Karaf, you are its original advocate (though lots of folks, including me, like it)
15:51:44 <readams> I've been watching it from afar;  I've been waiting for some example of how you would actually do the Karaf stuff
15:51:58 <mlemay> @ed : ok let me take a stab at this..
15:52:17 <phrobb> Pardon my ignorance on Karaf, but would we need some type of config tool to allow the pick&choose of componentry as well?
15:52:25 <readams> Does it mean we'd need to have depedencies twice: once in pom and once in features.xml?
15:52:40 <mlemay> @phrobb: not necessarily
15:53:05 <phrobb> OK, then config-file based then I assume
15:53:41 <mlemay> @readams: pom doesn’T specify dependencies for runtime it only specifies the bundle’s current compile deps for almost all bundles out there.. and most project import the .zip for controller which is a huge runtime blob
15:53:43 <colindixon> do we still need to have “editions"
15:54:21 <edwarnicke> readams: mlemay poms are also notoriously inaccurate at really figuring out runtime dependencies :(  They rock for building, but not so much for the runtime stuff.
15:54:21 <mlemay> phrobb: right now we have minimal container which doesn’t run anything from the startup but you can then specify what you want running at startup
15:54:50 <regXboi> @colindixon: I don't think so
15:54:59 <edwarnicke> #link https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf#User_Driven_Feature_Selection - colindixon: the pure karaf proposal is no Hard Editions
15:55:20 <mlemay> as part of the DLUX ui we’ve done a small feature installer screen which allows user to turn on / off components at runtime
15:55:37 <hideyuki> edwarnicke: does it mean we have no editions in Helium?
15:55:37 <mlemay> #link https://s3.amazonaws.com/uploads.hipchat.com/32585/802758/yx0ltRFqA5enZsW/features.png - Sample Feature management in DLUX UI
15:56:20 <edwarnicke> mlemay: Anyway we could get that to represent 'high level' features
15:56:21 <edwarnicke> ?
15:56:35 <colindixon> so, the next question is how far along are features and karaf?
15:56:40 <mlemay> however we need to choose “where” we put the artifacts (most likely .kar packages.. or can also be provided via any PAX-URL )
15:56:41 <readams> well actually we'll have dependencies three times, once in karaf, once in pom, and once in config subsystem
15:56:41 <colindixon> and how do we test thigs
15:56:49 <liemmn> One of the things AAA is interested in is OSGi security...  How is that different between Karaf vs the OSGi kernel we are using today?  I think a "Karaf for dummies" Wiki would be helpful.
15:57:06 <edwarnicke> hideyuki: I think the suggestion is that rather than trying to pull together editions, which is both hard, and unlikely to actually end up with the combinations users want... we would give them the ability to get the features they actually want
15:57:31 <readams> on security: loading/unloading OSGi bundles at runtime is not something we should be trying to do
15:57:49 <hideyuki> edwarnicke: I see.
15:57:53 <mlemay> @liemm: OSGi security stays OSGi security however you do have container JAAS support and stuff which we could link to AAA project
15:57:53 <icbts> edwarnicke: howdy
15:57:57 <readams> edwarnicke: this is made harder by the fact that currently everything depends on everything else
15:58:22 <liemmn> @mlemay, thanks
15:58:24 <phrobb> mlemay could you describe the additional work that would be needed by all the projects to support Karaf?
15:58:25 <edwarnicke> icbts: Welcome... guys icbts is a core karaf guy who may be able to answer some of our questions
15:58:39 <edwarnicke> readams: Not actually true for everything...
15:58:50 <mlemay> readams: not really true..
15:58:57 <brockners> In case we don't have editions any more, does that mean that any possible combination of features would be tested (would karaf help with that?)
15:58:58 <readams> I attempted to make a trimmed distribution but I couldn't effectively remove much
15:59:26 * icbts reading above a quickly as possible
15:59:38 <mlemay> phrobb: work needed is inclusion of a features file and proper .kar packaging by the project which outlines properly its dependencies
15:59:49 <readams> The model would be presumably any particular application would test its configuration
15:59:58 <readams> So GBP would pull in some set of dependencies and we'd test with that
16:00:24 <readams> You still want a sane tested core platform but we're still a long way from that
16:00:24 * icbts We discussed security concerns in the security analysis meetings a few weeks ago https://wiki.opendaylight.org/view/CrossProject:OpenDaylight_Security_Analysis#OSGi_Runtime_Container_Security_-_OpenDaylight_Apache_Karaf_Distribution
16:00:33 <colindixon> the other major problem about not having editions is that then we have to test 2^f “editions” if we have f features
16:00:38 <mlemay> phrobb: for most projects out there it is trivial… the hard one was controller and it’.s 90% complete some NSFs are still troublesome and we need to revisit the old builtin Webapp the rest is currently in
16:01:01 <edwarnicke> brockners: https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf#Testing_Strategy - the idea is to test the feature in isolation and with everything else
16:01:10 <mlemay> colindixon: no that problem is not about editions it’S about the lock of proper componentization within ODL
16:01:16 <mlemay> *lack
16:01:22 <edwarnicke> brockners: So not full combinatronics, just 'does the feature work by itself'  'does the feature work with everything else'
16:01:44 <readams> colindixon: it's not useful to think of all subsets of features.  A particular application will have specific requirements.  You test the applications
16:01:52 <mlemay> also this can be easily done via PAX-exam tests
16:01:57 <mlemay> makes testing much easier in fact
16:02:12 <brockners> edwarnicke: So what if someone pulls together subsets... - does this mean "it may work"?
16:02:14 <readams> OSGi makes testing very hard in general of course
16:02:22 <edwarnicke> I am also told that features fix a lot of the crazy fragileness of pax-exam that has vexed us
16:02:33 <edwarnicke> brockners: A feature defines all the things it needs to work
16:02:34 <icbts> readams: ?? Use Pax-Exam
16:02:39 <readams> The best solution is, of course, to not use OSGi
16:02:40 <edwarnicke> So if you test the feature, it works
16:02:55 <edwarnicke> Testing agains the kitchen sync is to make sure it doesn't get stomped by something else
16:02:56 <icbts> readams:  https://wiki.opendaylight.org/view/CrossProject:Helium_Release_Vehicle_Brainstorming:Pure_Karaf#Testing_Strategy — that strategy has been used by many prohjects
16:03:14 <icbts> readams: install what you need into the distribution and then test
16:03:15 <colindixon> readams, mlemay: I get that the issue is that we *need* to test some combinations fo things to “bless” them and we need to define those combinations, I think those become editions
16:03:17 <colindixon> am I wrong?
16:03:26 <readams> yea, great, I can't write actual unit tests.  Wonderful...
16:03:29 <edwarnicke> brockners: Am I getting your question... or talking past your question? ;)
16:03:59 <edwarnicke> colindixon: The problem is... nobody has come up with *any* sensible suggestions for Editions for Helium that I am aware of
16:04:03 <icbts> readams:  You can write unit tests
16:04:04 <readams> colindixon: I don't think the "edition" thing makes sense.  You can't just lump together a bunch of stuff
16:04:04 <edwarnicke> It turns out to be hard
16:04:05 <mlemay> readams: I don’T see OSGi going anywhere for ODL.. especially with the current way projects are structured…
16:04:11 <edwarnicke> Thus the Pure Karaf proposal
16:04:23 <colindixon> I don’t think we’re going solve this here
16:04:34 <edwarnicke> colindixon: Solve which thing particularly?
16:04:35 <colindixon> :-/
16:04:35 <xsited> I would like to suggest putting little time on the next TWS meeting agenda after reviewing the wiki
16:04:40 <readams> mlemay: It would solve a lot of problems, but I agree we're unlikely to fix that immediately
16:05:01 <colindixon> edwarnicke: answer the question “what are our release vehicles and how can we test them?"
16:05:04 <edwarnicke> xsited: I think that's a good suggestion
16:05:07 <colindixon> which I think is the question
16:05:15 <edwarnicke> LuisGomez: Could you explain the need from integration to figure something out here?
16:05:18 <colindixon> the TWS agenda is empty to my knowledge
16:05:24 <hideyuki> For Helium, for example, for vtn users, we describe "vtn feature", we describe what bundles should be included in "vtn feature".  And we put the feature description in Integration group git repo. is my understanding right?
16:05:32 <colindixon> becuase it was going to be XSQL, but Sharon is out
16:05:34 <edwarnicke> colindixon: The Pure Karaf proposal has concrete answers to those questions
16:05:38 <icbts> OSGi provides modularity, runtime management, and sanity. Karaf enhances it with easier to admin features and friendly interface - our Pax Exam integration makes testing large integrations sane.
16:06:01 <mlemay> @hideyuki the best is for projects to provide features locally
16:06:08 <Madhu> icbts: +1 . lot of scars using non-karat Pax-Exam
16:06:12 <Madhu> karaf
16:06:18 <readams> OSGi provides nondeterministic loading, incorrect semantics for a controller, slowless, and testing challenges
16:06:19 <LuisGomez> I like karaf way of going things but i still think we need to test some feature combinations that we think are going to be very used
16:06:28 <mlemay> then in integration we integrate the features by adding the different feature repositories to the config / pacakaging
16:06:31 <hideyuki> mlemay: what do you mean "locally
16:06:33 <hideyuki> ?
16:06:34 <edwarnicke> hideyuki: You would define the "vtn feature".  It would describe what bundles (and other features) the "vtn feature" needs.  You probably want to keep that feature file in your vtn project, but we can aggregate a registry in the integration project
16:06:45 <mlemay> @hideyuki local to the project sorry
16:06:45 <abhijitkumbhare> colindixon I think Luis wanted making the OF plugin default on TWS agenda - but now the change to default is done anyway (so not sure if its needed)
16:07:01 <regXboi> so I'll wade back in here
16:07:07 <edwarnicke> LuisGomez: Do we have any idea what those really are? (the feature combinations that will be used)... the feedback I've heard from customers has led me to believe we don't guess that well.
16:07:21 <regXboi> edwarnicke: +1
16:07:28 <mlemay> @Luis : Yes.. we should test some default combinations based on what the test is actually doing
16:07:56 <hideyuki> edwarnicke: Thank you! I can understand it!
16:07:56 <LuisGomez> i will have to think about this
16:07:57 <mlemay> @ed: I’ve gotten the same comment
16:08:07 <hideyuki> mlemay: Thank you! I can got it!
16:08:08 <abhijitkumbhare> Probably it is good idea to note what things will absolutely not work together
16:08:26 <edwarnicke> LuisGomez: Can we agree that *minimally* tests for a feature should run against *just* that feature and against *all features installed* ?
16:08:34 <regXboi> abhijitkumbhare: yes, but that's (unfortunately) likely to be Lithium
16:08:51 <edwarnicke> abhijitkumbhare: Do we know which things won't work together?
16:08:53 <readams> edwarnicke: "all features installed" is a nonsensical concept
16:09:11 <abhijitkumbhare> I remember VTN, OpenDove and Affinity did not work together in Hydrogen
16:09:11 <readams> edwarnicke: I can't run two things that both manage the OF data plane, for example
16:09:13 <edwarnicke> readams: For deployment yes, for detecting features stepping on each other... its actually the best I can think of
16:09:30 <LuisGomez> just the feature means with all recommended dependencies, yes i agree with that
16:09:32 <readams> edwarnicke: my point is that features _do_ step on each other and this is expected
16:09:32 <edwarnicke> readams: Doing so is actually explicitely in our goals for ODL
16:09:51 <edwarnicke> readams: Then we should identify those places directly
16:09:55 <LuisGomez> testing with all features is impossible today
16:09:55 <readams> edwarnicke: This is an unsolved research problem that people have tried and failed to solve for years
16:10:16 <edwarnicke> readams: So I amend to 'just the feature' and 'the feature and everything else not explicitly identified as conflicting'
16:10:39 <mlemay> @all: Features is about packaging, the fact that features step on each other is a lack of internal componentizaiton guidelines and should be provided by a proper component model / metadata at a “add-on” level , features should be able to contribute one or many of these “add-ons” these concepts are orthogonal but linked
16:10:55 <mlemay> what features avoid a huge .zip blob that we’ve been having for editions
16:11:05 <mlemay> *is a huge*
16:11:11 <icbts> mlemay: +1
16:11:32 <readams> edwarnicke: well you can't really define all things that might conflict easily.  Though if you can do virtual packages you might be able to.  For example when I did the packaging for the Big Switch internal floodlight platform, I had a virtual "floodlight-application" package that was provided by and conflicted with anything that needed to control the data plane
16:11:33 <alagalah> I'm here now, sorry for the delay
16:11:48 <edwarnicke> So... folks other than edwarnicke LuisGomez mlemay icbts readams (who have been vocal)... we'd like to hear your thoughts... would you please speak up?
16:11:51 <readams> edwarnicke: Can Karaf handle a similar concept to enforce "exactly one of something"?
16:11:56 <mlemay> also people can download standlaone .kar package drop it in “/deploy” and make add-ons etc.. or otherwise can do feature:install from official repositories
16:12:17 <phrobb> colindixon and madhu:  Can we reserve next Monday's TWS call for this Karaf discussion? So that testing, configuration methods, docs and per-project work needed for pure-Karaf implementation can be discussed more deeply?
16:12:27 <imcharly> I had some internal stuff to take care off... can we repeat this entire discussion   ;)
16:12:28 <Madhu> phrobb: yes. lets do it
16:12:33 <colindixon> phrobb:
16:12:34 <icbts> readams: A sigleton pattern or do you mean only one HTTPD, only one JMS Server ?
16:12:36 <Madhu> am quiet because am listening :)
16:12:37 <colindixon> I’ll put that on the agenda now
16:13:03 <Madhu> readams: has a valid point on features stepping on each other.
16:13:09 <Madhu> and that is unresolved still
16:13:11 <readams> icbts: I mean give an error if the user tries to load, for example, two things that do the same thing
16:13:17 <edwarnicke> Madhu: That's fine... listening is good... just speaking as one of the vocal folks... I worry about not leaving room for others to get a word in edgewise
16:13:20 <Madhu> but the concept of editions that we had for Hydrogen helped
16:13:23 <mlemay> also I don’t know if everyone saw my proposition but a role I would see TSC doing in the future is determining feature level lifecycle to a “stable” feature repository.. because project-level is not appropriate (I might have experimental features in my project) I know it’s out of scope o fthis meeting but it’s an important thing to see where the released feature repositories will be.. now it willl likely b
16:13:24 <mlemay> locally pacakaged for helium
16:13:50 <Madhu> with Karaf... I don't think it changes the notion.
16:13:55 <readams> Ultimately the actual useful unit here is going to be RPM and deb packages
16:14:09 <Madhu> +1 readams yes.
16:14:15 <readams> Nobody really wants to deploy by downloading bundles from nexus
16:14:16 <edwarnicke> mlemay: I think part of that for helium will be identifying the 'top level features' a project wants to represent to the world... for example, OFplugin has lots of cool testing features you should *not* drop into a production deployment... but they are mega handy
16:14:31 <edwarnicke> readams: I disagree entirely with your point no rpms
16:14:40 <edwarnicke> They are important, but not the end all be all
16:14:44 <rockyg> readams: +1
16:14:53 <readams> edwarnicke: You're against the concept of RPMs?
16:15:29 <icbts> having two things that do the same job is fine under OSGi - karaf won’t prevent that. If two features want to grab port 61616 then standard port bind error will happen. Other than that the usual service version rules apply
16:15:33 <tbachmanBrb> <cough> windows <cough>
16:15:52 <edwarnicke> readams: Please read my comment again.  They are important, but they are not the end all be all.  They are deeply natural to Linux Sysadmins, and deeply unnatural to folks used to deploying services written in Java.  Also, work rather poorly and are very difficult to do for Java stuff
16:15:57 <readams> tbachmanBrb: having RPM packages doesn't preclude ZIP or whatever
16:15:59 <edwarnicke> tbachmanBrb: That too :)
16:16:17 <edwarnicke> So... we've been talking about this for 45 minutes, what can we conclude?
16:16:21 <readams> edwarnicke: I've done it before and it works fantastically
16:16:46 <edwarnicke> readams: I have the scars, and also know the folks who have the accumumlated scars at the distro level.  Consider yourself lucky
16:16:57 <LuisGomez> i think if every project declares what is needed for ‘just the feature' and ‘what is conflicting’, we can probably do some testing around but it is possible that with this approach we do not hit the most used feature combination, therefore my concern
16:17:14 <mlemay> readams: rpm / deb could drop at right place but I’d only wrap a kar for that as deb/rpms have no link with the osgi framework
16:17:18 <readams> edwarnicke: well you have to do it right.  When the project fights against you it's harder
16:17:35 <readams> OSGi is one of the ways the project can fight against you
16:18:05 <hideyuki> LuisGomez: +1
16:18:25 <phrobb> Folks this is a great discussion, but may go faster, and we'll have more time for it on the TWS call.  Shall we table this discussion until then?
16:18:41 <colindixon> yeah
16:18:44 <colindixon> please
16:18:50 <colindixon> I’m putting it on the agenda
16:18:52 <rockyg> ++
16:18:54 <Madhu> thanks colindixon
16:18:55 <phrobb> Any opposed…..
16:19:00 <edwarnicke> Quick check for the global folks... are you comfortable with this discussion continuing on the TWS?
16:19:08 <mlemay> Luis: I think it would be hard to test all projects just looking at the list..  TEsting interproject deps will get exponentially difficult… any suggestion?
16:19:10 <hideyuki> edwarnicke: yes.
16:19:20 <phrobb> Moving to next topic…..
16:19:27 <phrobb> #topic Documentation
16:19:31 <goldavberg> edwarnicke: yes
16:19:41 <phrobb> thanks David
16:20:05 <phrobb> paulz:  could you give us a rundown on current doc state and needs?
16:20:12 <mlemay> phrobb: another can of worms ;) hahaha ok on docs.. did everyone see what recommended level of docs from the docs project?
16:20:27 <edwarnicke> mlemay: No, link?
16:20:44 <LuisGomez> mlemay: i will propose some test strategy for karaff offline after this meeting
16:21:27 <mlemay> #link https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Docs_and_Structure#Recommended_Documentation_for_Helium
16:21:30 <rockyg> LuisGomez: Thanks
16:21:34 <paulz> Sure... we have been working on setting up the tooling for structured docs. (Mathieu has been leading that) We had an OK-sized crew when we kicked this off in Feb, but have lost most of the folks due to competing needs. Currently, we need more folks to help pull the docs together
16:22:09 <paulz> It has been suggested that we have a member from each project help with the docs, which would be great.
16:22:35 <mlemay> @all I was wondering are most of the projects using the parent pom project pom file?
16:22:37 <edwarnicke> mlemay: A lot of that templating looks good... but only seems to reflect Hydrogen projects
16:22:48 <mlemay> (related to documentation)
16:23:04 <edwarnicke> mlemay: related how? (curious ;) )
16:24:09 <mlemay> from a “structured” docs standpoint (especially from an API point of view I need to get access to a .WADL file for any northbound) moreover I need to potentially create additional scaffolding for RESTconf + models based off apidoc
16:24:24 <edwarnicke> mlemay: Good to know
16:24:45 <mlemay> right now we have some of the manuals in docs.. however we need proper “chapters” for each of the projects
16:24:52 <edwarnicke> mlemay paulz Do we have immediately executable recommendations... we were all on the line for doc start for M3, but I for one didn't know what to do for it
16:25:21 <mlemay> the question I have for this community at this meeting is would projects rather commit documentation to the “docs” project or would they prefer to have a “standard” location within their repository?
16:25:32 <readams> On documentation: just writing something coherent on the wiki would be a 5233% improvement
16:25:47 <regXboi> mlemay readams: no to wiki
16:25:47 <edwarnicke> mlemay: It would depend... but my instincts would be in the project and have something like docs gather it.
16:26:00 <regXboi> documentation for a release needs to be in a place where it doesn't change on the fly
16:26:03 <edwarnicke> regXboi: Got something else workable now?
16:26:10 <regXboi> it only changes on a release point
16:26:26 <regXboi> I've done work with the site target
16:26:28 <regXboi> in maven
16:26:34 <mlemay> regXboi
16:26:35 <mlemay> yes
16:26:40 <regXboi> and put up wiki pages,  etc. on it
16:26:43 <readams> regXboi: the problem is we've made it too hard to document anything
16:26:46 <regXboi> and we really need to use that
16:26:46 <edwarnicke> regXboi: Is it in a state folks could adopt it?
16:26:50 <mlemay> it is the reason I was asking about parent pom as I wanted to provide a parent Site config
16:26:53 <mlemay> to projectds
16:26:55 <readams> regXboi: there's no structure where you can create documentation that's findable
16:27:06 <regXboi> readams: sorry - wiki loses
16:27:10 <regXboi> anything editable loses
16:27:20 <regXboi> because then you can't trust it
16:27:24 <readams> regXboi: the alternative is, I suspect, no documentation
16:27:37 <mlemay> regXboi: I agree it should be snapshot like everything else
16:27:39 <regXboi> edwarnicke: I think it is consumable
16:27:53 <regXboi> mlemay: no release needs it's own place
16:27:55 <edwarnicke> regXboi: Got a pointer to how folks can do it in their projects?
16:28:01 <abhijitkumbhare> +1 to readams point of wiki - we usually would end up in the alternative of no documentation
16:28:05 <regXboi> edwarnicke: let me go dig
16:28:12 <regXboi> ok, I'll be blunt
16:28:18 <mlemay> #link http://asciidoctor.org/docs/asciidoc-writers-guide/
16:28:23 <regXboi> -2 TO WIKI FOR THIS DOCUMENTATION - ITS A BAD IDEA
16:28:30 <regXboi> and yes I'm shouting
16:28:31 <edwarnicke> regXboi: I think that a 'site' solution like what you are proposing gets both... because SNAPSHOT if the site act like SNAPSHOTS, and releases like releases
16:28:45 <edwarnicke> regXboi: I don't disagree about the desirability of your proposal
16:28:50 <mlemay> regXboi: from a docs project standpoint I would like Ascidoc content + WADL files for API and I’m all set
16:28:52 <edwarnicke> I am pressing on 'how do we get this done'
16:28:59 <paulz> We have some info on how to set up the tooling:
16:28:59 <readams> can we just archive documentation periodically?
16:29:03 * edwarnicke dislikes stuff that can't be done ;)
16:29:04 <paulz> #link https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Tools
16:29:10 <regXboi> mlemay: I've not done anything with repect to Ascidoc
16:29:19 <mlemay> regXboi: these ahve to be versioned along side the code (stable, snapshot, etc..) and pushed to nexus..
16:29:20 <regXboi> I was working within javadoc
16:29:39 <mlemay> Asciidoc is for “instructions” (chapters, etc..)
16:29:43 <readams> javadoc is necessary but not sufficient.  We need a sane developer guide
16:29:51 <alagalah> Can we look at how openstack has done docs ?
16:29:52 <regXboi> looking for where I linked this in
16:29:54 <mlemay> javadoc is API documentation only
16:30:00 <regXboi> alagalah: oh please no
16:30:06 <regXboi> I'm looking at that right now
16:30:14 <alagalah> regXboi: Why? Its nice
16:30:15 <mlemay> algalah: it is already based a bit off it but a little btter I hope
16:30:20 <paulz> We used the OpenStack methodology as a base for our original setup
16:30:22 <edwarnicke> mlemay: I agree... javadoc is often *not* the most useful thing
16:30:33 <regXboi> alagalah: sure it's nice - it's wrong quite a bit of the time
16:30:34 <alagalah> regXboi: I'm not saying adopt wholesale, but we could take ideas
16:30:52 <LuisGomez> paulz: what is the scope of documentation group? global/cross project related documentation or you also cover project specific documentation? if the second i agree you need people from every project to work with you.
16:30:54 <rockyg> Openstack docs are really hard for developers to contribute to.
16:30:58 <regXboi> alagalah: not clear we can cherrypick
16:31:02 <regXboi> rockyg: +1
16:31:04 <mlemay> alagalah: we have different tools, technology and infra setup.. the openstack way 100% doesn’T apply but we did build off some of their stylesheets
16:31:07 <readams> It's possible to make really good javadoc but pretty rare.  And you do need a guide to point you in the right directions.  With ODL though javadoc is close to useless because of the 10 million bundles
16:31:07 <edwarnicke> alagalah: I go way back with docbook... so I expect to find asciidoc workable... but maven sites are also *mega* nice, and very familiar to folks as its the way 3/4 of the java world is doced
16:31:22 <mlemay> ok
16:31:24 <mlemay> @all
16:31:33 <mlemay> here is what I would like
16:31:36 <mlemay> if possible
16:31:36 <readams> edwarnicke: did you just make the claim that maven sites are nice?
16:31:57 <mlemay> #1 Maven Site for each project, #2 Asciidoc chapter for guides, #3 WADL for APIO
16:31:58 <edwarnicke> readams: Very compared to most everything else I've seen.  And familiar to most folks who do any kind of java dev.
16:31:59 <mlemay> *API
16:32:15 <mlemay> that would actually cover all that is required for a proper release IMHO
16:32:26 <edwarnicke> mlemay: Not sure WADL is the best solution for APIO as models can be dynamically augmented...
16:32:30 <paulz> LuisGomez - I think it's both...
16:32:35 <edwarnicke> So... question
16:32:36 <readams> edwarnicke: I've really only seen them used for maven plugins
16:32:36 <regXboi> so, I have two jenkins jobs around site deploy
16:32:41 <regXboi> #link https://jenkins.opendaylight.org/opendove/job/opendove-stable-site-deploy/
16:32:48 <edwarnicke> Could we have maven sites with standard sections that point to asciidoc generated guides?
16:32:58 <regXboi> and #link https://jenkins.opendaylight.org/opendove/job/opendove-master-site-deploy/
16:33:02 <mlemay> ed: yes I need something else for RESTconf but right now for non-restconf at least I have a scalfolding for it
16:33:11 <rockyg> Template for each doc type with needed scaffolding and an example (cut and past real stuff) would help a lot
16:33:30 <edwarnicke> rockyg: +1M
16:33:41 <edwarnicke> rockyg: Do we have templates for each doc type?
16:33:59 <mlemay> rockyg: +1 on that.. thus the reason I was asking about parent pom or whatver.. I want to provide concrete “sample”
16:34:04 <mlemay> for all these artifacts
16:34:30 <mlemay> ed: I don’t think so
16:34:42 <rockyg> The parent POM is the only thing that makes docs in Openstack even editable for devs
16:34:51 <regXboi> heh
16:34:53 <regXboi> #link https://lists.opendaylight.org/pipermail/discuss/2014-April/001976.html
16:34:55 <edwarnicke> OK... so I think the proposal is something like this:
16:35:10 <regXboi> and #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:How_To:_Site_Deploy
16:35:11 <edwarnicke> 1)  Everybody should put up a maven site for their project (at least for their java bits)
16:35:31 <edwarnicke> 2)  Someone should come up with templates for the 'guides' sections in asciidoc
16:35:44 <edwarnicke> 3)  Projects should start keeping their guides in their repos
16:35:52 <edwarnicke> 4)  Roll the 'guides' into the maven sites
16:36:07 <edwarnicke> 5) REST - still some open questions there
16:36:10 <edwarnicke> Did I get that right?
16:36:14 <regXboi> no quite
16:36:17 <regXboi> er not quite
16:36:21 <rockyg> Amostly standard TOC with chapters, sections, subsections would go a long ways for consistency
16:36:23 <regXboi> on #1: Two maven sites
16:36:25 <mlemay> hum ed I’d avoid full guides in projects if posssible
16:36:26 <mlemay> https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=tree
16:36:29 <regXboi> release and snapshot
16:36:39 <mlemay> and concentrate on “chapters"
16:36:49 <edwarnicke> mlemay: That sounds very smart
16:36:52 <edwarnicke> But either way
16:36:57 <mlemay> as in docs we collate the final guides
16:37:00 <edwarnicke> I think it would be good to link them into the maven sites
16:37:14 <regXboi> I agree with links in the maven site
16:37:17 <mlemay> I can do something with that yes
16:37:19 <edwarnicke> I honestly don't even care of the maven sites point to the central collated docs
16:37:27 <regXboi> but I still want 2 maven sites
16:37:34 <edwarnicke> regXboi: Please say more
16:37:46 <mlemay> I also want multiple sites
16:37:47 <regXboi> we need a maven site for snapshot documentation
16:37:54 <regXboi> and we need a maven site for release documentation
16:37:58 <mlemay> for release and for snaphosts
16:38:02 <regXboi> we have to make sure they go different places
16:38:08 <regXboi> mlemay and I are saying the same thing
16:38:10 <mlemay> I agree 1000% with Ryan
16:38:17 <regXboi> if we don't have two, then release docs get lost
16:38:24 <regXboi> which is what happened with Hydrogen
16:38:49 <regXboi> edwarnicke: note - this is a gate on stable/H too :(
16:38:53 <edwarnicke> regXboi: So basically release and SNAPSHOT repos, right?
16:39:00 <regXboi> edwarnicke: yes
16:39:02 <edwarnicke> regXboi: ??? re stable/hydrogen
16:39:03 <mlemay> yes
16:39:13 <edwarnicke> regXboi: I see those as simply two repos for the same docs...
16:39:23 <phrobb> Mlemay, paulz could you augment edwarnicke's proposal or make a different one?  We are running over and I'd like to get an actionable proposal from the docs team for folks to consider before departing this mtg
16:39:25 <regXboi> it's a matter of history
16:39:34 <mlemay> k
16:39:49 <edwarnicke> Madhu: colindixon networkstatic Could we get the concrete docs proposal for the second half of TWS on Monday?
16:40:06 <regXboi> you can think of it as two repos, but as maven says sites - I think of it as sites
16:40:17 <edwarnicke> #info new agenda request... there is a request for respin of stable/hydrogen...
16:40:30 <edwarnicke> regXboi: Tomato, Tomatoe
16:40:37 <rockyg> Or you can think of it as trunk and release branch
16:40:55 <regXboi> respin of stable/hydrogen?
16:40:56 <regXboi> what?
16:40:58 <mlemay> 1) Create maven site by inherinting from a Maven Site configuration from default parent if possible for consistency (look & feel, reports, etc.) actual confent may change…
16:41:01 <Madhu> edwarnicke: if we have the time after the feature discussion, we can add it to the agenda
16:41:02 <edwarnicke> See the release list
16:41:11 <edwarnicke> #link https://lists.opendaylight.org/pipermail/release/2014-July/000037.html
16:41:20 <edwarnicke> Madhu: I'm fine with that :)
16:41:30 <mlemay> 2) Create chapters for guides (install, operations, user guide) so they can be imported in final documentation guides
16:41:42 <edwarnicke> mlemay: OK... so who has what actions for docs?
16:41:50 <regXboi> edwarnicke: oh that :(
16:42:04 <rockyg> So really important then is template for chapter
16:42:20 <edwarnicke> rockyg: I agree... and overall 'what chapters do we need from the projects'
16:42:22 <mlemay> 3) Link guides and any other relevant artifacts + info in sites
16:42:37 <mlemay> 4) Document the API accordingly (RESTconf will need special attention)
16:42:51 <rockyg> mlemay ++
16:43:01 <edwarnicke> OK... I hate to be the action item guy
16:43:10 <edwarnicke> But what are the concrete actions, who is doing them, and by when?
16:43:16 <mlemay> ed: on action item.. it’s me doing that in docs project.. :S
16:43:33 <edwarnicke> mlemay: You have a lot on your plate, anyone else able to help guys?
16:43:41 <paulz> mlemay is doing our tooling... maybe there is someone who can help?
16:43:45 <edwarnicke> mlemay: And I don't think all the action items are on you
16:44:06 <mlemay> ed: exactly  a bit much on the plate at the moment ;)
16:44:12 <regXboi> edwarnicke: I agree... I think some of that is on the projects themselves
16:44:25 <mlemay> @ed: I can at least give out templates
16:44:26 <mlemay> ?
16:44:32 <regXboi> I would expect for example that #1 and #2 are on the projects
16:44:35 <paulz> I'm not well-versed in the tooling... need someone more in tune with Maven, etc
16:44:36 <edwarnicke> So.. here's what I think  I heard that could be made useful AIs:
16:44:40 <mlemay> @ed: action me on the default site structure if you wish
16:44:47 <rockyg> Tmeplates move responsibilities to projects :-)
16:44:54 <edwarnicke> 1)  Clear directions on how to do a maven site for your project (regXboi?  maybe already done)
16:45:03 <mlemay> I already have potential template for guides
16:45:06 <edwarnicke> 2)  Each project needs to get someone named responsible for getting that up
16:45:08 <rockyg> kewl
16:45:30 <mlemay> what I can do is setup how to do it in “reservation” project and send that off
16:45:30 <edwarnicke> 3)  Templates need to be written for chapters (rockyg?)
16:45:30 <regXboi> #link https://wiki.opendaylight.org/view/OpenDaylight_Controller:How_To:_Site_Deploy (for #1)
16:45:34 <mlemay> I have to do it anwyays
16:45:47 <phrobb> Does it make sense to have a person from each project as a contact for the docs team?.. for both cross-project coordination and as the contact for per-project-content?  Shall we have the docs team send a note to release to get those names?
16:45:49 <edwarnicke> 4)  Clear directions on how projects can start contributing their chapters
16:46:00 <edwarnicke> 5)  Projects need to identify a responsible person for their chapters
16:46:10 <rockyg> phrobb +1 a contact point per project on dos
16:46:12 <edwarnicke> 6)  Someone should actually get this stuff clearly on a simple wiki page that can be referenced
16:46:17 <rockyg> ^dos^docs
16:46:20 <mlemay> phrobb: +1 that would be great
16:46:23 <regXboi> edwarnicke: I think #1 is done - see above link
16:46:24 <edwarnicke> So... does that sounds reasonable to folks?
16:46:33 <liemmn> +1
16:46:33 <regXboi> edwarnicke: +1
16:46:40 <edwarnicke> regXboi: Awesome, we just need to get it int #6 then :)
16:47:01 <edwarnicke> regXboi: I am inclined to count #1 as assigned to you and completed then :)
16:47:05 * regXboi confused - I just gave a wiki link
16:47:24 <paulz> I can do the documentation on the wiki pafe once 1-5 are done...
16:47:27 <regXboi> I don't know if it's "simple" but it walks through the whole thing
16:47:36 <regXboi> oh... n/m I get it
16:47:48 <mlemay> @reg / @ed: making sure that project site-deploy via jenkins should be part of M4?
16:47:55 <regXboi> at least with respect to #6
16:48:07 <edwarnicke> #action regXboi 1)  Clear directions on how to do a maven site for your project
16:48:07 <regXboi> and yes _ I have #1 and I think it's done
16:48:23 <edwarnicke> #info regXboi Completed "1)  Clear directions on how to do a maven site for your project"
16:48:36 <edwarnicke> #link  https://wiki.opendaylight.org/view/OpenDaylight_Controller:How_To:_Site_Deploy - for "1)  Clear directions on how to do a maven site for your project"
16:48:38 <regXboi> #info note: that will modify based on the template changes
16:49:00 <edwarnicke> phrobb: Would you mind doing the cat herding for #2 ?
16:49:06 <mlemay> #action mlemay to provide maven site template for consistency across projects
16:49:12 <regXboi> mlemay: can I look to work with you on adapting that link when we have the template?
16:49:22 <mlemay> regXboi: of course
16:49:30 <phrobb> #action phrobb to work with projects for contacts to the docs group
16:49:39 <edwarnicke> phrobb: many thanks
16:49:42 <regXboi> #action regXboi and mlemay to adapt site deploy how to wiki once the template is available
16:49:51 <regXboi> mlemay: thanks :)
16:49:55 <mlemay> @all just out of sanity on my behalf.. which is higher priority docs template vs karaf instructions?
16:49:56 <edwarnicke> phrobb: What is the goal date for #2?
16:50:03 <edwarnicke> rockyg: Are you willing to pick up #3?
16:50:12 <edwarnicke> (or is someone else)
16:50:19 <edwarnicke> mlemay: karaf
16:50:21 <regXboi> edwarnicke: when do APIs have to be frozen?
16:50:26 <regXboi> M4, right?
16:50:31 <edwarnicke> regXboi: M4 if memory serves
16:50:54 <regXboi> yes - then M4 is deadline for docs
16:51:01 <regXboi> we freeze the APIs and put them in docs
16:51:13 <rockyg> edwarnicki:  I think a docs person needs to do the template.
16:51:36 <rockyg> But I can work with a docs person...
16:51:39 <edwarnicke> Guys... who can do the templates for chapters? (not mlemay ... love you dude... but to much on your plate already)
16:51:39 <mlemay> @all to know on the TODO from a API poitn of view.. what is the propostion of projects using RESTconf vs Jersey Northbounds?  Anyone knows that?
16:51:40 <phrobb> edwarnicke:  since I've been pestering everybody over the past week or so, I'll just continue on immediately.  Let's say 1 week to get all the cats identified (7/16)
16:52:09 <regXboi> mlemay: right now, that wiki page is based on Jersey for REST northbound
16:52:11 <edwarnicke> Cool, could you #action in with the date?
16:52:25 <regXboi> we can update it once we collectively figure out RESTconf
16:52:42 <mlemay> regxboi: yes I know, I’m asking as it affects tooling..
16:52:45 <edwarnicke> regXboi: I think we have something figured out with swagger, just need to dig it out and link it in :)
16:52:56 <regXboi> edwarnicke: you beat me to the question
16:52:56 <mlemay> k
16:52:59 <phrobb> Is there a dependency on the pure-karaf decision that ties to how docs are done?
16:52:59 <edwarnicke> So... guys... seriously... who can do #3?
16:53:10 <edwarnicke> phrobb: I don't think so...mlemay, thoughts?
16:53:18 <regXboi> I'm not familiar with #3 enough to step up
16:53:37 <mlemay> phrobb: pure-karaf decision will have impact on install guides and user guides from the docs projects
16:53:43 <rockyg> Do we have a chapter people like we can pattern on?
16:53:50 <edwarnicke> OK... so we are blocked at #3... can we take the beg to the lists/TSC?
16:53:57 <mlemay> yes
16:53:59 <regXboi> I think we need to
16:54:03 <mlemay> you have a smaple book from docs
16:54:14 <regXboi> mlemay: link?
16:54:16 <edwarnicke> phrobb: Could you take the action to ask dmm to add the docs stuff to the TSC agenda?
16:54:33 <mlemay> #link https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=tree;f=manuals/sample-guide;hb=HEAD Sample Guide in Asciidoc
16:54:34 <edwarnicke> @all: Anything else addressable on docs?
16:54:41 <colindixon> edwarnicke: I can take that action
16:54:44 <colindixon> if you want to give to me
16:54:47 <colindixon> tell dmm about docs
16:54:53 <edwarnicke> (I mean right now on this meeting... because if not I'd like to briefly discuss the stable/hydrogen respin)
16:54:56 <phrobb> #action phrobb to send a mail and go searching for someone to create docs template for per-project content
16:55:14 <edwarnicke> #action colindixon to ask dmm to add docs to TCS agenda
16:55:17 <rockyg> Will the sample ascii doc work as a template?
16:55:31 <edwarnicke> rockyg: Might, I don't know
16:55:41 <mlemay> yes
16:55:48 <regXboi> so we want projects to put together just chapters, correct/
16:55:51 <regXboi> er correct?
16:55:53 <mlemay> yes
16:55:58 <edwarnicke> regXboi: That was my understanding, yes
16:56:13 <edwarnicke> Guys, can we switch to stable/hydrogen respin as the topic now?
16:56:13 <phrobb> If no more questions/comments, we'll move to hydrogen respin….
16:56:15 <rockyg> Cool.  That's #3.  At least good enough for the moment?
16:56:15 <regXboi> um... then isn't it just extracting out the chapter portion of that source and linking it?
16:56:21 <mlemay> ideally this way I can aggregate the projects in a “part” of the Book which would start with “common” stuff then dig in project specifics
16:56:25 <regXboi> phrobb:... give me a moment
16:56:32 <phrobb> regXboi:  ok
16:56:41 <mlemay> yes
16:56:46 <mlemay> @regXboi : yes
16:56:57 <mlemay> then people can write anything using this:
16:57:15 <regXboi> ok... then I can step up to #3 and create an adoc which is just the chapter section from that sample doc and contribute it back to the docs project
16:57:22 <regXboi> because it's just a simple copy/edit
16:57:34 <regXboi> (unless I misunderstand how things work)
16:57:46 <mlemay> http://asciidoctor.org/docs/asciidoc-writers-guide/
16:57:50 <phrobb> regXboi:  sounds good, are we ready to switch topics?
16:57:54 <mlemay> yes
16:58:04 <mlemay> phrobb: yes ;)
16:58:06 <regXboi> ok... then action me with #3
16:58:08 <regXboi> and we can move on
16:58:34 <regXboi> @phrobb: will you mail the minutes link to release ML when we are done?
16:58:36 <edwarnicke> #action regXboi to "Write templates needfor chapters"
16:58:50 <phrobb> #topic Hydrogen Respin
16:59:12 <phrobb> regXboi:  Yes
16:59:28 <phrobb> edwarnicke:  you want to lead this topic off?
16:59:36 <edwarnicke> #link https://lists.opendaylight.org/pipermail/release/2014-July/000037.html
16:59:40 <regXboi> @phrobb: thanks
16:59:49 <edwarnicke> We have a request to respin stable/hydrogen
16:59:58 <edwarnicke> We have not yet released stable/hydrogen
17:00:09 <edwarnicke> A respin can be done
17:00:14 <edwarnicke> How would we like to proceed with it?
17:00:22 <hideyuki> We have not yet released the 1st stable/hydroegn, right?
17:00:27 <edwarnicke> hideyuki: Correct
17:00:32 <edwarnicke> Folks have been testing the release candidate
17:00:35 <hideyuki> edwarnicke: Thanks :)
17:00:39 <edwarnicke> Which is the origin of the request for respin
17:00:55 <regXboi> I think a respin is fair
17:01:03 <regXboi> since this is from testing of the RC
17:01:22 <edwarnicke> So... how should we handle it?
17:02:06 <regXboi> I'm not getting the point of the q?
17:02:07 <edwarnicke> I would tend to give some appropriate notice to release (24 hours, 48 hours?) and then set a 'last call for objections to release' for some point next week - say Tuesday.  Then the TSC can consider it next Thursday
17:02:08 <edwarnicke> Thoughts?
17:02:46 <regXboi> notice to release or notice to respin?
17:03:00 <regXboi> and I'll make an objection to release now :)
17:03:08 <edwarnicke> notice email of respin to release@lists.opendaylight.org
17:03:20 <Madhu> edwarnicke: does that mean all the projects must retest it ?
17:03:31 <edwarnicke> Madhu: A respin would mean a new release candidate.
17:03:44 <Madhu> so the answer is yes :)
17:03:46 <edwarnicke> I would recommend that projects test the release candidate
17:03:55 <edwarnicke> (I can't *make* them ;) )
17:04:05 <regXboi> email notice of respin: +1, 24 hours: +1, retest: yes, objection: documentation <grin>
17:04:24 <edwarnicke> And we call Tuesday the cutoff for folks to object to that release candidate being published as the release
17:04:40 <edwarnicke> Madhu: Does that make sense?
17:05:03 * regXboi ducks on this one
17:05:09 <phrobb> @edwarnicke which Tuesday?
17:05:21 <regXboi> I think 7/15
17:05:21 <Madhu> general question to all.
17:05:27 <Madhu> so how do we decide on these dates ?
17:05:28 <edwarnicke> regXboi: Can I action you to raise the stable/hydrogen docs things at *this* weeks TSC?
17:05:35 <Madhu> we had the same discussion 2 weeks back
17:05:39 <regXboi> edwarnicke: sure
17:05:43 <edwarnicke> Madhu: I am simply making a proposal
17:05:45 <Madhu> and last TSC was the date to cut the release artifacts
17:06:11 <edwarnicke> Madhu: Last TSC the question of whether to release the release candidate was brought to the TSC
17:06:25 <Madhu> edwarnicke: yes.
17:06:35 <edwarnicke> My recollection of the consensus was that folks were not comfortable it had been sufficiently tested, and so we bumped the issue a week
17:06:48 <Madhu> edwarnicke: okay.
17:06:51 <edwarnicke> If you are suggesting that the TSC make the call on a respin, I'm fine with that
17:07:02 <edwarnicke> I still think that notice to release that the question is up is appropriate
17:07:21 <edwarnicke> Madhu: does that split the difference? :)
17:07:47 <Madhu> this meeting has gone way past 60 mins :) and don't understand the differences :)
17:08:12 <edwarnicke> Madhu: Its simple: the TSC makes the call tomorrow on whether to respin.  We let release know the TSC is making that call tomororw.
17:08:22 <edwarnicke> (so if folks want to be part of that discussion they can)
17:08:37 <edwarnicke> Madhu: Does that make sense?
17:09:13 <Madhu> okay. back to TSC
17:09:20 <Madhu> and each project to retest
17:09:23 <Madhu> thanks
17:09:27 <edwarnicke> If a respin is done, yes
17:09:40 <phrobb> Makes sense to me.  Will there be someone from the group who is making the case for the need for the respin?
17:09:43 <edwarnicke> But no respin till after the TSC discussion
17:09:56 <edwarnicke> I can try to arrange for that, yes
17:10:00 <regXboi> I'll make the case if nobody else does
17:10:13 <phrobb> thanks edwarnicke
17:10:19 <regXboi> but then again, I'll also make the case that the release isn't ready :(
17:10:35 <regXboi> even after the respin and assuming all the tests pass
17:10:42 <phrobb> With that, are we concluded?
17:11:04 <regXboi> I'll move to adjourn
17:11:12 * edwarnicke seconds
17:11:20 <phrobb> any opposed?.....
17:11:22 <regXboi> no I meant I'm going to go find lunch :)
17:11:33 <phrobb> #endmeeting