Live from New York, it's theCUBE. Covering the IBM Machine Learning Launch Event, brought to you by IBM. Now, here are your hosts, Dave Vellante and Stu Miniman. Welcome back to the Waldorf story, everybody. This is theCUBE, the worldwide leader in live tech coverage. We're covering the IBM Machine Learning announcement. IBM bringing machine learning to its Z mainframe, its private cloud. Dinesh Nurmel is here, he's the Vice President of Analytics at IBM and theCUBE alum. Dinesh, good to see you again. Good to see you, Dave. So let's talk about ML. So we went through this, the big data, the data lake, the data swamp, all this stuff with the dupe. And now we're talking about machine learning and deep learning and AI and cognitive. Is it same wine new bottle or is it an evolution of data and analytics? Good, so Dave, let's talk about machine learning, right? When I look at machine learning, there's three pillars. The first one is the product. I mean, you got to have a product, right? And you got to have a differentiated set of functions and features available for customers to build models. For example, canvas.  You got to have a set of algorithms available. So that's the product piece. But then there's the process, the process of taking that model that you built in a notebook and being able to operationalize it, meaning able to deploy it. That is, I was talking to one of the customers today and he was saying, machine learning is 20% fun and 80% elbow grease. Because that operationalizing of that model is not easy. Although they all make it sound very simple, it's not. So if you take a banking, enterprise banking example, you build a model in a notebook, some data science build it. Now you have to take that and put it into your infrastructure or production environment, which has been there for decades. So you could have a third party software that you cannot change. You could have a set of rigid rules that's already there. You could have applications that was written in the 70s and 80s that nobody wanted to touch. How do you all of us and take that model and infuse in there? It's not easy. And so that is a tremendous amount of work. The third pillar is the people or the expertise or the experience, the skills that needs to come through. So the product is one, the process of operationalizing and getting it into your production environment is another piece. And then the people is the third one. So when I look at machine learning, those are three key pillars that you need to have to have a successful experience of machine learning. Okay, let's unpack that a little bit. Let's start with the differentiation. You mentioned Canvas, but talk about IBM specifically. What's so great about IBM? What's the differentiation? Really good point. So we have been in the predictive side for a very long time. I mean, it's not like we are coming into ML or AI or cognitive yesterday. We have been in that space for a very long time. We have SPSS predictive analytics available. So even if you look from all three pillars, what we are doing is we are from a product perspective, we are bringing in the product where we are giving a choice or a flexibility to use the language you want. So there are customers who only want to use R. They are religious R users. They don't want to hear about anything else. There are customers who want to use Python, you know? They don't want to use anything else. So how do we give that choice of languages to our customers to say, use any language you want? Or execution engines, right? Some folks want to use Spark as execution engines. Some folks want to use R or Python. So we give that choice. Then you talked about Canvas. There are folks who want to use the GUI version of the Canvas or a modeler to build models. Or there are, you know, techie guys, developers who want to use notebook. So how do you give that choice? So it becomes kind of like a freedom or a flexibility or a choice that we provide. So that's the product piece, right? We do that. Then the other piece is productivity. So one of the customers, the CTO of Kaden.tv, is going to come on stage with me during the main session, talk about how collaboration helped from an IBM machine learning perspective. Because their data scientists are sitting in New York City. Our data scientists who are working with them are sitting in San Jose, California. And they were real time collaborating using notebooks in our ML projects where they can see the real time, what changes their data science are making. They can slack messages between each other. And that collaborative piece is what really helped us. So collaboration is one, right? From a productivity piece. We introduced something called a feedback loop, whereby which your model can get trained. So today you deploy a model, it could lose the score and it could get degraded over time. Then you have to take it offline and retrain, right? What we have done is like we introduced a feedback loop. So when you deploy your model, we give you two endpoints. The first endpoint is basically a URI for you to plug in your application. When you run your application, it will call the scoring API. The second endpoint is this feedback endpoint where you can choose to retrain that model if you want three hours, if you want it to be six hours, you can do that. So we bring that flexibility, we bring that productivity into it. Then the management of the models, right? How do we make sure that once you develop that model, you deploy the model, there's a lifecycle involved there. How do you make sure that we enable, you give you the tools to manage that model? So when you talk about differentiation, right? We are bringing differentiation on all three pillars from a product perspective, with all the things I mentioned. From a deployment perspective, how do we make sure we have different choices of deployment? Whether it's streaming, whether it's real time, whether it's batch, you can do deployment, right? The feedback loop is another one. Once you deploy it, how do we keep retraining it? And the last piece I talked about is the expertise or the people, right? So we are today announcing IBM Machine Learning Hub, which will become one place where our customers can go, ask questions, get education sessions, get training, right? Work together to build models. I'll give you an example that, although we are announcing the IBM Machine Learning Hub today, we have been working with America First Credit Union for the last month or so. They approached us and said, you know, their underwriting takes a long time. All the knowledge is embedded in 15 to 20 human beings. And they want to make sure a machine should be able to absorb that knowledge and make that decision in minutes. So it takes hours or days. So Stu, before you jump in, so I got the portfolio, you know, you mentioned SPSS, expertise, choice, the collaboration, which I think you really stressed at the announcement last fall, the management of the models, so you can continuously improve it, and then this knowledge base, which I call in the hub. And I could argue, I guess, that if I take any one of those individual pieces there, some of your competitors have them, your argument would be it's all there. It all comes together, right? And you have to make sure that all three pillars come together and customers see great value when you have that. Yeah, Dinesh, customers today are used to kind of the deployment model of the public cloud, which is I want to activate a new service, you know, I just activate it in its there. When I think about private cloud environments, private cloud is operationally faster, but it's usually not miniature hours, it's usually more like months to do to play projects, which is still better than, you know, kind of, I think before big data, it was, you know, oh, okay, 18 months to see if it works, and let's bring that down to, you know, a couple of months. Can you walk us through what does, you know, customer today and says, great, I love this approach. How long does it take? You know, what's kind of the project life cycle of this and how long will it take them to play around and pull some of these levers before they're, you know, getting productivity out of it? Right, so really good questions too. So let me back one step. So in private cloud, we are going, we have a new initiative called Download and Go, where our goal is to have our desktop products be able to install on your personal desktop in less than five clicks and less than 15 minutes. That's the goal. So the other day, you know, the team told me it's ready. The first product is ready where you can go less than five clicks, 15 minutes.  Can he install it? And if he can install it, you know, we are good. And he did it. And I have a video to prove it, you know, so after the show, I will show you. Because, and that's when you talk about, you know, in the private cloud side or the on-premise side, it has been a long project cycle. What we want is like you should be able to take our products, install it, and get the experience in minutes. That's the goal. And when you talk about private cloud and public cloud, another differentiating factor is that now you get the strength of IBM public cloud combined with private cloud. So you could, you know, train your model in public cloud and score on private cloud. You have the same experience. Not many folks, you know, not many competitors can offer that, right? So that's another. So if I get that right, if I as a customer have played around with the machine learning in BlueMix, I'm going to have a similar look, feel, APIs. Exactly the same. So what you have in BlueMix, right? I mean, so you have the Watson in BlueMix, which, you know, has deep learning, machine learning, all those capabilities. What we have done is like we have extracted the core capabilities of Watson on private cloud and it's IBM machine learning. But the experience is the same. I want to talk about this notion of operationalizing analytics. And it ties, to me anyway, it ties into transformation. You mentioned going from notebook to actually being able to embed analytics in the workflow of the business. Can you double click on that a little bit and maybe give some examples of how that has helped companies transform? Right. So when I talk about operationalizing, when you look at machine learning, right, you have all the way from data, which is the most critical piece to building or deploying the model. A lot of times, Dave, data itself is not clean. I'll give you an example, right? So, yeah. And when we, we are working with a insurance company, for example. The data that comes in, for example, if you just take gender, a lot of times, the values are null. So we have to build another model to figure out if it's male or female, right? So in this case, for example, we have to say if somebody has done a prostate exam, obviously he's a male, you know, we figure that. Or has a gynecology exam, it's a female. So we have to, you know, there's a lot of work just to get that data cleansed. So that's where I mentioned it's 20, you know, machine learning is 20% fun, 80% elbow grease, because it's a lot of grease there that you need to make sure that you cleanse the data, get that right. That's the shaping piece of it. Then comes the building the model, right? And then once you build a model on that data, comes the operationalization of that model. Which in itself is huge, because how do you make sure that you infuse that model into your current infrastructure? Which is where a lot of skill set, a lot of experience, and a lot of knowledge set comes in, because you want to make sure, unless you are a startup, right? You already have applications and programs and third-party vendors applications who are running for years or decades, for that matter. So yeah, so that's operationalization is a huge piece. Cleansing of the data is a huge piece. Getting the model right is another piece. And simplifying the whole process. So I think about, you know, I got to ingest the data. I've now got to, you know, play with it, explore. I've got to process it, and I've got to serve it to some business need or application. And typically those are separate processes, separate tools, maybe different personas that are doing that. Am I correct that your announcement in the fall addressed that sort of workflow? How is it being deployed and adopted in the field? How is it, again, back to transformation? Are you seeing that people are actually transforming their analytics processes and ultimately creating outcomes that they expect? Huge, so good point. We announced data science experience in the fall. And the customers that who are going to speak with us today on stage are the customers who have been using that. So for example, if you take AFCU, America First Credit Union, they work with us in two weeks, you know, talk about transformation. We were able to absorb the knowledge of their underwriters, you know, whatever it is in. Build that, get that features. And was able to build a model in two weeks. And the model is predicting 90% with 90% accuracy. That's what early tests are showing. And you said that was in a couple of weeks. You were developed that model. So when we talk about transformation, right? We couldn't have done that, you know, a few years ago. We have transformed where the different personas can collaborate with each other. And that's a collaboration piece I talked about. Real time, be able to build a model and put it in the test to see what kind of benefits they're getting.  You know, like the 80-20 rule, or maybe it's the 90-10. You're saying most use cases can be, you know, solved with regression and classification. Can you talk about that a little bit? So when we talk about machine learning, right? To me, I would say 90% of it is regression or classification. I mean, there are edge cases of reclustering and all those things. But linear regression or a classification can solve most of our customer's problems, right? So whether it's fraud detection, or whether it's underwriting the loan, or whether you're trying to determine the sentiment analysis. I mean, you can kind of classify or do regression on it. So I would say 90% of the cases can be covered. But like I said, most of the work is not about picking the right algorithm, but it's also about cleansing the data, picking the algorithm. Then comes building the model. Then comes deployment or operationalizing the model. So there's a step process that's involved, and each step has involved some amount of work. So if I could make one more point on the technology and the transformation we have done. So even with picking the right algorithm, we automate it. So you, as a data scientist, don't need to come and figure out, if I have 50 classifiers, and each classifier has four parameters, that's 200 different combinations. Even if you take one hour on each combination, that's 200 hours or nine days that takes you to pick the right combination. What we have done is like in IBM machine learning, we have something called Cognitive Assistance for Data Science, which will help you pick the right combination in minutes instead of days. So I can see how regression scales, and even the example you gave of classification, I can see how that scales. You've got to fix classification, maybe 200 parameters or whatever it is. That scales. What happens? How are people dealing with sort of automating that classification as things change, as some kind of new disease or pattern pops up? How do they address that at scale? Right, good point. So as the data changes, the model needs to change, because everything that model knows is based on the training data. Now if the data has changed, the symptoms of cancer or any disease has changed. Obviously you have to retrain that model. And that's where I talked about the feedback loop comes in, where we will automatically retrain that model based on the new data that's coming in. So you as an end user, for example, don't need to worry about it, because we will take care of that piece also. We will automate that also. Okay, good. And you've got a session this afternoon with you said two clients, right? AFCU and Kaden.tv. And you're on, let's see, at 2.55. So you folks watching the live stream, check that out. I'll give you the last word. What should we expect to hear there? Show a little leg on your discussion this afternoon. Right, so obviously I'm going to talk about the differentiating factors what we are delivering in IBM machine learning. And I covered some of it. There's going to be much more. We are going to focus on how we are making freedom or flexibility available. How are we going to do productivity, right? Gains for our data scientists and developers. We are going to talk about trust, you know, the trusted data that we are bringing in. And then I'm going to bring the customers in and talk about their experience, right? We are delivering a product, but we already have customers using it. So I want them to come on stage and share the experiences of, you know, it's one thing you hear about that from us, but it's another thing that customers come and talk about it. So, and the last but not least is we are going to announce our first release of IBM machine learning on Z because if you look at 90% of the transactional data today runs through Z. So they don't have to offload the data to do analytics on it. We will make machine learning available so you can do training and scoring right there on Z for your real time analytics. So. Right, that's extending that theme that we talked about earlier, Stu bringing analytics and transactions together which is a big theme of the Z13 announcement two years ago. Now you're seeing machine learning coming on Z. The live stream starts at two o'clock. Siliconangle.com had an article up on the site this morning from Maria Deutcher on the IBM announcements, so check that out. Dinesh, thanks very much for coming back in theCUBE, really appreciate it and the product today. Thank you. All right, keep it right there, we'll be back with our next guest. This is theCUBE, we're live from the Waldorf Astoria for the IBM Machine Learning Event Announcement right back.


One extremely important idea is that we can define a function as an integral. For example, let's define the function n of x be the definite integral for minus x to x of e to power minus t squared over 2. Now, fair warning, you can try to find an antiderivative for this function, but you won't be able to, at least not among the familiar algebraic or transcendental functions. There is no simple antiderivative of e to minus t squared over 2. Nevertheless, even though n of x is defined as a definite integral of this function, we can still find quite a bit about n of t. So let's start off by showing that n of x is 2 times the definite integral from 0 to x. So let's do this problem the hardest way possible and not draw a graph. Let's not. Let's actually draw a graph. So the geometric content of the definite integral says that n of x is going to be the area of the region under the graph of y equals e to the minus t squared over 2 above the x-axis from t equals minus x to t equals positive x. However, it's useful to note that y equals e to minus t squared over 2 is actually symmetric about the y-axis. And the beautiful thing about symmetry is that it tells you some things are equal. In this particular case, it tells us that the integral from minus x to 0, the area of this region, must be the same as the integral from 0 to x, the area of this region. Is that useful? I don't know. Let's try it and find out. If you don't play, you can't win. We know that n of x is defined as this definite integral. We also have this additivity property of the definite integral. We can split the integral at 0 until our first integral runs from minus x to 0 and our second runs from 0 to x. But wait, we know that this integral from minus x to 0 is the same as the integral from 0 to x. And so now I have two copies of this definite integral from 0 to x, which gives us the result that we want. Well, let's see if we can find some actual function values. How about approximating n of 0.1? Again, it's worth emphasizing that you can try all you want. You will not find an antiderivative of e to the minus t squared over 2 among the familiar functions. Nevertheless, we can still approximate n of 0.1. We'll try a linear approximation. But we'll need a value of n of x, where x is close to 0.1, where we know both the function and its derivative. Since n of x is defined by a definite integral, then we know n of 0 is 0. What about n prime of 0? The fundamental theorem of calculus tells us something about the derivative of a function defined as an integral from 0. Unfortunately, this function is defined from minus x. Fortunately, we showed that this could be written as a function defined from 0. So we can apply the fundamental theorem of calculus to find the derivative. And that tells us that n prime of 0 is equal to 2. And so now I know the function value. I know the derivative. So now I want to write the equation of the tangent line. And if I want to approximate n of 0.1, it's going to be... Let's talk some limits. What's the limit as x goes to infinity of n prime of x? And what does this tell us about the graph of y equals n of x? So again, by the fundamental theorem of calculus, because I know that n of x is 2 times the definite integral, then I know... Now as x goes to infinity, this expression goes to 0. And since n prime of x is the slope of the line tangent to the graph of y equals n of x, this suggests that as x goes to infinity, the tangent lines have slope going to 0, which means they're going to become more and more horizontal. So let's put together everything we know and everything we can determine and see if we can try to sketch a graph of y equals n of x. So first, remember we already found that n of 0 equals 0, and n prime of 0 is equal to 2. We also found that as x goes to infinity, n prime of x goes to 0. We could also try to find the limit as x goes to minus infinity of the derivative. And since this is also 0, this suggests that as x goes to minus infinity, the graph also becomes more and more horizontal. Next, we were able to use some of the properties of the function and the fundamental theorem of calculus to find the derivative. Since we know the first derivative, let's make use of it. From the form n prime of x equals 2e to power minus x squared over 2, we see that because exponentials can never be 0 or negative, n prime of x is always positive. We can also find the second derivative. And since we know the second derivative, we can use it. So from our second derivative, we see that if x is less than 0, our second derivative is going to be positive, so the graph will be concave up. On the other hand, if x is greater than 0, our second derivative is negative, so the graph is concave down. So that means at x equal to 0, the graph changes from concave up to concave down. So let's put all of these pieces together. First of all, we know that the graph goes through the origin, and the slope of the line tangent to the graph at that point is 2, so the tangent line looks something like this. If we go way off to the right, our slopes are getting close to 0, so our tangent lines look horizontal. And similarly, if we go way off left, the derivative is always positive, so the graph is always rising. At x equals 0, the graph changes from concave up to concave down. So before x equals 0, our graph is concave up, and afterwards it's concave down. And at this point we can connect the dots to form a smooth curve.


Welcome to Jenkins documentation office hours. It's the 17th of January. Let's go through our topics we've got news, the change log PR. Yes, and that is not just a question mark that's a yes we need to do it.  And I think, I think we owe it to ourselves to the weekly change log very first one because it's a relatively contained task and if we don't do it. Then we've got a much bigger task when the release happens tomorrow morning. Absolutely. And then open poll requests, and we could probably talk briefly about the improve a plug in tutorial. But it's basically say no progress in the last week. We should plan for how we could start releasing pieces of that, because they're that are ready to go or is that not going to be. Yeah, I think we it's just a matter of, of the work, the work that's there is finished the piece that's ready and publish it. Absolutely. Okay. Okay, so she could Africa contribute on. I still need to next steps. So that's a talk to it. And yeah, I think those are the topics. Anything else from you Meg. Nope, I don't think so. Okay, great so. And welcome to dirage she's joining us that's great. Hey, dear. Thanks for joining dirage. Thank you. So we were just reviewing agenda. Are there any agenda topics you needed to add dirage. I think I do but I'm wondering whether discussing technical things in Docs office or we create idea or not. It is a good idea. We've done it we've done we've on a in the past spent entire the entire Docs office hours on one or two technical topics so if you've got technical questions let's let's answer them. Yes, so it would be around the required upper bound depth error. Oh, yes. Discuss on that. Good good this is a good chance to read some documentation talk about it and then use specific experience on something you're you're actively researching to see okay how did the documentation meet or not meet the needs. Good. Okay, so, and which plugin. parameterized trigger plugin. Good. Okay, good. Yes, parameterized trigger plugin. Excellent. Okay, so this is a this is part of the improve a plugin exercise. Yes. And it will highlight for us one of the challenges that sometimes what we would like to be a trivial task is not a trivial task because there's complication there are complications. Good. All right. Any other agenda items you want to add dirage. Discuss the same thing about another plugin, the build, build time out plugin. Oh, good. So you've got two examples that you'd like to use as part of that. Okay, good. That's all. Welcome. So yeah, you didn't expect me to see this meeting but It's great that you're here. Thank you. Yeah. I'll, we haven't meant for quite a while I guess. Yeah, it's nice that you're here. Thanks very much. So, so we were just reviewing agenda like the topics we've got on the agenda right now include brief news and then we'll do a review of the weekly changelog. Dirage has an upper bound dependent upper bounds dependencies question that we're going to use to test the existing documentation and the improve a plugin tutorial. And then make has prepared a number of reviews of existing pull requests that we can use for an open PR topic review. Are there any topics you want to add to the agenda like I guess it's already packed. And the kitchen couple is all the stuff because I was basically absent for a few months. Great. Okay, well, so then by way of news, the 2.319.2 security release has been delivered. The 2.330 security release was delivered so that was LTS. The weekly security release was delivered. And that one had a complication complication due to an unexpected. Automated build of 2.329. That was the security med do some quick scrambling we had a Tuesday build launched when it was thought to have been stopped and so working to fix the root problem that allowed that build to run on schedule when it had been intended that it would not run. That's it that I've got for news. I guess we should do heads up there are discussions on Java end of life. There are discussions on Internet Explorer 11 end of life and of support. Rest in peace. Exactly, or just rest maybe not even yeah I don't care if it's peaceful or not just go away. Exactly. And those are continuing the plan right on Java eight end of life is marked to write the gap. We discussed it in the platform sick last Friday with Tim Jacome, and we'll use the jet process to lay out a plan that we can then discuss alternatives etc. All right, so next topic then is in this meeting we like to do a review of the weekly changelog. And it's we use the automated changelog that's been generated and then we sanity check the contents of that automated changelog. And then we look at the automated changelog for 2.331. Okay, so we've got unified labels in plug in manager, remove deprecated terminology labels from the plug in manager. That looks pretty good to me it's an RFE any objections to the phrasing. Okay, and then we've got the next which is a bug fix increase the width of the forms. And this one is a bug fix that's quite important on the UI improvements, we very much want to get it in the only thing I see it's missing is it doesn't have a full stop at the end of the line but that's easy to fix. Also, the most one. It would be also nice to clarify what other forms exactly. So, so well so let's let's read the let's look at the pull request then. And let's get the ideas for improvements so it was. It was just a minute it ups wrong wrong repository sorry we got a quote to the core not to. Okay, so the pull request is just borrow that. Okay, so the bug that it's fixing is described here. And it's one of the most popular bugs in the rating system. So the job configuration dialogue is too small and if we look at the image that they show notice how it lays out right it's it's not using the full width of the editable area, or the working area. But what recommendations you have in terms of improving the, the description. Well, I would rather start from looking into the code of each particular form say improved. Because, yeah, this is a key but we need to understand whether on the job configuration forms were changed or any configuration form. Yes, the description here says it's the job configuration dialogue we certainly look at. So this is a problems statement so basically what only experienced as a user. But, for example, the fix have included actually all forms in Jenkins. So I would recommend to just open file changes and to confirm that the scope of the fix was actually what is reported. So this is job configuration, then top bar, which is available for everyone and theme. I guess, so theme is likely up like to all forms. So if this just said increase with the forms on job configuration page is that do it. So basically any Jenkins config continue reference would have the same behavior, but the class was introduced only for one entry for job configuration so I think that the issue description is correct. Okay, all right. So, so what we bet seems like then it should be something like increase with the job configuration forms. Like screens. Ah screens okay all right. So is, is that what you're thinking like. Is that going to be on all devices. I mean on my phone that that might not be a good thing. Yeah, well it's, it's the code change was such that it's smart about device widths and if I remember it was using percentages so I think it should be even okay on the phone. So me and yeah this way I actually suggested in white screens explicitly because this is what the scope does. Okay so job configuration on wide screens. Okay so is it increased job configuring, or is it. Let me try an alternate loops alternate phrasing, expand job configuration to better use wide screens. No that's not not saying it page to display better on wide screens. Okay. I think I'm fine with it. Okay. Great. So make you okay and do you're as you're okay with first entry, the one that's highlighted. Yeah, yes. Okay, great. All right, so we'll save that when we do we want to say job configuration screen. Increase duration seems like not a screen. Okay. There. Okay, now I'm happy. Okay now I've got redundant use of the word screen on screens. Oh, is it should be job configuration page or work to me. But I'm careless with these matters form that works. Is that good with your leg. Okay. All right. Great. So let's go back to the change log then there were two items in the change log and then there are these that are comments so documentation is no longer in the wiki so rephrase labor so that label that's a documentation or a an online help update. Let me show you the content if there's worry should it be in it was intentionally excluded by the maintainer or the review the person who submitted it or the yeah Daniel Beck said this is too minor to to include in the change log. It's not like we have a big change log for the speaker. Yes, to two items so far. And then Jenkins test harness we typically don't include that friend for users they don't see it. Likewise the build tool for spotless. And this is a test fix. And this one is a dependency update so for me it looks like those two for right now are the right things to say yes to. I'm going to show you extra spaces before the world and move. Where do you see the word in the first in the first entry, the first entry. Somehow I'm not deprecated. Oh, okay. And in that case, it's, it's harmless because it will be rendered whether it has single space or two spaces. It will be rendered as an end of sentence by the web browser. Okay. Okay. All right so then I'm going to go ahead and mark this as approved. Okay, great. And in order to get the next chain that change that we just made. We have to run an action that changes lock so I'm going to go ahead and start that now. We don't have to wait for it to finish. But this way, it will update it. Okay, so change log reviewed and approved. All right so next topic then was dirage and upper balance dependencies testing our documentation and the ideas for improve a plug in your eyes you want to share your screen and look at it together how would you like to Yes, I will share my screen in some time. I'm just compiling it and reproducing the error. So, in the meantime, I can describe it. So can you go to get her and open the Jenkins channel. Oh, oh sure you bet. Oh, so here, you're okay if I share my screen and we'll look at the Gitter channel. Great. Yes, here we go. So here's the Gitter channel. And which which which of the feeds which of the channels. This one only is you need to scroll up. Okay, there's an image. The first image you see that is the message we're looking for. Okay, Jenkins slash Jenkins this one. Okay, yes, this one. Yes, and can you look at the messages which are in this thread. Sure. Okay, switch to Gitter and in the fire applies. And yes, this is the one. Okay, long message. So it talks and there's a pull request and it will direct you to the error that I'm seeing. Good. Okay, so let's take a look at that. Yes. And the error is in the console output. Yeah, here we go. Okay. Yes, this one exactly. So first of all, it looked alien to me. So then I read some articles to understand how to read this. So I found out that there is some transitive dependency problem going on some dependent on one other. So there's like two dependencies are causing the problem. First one is JNA platform with whose version version is 4.1.0. And if you look at all those trees that are there. It is pointing out to this version called 5.8.0 as well. So there's like different version for the same dependency. So maybe, so I'm just wondering maybe that's the problem. And the second dependency if you scroll down, it's for Java X annotation API. So it has a 1.2 version provided and then 1.3.2 as well mentioned in the below trees. So there's like similar problem, same dependency, but different versions. So then I read about how to fix it. Then it talked about that we need to give it like the maximum of the ones mentioned here. And then I was wondering where should I mention them because I was hoping to find the mention of these. Dependency in the form that XML file, but I was not able to find them. So the question comes back to whether my observations are correct. And if they are, then how do we fix the upgrade the versions of these dependencies so we don't see the problem. Right. Okay. So, so the Jenkins documentation that talks about upper bounds, let's look at that. Because I'm accustomed to doing a certain thing, but I think it'd be helpful for us if we look at what the docs say just to be sure. Okay, so sometimes you will encounter Maven enforcer errors. Your plugin depends on a component in another plugin. So, yeah, so this is a case where one plugin says it needs version X and another says no it needs X plus two or three or some, some more. Yes. And then the solution. Okay, so now it says talks about what the what the dependencies are. I get it's talking about what the classes of failures are. But here it says the fix is to update the get client plugin version and I think that's the most common thing that I've seen is the usual solution for me in these cases is not to reference where let's see let's go back and find that log. It's not to include a reference to this final thing in my palm if I can avoid it, but rather do my best to upgrade the other components that I'm directly dependent on to current versions. And that upgrade often will resolve the problem for me. So in this case you're talking about the plugins subversion to point one five point one. So assistant update this. At least that's been that's been my experience of, okay, when I do that. That's, that's the that's usually a desirable thing to do anyway. And when I do that it can I can get past so that it doesn't give me these upper bound dependencies errors. The other is I can use sometimes I've been able to use the plugin bill of materials as a way to resolve these kinds of error errors, because it uses a consistent set of versions that have been determined by the plugin bill of materials development process. So, so, are you okay if we do some experiments here or Oleg any guidance you want to give Oleg's much more expert guidance that currently plugin bill of materials should be used by default, because it actually results a lot of issues. I'm not sure about this particular one but the scope looks promising. Yes, that's a version plugin isn't in the best maintenance state. But there was a time to try to plug in bomb. I'm not sure why it ended. So, so, so I think Oleg's Oleg suggestion matches with my experience that. Now, now, dear, I was one of the challenges here is sometimes I'll encounter these messages when I'm trying to upgrade the parent palm version, doing something I think is relatively simple. And in order to get that relatively simple thing, I have to also use the plugin bomb and the plugin bill of materials. And so it's, it's sometimes I've had to do combinations of things in order to resolve these. And I think that's okay. Would you be okay if we, if we tried that as an experiment with with yours. Yes. So, are you at a point where you could we could switch and do some editing in your in your in your shared screen or would you like me to bring up the plug in and do editing on mine what's your preference. I think I can share my screen. Okay, great. So I'm joined from another laptop and I'm working on a personal one. So I'm sharing my personal laptop screen. Okay. Yes. So about the plugin bomb you were saying, did you explain it on the habit of this session as well. Yeah, I did. We at least we tried to explain it. We've tried to explain it in several different places. Darren, Darren Pope and I did a modernizing Jenkins plugins. Yes, I think. So the screen that I'm seeing right now is has has a camera view. So, so the, the screen that you're sharing looks like it may not be the one with your editor on it. Right. So it's, so this is the one with built on or plugin. Very good. Yes. So this is exactly where I was getting the error. And it's, this is the far maximum file for that plugin. Perfect. Okay, so now if we, if in your in your web browser, if you're willing to open, well, and I assume this does not have the plugin bill of materials in it. So open up a web browser on this same shared screen to Jenkins.io. And let's go find the instructions for the plugin bill of materials. Okay. See, I think it might be really slow. So if it is, can I request you after some time to do it on your screen. Sure, I am happy to do it from mine as well. If you would rather that's no problem is parameterized trigger trigger plugin. Yes. So plugin form Jenkins. Yeah, so, so depend that dependency management the second link down should be I think the one we want. The garage, the, it was the, the, it's a scrolled off the screen up above. Oh, no, yeah, up above. Actually, it's a, it's low. Oh, oh, I see. Open that one. Got it. Now, you might be able to not. It's still there. I'm actually on dependency management page. Okay, great. So. Yes. Okay, so this is the Jenkins core bomb. So scroll downwards Jenkins plugin bomb so click the hyperlink that's in that the C Jenkins CI slash bomb. Yes. Okay, and here I believe it's in the read me. Yeah, notice that that copy and paste is what we need. Copy that. Yes. So it's very slow. That's okay. Well, so, so while while we're waiting for it, if you're okay, I'll do some, some dialogue describing so what the plugin bill of materials provides us is a, a set of versions that have been evaluated together through a series of automated tests to be sure that they are, they work together with each other. And so that set of versions that the plugin bill of materials provides means you can simplify your management of versions to reduce the number of places where you have to declare a particular version of a dependency. Okay, so then maybe clean install command that we were running to check if everything works well or not. So even that runs some tests as well right. It does but for the purposes of this you can skip the tests by using minus capital big D skip tests. Because the that we don't need to run the tests for two in order to evaluate the, the plugin bill of materials. Okay. So should I paste this up to the properties. Yeah, I need to look to see where it belongs just a minute. I don't think it can go after the properties but I, I'm just lazy I go look at examples from others and use, figure out their placement. Okay yeah so it's a freestanding section that you could put right after the properties there. And there will be one thing that we need to replace online 229. We need a version with three dots, delete that. And we need to put in a different version number and I'll, I'm just going to paste the version number I'm using at the moment into the chat, so that we don't have to go do the look up. So. Oh. Okay, and be sure you get all of that string including that that very last underscore. Yeah, well he's doing that would you repeat that succinct little sentence that you gave about what the bomb is doing. Yeah, so well so the, it's probably best if I use the text as it's described so let me go there just a minute, because I suspect I'm probably describing it imperfectly. So, what doesn't actually. What the plugin bill of materials does is, it provides us a way to simplify the management of dependencies for common plugins. As an example, sometimes I want to use a pipeline plugin to create some tests for pipeline, but it's actually requires five or six plugins to do it. I have to then manage a set of version numbers that match to those things and work to get them all to combine together. What the plugin bill of materials does is gives us a predefined set of version numbers that are maintained and monitored and cared for by automated tooling that maintains the plugin bill of materials. So I'm basically delegating the hard work of finding a set of matching version numbers to somebody else. Have you been able to paste that number into that field and describe to me this for what you're putting in for the version I'm getting I'm going to do a PR when we're done here and fix that documentation. That's why I'm taking notes. Okay yeah so that that number comes from the, the releases page on the plugin bill of materials. So it's that number is just a plugin bill of materials release number. Okay, yes. You can check the PR and see what I screwed up. So now that I've pasted the version. What should we do next. Okay, so now we're ready to so search in the file for other tags of version, so less than version greater than. Oh, yeah so exactly so you're looking for that. And let's walk through each of them taking a look at them. Okay that one we won't touch. This is that one that when we keep that one stays the same that's the parent palm version and it's current. Then that one stays the same. So this is one that we can probably just in week, I think we can just delete that line 29 completely. Let the plug in palm, manage the version number for the plug in bill of materials, manage it for us so delete that line 29 completely. Search promoted builds. I think is included. Let's, let's comment this one out because we may need to come back to it. Okay, keep going. Conditional build step. And I don't think that one is covered so I'd leave it. So what do you think about this one. So the screens not keeping up you said it's a waitility. Yes, yes. So, I would try leaving that one. Well, I don't know. Try leaving it for now and let's see we'll we'll see if we one of the exercises I do when I when I'm doing these kind of things is I will typically. Oh, this this already has a plug in bill of materials. Okay, good. All right. So then then we were going to get compilation years let's continue looking. Then there's common land three. Don't know on that one is agent proxy connected factory. And I'm confident those are most likely not covered so keep going. And this is our. Okay, and notice that it's, it's alerting us there. So take take copy lines 227 and 228. And let's put those up earlier in the file. Okay. Keep going no no it's we need to find the reference to the bill of materials. What it is is there's already a plug in bill of materials referenced here. Yes, this one. So instead of bomb dash to start to 63.x, we want to put in there the 2.289 version that you had. So we're going to use a newer version. And, and now this means we've got to go look at the Jenkins dot version value. Yes, so it's still. Yeah, so change that to 2.289.1. And should we delete this dependency. Yes, yes. Now that section that we added, we absolutely want to delete. So I think the bomb is correct. Correct. The bomb is the bomb is 2.289.x but the Jenkins that version has to be a number. And so it's 2.289.1. So dear us let's try compiling this and see if it already resolves the upper bounds dependency errors. I'm just sharing my take time. So do you want to just leave this on compile? Yeah, why don't why don't you can go ahead and stop your screen share and go ahead and do the compile. And we'll switch to a different task. We'll look at the pull request that Meg has reviewed, and we'll come back to this is that's okay. Exactly. That's totally fine. Yes. Nice. Great. Okay. So then O legs. Oh, I'm sorry. Go ahead Meg. I was gonna say, when you're back to looking at the PRs, since O legs here. Let's jump down the list a little bit. There's two related to terminology. Oh, good. Okay. I know there's history and all sorts of fun things in there. I saw Tyler's name and. Okay, which of those would you like to look at first then this. 3362 and 2926. Okay, so 3362. I used the wrong, I used the files, but that's okay. Okay, so. So this is terminology and the question was, so is it. Oh, right. While it was blocked. We discussed it at the governance meeting at the time. I believe Mark was present there. Maybe not. It was long ago. So, basically what we concluded that we cannot say what is the official terminology in Jenkins, because there has been connected between Tyler's opinions and factor state in the code. We asked the documentation seek to review the case and come up with the terminology. This is why it was put on hold. Okay, so it's left to left to our recommendation as hey let's let's use this or that. So, one generally question we have basically two terminology matrices. One is on Jenkins glossary another one on the CDF glossary. And there is a mismatch between these terminologies. And, well, practically speaking I have never. Yeah, I mostly see people using job than projects, even though project seems to be more official taking the history of events. So, basically, the idea was that the documentation seek and the condition officer would take care about that and come up with a decision. So, so help, help me understand this so like the, the more common usage is the word job, I think is what you said right. I don't have statistics for that. And that's something we could we could test, but your your initial perception is it's probably, and now you mentioned the CDF terminology is there. Is there a one of these two that's preferred and the CDF terminology, one that's not or Well, the story of the CF terminology is actually so basically the continuous delivery foundation interoperability seek I believe they tried to modify the terminology. They created a matrix of different terms across multiple projects including CDF members and other CD tools. And the for Jenkins that are jobs, etc. And I believe it's basically because of me because when I was asked what is the Jenkins technology I provided the terminology we use the factor. And so there was a disconnect ever since. Okay, so, but, and so I'm interpreting from that that you would be okay with the switch from the word, the, the, the word project to the word job, because that's the common usage that you perceive and if we could have data to support that, that would be even better. It would be my preference, we can also give documentation to explicitly reference the synonym. For example, if you open the job term, it could reference project as a commonly used synonym. Okay. So basically, it's up to. Good. Okay. Mark, it's basically something for you to coordinate because it's documentation, it's maybe just making a call. Because I guess 99% of the community doesn't really care. But for users that might be beneficial to have. Good. All right, so but, and so it feels like this is something where my recollection of, I think it was Tim Jacomo observed that it's he agreed with your observation that job is the more commonly used term, and that project while it may be quote, more precise in the code or whatever, people say job and they understand each other more clearly when they use the word job. So that that makes sense advocate are they being careless. I've been, I've been, you know, and there's religious issues here, but I've seen a fair number where job refers to a freestyle job versus pipeline is a pipeline also a job. And that project is either a freestyle or a pipeline. I'm not necessarily arguing for that, but here you're looking at the class structure. Because in theory job is high level entity compared to project. But there is actually an interesting case because there is project interface which is inherited by job and then there is abstract project inherited from job. So, yeah, we just, we're just used to abstract project as a class because it's everywhere, especially in the security matrix we have a whole bunch of items that are grouped under job. Do those apply equally to freestyle and pipeline. I've never figured that out. It's because all rankings extensions so they can actually take the filter themselves to be sure so they apply. So, for example, yeah, there are many properties etc apply on the abstract projects on pipeline to both of them. We still have a lot of other project types which are less widely used. I wouldn't rely on the code structures source. I mean, that's the problem I think the terminology is really sloppy and it's. I don't know how we fix that without. Well, so, so Meg to the to your point on terminology. So I, I was I am quite willing to ignore the class structure, because I think users in general are not aware of the class structure developers maybe. I think are not and for me. I'm that's why I'm still biased towards job, even if the worry is oh that may be sloppy now, Meg to your example to your question here's, here's an exact text so in the downstream item here it's giving a definition of downstream. It's saying a configured pipeline or job which is triggered as part of the execution of a separate pipeline or job and so in that case it seems like it is acting as though pipeline and job are two distinct entities so I think it may be lobbying for what you were saying that this may job may mean freestyle or matrix or Maven and pipeline is distinct so, but wouldn't the correction here be to just converge these and say a configured job which is triggered as part of the execution of a separate job. And job means pipeline or freestyle or matrix or Maven. Or another option again not sure I'm arguing for this just it's a theoretic is that we could put in, we could make the glossary use the proper to my terminology of project and say that in common discussions project is often used to be synonymous to pipeline or job, or job or pipeline. I don't know if I like that or not. Yeah, I don't have my senses. Well, well for me job means the union of pipeline and I'm exactly opposite to what this is saying so this is probably me being wrong but job is the union of pipeline freestyle matrix Maven, even external job type is is a job. Oh like you're grinning and that usually means I've made a mistake. Go ahead. There is an edge case, because for example multi configuration job isn't a job. Multi configuration pipeline isn't a job. And in that case you're you're what you're describing I think is the inheritance tree right.  Yeah, okay and and you just described it the way the way my mental model is that there there are folders, and there are jobs. Now you mentioned one other and I dropped it what was the. So there is item. So, for example, yes, so it's a generic abstraction level, which actually has multiple users. So for example, top level item. Again, speaking code is the item that can be put on basically the job list can be created as a job. And there are a few examples for that. So, for example, in Docker traceability plugin you can create an item for monitoring containers. What use case maybe closer to mark and make there is a vision inspiration center which actually does a lot of the things through items. And it's enter connect the controllers, share integration, all of the things implemented as items. So basically what it means that you can have them on the, on the list, but they need the folders, no jobs. And they can be buildable to make it fun. But yeah, it's a separate story. Okay, so so this one then needs. If if I take the conceptual model of Jenkins has jobs folders and items where items may be a folder is an item, a job is an item and there are other things that are items as well right so items is is a is a super set of both folders and and jobs and other things did I say that correctly. Yeah, that's correct. Then what's an object. Then it was fire. It's honest. No, make the right that there is object in class section, but I have never seen object as a term being used anywhere in documentation. Yeah, and I don't, I hope it's not even not mentioned on this page because I've, I that's, at least in my Java mind, that's such a generic thing that it's, it's almost a content free word it's a word that has no meaning it is so general purpose. Whoops, I know somebody who's used it all over the place. Okay, alright. You've had me cool late early on you know and I just strength whatever they handed me well and and good for you that's will we learn from it and go onward. Yeah, so that's why it would be nice to have terminology because yeah there are some misconnects and reducing the terminology just to three terms seems to be beneficial. Yeah, class structure in Jenkins is a pain. Some of the classes have never been touched for years. Well, and I think from from user comprehension, they don't they largely don't care about the class structure right they have, they have a relatively simple conceptual model and, and if we can use correct terms to describe that model, all the better. I still have one challenging case is abstract project, because we need a term to explain non pipeline jobs, but actually other non classic job types to. But there it wouldn't be enough to just say, say the specific job type this is a freestyle job or a, it's also matrix project, literally project, maybe in project, etc, etc. Yeah, in my presentations, I can find it, but basically I just do comparison so pipeline job type is what is not tied to the workspace in the particular node, while abstract project is tied to workspace and the node. And this is the key difference in terms of APIs. But again, it's API doesn't say much to users, and we often struggle answering the questions, even into 722. So I guess it's okay, what the plugin type or job type, the property applies to, and, for example, time out. It supports abstract projects and pipeline, but it wasn't the case before and every time you hit something unsupported or is limited support and documentation like and project, you start strongly explaining to users would actually can do. Okay, so thank you. I would really like to put abstract project here, I use a disclaimer, but it's a slang term or whatever, programming term, but yet I think that it's widely used in documentation. Hmm. Okay. All right, and that's because a plugin may support ways of modifying behaviors of a freestyle project but not a pipeline project, and it not a pipeline it may support ways of modifying a maven, maven project type, but not a pipeline. Exactly. Okay. All right. API extensions, they're specific, and we still do have many extensions in the Jenkins core, which you don't properly support pipeline because pipeline engine also doesn't properly involve them. So there are some decennials, etc. You always discover the case when you start refactoring the old plugin. But speaking of the terminology I think that abstract project, it would be important to include it here to some extent, because we cannot get rid of this term easily. And it's, I'm back to the I would, I was hoping to avoid abstract project is such a programmer concept but I think what you're saying is it's unavoidable because the separation of implementations means that I need a way to describe pipeline matrix project maven project is a literate project, freestyle project, each of those, and there are subgroupings of those and abstract project is a subgrouping that includes all of those except pipeline. Not all. Not all. Okay. All right, so, so, so it's, it's even more complicated than I was trying to describe it. Okay. Well, there are some other types, for example inheritance project, which is also an abstract project pipeline, etc. Yeah, if you want to deep dive, there is a lot of things, but I would like to have abstract project here explicit because it's an edge case. It's used all over the place. And it's really difficult to explain what it is without going into code. Okay, so, so we've got more to do here. And mega I'm afraid, I'm not sure that we've resolved it yet but I think the clarity oh legs given is that it's ours to ours to work the question, and bring it to a proposed. Okay, let's, let's try to describe this in a way that suits users, and, and does not obfuscate or does not hide things that are important. Right. Okay, well like thank you very much. I can't thank you enough for being here at this crazy hour of the night for you. Thank you so much. I would prefer to be asleep. I'm not Mac. Okay. All right. Yeah, but legs really sharp at like four or five in the morning and the only time makes functional that hours if she's still up so. Well, let's talk again tomorrow when I have a lot of meetings to attend. Then I think we can quickly look the second one I think is almost the same as this I'm not sure there's a difference. Okay. 2926 2926 Okay, so let's take a look at it. I guess. Yeah, it's the same basically the same story. It looks, it looks almost exactly the same did I did I thought I was that was exactly what I was seeing before. Yeah. Okay, they are there are two pull requests both touching the same thing in much the same way. Right. Okay. All right. We'll get them and get rid of both of them. Okay. And Oleg's name is mentioned on a couple of other ones do we want to. Oh, right.  We just have a huge backlog of things, including various hackathons, etc. Which we actually needed to land or close because they stay in cacti if they distract people. They create much conflicts. Nobody actually knows what to do. I think this is some object for the documentation seek to figure out what is that approach. I think here. Yeah, so this, but it looks like makes makes attempting to start down that path of hey let's let's rationalize let's make these sensible. Yeah, so some bits are sensible, but well, generally, it's mostly work. For me, many of these beats are still related to we key immigration, because we still haven't migrated all the content we have the backup side. Now we also try to integrate Jenkins is the way to Jenkins. Which is a supporter of that. But it creates a huge technical depth for us, especially since Jenkins IO website runs on a legacy engine on its own. So we're still using a struct, which is basically not really maintained anymore. We created a pull request prototype, which would mostly move it to gets be but mostly is a keyboard. So finally, we ended up in a situation when we haven't fully migrated to Jenkins IO but we already need to migrate out. So, yeah, this is just something for the documentation thing seek to think about. I don't have advice except current few documentation developers to sort it in one year, which is not the case for doing this community right now. But that's the that's a kind of the kind of idea I think that you're you're right, we do need to just spend a significant time. We're working and yes a switch to Gatsby. That would certainly energize, energize Gavin and make the site more maintainable. So yeah, switching to Gatsby is a kind of controversial topic. Because Gatsby is really nice from the point of view of studying something new. But this is not a technology used by open source projects for documentation by default. They use, they use huger, they use docos hours, they use enter a specific special engines created for documentation management. Enter has a lot of benefits when you go after my old version documentation multi source documentation, because currently we still have an issue that Jenkins IO isn't really documentation is called. It's basically a separate repository and we just keep our fingers crossed that the plugin developers submitted them to purchase when they do something big. Not the keys. So, I, again, I do not really support more than Jenkins IO to Gatsby. You know it's nice prototype. I would rather suggest that we can see the standard documentation engine. Okay, good, good, good feedback. Thank you. But yeah, it's also part of the documentation technical depth. So at some point it's going to bite us because you're currently you see a lot of open pool requests. So in the current state Jenkins IO becomes less and less sustainable. Right. Okay. So, I'm, I'm mostly out of time here but I wanted to come back to dirages situation dirage or make or is there more that we need to do here. No this is just sort of a running list I'll go back in and rework it and. Okay. Okay, go ahead Oleg. I just want to think in the case you missed that race me run list, depending down from the continuous delivery foundation. What it means in practice for the recommendations you can call the Jenkins you that the foundation is basically down to one and a half. At the moment, including call things marketing product management, keeping clients on etc etc, which means that you have the right independence is like vocabulary etc just no product program managers who could take care of these demands. So, it's also something to keep in mind. Yeah, so, so the guidance there seems like we should just operate independently and asynchronously and not panic if CDF is overloaded and unable to help us with something that that we might want to help. The project that we will need to be a part of eventually is the events specification, but CD events specification is all that we accept it as a incubating project to the continuous delivery foundation. Well, I participate in the meetings when I can. I think it's an initial marketing to cloud events plugin created by Google summer of course last year, but it's definitely the topic that we will need, we'll need more attention. If you want to support CD events out of the box. Got it. Okay. It's not a project again, but yet the problem that timeline for specification is also not clear. Well, we want to have preview in one month or two months according to the initial roadmap, but with CDF basically being organized seems to be less probable. Okay. All right. Raj, are you at a point where we would like to switch back or should we conclude the session let everybody disconnect and you and I will just pair program on your, your question how would you like to approach it next. Yes, I think that would be great if we have debug the problem with one on one session that others don't have to go through this unbearable process. Okay. So I'm, I apologize, I need to take a brief break. So if you'd be okay if in about five minutes you and I could reconnect and and we'll just go through it together if that's okay. Okay, and I'm going to write up a little PR later tonight that captures what I saw just a couple of sentences but I this thing of, you know, it's just like see the repository is not really useful documentation. I think a couple sentences there, and then you guys can fix anything that I missed. This is on the plug in bomb. Yeah. Okay, great. So nice to meet you all like this is the first time we are meeting right. Yeah, well this meeting time wasn't particularly convenient for me. It's, it's, it's now 830am in India I don't know what could possibly be bad about that or like. Well, it's 4am in my time zone. Yes. It's time though it's crazy. It's yeah sorry completely insane. My shoulder is just hurts too much so I can fall asleep anyway. So we can continue synchronously. Yeah one thing that currently I receive a lot more GitHub pinks than I can process. So if you need something urgently etc don't hesitate to drop an email. It's, well, not something we usually advise for the drinks community but yeah right now I'm still a bit overloaded. So thank you for all that you do like much appreciated and and good luck in all the things. Okay. Yeah, I'll probably follow up with you later so I guess time for to find this in God. All right, we could say vice versa you're free to just shoot if you don't have to kind of show up to shoot something to us with you guys straighten this out. Absolutely. If you've got a sync email is certainly welcomed. You're no problem. Well they still have Jenkins welcoming to Jen say also likely use of that if it's not urgent. Okay. Okay, so yeah have a nice day evening morning. I'm sure. See you. All right. Okay so dirage you and I will connect what I'll do is I'll probably just send you a message through getter to to a zoom link that I'll establish here in just a few minutes. So we leave this meeting and then we'll rejoin after right we'll end this meeting in about five minutes. I'll, I'll post a link to a new meeting and we can record that new meeting as well so that if, if we find it's helpful. We're welcome to post it later but but I think it'll be more effective if it's just you and me and we, we can then decide okay should we put it on Mark's computer should we put it on yours etc and talk through it. All right. So, thanks everybody Meg thank you very very much. I'm going to go ahead and this and I'll be back with you in about five to 10 minutes dirage. Okay, I have a PR by tomorrow so Thank you Meg. Thanks very much.


we have seen that what are the various steps to be taken, what is the various uhh level of data which is required for the purpose. Let us look at the various analysis component, what we do with this data or we can make use of this data which has been collected from the the motor strip or a set of motor strips which have been the actual area. To do that I think it will be quite appropriate if we take a sample example and go through that sample example which will also give us some in-depth details on how the data is recorded, what are the elements of data which we have already uhh listed in the previous lecture and then we will go on to the analysis, what type of analysis we perform and how that analysis is useful in our latron design or even for finding out as the manager of the water distribution or as farmers, how effectively you are utilizing the water. This example which has been taken is the result of actual test run which has been performed on the field and some of the the details, the initial details which are uhh important in terms of knowing some of the quantities, these are that the crop is wheat crop on which the test was performed, the roots on depth of uhh this crop is 1.8 meters, the AMD, AMD is management allowed deficit is 50 percent and the soil which is in question is a sandy loam soil. For this soil it has been found that the available available moisture is 124 millimetres per meter depth, so if it is 124 millimetres per meter depth then for 1.8 meters the amount of moisture will be this will be 223.2 millimetres, this is per meter depth 124 millimetres of moisture available for 1.8 is around 223.2 millimetres and if you now find out what is the 50 percent of that is around 112 millimetres, so the management allowed deficit you can have a deficit of up to 112 millimetres in that soil and this deficit signifies that if you remain within this deficit level the yield of the crop would not be affected, if you go beyond this deficit it means if you let the soil moisture deplete below this level or beyond this level then there will be some impact on the crop yield. The other data which is given here is that SMD the actual soil moisture deficit which was prevailing at that time when the irrigation was done is only 73.6 millimetres, the other information which is available is the stage of the crop is crop is that flowering stage with this initial data which is either observed on the field or is available already existing with the organisation or the farmer, this is the data which is taken from the cylinder infiltration test. There are different tests which have been performed in the field, this is the first surrender then at location number 2 there are 2 more observations, so these are the actual observations which have been taken, we will just concentrate on this particular part, what type of observations have been made and what analysis or what is inferred from those observations, you can see here that this is the time in a minute, these are the watch, the hours which at which the observations have been made, 1055, 56, 59, in the beginning the interval is much closer because the infiltration rate will be higher and then the difference in time has been noted here. So while making the observations you might be observing only this and the depth, this is the depth, the infiltration in centimetres, so these 2 observations in the column number 1 and column number 4, these are the 2 which have been put and later on then these have been derived from the observed data, you have the difference in time and then the cumulative values that after this time how much is the the cumulative time, that cumulative time is also written here, similarly in the case of depth, how much is the depth per interval 6.25 centimetres and the next is 6.5 after 1 minute, so in that 1 minute is 0.25 which is the difference and that this the last column gives the cumulative value of the infiltration. So basically these are the cumulative time and the cumulative infiltration that is what you will need to plot the the data or to analyse the data to find out the infiltration characteristics. Similarly the other observations have been made and there are 2 more on this side because in general you will find that these observations are required to account for the variabilities in the soil characteristics and also to sometimes to account for the inaccuracies which might we might incur while observing the data. Then this has been plotted over a log log paper, all these 4 cylinder tests, the infiltrometer tests, data has been plotted and these are the numbers, number 1, number 2, number 3 and number 4 samples which have been taken and that those are plotted the time versus cumulative depth. Now you will see that all these are quite different in terms of the scatter, these 4 different samples are giving quite different values, that is the reason that you will you will need to arrive at some average value. So the typical value has been interpolated this lower dash line which is given here, is it visible? This lower dash line is the typical value which is the average value may be, fine. Having computed this average value you have the you have the characteristics, the infiltration characteristics available with you for that representative area or for that particular field. After that you will have to go in for the other observations which are the observations on the the water movement, how the advance curve and the recession curve will be with respect to a selected stream size. So in this particular test the various observations which are made before you have started the supply at the upstream end, these are that the border width, the border width might different than what is the the vector width because there will be the ridges will also have some slope. So you will you can note down both the things, what is the border width that means the clear width between the two ends of the border and what is the wetted width? In this particular case the wetted width was found to be 7 meter and then you can also take how this width is changing from one station to the other station when you go in the stations which have been installed at those levels how the width is changing, if there is a change in width you will have to again account for that or take an average width. Then the slope again you had taken the observations on the elevation points, what is the elevation at all those stations? That will provide you the slope and in this particular case the slope is 0.5, 5 percent which has been observed. The selected stream size we had said that will stream size, suitable stream size will be selected and that selected stream size will be used on one strip. On the other two strips you will have some variation of that stream size may be in one slightly lower in another one slightly more stream size. So in this particular case we are only discussing one strip data. In this particular case the stream size which is used is 33 liters per second and since this is a border strip case it will be per unit width per meter or width of the border. Then the duration of irrigation can be pre-decided or at that time when you it again depends on what type of soil you are using and what is the slope in general. You might if there is a light soil you will stop the water when it reaches around 70 percent of the length of the border whereas now is the other way round if it is light soil you will let the water spread up to around 90 percent and if it is heavy soil you will stop the supply of water when it has the waterfront has reached around 70 percent of the length of the border. This is a thumb rule basically but you can also vary in this case you can in different which are segments or in different strips you can use different timings of the supply of water as the idea is that you should have the minimum surface runoff and since in the case of light soils the infiltrations are higher you will find that if you stop it too early the last bit of the field might not get any water. So is a function of along with the stream size is also a function of the slope and the soil type. In this particular case the irrigation has been done for 88 minutes and the data the other data which has been recorded is again this is the data which has been we will see we can concentrate on this segment first this is the first segment. These forms are pre-designed forms which can be used which I was referring to in the last lecture that the pre-designed forms can be used which can reduce the inaccuracies because of the recording of the data. So here you can again say that this is the watch hours what hours the readings have been made and this gives the a different when these are the stations which are 30 meters apart which we have installed on the this particular border strip. In this case in this example the border strip is 255 meters long so that you can see here that 0 meters is the first station then the next is 30, 0 plus 30, 60, 90 and this is 1 plus 20 that means 120 meters 150 and so on. Now what we are recording is that at what time the water reaches each individual station so this is the time when you have started the supply of the water. At the next station the water has reached at 59 minutes at the next station it has reached at 11, 12 and so on. So what you have what you can found in turn is that what is the time taken between the two intervals there is a difference and then the cumulative value also can be recorded. Now these two data the distance versus the cumulative time or the elapsed time will give you the advance curve. Similarly for the recession curve you have recorded the data in this particular segment where this is the same thing as this what is the time of start and then after 88 seconds this is the difference at 12.19 which is the difference is 88 minutes, so after 88 minutes you have supplied stop the supply of water then you have found out that when the water disappears from this station so it did not disappear till 12.27 so that means at 12.27 the water just disappeared so it has taken around 8 minutes for the water to disappear that is the lag time, that is the time that the water has taken to the detention storage has taken 8 minutes to disappear from that station and then similarly you find out the time this is the at each station what is the time when the water the recession uhh part of the water that got disappeared. So you have noted down that time against each station and that is how it will give the cumulative value that what is the cumulative value at which your water is getting disappeared so that will this and this will give you the recession curve okay and along with that this is the uhh this segment is used to get the slope this is the the reading of the elevation with respect to some data at each of the stations and that will give you the slope of that. Having uhh observed these basic data then the data is plotted and this is the plot of the data the same data the way it has been plotted you can see here that these are the stations station number at 0 this is the upstream end and this is the downstream end and the total length is uhh uhh coming up to here somewhere here and at each station you have used data of the the accumulative time or the elapsed time and this is the advance curve this is the recession curve which has been plotted and these values which have been written these values are nothing but these are the the values of the opportunity time the difference between this time and this time. So at each level what is the time at which the water has disappeared was the time when the water was available and these are the timings at each station for how long the water was available at those respective stations and this gives quite a good uhh picture about what is the what is the the time and uhh since you know the time you can also find out using the characteristics of the soil how much will be the infiltrated water at these locations Now there comes a problem when you do not have uhh on this side you have plotted the surface profile again the readings which have been recorded and sometimes you might find that there is a depression or there might be a hump at some place and that uhh give you the indication whether uhh what what type of problem you can face so if that is observed somewhere in some of the steps you can try to remove in the next uhh if it is a crop which is already available crop you might not be able to do anything but you will be able to associate your reduction in the efficiency or the the relevant efficiency to those observed uhh things or uhh those problems which you have observed and the data itself. Now using suppose this data which has been observed you use this data to find out how much is the the depth infiltrated depth let us have a look that we know these are the various uhh uhh if we see that we have stations 0, 1, 2, 4, 5 these are the various stations and we have recorded that what is the the net time with the water is available at these stations and we have said that we have found uhh this is in minutes 96 minutes 118, 126, 123, 112 minutes. Using the average soil characteristics which we have using those infiltrometer tests we have found out the soil characteristics in terms of that equation y is equal to A t to the power b plus c and using that equation we can find out what is the depth of infiltration in millimetres the depth of infiltration which we find for the corresponding uhh locations in the present case this is the these are the actual values which you derive by using that infiltration uhh curve characteristics that this this much is the depth which can be infiltrated depending on the time which you have observed at this location using the actual data. Now here if I try to take the average depth because in each of these cases when we have the various stations we have said that this is our the advance and recession curve at each one location we are finding out how much is the infiltration time at each of these locations we are having a value which is only a single value. So if we assume that this part is representative of this this segment we can always take a average of uhh the previous and this one and that is what is being uhh represented by this segment. So that way you can you can take the average and those averages uhh you can note down at this location that is this is just trying to reduce the the impact of discretization you are taking the individual values so if you take the averages you will get some average value for all these different segments which are 30 meters each and then you can take the overall average the average depth for the total length which is 255 meters comes out to 97.6 millimeters using this data. The average if you take the average depth these are the actual depths uhh for uhh for example in this particular case you will find that between this and this the average will be 80 between this and this it will be it is 6.25 and so on. So if this 80 is representing the first 30 meters then you can find out that for the total segment of or the total length of 255 meters the average works out to be 97.6 millimeters and if you take we are also trying to look at another if you see here we are trying to find out that if the length would have been 100 and uhh 210 meters only then what will be there because in this segment you can see is quite obvious that the distribution would be very daily very poor because the time of infiltration is very low. So if you go beyond beyond this segment up to here you still have uhh these two curves are not uhh trying to converge the the opportunity time is still quite reasonable we will have to check that because we might ultimately find that even this length is not sufficient you might have to choose a length which is another 30 meters on this side. So that is where you can make various various options and let us try to make a option that if we select 210 meters of the border length what will be there? The average uhh depth which we will get using this the the soil typical soil characteristic curve which we have assumed or which we have selected from those 4 samples you will get a depth of 105 and uhh 0.7 millimeters. So these two that are the ones which you are uhh getting from the the data which you have observed. Now at this juncture it will be quite worthwhile to check are these depths because this depth is totally constrained this depth which you have which you are uhh finding out is totally constrained with the fact that whether the soil properties or the soil characteristic curve which you have obtained is reasonable or not because the range was so much if you again have a look on this the range is too big. So you have to you have to justify you have to have a in depth study of that uhh characteristics whether the selected characteristics are reasonably representative of the area or not. So to do that we make a analysis depending on how much volume has been sent to the strip, how much volume we need to do some analysis on the the basis of the supply of water. We know that we have stream size which is 33 liters per second okay. We also know that the elevated width of the border is 7 meter and we also know the time of application. So the width is known the time of application is known this is 88 minutes. Using this if you want to find out what is the volume and convert that volume into the equivalent depth that depth will be if you use 255 meters length because it will be a function of what length you are using. So if you use 255 meters length this volume will work out to be 33 liters per second and uhh these are the 88 minutes seconds divided by the area and this will about to be 97.6 millimeters. There is a slight mistake which has been made here in giving you this information but this is not my fault. This is not 97.6 millimeters this is the value which is less is 73.2 millimeters and this is also accordingly this is the value which will be the value which is after the adjustment has been made. So it is observed here at this juncture that because it cannot be if you look at these values it cannot be 97.6 the average value. This average value has to be lower and looking at these values also is 60, 48, 217 and there are some higher values so the average is around 73.2 millimeters okay. Now this depth which works out to be 97.6 is if you try to visualize what is this depth? This is the average depth depending on the fact that you have depending on how much water has been sent to the strip, how much volume of water has been sent to the strip. So your infiltration characteristic curve is giving you under simulation. This signifies that the infiltration characteristic curve which you are using is giving a under simulation and that needs adjustment. How you adjust that? Because even if you look at there will be some surface runoff there will be some other losses also. This 97.6 is corresponding to because the minimum which you want to send if you find out what is the where is that term. If you look at this particular place the average time if you look at the typical curve which we have selected this is the lower curve which has been selected and at that curve you are getting a value of 73.2 which is the average depth. At 73.2 what is the time? The corresponding time is around it works out to be around 96 minutes. So if I take a value of the average depth which is 73.2 which I have found out from here that this is the average depth which I was getting. If I use this typical curve which I have found out on the basis of the average data or on the basis of the actual data I have found out the average curve and I am not sure whether that average curve is still representative of the total area or not. Verify that I went to the volume basis I have found out that that volume will create how much depth on the average. So in this situation if I find out that 73.2 depth how much time it takes to get the 73.2 depth is around 96 minutes. Now for that 96 minutes in that 96 minutes I should get a depth with respect to the volume or with respect to the stream size which has been selected I should have got a depth of 97.6 centimetres. So I take this point to a level which gives me a cumulative depth for the same time which is equivalent to around 97.6 millimetres. So I shift this curve up and then I draw a line parallel to the previous typical curve that is how I make the adjustment. I have kept the same slope but I have changed I have shifted I have adjusted the the the infiltration rate in such a manner that for the same time I get a value at least which is equal to the value which I spread using that average stream size and that minimum that average value of depth I should get from that infiltration curve which should be the representative curve. Having got the suggested curve now I I try to verify that and I find out how much is the or in other words I get a new curve which give me a analyzing this this particular adjusted curve I get a new set of values which I analyze for A, B and C and use that curve in turn to find out how much is the how much will be the depth for these infiltration opportunity times okay. So that is what I do here and I find out what is the change depth I will write at this level the change depth in this particular case is 95 point 97.5 at this station will be 112.5 instead of 85 and then I will have 117.5 117.5 110 millimeters 102 millimeters and the 92.5 77.5 and so on. So these values are the adjusted values or the revised values with respect to the new characteristics and this I analyze again to find out what is the average depth now. The adjusted average depth if I take the total length of 255 meters works out to be 97.6 millimeters okay which is the same now which is the same as what I have found from the the criteria of the steam size by analyzing the volume which has been put on to the total length. At the same time if I decide to reduce the length because you know the last segment is quite poorly represented or the the infiltration opportunity time is very low in that. So if I decide to take only 210 millimeters of the length this quantity works out to be 95.7 millimeters. This is important because you have seen that how the whole computation changes so either you have to have lot of those infiltration tests made and take average which will be representative of the total but still it will be much better if you can verify those characteristics because these characteristics are varying so much in the the location of the test or even otherwise the soil characteristics are so much variable that when you are doing the point test infiltrometer test is a point test in fact you are using a very small area of the total area which might not be representative and they can be some other inaccuracies also because when you are using the infiltrometer test we have seen that even if you have the double cylinder the double that two cylinders you are using but still there can be some lateral dispersion. So it can give some values which are not always the representative values so having that you can use the actual test to find out what are the general characteristics, what shape it takes, what slope it takes that slope might be a representative slope because the slope will change when you go from one type of soil to another type of soil that is what is reflecting the rate of change of infiltration and once you have done that then you must at least verify how much is the variation or whether that that infiltration characteristic curve which you have arrived at is it really representative or not and that is how we do it that is what we have just gone through. Now having done this then the next part is to find out the various efficiencies that is what we have the main aim of doing this total analysis was to arrive at to check various efficiencies whether those efficiencies are reasonable or what are the upper limits of those efficiencies all those things you have to uhh you are interested in. To do that this is the another depiction of the same data but drawn in a different manner. Now here the same thing has been uhh redrawn by taking the this as the the starting point for every individual value at each section how much is the the total infiltrated water. So we had found out that that in the first case this is 96 97.5 millimeters and so on. So this gives you a depiction that how much is the total water which has been infiltrated at different stations and this is the level the actual soil moisture deficit level was in this particular case we had mentioned in the beginning that 73.6 millimeters is the deficit which is prevailing in the field.  Any amount which is above this level is the water which has gone into the deep percolation which has gone beyond the the root zone depth and if you decide that you will end this trip at 210 meters then this will become the runoff component. This will be there will be some still some water which will be available and which will go as runoff. So finding out the the efficiencies the different ways by which you can evaluate those efficiencies one is that you can use these areas directly because areas are depicting the volumes. So if you do that you can find out the efficiencies using that or you can use only the depth you can you can find the the suitability of these different ways or procedures and they are they are not giving much different results the results obtained are almost similar. So if we we try to look at what are the various values of these efficiencies I will if we if we note down the areas the areas which are observed the total curve under the total curve the area is 33.2 units okay either you can have a mesh or you can use a transparent graph anything you can do is or a graph paper can be used to find out the unit areas and the unit can be any unit is immaterial. The runoff is observed to be 73.7 units I will just say units and depoculation is 9.2 amount stored in root zone is 20.3 units okay. Now using this you can you can find out the various efficiencies which we have already discussed earlier. For example if you want to find out the distribution efficiency, distribution efficiency in this case let me also mention that another if we look at this value 77.5 millimeters this value is the the minimum depth which has been observed up to the spreader level. The minimum depth which has been noted down which is required for example in this case this is 77.5 millimeter is the depth required up to 210 if you take the length of the border up to 210 meters only then 77.5 is the minimum of the total but every location the minimum depth which is required is 77.5. So with respect to that depth if you have to achieve that then you will have to provide some water which is in the the stored in root zone will be more if you would have got more deficit okay. In other words you can also say that the potential value of the the efficiency the application efficiency could have been slightly different if you did not decide to irrigate the the field at this soil moisture deficit level if you would have allowed the irrigate the the soil deficit to increase to 77.5 millimeter depth then it was possible to because in any case you are getting this much water throughout this length so it was possible to achieve a higher efficiency and the area up to this level of 77.5 millimeters is that area is between 77.5 and up to that 210 meters level this area is 21.7. So this give you a value which is achievable value and in that situation the distribution efficiency would have been 21.7 is the depth which is applied depth and if you take care of the surface runoff you are left with this is the depth which is required this is the depth which is applied 33.7 uhh 0.2 minus 3.7 which is gone as the runoff. So multiplied by 100 this is 74 percent so the distribution efficiency can be walked out from here. Similarly the application efficiency on the basis of the the actual actual case actual SMD the actual soil moisture deficit this is basically 20.3 and how much you have the water you have applied this works out to be 61 percent only whereas the potential value of the application efficiency this could have been higher this could have been 66 percent had you waited for some more time and had you let the soil moisture deficit go to that level. So that is where the management allowed uhh deficit comes into picture that if you if you can manage your irrigation in such a manner that you let the deficit which is reasonable deficit reach a level which is optimum level you will find that the efficiencies can be much better. Similarly you can find out the other uhh efficiencies which are which we have already looked at and we also know the procedure how we can make use of those efficiencies this is only one aspect which we have seen. Similarly in this particular case now this is with respect to the stream size which is 33 liters per second if you use a different stream size you will find that all these quantities will change. So in the evaluation procedure your aim is to come out with those combination of parameters which give you the optimum efficiencies and that is only a possible if you analyze more number of uhh these strips with variation in these parameters and is more of a trial and error procedure when you are doing the evaluation okay. With that we will close this uhh chapter on the border irrigation system if you have any questions you can ask.


ket and maybe that's something we can look to when we reopen the rules as soon as we file them so but I think you know from the mix light perspective from trying to change a narrative that exists about outdoor because I think we've got a lot of good quality outdoor growers in the state I think this gives them another tool in their tool belt so you know from that perspective I'm kind of in Rick's camp there I think that this is really designed to help our outdoor cultivators and help outdoor products and high quality outdoor grown flower really thrive in Vermont that's that's our intention so it's not going to please everybody but nothing we do please is everybody and we didn't get rid of the other three we added a fourth right we did change something there there was at one point and Jesse's right there was one point where there was a couple mixed tier options and one was a 2,500 square foot indoor and I can't remember what the plant count alternative was and you know think the way things are going it's a little bit more clarity from a regulatory perspective on what's going on for us to be able to implement and again the mixed hearing is designed to help our outdoor growers more so than anything I think all right well any last comments from board members or from brand or from David before we adjourn that we need to think about before Wednesday something will occur and I'll bother bring it 11 p.m. all right well then we'll wait for that stay tuned but I guess with nothing else on the agenda I will adjourn this meeting thanks everyone who stuck it out online and we'll see you on Wednesday