Just briefly, what do you like most about the EMCSR 2012? The people that are here. Opportunity to meet people that are working in complementary fields. One of the most positive things about it and certainly what was a great benefit to me was the huge range of diversity of views and all the different sorts of systems worked. Well, I think they're trying new things in terms of bringing the various subfields together. Possibility to participate. It's something that I really enjoyed. I think what I've learned though is going to be something that I will realize in a couple of weeks, you know, when I've had a chance for it to sit with me. Yeah, sure. You're listening for us, I guess. Yeah, it's dense. Okay, thank you very much. Thank you.


Hello, welcome and thanks for joining me on my talk about a solution to the personal data problem. I'm really excited about this talk for two reasons. First of all, it's been really a long time since I last talked to you here at the Academy. And for those who don't know me, my name is Björn. I work at KDAB as a project manager and UX guy, but I also have history in free software. It all started shortly after 2000 when I helped to initiate the open usability initiative. I was also involved in creating the visual design group within KDE. And my last contribution was the K-user feedback, which I happily see all around KDE by now. On the other hand, I've always been a data activist. So I try to avoid producing personal data as much as I can, you know, next to running Linux. I Google, Android, run my own cloud or better next cloud, you know, whatever. I try a lot to avoid producing personal data. So as you can see, there are two hearts beating in my breast. On the one hand side, I need to know everything about the users to be able as UX guy to optimize services, products and so on. On the other hand, I know the danger about the danger producing personal data brings. And the second reason I'm really excited about this talk is this is the first time I'm talking publicly about what I think is a solution to this problem. So let's take a look at what you can expect from this talk. First of all, I'm going to explain to you what a personal data cooperative is, how it can look like. Because I spoil up this in the abstract, this is the solution to the problem. But more interesting than that, even more interesting than that, I will explain to you why I think that if it's done the right way, it will actually change the world toward a private world where we can still benefit from the comfort and the services, big data analysis based on our personal data brings. And last but not least, I will explain to you how and why we as civil society as free software and as KDE specifically, why we are the ones who can start it. We don't have to wait for anybody else. We can just hack the current system and start it and change the world to a better place. I'm deeply convinced about this and I truly hope that at the end of my talk some of you are convinced as well or at least as curious or curious enough to join me refining the ideas. What I'm going to present to you is a blueprint. It's not a detailed concept, but it is the fundamental idea behind it. And I hope you'll understand and get it. And I hope that you will agree at the end, even though I know you're probably very critical because I know about the discussions about collecting private data within KDE. But I still hope that I can convince a couple of you to help me take this further. So obviously we need to start with a fundamental question. If I want to propose a solution to the personal data problem, the fundamental question is, is there a problem with personal data? And the answer is yes. There is a problem with personal data, a huge problem with personal data. And I really don't want to pitch you about this too much because I think we can spend our time here much better. But still, I want to bring your attention to a couple of aspects of the personal data problem. So first of all, why am I talking to a free software community about this? Because I think free software is falling behind because we constantly say no to producing or using personal data. Our proprietary competitors, they collect and create personal data at large and they improve the usability, the user experience of their products. And this is something we're not doing. And by this, the quality of our products will fall behind and behind and behind. So using free software will become more and more a matter of belief, of thinking of doing the right thing rather than using the better product. There are exceptions, definitely. But at large, we can't compete with the quality of proprietary software, of software that engineers the user and the user experience into the products itself. We're trying our best, but the key to success really is personal data. The second aspect I want to bring your attention to is innovation today often isn't about creating great algorithms. Innovation today often is based on the availability of personal data. Think, for example, about predicting traffic jams. It is really, really simple. You just have to know, okay, there are a lot of people on the street and they're not moving at the pace they should be moving. So traffic jam. So if we want to help people with a good routing algorithm, we wouldn't need to know that there is traffic jam. But this is something, if we don't have the data, we will not be able to create such a service. So these two points together mean that I think that our reluctance to create personal data and use personal data will actually lead to the situation where we as free software become more and more irrelevant. And this is something which is utterly wrong for society. We need free software, we need free services, and we need something as simple as a free traffic jam warning thing. But it goes even further. If we think of those who actually own the personal data right now, it's very few companies that know a real lot about us. Think about those companies. Those companies are also those who actually have most of our attention span. So when you, I don't know if you've seen the Cambridge Analytica documentation on Netflix, but if you see how knowledge about the personal data can help to influence elections, even the US presidential election has been influenced or the Brexit. If you see this, then imagine how hard it will be to regulate those companies when we actually reach a point where this is necessary to do. And the last thing which I want to mention here, it's sort of pitching you about the problem personal data brings. The last thing I want to pitch you about is I think I am trying to avoid producing personal data. I guess a lot of you are doing just the same. But still we have to suffer from the effects that the misuse of personal data brings. Trump has been elected, the UK has left the EU. Even though we do all we can to avoid producing personal data. And that is because the current approach is a kind of an elite thinking. We are thinking, well, you know, go ahead and there are alternatives use them, but we don't see that you have to be really, really competent. You need to have a lot of time and willingness to be able to not produce data. Giving you one example, I've been working on a home automation system for my little flat I have. I've been spending, I don't know, 500, 600, 700 hours into setting up a home assistant to, you know, work within my flat and it still doesn't fully. I don't think we can expect a lot of people to do that. So the problem we have is really a usability problem. People at large will not and will never ever spend the time needed to live a life without producing personal data. And as long as we don't get the large majority of people to actually be sensitive with the personal data they produce, as long as this doesn't happen, we'll have ruthless people around that will take advantage of the personal data that is being around. Again, take a look at the Cambridge Analytica documentation and see how elections have been influenced based on personal data. So I think enough has been said about personal data. It's a conclusion personal data is often called the new oil. The problem we have is that we as individuals, what can we do with our little share of oil? Well, currently the only thing we can do is we can trade it for a couple of shiny digital marbles. And that's what we're giving it away for. And I've spoiled it before. The solution to this problem is creating a cooperative. A cooperative is, well, it's a concept that's been around for, you know, thousands of years. Basically, since we started living in tribes, we are cooperating. So you could call a tribe sort of the starting point, the first cooperative there was in the world. So a cooperative basically is about a bunch of people that have the same interests and that work together against sort of, you know, a larger enemy which they couldn't face individually. So they collectively do this. And the goals we have, I think the goals we share are we want to have and live a private life. But at the same time, we want to benefit from the new services, you know, that are based upon our collective personal data because they just make our lives much, much greater. Yeah, go back to the traffic jam. It is good that you can predict traffic jams and that you can take a detour which takes you to your destination much faster than sort of going through the traffic jam. But for this, we need the kind of data. Think about the COVID pandemic.  But there is no one we would trust our data right now. But this would be something a cooperative would actually, you know, solve. Yeah, if we would have some place to put our data, then it would be easy to do the necessary calculations based on this data. So you might ask, why can't I join a personal data collective cooperative right now? And to be honest, I don't know. I mean, a theoretical concept and if you if you search literature and the web, you'll find tons and tons and tons of material about it. And, you know, almost everyone is saying, well, the solution is a cooperative, but there is still none. You can join. So perhaps to understand the problem a bit better. Let's compare the personal data cooperative with traditional cooperative. A traditional cooperative could be something like, you know, a couple of farmers that want to that together want to sell the milk they produce. So the first thing is the milk the farmers produce once gets sold, you know, somebody drinks it or, you know, bacteria do their work. At some point it's gone. I know some Frenchman might disagree on this, but, you know, it will be gone at some point in time. But personal data is an intangible good. Just the opposite is happening here. Yeah. So when you when you sell it, it's still there. It doesn't vanish. Yeah. It's that you can copy it and you have an exact duplicate of it and you can, you know, resell it. You know, people can do whatever they want. So we can't we cannot give it away like we can give milk away. The second aspect that's different is if you think about the farmers, they have to live within a within a small area because they, you know, they have to carry their milk to a central point. But with personal data, everyone on the planet is a potential member of this cooperative. Last, if you spill a litter of milk, you wipe it away and everything is okay. But if you spill personal data, this is a catastrophe for a person and potentially even for society. So we have to have an enormous amount of trust into the system to be willing to join it. So when we design the system, we have to put trust in the first place. We have to optimize the system for trust and three things for me stand out there. The first thing is protection has to be the foremost goal of the system. We have to protect our personal data by all means. There can't be any compromises. Protection is the thing, the thing we have to go after. The second thing is transparency. You will only trust the whole thing if it's transparent and we as free software community, we know our way around with transparency. But this goes way beyond software. Of course, all software we will use will have to be free software, but this will go way beyond this. The whole organization will have to be transparent to the bone. It has to be transparent that it hurts. And the third aspect, which is actually pretty natural if you think about a cooperation because obviously it says everybody has to have one vote within this corporation. But we have to really think about it because it has to be a worldwide corporation. Still, everybody has to be able to participate in this. I've created a mission statement. Let me read it out. So our mission is to create the most trusted organization in the world. It will protect our digital privacy while enabling innovation based on our collective personal data. I'm totally earnest with the idea of creating the most trusted organization in the world. This organization handles our most sensitive data. This is what affects us most. This tells everything about us. So we really need to have an enormous amount of trust into this organization. But let me explain how a solution can look like or how such a data cooperative will look like. And I'll go through this step by step. So if we want to collectively collect our data, there needs to be a technical solution to it. So we as consumers, we contribute our data into a technical solution. So this means there has to be some input mechanism. There has to be a storage of the data, I'd call it a data pool. And there has to be the possibility to do evaluations based on the data and the data pool. And we should strictly follow the open algorithm approach of the MIT which says we should not move the data to the algorithms. Instead, the algorithms have to move to the data. And this is because data is an intangible good as we've seen before and it can be copied. But if there is a technical solution, we will need to have somebody who's actually running the technical solution. So we should create a for-profit company that runs this technical solution and that actually earns their money by creating a marketplace of evaluations of anonymized evaluations based on the data on our data pool. But as we have seen with FreeNote for example for a while, creating a for-profit can be problematic. So what we actually need is we need somebody or something to own this for-profit company which cannot be changed. So we need some sort of a foundation with a clear goal that owns the for-profit company and that actually gets the money and spends it again into projects that follow the status of the foundation. And I think this needs to be foremost, this needs to be researched about how we can make the technical solution better. Because I totally agree the current situation probably is not sufficient to run such a data pool. Probably we need to do more research to create a technical solution that protects our data enough to be trustworthy. But other things that need to be financed by the foundation is educating users. It is free software for example. So as I said before we also need as users and as consumers to influence what's been done. And for this we'll need some form of a parliament. The job of the parliament is actually mainly to control the for-profit and to set the rules for the for-profit. So basically the parliament is our way to influence our view on what privacy means to us. Because this is not set in stone. Privacy is a concept that will change over time. There will be new challenges to it and we have to react to this. So the parliament next to sort of defining priorities on how the money should be spent is mainly for controlling the for-profit. It will set the rules for the marketplace. The for-profit will run a marketplace but it cannot be allowed to do anything to sell any data. And foremost the parliament has to actually maintain the technical solution. If this is open source think of the parliament of being the maintainer that says which pull requests are accepted which are not. And by this the parliament can control which data goes in in the first place and which evaluations are allowed upon our data in the last, are finally allowed on top of our data. So the parliament really has to be the product owner of the technical solution. The for-profit can only use what the parliament allows. But if there's a parliament we also need elections. And this as I said before is a very difficult issue because consumers are placed all over the world. So my idea here would be to establish a chain of trust because trust is what we're really aiming for. So the idea is that consumers that contribute the data to the technical solution they can also vote for an NGO they really really trust. This can be the KDEV or the FSF or FSFE but it can also be Greenpeace or Red Cross or Red Half Moon or whatever NGO you think is doing a good job and is really trustworthy. And the top NGOs that have been voted for they each send an expert into the parliament. By this we don't have a direct democracy but an indirect voting system but still consumers are able to influence what's been done in the parliament. So this is the main system but there is still one little ingredient missing to make this a success and this is a seal. The seal is being defined by the parliament and it gets awarded from the for-profit company to product developers that comply with the rules. Why is the seal so important? Because I truly believe that giving people consumers at the point of sale or at the point of consumption because we also want to award this seal to free software. But giving them a real choice by informing them about the situation will actually change the world and it has in the past because look at the ecological movement. Nowadays in the supermarket you can buy an apple or you can buy an ecological apple and you are informed. You can make an informed decision and we need to do just the same. So if you want to install an email client you need to be able to choose between an email client and an ecological email client or privacy where email client. And it needs to be clear at the point of sale and I need to say okay this costs delta money more than the normal email client but I'm willing to pay this because I'm not willing to pay with my personal data to this. So that was the idea of why I think the whole thing will fly in the end. The question is how do we lift off and well the first step is we need to talk about this is what I've been doing right now. And the goal of this obviously is to win people that join me and have to sharpen the ideas and you know have to you know create content and to make this become real. But the same it is as important even though if you might not be convinced yourself. I'll ask you to take the discussion into your community not only in KDE but also into your product community because we need to find free software projects that are actually willing to take the risk to move on to step two with us. And step two is actually once we have sort of discussed the idea further and and found a couple of free software projects we together have to establish a temporary organization like an EV. The goal of this EV is basically to create some funding and to you know finalize the concepts. But the main goal of this is to create a proof of concept for the involved free software projects. So together we need to create a solution where our users can opt in and say yeah I'm willing to spend my data and the solution that fulfills our privacy. Demands because I think we have the highest level on this you know of of integrity of the system and only if we if we can fulfill it for ourselves we can be successful. But if we manage to create such a proof of concept that works for our free software projects. We're ready to move on to step three and step three means that we have to incorporate the final organization. We have to establish the initial parliament and then we have to create the visibility by establishing the seal if we have a couple of free software projects that are willing to join us here. They will be awarded with this privacy seal and the seal will create a visibility for the topic and with this whole package we can then go to you know commercial and proprietary software developers because what we now have to offer is a service they are willing to buy. Our service means that we take care of the GDPR issues for them. They don't have to care because they if they use our system they won't even have access to personal data anymore they will just have access to evaluations based on that.  Also the seal is a matter of trust you know it's it's it transports trust. So if a product gets the seal they can ultimately you know raise a higher price because it is a more trustworthy product. So again this is something product developers will be willing to pay. And the last reason is that they are that they get the opportunity to actually do the right thing and not just keep on piling the data they produce on the data piles of a few big companies that already know a lot about us. So I think that the right starting point for this is free software we within free software we can create everything we need and then we can expand the system towards commercial software. And by this we will allow people in the long term to take informed decision at the point of sale at the point of consumption and this will change the world and there is a plan how we can get there. So summing it up we can solve the personal data problem. I hope I can find a couple of you guys to help me bring this further. It is a blueprint a lot of concepts you've seen right here have been just superficially been been described. I hope we still have some time for questions. So I'm happy to explain concepts that interest you much further because there are thoughts going further. If you want to read about it I have created a web page. It's called private.org. You can also reach me via Björn at private.org or visit the both I've scheduled for Tuesday at 10 UTC. So again thanks for your attention and hopefully your interest and I'm happy to answer your questions right now. Thank you. I hope you can see me. Okay. Thanks. We will have our speaker online in a few seconds. So but anyway for now thank you for that was really a lot think about we even have already we have questions. We have a lot of questions actually. So I'm not sure now we will be able to answer all of them but let's try. Okay. So I can see you. Can you. Hello. Does it work? Yes, it does. Sorry. Sorry again for this being a recording. I really would have loved to do this live. Okay. But I think it was good in the end and very, very, very good. So and the feedback from the chat was on the same line. So let's start with the questions because we don't have a lot of time and we are going to use the score. So I see a battle of score there. So from Cornelius the first question is what examples what kind of data do you see where companies will buy data from such a cooperative. And I think that's that's potentially a lot of data. Let me give you an example. If you I mean Cornelius you're asking this you're working for a transport agency or transport. I don't know. Agency is not the right word. It's whatever for the ban you work. So if you sell a ticket for example, yeah, then then you collect personal data. Yeah, and this data can go into our database. Now you this data belongs to me as I've been buying the ticket and to you as you've been sort of the ones that produce the data. So now but you want to keep this data exclusively for yourself in the first place. But you might be interested to share this for example for research with other institutes. Yeah, so they can do research on your actual data. So that would be the idea of creating a marketplace in very few words. But I mean the kind of data is really we have to discuss what goes in and what doesn't. Yeah, but it can potentially be a lot. Okay, the next question is from Alash, which is short but very big. How theoretical do you think this is? I think this is absolutely practical. It's a matter of wanting wanting to do it. Yeah, I mean I'm I can't do it myself. I'm psychologist. You know, I work as a project manager. I can't program anything. I'm not a law expert. You know, I'm not an expert on any of the specific topics except perhaps on the usability side, which I would like to answer Nuno's question as well with within one go. He asked about the sort of what what does it mean for the user. And I think that's the that's exactly the the important thing. The user has a single point.  I do want free software to be to be able to access it. But I don't want, I don't know, big tech or I don't want, you know, anyone dealing with weapons to access my data. So the user actually gets a single point where he can control all the data and define where that data should go to. So for the user, the user experience is extremely improved. By now or today, you would have to, you know, go through thousands of apps and, you know, individually state, yes, I want to share this kind of data. And I mean, you totally lose overview there. So I think it's very important that I think it's an absolutely practical idea. I mean, there are a lot of pitfalls and a lot of research to be done. Yeah, I think our database structure isn't good enough right now to, you know, cope with what we're asking for. But yeah, it will be, it will change the thing for the user as well. It will make it much easier. Another question is from TR, which has a higher score. So how will it be protected from abuse from inside, from inside the company or from accidental leaks? Would it be integrated into the way private data is handled inside the company? I can't tell you exactly how this has been done, but we have to create a structure that makes it very, very hard for leaks. I mean, obviously we're all humans. There will be leaks. I mean, you can't promise anything else. But I think an important role here is again, the parliament I proposed, because it really takes the instance of controlling the for-profit company, where the for-profit company by itself cannot be transparent because it has to protect certain things. You cannot put your passwords out there. This would be not helpful. But exactly there, the parliament steps in and has to actually check that beyond the scenes that are public anyway, everything is okay. And this is why we have to create a chain of trust into this parliament. We have to trust that the people sitting in the parliament are actually sort of working on our behalf. We as contributors to the data are the shareholders of this business. So this business has to work for us. That is the whole idea. There is another more tech questions about the competition. So how can this highly regulated for-profit data vendor compete with huge company collecting, selling all the data that they can get nearly unregulated or even financed by intelligence organizations? I think the lever for this is actually that we start with in-free software. We just offer an alternative. We don't force anyone. We don't force users into this and we don't force companies into this. But from my professional experience, I know that not a lot of companies are actually interested in my data. They're interested in our data because they want to know how their users behave. They don't want to know what beyond us. They're simply not interested. So they do have an interest in joining us. We have an offer that is good for them, not only on the GDPR thing, but also this label will transport trust onto those organizations that have it. It will work just like the organic apple. The organic movement is successful because the users have a choice. And that is exactly the mechanism working here. And companies will just join because it's the better choice for them than to deliver the data to some of the big companies. I'm not sure we have time for another question. Let me start reading it. We have like two questions left in case we're not going to have them. You can always discuss them in the chat. Well, there is a buff on Tuesday at 10. So join me there. I'm happy to discuss a lot of issues. There are a lot of questions and I could only sort of go through it on a pretty shallow level. There are thoughts to a lot of things. So I'm happy to discuss this. So thanks again. And let's move forward with this room, which is now unified. So Adam, what's up? Thanks. Thank you very much, Bjorn. Thank you, Luigi, for handing the questions as well.


everything. And let's go. Okay, so I'll start with the agenda directly. So the first thing I wanted to discuss today was the interactive testing I did for the redundant fetch fix and the modification for which for which I had a discussion with Mark. So the first thing is interactive testing. I shared the plan with you guys yesterday. So I took some scenarios I thought would affect would affect the results of removing the second fetch. The first one was with advanced clone behavior because of course we're cloning we do this is directly related to the fetch, get fetch. So the first was to see if fetch enabling or disabling fetch tags would directly result in any kind of difference in the information we have for the repository. And so I apart from looking at the result, I also looked at the code and I was looking at how the second fetch is handling the same behaviors, because if there was a difference in behavior, then there would be a chance that the results would be affected by removing the second fetch. That is what we saw with with one of the one of the issues Mark caught, which was that some of the references were not being handled by the first clone API, but were actually handled by the second fetch we were performing. So with fetch tags, the second fetch is also doing the same thing as the first fetch is. So there is no difference when if we disable them, the first first, if we enable them, the first fact, the first fetch will bring all the tags, we disable them, there will be no difference. The second one I was interested in was the shallow clone. First with no depth provided, I was, I wanted to see if by default the second, the second fetch, is it providing some depth by default? And the first is not doing that so that there might be a difference in the commit history. So, so when I when I compared the code, I could see that the clone API basically shares the same implementation for doing a shallow clone. So they both if I don't provide any depth, they have a by default depth one level for doing shallow clones. So there is no difference if I so the behavior will be same if I if I remove the second patch, the first fetch will take care of performing a shallow clone with depth equals to one. Then this third test was with shallow clone with depth two. I think it was, it didn't I think it's the same thing it doesn't it won't make any difference in the results. Then timeout was kind of just I just wanted to see if there would be I was sure that timeout would not make a difference because both of them again, they implement the same get clone API is also is doing what the second get fetch the functions it uses. It's the same functionality. So there is also no difference in case of timeout. Then what does that this timeout specify exactly? So basically time what it specifies is if if you're cloning a repository, if it takes more than five minutes, it's going to it's going to abrupt abruptly cancel the bit. That's what happens is the mark, right? Yes. So that is timeout. By default, it's 10 minutes for an for an for an operation. Yes. The second scenario was with Vibe workspace enforced clone. So this I just tried because I wanted to see because it's it's cleaning the repository and forcing a reclone. So I wanted to see if that would somehow change anything. So I enabled Vibe workspace and I tried. I tried I compared the results without the fix and with the fix and I could not see any difference in the repository information we had. Then it was for checkout for a specific branch and I realized so this is this is the third scenario and I realized that it has basically no it's something we do after the step of which involves these double fetches. So it's in a function called the tree changes. Check out is a stage which is which comes at a later part of the code. So then there's this interesting behavior I found out which is not user visible. It's called get SEM source reports. As far as I could understand it's it's basically done to it's done to those reading and let me recall it's it's done to go to the default river to the default behavior that is enabling on a respect and the second thing was I don't remember exactly. So I was not sure if this would make any difference. I tried it. It did not but since it was doing it was it involved honoring respect. I just wanted to check if this behavior would although I could not understand how is this behavior being called. I did not go too much in deep how this behavior was working. I just wanted to test how this is working and then pre very much I wanted to ask Mark and Fran and everyone you guys if it would make any difference. I actually did not try this scenario. I would not expect to make any difference but it's an interesting question because pre build merge requires two branches at least inside the workspace right there's got to be a source branch and a destination branch but that you've got to have that one way or the other whether it's from a wide respect initially or from an honor respect and you declare both branches so I think I think it is is on an effected by this. Okay so I haven't tested it so I think I should test it still. I would given what you've done so far I would even propose skip that safely. Don't worry about it. Let's trust that it's it's it is not going to affect this. Okay, so after doing these interactive tests there was one interesting problem which Mark he pointed out and that problem was that with the ref specs while while we're fetching the ref specs so we have multiple kinds of references. Ref specs are basically mappings for the references between a remote repository and the local depository so so we can then the ref specs which the first fetch handles they are they are related to the references of branches that is refs heads any any related branch or star which brings all the branches. Now if there is a case when we want to check out for a particular pull request which is a feature specific to GitHub or maybe something some other kind of a reference for GitLab. The first fetch will not handle that if we are not honoring the initial the respect for the initial flow if the user is not choosing that option. Those fetches will those references will be missed by the fix I have proposed and so so that so this is a huge issue for for us to move on with this fix because that would bring direct failures and many use cases will be broken. So so I had a discussion with Mark on how we could safely retain the fix and modify the code so that we can we cannot break any use existing use case and we still do not have to call the second fetch although the current modification I have tried there are cases where I would have to call the second fetch call to not break any use case. So right now would you guys like me to go through the fix the modification I've tried and then the interactive testing I tried upon upon that modification to see the cases which Mark Mark pointed out for which code was breaking the use cases. I tried those cases and now it's working with them. So would you should I explain and go through that code or would you guys review that from the PR and that's a we shouldn't use this time on discussion of that code. I'm I'm open to either I will have to review the code either way. So let's look to the Omkar and to Justin and to Fran. What's your preference? Do you want to skip detailed code review in this session and go on to other topics because you've got several other topics we need to address Rishabh, right? This is this is not the only topic for a session today. Agreed. Agreed. So that is I just wanted to ask. So was that is that there already raised the one you mentioned is is it talking about that? Yes, yes, it's it's a comment on the latest PR. I'll share that PR on the Gitter chat. I think it's 904 if I remember right. I'm I'm becoming very aware of exact PR numbers for your work, Rishabh 845 904 because of the multiple bills. Oh, no, it's because it's very important. I'm very interested. Okay, so just in Frank and Omkar, would you like to discuss it or should we move forward? I think we can. Yeah, thank you. Yeah. Okay. So the second, the second agenda is related to the performance benchmarks and benchmarking in general levels. Very benchmarking has been surprising and irritating at the same time for me right now. So what has happened with the first of all, what I what are the important things I have to discuss is that I was profiling the Jenkins instance with with whatever changes I did with the fakes and without the fakes with Java flight recorder. So using that profiler, what what I was experiencing experiencing with consecutive builds was some kind of issue I could not find out what the issue was, but there were there were huge time differences between the git fetch calls between some repositories, which was which was what I showed in the platform, say meeting and which was wrong. So then and it also took a lot of time for me to change the repositories and then again, run the instance fixes, it was taking a lot of time. And I wanted to do it with a lot of repositories to actually see how are we doing with redundant fetch, what kind of performance overhead would be reduced if we're allowing that fetch. So I shifted to so I shifted my strategy to use a performance bench or GMH benchmark, because I would have to just write a benchmark, I will, I will have parameters where I directly put a lot of multiple repositories and I, and then I don't have to do anything, I just have to wait for the results. And also, theoretically, benchmark is the thing to understand the root cause if you have to do a root cause analysis, it's the best thing. One of the best things to do is what I thought. So, so I tried a bench. So I've written two benchmarks related to the redundant fetch and I'd like to show you the results and the benchmark. So the first benchmark is so, so I've raised a PR for the redundant benchmark as well. I've also written another benchmark. Meanwhile, I'm going to show you that benchmark first. So with this benchmark, what we're doing is we have so I've written two benchmarks here. The first one is going to use the initial clone. It's going to initially, so it's going to clone a repository. And we're going to see what kind of time it takes to clone the repository for the first time. Then in the second benchmark, so the first benchmark acts as a baseline experiment that we can compare when we actually add the second operation that is the second fetch call. How much time difference are we gaining because of that? So the second benchmark is basically, again, the first thing, the initial clone, and then again, a fetch, a fetch operation. One thing I realized when writing the benchmark was that I was not doing any kind of validation to check if these operations are actually doing what they should do. And I what motivated me to do that was that some of my benchmarks were giving me results which I could not understand completely. I was like, I don't know how to write a benchmark either or I'm not able to understand. So what the initial validation I've put here is that the first thing we do with the benchmarks is that we clone the benchmark from an upstream source repository to a local place for the instance of the benchmark. So that is the first thing we do. So at that time, I record the size of the repository we have when we're doing that. And then when I'm using the benchmarks, and I'm actually cloning them from that local upstream, local repository, I have local repository. So once I do the fetch, I compare the sizes and I see that actually this operation has taken place and the time is not just because it's actually not doing what it's supposed to and I'm getting time analyzing them and I'm inferring some observation from that and those operations are not doing what they should. So this is the first validation I have put here but I am thinking of putting more validations to actually see if the operations I'm trying to benchmark are working or not and the times are real or not. So with this benchmark, the results I have is yes. So the results I have, I'll explain what you're seeing here is. So these are the two benchmarks. The first benchmark is here with the initial clone. This is with the double fetch calls. So this is the second benchmark. This is the first benchmark. With the first benchmarks, the color grading, it basically means is that so we have get and implementations. I'm actually also testing that as well to see how both of the implementations work. So the two bars here, these represent, so I took two repositories. The first is the Jenkins repository and the second is the Ruby repository. And why I took those two repositories? Let me just show you the reason. The Jenkins repository, the number of commits 30,000 branch is 31. With the Ruby repositories, I have 61,000 commits. It's basically double. So I wanted, so one more thing I'll discuss after this, whatever I explain is that I'm not able to find constant size repositories or something near that when I'm actually looking for real repositories. So with the Jenkins one, this was the closest thing I could find. This is 366MV and this is 471. There's a good 100MV difference. But this was, I thought maybe I could get something out of this because the commit size is increasing. The double, it's double. With the branches, it's not, it's actually, let's not see the branches here first. Let's see if there's actually any differences because of the commit. So the results here we see is for the, for those two repositories, Jenkins repository and Ruby repository. The first one is the Jenkins repository with the git implementation. The second bar is the Ruby repository with the git implementation. Then the next lighter blue color bar you see and the gray color bar you see are both of the repositories with Jenkins. And this is for the first benchmark and then the same thing for the second benchmark. So if we see the results, technically real-life performance, there is theoretically from these benchmarks if I could infer, there is no difference, no tangible difference between a single fetch and adding a second fetch on that same repository. And as you can see the first benchmark, 11 seconds per operation with the second, with Jenkins, it's again 11 seconds. There was some difference. It was some microsecond difference, mini second, sorry, not much. So I took the time unit for seconds this time because I actually wanted to see real-life differences, how much would we have when we're removing, when we're actually adding the second fetch. So and the only difference, the only difference I could see was with the last one that is with JGIT and with Ruby, there was one second difference between both of the benchmarks, which is kind of... So you're confident that it was really using JGIT as the implementation. Those are so similar to each other, it seems like they're either both using, they could either both using CLIGIT or both. That's fascinating. I can't explain what you're seeing. That's really interesting. So I have another test for the redundant fetch benchmark. And you looked at the logs and you saw that the logs were showing in both cases. Or did you use some technique to confirm that, yes, I really am using JGIT for this, for this one. I really am using CLIGIT for this other one. So I usually log, I have, I usually print and I'm using, when I'm with the benchmarks, I print the implementation I'm using. That is how I'm sure that, okay, this is how it's being calculated. And since this is looking a little absurd, I actually have a place where I ran these benchmarks. I'll show you. Okay, so and this one, that one was clearly using command line get because it has the command line get markers in it. So. Oh, which one Mark, what are you? I just saw a screen that went by that had the clear logging from command line get. I don't know that it's all related to what you're doing. Go ahead and show us the files that you were going to. Yes, so this is the run which happened. The visualization you're seeing, these are the results in this form. So here you can see where the first benchmark, which is just the initial clone, get it's giving us 11 seconds. And with again, get with the second benchmark, which has two fetches, it's giving 11.181 seconds. So the difference is very minute and it's not a good thing actually. Okay, that supports the observation I had earlier when initially people told me this fetch is enormously expensive. You have obviously found at least one case where the fetch is not enormously expensive that redundant fetch. That doesn't mean it's always free, but at least it means you found one case where it is free and it's surprisingly low cost. So interesting, fascinating. I wonder if so when you're when you reference the the repository on a local disk, do you reference it by absolute path or do you reference it by file colon slash slash url? File colon slash slash url. Okay, because you may want to read the CLI get documentation. I don't think they do the same optimizations for jget, but CLI get may do some things where they say I know this is local and remember that the person who started writing this was Linus and therefore he thought very seriously about file systems. He says if I know it's local, I'll just do hard links or I'll do symbolic links or I'll do, you know, there are all sorts of things that he could do knowing, oh, this is local. I'll just I'll just make take advantage of the fact that it's local. Okay, that might be because with these benchmarks, we're assuming what we're doing is we're fetching the repository from a local file system repository. So this is not a real use case, real life use case. That is so because with profiling what I saw, I saw results, not huge results, but at least there were there was a 10 second difference between so that the second fetch it was costing around 10 seconds or maybe eight seconds or 12 seconds, at least that much. So this was a little surprising. Well, okay, so another argument here might be that in fact, the network transfer time to do the incremental fetch is so important, it may be maybe a dominant factor there, and therefore we won't see it in this in this intentionally controlled environment. Good. Okay. Interesting. Yes. And one more observation I think which we've discussed already is that JGIT with a larger size repository, JGIT is performing waivers than what CLI get is doing. Right. I kind of have a question that why are we you, why do we give JGIT as an option when we're seeing that I actually don't know why we use JGIT. I have never asked you that but why are we using it when and we see that for any normal size repository, JGIT is going to perform worse than CLI get. So the original dream many, many years ago before I became a plug-in maintainer was that JGIT would be ever been as good as command line get and we would get better results by using a full native implementation. The reality about a year into using that implementation was we learned very painfully that JGIT was not a complete implementation of CLI get and since that time the evidence has proven it will probably never be a full implementation of CLI get. The people who maintain JGIT are very committed to it and they do great work for the things they need from it. But of course they work on the things they need and so the one use case where JGIT is very, very helpful is if you have a platform where you can get Java but you don't have a command line get port JGIT will still work for you. So in that case it's interesting for large repositories it looks like we have clear evidence it's never interesting for you. The other danger with large repositories is it's using Java virtual machine memory to do the clone and therefore you have to worry about memory leaks inside or inadequate garbage collection etc. inside the JGIT implementation whereas with CLI get it's always a sub-process the operating system will garbage collected for you. So yes your observation is very wise that why use JGIT for anything larger than about 10 megabytes. Okay and so the next benchmark I have actually raised up here for that. So this with this benchmark what I'm doing is I think I'll show the benchmark as well. So with this benchmark we have multiple repositories it's from the Jenkins these are Jenkins repositories small plugins I just incrementally increase the size and number of commits, number of branches to see what are we seeing here and I was actually tired to find so what so the conclusion I came into was that either we we need to create repositories on our own where we have constant sizes but different number of commits Omkar also suggested that but the issue with that I see is that we will never be able to simulate what an actual repository is for an example right now I can compare two repositories where I have a 30,000 number of commits difference I think it'll be very difficult for us to see all of those kind of parameters we set those parameters for repositories we create ourselves while we're benchmarking but to have a clear sensitivity analysis where we directly want to find out how this parameter like the number of commits would affect the execution time for Git fetch without freezing without taking the size of the repository constant I'm not sure how we'll be able to confidently say that okay if we increase the number of commits this is how the execution time is going to change because the size with what I've seen the size always increases when the number of commits are increasing with what I've seen I think that's kind of an obvious fact and so that is that is one of the issues with this strategy both of the strategies I have so with this this benchmark sorry I had some of the repository I had four repositories here and it's doing the same thing it's actually not doing the same thing here's a difference the difference is that with the earlier benchmark I was actually cloning the repository for the first time within the benchmark test so I was benchmarking the execution time for that operation as well here the that operation is is taking place in the setup before the benchmark it's it's happening before the benchmark so ideally it should not affect the time so clearly I should what I should get is the execution time when I have the results the execution time for the incremental fetch is what I should get from this benchmark and so what I got so I'll just show the benchmark this is the benchmark it's incremental fetch the Git client I'm using it the Git repository it's referencing it should it should have already have a Git repository fetched from the local Git repository I have so so the results here we can see is that with Git so the colors you see is basically multiple repositories with Git and then with JGit it's just one benchmark so we don't have a confusing result here it's not that much confusing so with Git as we increase the repository size one positive result I can see is that the execution time is increasing for the the cost of having an incremental fetch is increasing though the increase is in microseconds uh milliseconds but it's an increase and I'm sure as I increase the size I take it to maybe much larger repositories we'll have a change but uh what I have to do is after this one of the most important thing is to map this the theoretical observations with practical observation and to do a practical observation what I've seen is that I can use JFR profiling tool to see how for those repositories what kind of performance overhead I am reducing while I'm avoiding the second fetch with this we can see that okay now there is a change there is a difference there is an increase uh when we increase the size of the repository the number of commits also increase the number of branches increase but I can never say for sure what is contributing the most for the Git fetch right now because since the size of the repository is increasing I there's no way I can say that okay the commits is why this is happening for for that to happen I need maybe two 500 MB repositories with one we're having there should be a clear difference in the number of commits possibly something like 20,000 commits in one and second might have 30,000 or 40,000 so that I can see okay for these constant size repositories if the number of commits are increasing this is how the execution time is increasing or decreasing or it is having no effect so but that is yeah I thought I thought our intent here was trying to understand which thing should we include in the sizing heuristic and isn't isn't your observation here saying we should include both repository size on disk and number of commits because they seem to both show as they increase we we the execution time increases so do we already have enough information here to say yeah number of number of commits in the repository and size of the repository on the disk are both relevant to to performance so we include them in the heuristic yes mark you're right the ultimate aim for doing that is to to find what performance how is the performance affected from what predictors but what I'm saying is that we're not able to test them independently not as independent variables they are they are dependent I'm not sure is if the file what is contributing more to the performance changes in the git fetch is it the file size is it the size the pack the size of the pack dot pack object or is it the number of commits of course it would be the dot pack object most of the performance would be affected by the size only it's common as my common not sure technically I haven't even yes yes mark no no you go ahead and finish excuse my interrupting no no so my hypothesis I wanted to test was that if we have a repository with a large history and maybe not a considerable size but a large history would that affect the second fetch more because what I assumed with the second fetch was that the first fetch would download all the word clone all the objects the packed object the second fetch does not have to do that what it should do is to is what I think I haven't checked I haven't looked into confirm this what it should do is to iterate through the list of the commit history or basically it has to get the incremental differences or any changes in the repository the second fetch would want to do that and to do that it would go through the history and so my my hypothesis what that was that the redundant fetch would actually have a considerable performance overhead if we have repositories where the history and the branches they're they're larger then there are cons I would say a considerable number is there for those repositories that is something I wanted to test and I'm not I'm still not sure with these we're sure that with increasing the size and all of those the number of commits we're seeing that there the performance overhead of the second fetch is going to increase we're sure about that because we can see that with both of the benchmarks not for the second first one too much but with this in in with a the microscope the time unit we can see clear difference but I'm not sure independent variables how they're contributing to the performance and also again we can see that jgit is actually performing better for us for small size repositories the thing we have the the observation we have that for a small size repository jgit is going to perform better than yet we've seen that with these this bench mark as well that it's performing better though it's the difference is not much in real time I think we see the differences with much larger repositories jgit is not performing better I'm not sure how much this would affect the performance for a user noticeable changes but theoretically it's jgit is performing better than yet for small size repositories so yes so with benchmarking strategy I have so if if our aim is say if our aim is just to see that so we need to make an estimator and to make make an estimator to estimate the size of the repository what kind of parameters we need to see so the obvious one is the size of the object the second it's safe to assume it's number of commits number of branches but how much how much independently they affect the performance is something I haven't not able to figure out right now that's that's my concern yes so any yeah what do you guys want to say yeah I so so I'm I think you've you've you've answered the question should we include size and number of commits in in the in the the assessment absolutely and we've got you've got data here that says yes jgit for small size repositories is marginally faster so so there's there's another incentive to say okay we should now probably look at code and say or put you into code and say all right how do we use this now to implement the heuristic or to implement the estimator the size estimator and and start seeing how do we get that into the code to allow people to the option to say I want to use the fastest thing for my repository okay that is what I thought as well that we could we have clear evidences that some of the parameters they how they are affecting so we can start working with the estimator and and I think the next agenda the thing I had agenda was analysis on fine so we have discussed this performance predictors for git fetch now the repository size estimator so I thought that I would write a class I could show a prototype on how we're going to do it the approach but I could not do that this was stuck with benchmarks and effects but I did research on the heuristics we were talking about a little bit I saw the things we could do and so the first option we had was I think the first option we had was to use the easiest one to use github APIs or the API is already exposed by these providers so with github war the problem I have seen is that they give the size of the bare repository instead of the actual repository so so that might not be a clear indicator of the size of for the deposit so I experimented that with vscode microsoft vscode so I cloned it and I and I also I I tested the API provided by github to check what was the size it was returning to me so the size was around according to the github API it was around 300 and but when I cloned it it was around 900 so that's that's a huge difference inside this so I checked around so I found out that github they on the servers they have repositories bare repositories so they they gave that size as a result when we're trying to receive that information and yes Mark so on when you say that the repository in your local copy was 900 meg does that mean that the dot git directory was 900 meg or that the whole workspace including the checkout copy was 900 meg or reshub I think we may have lost you yeah I think we did yeah okay well while reshub gets ready to come back I assume he will eventually reattach for us as mentors we've got an upcoming day arriving soon oh he's back good I'm sorry I'm scheduled powered guy so yeah yeah so I was what were you saying Mark I kind of missed it so when you when you when you say that the the vs code repository on your disk was 900 megabytes is that just the contents of the dot git directory or is that that the entire checked out copy not just the dot git directory so to to measure that how do I measure the size of when I'm cloning the repository how do I do that I basically I I think I have it yeah so when I'm cloning it it usually shows us downloading the objects and so if you if you I'll show that instead of explaining something I think we all think we can go ahead yes so I'll show it here so take a little bit of time so the amount of objects it's downloading so it shows the size so here I just so this is what I consider the size of the repository when I'm cloning if you guys can see my and I have no idea what that number represents okay all right so so that number I don't know what that represents I I usually look at the size the du minus s output of for the dot git directory because what that tells you is size on disk of the of the the fundamentally what is almost the bare repository as represented on the other side so I think I have to confirm that I haven't I I I think I did check the objects dot pack object which is downloaded by cloned by cloned so I could see similar sizes from from these from this thing and from from that object but I think I'll check that mark first to see if that is working and so and with estimators with the estimated class so right now the one option mark gave was the great option is to if we have a cache cache repository for for the project we could use that if it exists so we do that currently in our code right mark and and if we want to if if that exists already we could that's it's the best way to estimate the size of the repository uh so we could use that I haven't explored uh how in what for what lifetime that cache exists where would I find that cache I assume it's it's it's on the it's in the workspace right agent workspace no it's it's in the master only in the master actually and and okay so mark if I if it's in the master and I have my workspace in agent so either I so what do I do I reference it okay for one second master agent please share the same hdfs and I'm actually not very sure how that's going to work so so the the the the execution of most of the logic is happening on the master for you therefore you can ask questions of the cache on the master pretty directly so things things like the when the git scm object is created you can assume that's on the master and that scm object then can can look at the local cache and interrogate the local cache so I don't think you have to I think it'll be pretty straightforward actually if you just use that I don't even think you'll have to do a cache lock in all seriousness because I think all you're trying to do is look at the file system so you get the get the directory of the cache and then knowing the directory name you go use file system calls to ask for the size of the contents of that directory and that gives you a relatively quick approximation of the size of that repository repository yeah okay so I'll let you explore that I think I'll write a prototype as fast as I can for the estimated class uh so um I think we've we've extended the even officially unofficially extended this to one is that okay with everyone I'm sorry that oh yeah for me I trust that the mentors who can't be here will drop off so so you that that's we set it at 30 minutes and we'll we go as we can okay so I did want you to get to the the demo work the demo plan because you've got a demo coming up is it next week or the following week I think it's next next week okay great yeah so um so I have to do a bunch of things I saw the mail so I have to publish a blog post before that I think we should discuss what all should I put in the demo and so um from my side what I would like to show is first the whole benchmarking strategy how we're doing that the code and then the results what I would also like with benchmarking maybe one more operation so that it's maybe like gate ls remote I was interested to see how that would work maybe I have some interesting observation to show for gate ls remote so I I I want to expand the benchmarking strategy for those two operations um that's the first thing we could show the second thing would be the redundant fetch work how we've done it and um so I was thinking because of the demo I would have to show what I would have to show something visually so I as a feature or something in the user interface and most of the things I have it's usually code or weird results so I'm actually not sure what what are your guys expectations how is the are you the guys who will be my uh who will be in the panel when your evaluation in the evaluations or is it the core committee of Jenkins how so yes we're the we're the evaluators you it's it's us you've you've got all four of the evaluators online and sorry yes so I guess the best yes yes mark yes sorry I think I think if you show graphs and I don't think you have to show a Jenkins UI as much as graphs and highlights of hey here's what we've learned as part of this exercise look at this look at this here's an improvement here here's an improvement here and people will be more impressed actually with with graphs and charts of performance performance comparisons than they ever would be with show them a Jenkins UI because we knew this was a performance performance project okay yes so that's a great relief because I was as I was seeing other projects I was like I don't have any kind of so I was seeing that they have their own plugins they have user interfaces and I I don't have all of that right yeah last year from my experience last year we had some other projects that were similar to this as well and it's it's not a big deal like if it's a plugin-based thing where you're actually building a new plugin yeah like you might get into the demos of how that works and use your experience and stuff like that but yeah like Mark said I think I'd definitely focus on the meat of this project and that'll people will like it in a perfect world they will see nothing different it'll just be faster right yes so so so if you if you show I'm going to show you nothing except it's faster then that that should already delight people it's like wow that's great because usually it's it's faster and I had to break the following things in order to make it faster okay so so what I'm thinking is the first thing is the benchmarking strategy where the kit fetched what I did and how I improved the benchmark on the Jenkins it's running and everything one thing which is missing right now which I haven't showed you guys is integrating the jmh visualizer plugin on the Jenkins which I have to do that I haven't done that because that's I think it's going to be a great improvement because we'll be able to see visually how the results are showing so that's something I'm going to do and I'm going to do it for get LS remote as well so for these two operations the benchmarking strategy then with the redundant fetch I think from the the the fix the would you guys be interested in seeing the testing scenarios and the cases we considered while we were fixing this and the use cases we had to consider if we would break them or how to do this safely the whole thing or is that something we don't have to discuss we have to discuss the fix and then the benchmark which would show that this fix is showing some improvement I did yeah so for me I'd keep the the testing in your back pocket in case somebody asks hey how did you check this I suspect the audience will be I'm I'm gravely concerned about not breaking compatibility right that's a big deal for me but the audience the larger audience probably will just assume that think of course no one's going to break compatibility and so they'll be more interested in your results with numbers and with the performance results and your observations on hey here are the characteristics we saw okay so with benchmarks as we've seen that the theoretical results they're not showing much of a difference so what I want to say what with the the redundant fetch the results I would like to show is the profiling results as much as I can so that I have a large sample and the result is results not something which we do not expect well I think it's okay to show the show the surprises as well and say welcome to the real world sometimes we get surprised by how software behaves I feel no shame in declaring that we were I was that you were completely surprised to see this result comparing to this other result and that more investigation is needed that's that's perfectly okay okay so so the benchmark results and the profiling results both of them for the get it done fetch issue and then I think the third thing would be the third thing would be the estimator class if I'm able to create that with some heuristics which we've thought about and so I need to first consolidate the approaches we can take and if it's even possible with the way we want to do it because I'm right now not too mature because with the apis I was actually seeing something which I discussed their difference in the size because of bear and the object I have to confirm that with the cache thing so if the cache doesn't work then what we do because with the cache it's I think if we have the cache then it's it's it's simple to estimate the size but if we don't have that then it's the real work where we would have to understand how what's the how we could estimate the size I was hoping that number of commits and branches would have a great so if we could get the number of branches we could get the number of commits and even if you don't have the size of the objects we might be able to make the decision but with the the experiments I've done I was not able I'm not able to find out independently how these factors how they contribute to the performance so maybe I'll try to I'll try with some more experiments if I'm able to isolate that so I think I already have a lot to yes and one other thing you could maybe try if you wanted to like if we wanted to rule out the disk things like the Linus thing that Mark was talking about you could maybe set up like a Bitbucket or GitLab server on your local network put these repos on there and then that would like get you to like maybe Git's not going to optimize for being on the file system that's a possibility as a that's an optional possibility but well and Rishabh I have an environment that we could use to simulate exactly what Justin described I have a local Git server on my network that that happens to be just full of all sorts of interestingly sized repositories so so Justin's idea is good however even before that I would take one more I think you've learned something in this extra you you've gained a crucial piece of knowledge that I don't think you highlighted nearly enough as you're in your summary it is that there is a performance curve there's a performance result for Git command line Git and there's a performance curve for J Git and there's an intersection between those two curves that is dependent on repository size factors and and that is something truthfully before you did this project we did not know that I had not I had an assumption but I had no data to support that and what you have is you have hard data which says as these attributes of the repository increase the the characteristic performance of Git is like this and J Git is like this and that curve if that curve is your opening slide even for me that would be great because it says oh uh oh everybody should be aware of this characteristic of the J Git implementation okay you've done you've done concrete measurements and the measurements keep showing over and over again this exact same story that with large repositories J Git is a poor choice yeah and and so people should be aware of that you've you've already contributed to the body of knowledge just with that that that initial graph okay so okay and make sure that I so I did not highlight it this time because I thought that we've already had discussions at benchmarks which show these results that is why I wanted I did not highlight it as much so um so this is what I was saying I'll show in the evaluations and apart from the plan also what I have to do is I need to write a blog post where I'll probably show the results to the thing you just described I'll show that and I'll show the benchmarks and I would also have to make a presentation so would you guys like to be a part of how I'm making the presentation or is it something I'll just make and I'll show it's you guys are not involved in it so I propose that we that you show us a your initial framework of the presentation on Friday if you would be willing so that so that we have a chance to give you feedback for instance it asks for a blog post and I thought you know what the performance results you've seen would be a great blog post let's say look just for the information of Jenkins users without any code change you should be aware that if you choose JGIT and your repository size is larger than such you are sacrificing performance intentionally okay okay so I'm going to do that and with the presentation okay so I'll show you show guys something on Friday presentation sample presentation just to highlight we use JGIT as the implementation on ci.jankens.io and that's fine for small repositories but remember that the documentation repository and the Jenkins core repository are both well beyond the threshold size that you've identified so I already have an improvement to make in ci.jankens.io to get it to get some performance back okay yeah so um okay so I think this is I think this is what I wanted to discuss with the blog post I wanted to ask do I have to do that on Jenkins.io or can I do it oh it's it's mandated with Jenkins.io I thought I was setting up a github page blog and I was thinking that I could do it there you are welcome to start it there but ultimately I will expect it to be a Jenkins.io blog post but what's that it'll give you some visibility to having it on the Jenkins.io right okay yeah it'll be good I'll add it to the Jenkins.io page okay okay so so the evaluation starts from June yeah yes Justin yeah plus one for like demoing your demoing your demo uh that was a good way for us to get feedback uh before and then uh one thing that we did before too which is up to you uh I think we had done it in Google Slides doesn't matter like what technology you use but if you want to share that with us too like we can do markup and comments for if you want feedback on some things too okay up to you I want you to use Google Slides necessarily but I like to use that because it'll be collaborative the work and we collaborate at the time okay okay so I think that's it thank you guys for spending much more time than allocated for the meeting thank you Rishabh okay thanks I'll post the recording thanks everybody have a great day we'll talk to you Friday Rishabh yes


How's it? How's it guys? So great to have you here today, having a little chat on the couch about our photography and because I am so thrilled that you are here sharing with me and I want you to be the like the best photographer that you possibly can can be. I want to give you a little warning. I want to give you a heads up about something that has probably affected you at some point in your photography. If it has now it is going to at some point in the future and so many photographers struggle with this mistake. It's not a mistake that can be rectified by doing a tutorial or reading in a book or or any of those sort of things and yet because it it affects so many photographers I'm surprised that nobody has ever addressed it. So that's what I would like to do with you today is have a chat have this this kind of informal conversation about this very thing that is is threatening to sabotage your photography. I'm going to share with you a a story a secret about me if you will that is very difficult for me to to say especially to you and everybody else who watches this channel and is that that is that for the longest time I fell out of love with photography. I was not into photography. I sure I was I was still working as a photographer. I was still running my studio and I would put on the the stage face and and go and do you know do family portraits you know and make a reasonably good living from doing that. But yet every time I went into that studio every time I opened the door every time that I sat down with a family I showed them photographs of them it reminded me that this was not really what I wanted to do in photography that by step by step inch by inch I had moved further and further and further away from the excitement of taking photographs of the joy the simple pleasures of just taking a photograph for that simple fact of just because I liked looking at it I wasn't doing that anymore I spent you know 18 months two years really not taking any personal photographs at all like nothing I barely looked at any of my monographs I if I didn't have to go into the studio because really I'm only trained as a photographer I don't have any other skills to fall back on I probably would have ditched photography completely and and my life would be so much emptier for that and the reason that I haven't the reason I have now rediscovered my enthusiasm photography is down to two things the first is a guy called Chris and we'll come back to him in a little minute but the second thing it's well it's you it's you there watching this having a conversation with me albeit just a one-sided conversation it has reminded me that there are people out there who enjoy photography that they don't see it just as a way to make money and and that's kind of you know in in the in the area that I was working in a lot of photographers would pay lip service to the the idea of being a photographer of you know a wider sort of thing but they weren't taking pictures to have fun they were taking pictures that were mechanical in process simply to make some money they were effectively marketers who were taking photographs and so I was worried the very first time that I put up a video and it's almost a year ago now in fact this time last year I was busy putting the touches on my first video the Richard Avedon one and if you haven't seen it before I will link to it at the end of the video and it's always at the site for sore eyes right but I was sitting there and I go okay well I've got to do something I have to try something to rediscover my connection with photography and I thought maybe I can do this by helping other people remember why they start taking photographs in the first place they're having that that fun back in in the images so it's thanks to you and the rest of the community who sit who talk who give me feedback send me emails who who say great things and and and enjoy the content that has helped rekindle my love and my interest and my passion and my joy for photography that I felt when I was just starting out taking and holding that camera in my hand and and just seeing the world with the possibilities that it could so the second person and and is is what I would call a friend of the channel in old speak which is um I don't it's a bit of a naff with saying it yes okay so Chris Cuffero you are a friend of the channel you're officially been you know knighted as a friend of the channel now Chris is an american photographer and he is doing pretty much what I would have liked to have done when I was younger I wanted to be a musician not a musician a music photographer I wanted to be in there with bands and stuff because you know I was young was into music and stuff and Chris obviously has made a career from doing this he has photographed many many many many many many many many famous people and and I would love to do a a deeper look at his photography at another point we certainly will come back to him because he's he's a great he's a great guy and a great photographer but he would reach out and he would say listen Alex wake up right your content is good it's interesting I enjoy it but dude you need to lighten up right you are like ramrod stiff and you are kind of like not from presentation thing but you're being very earnest you're being very serious you are drifting into the realm of the strokey beard person who's telling you all about the high highfalutin sort of things and concepts remember why you take photographs in the first place you take photographs because it's fun man because it's it's it is a fun thing to do so Chris absolutely thank you ever so much for reminding me and for in extension reminding everybody who's watching this so that's you you need to be having fun with your photographs the people who tell you that you need to be in a certain way are the same sort of people who would sit there and they would look at somebody like Keith Moon this lunatic drummer over here and they would look at Charlie Watts and say this this very studious looking man over here and they would say well Charlie Watts is evidently the better drummer he is evidently the better because he is learned he's wise he he behaves in a in a serious fashion he takes it seriously and you know and and he just sits there doing his stuff whereas Keith Moon is was rather a lunatic I think it's fair to say he beat the drums like they owed him money and and I don't think you could say that he took anything seriously and yet both of them enjoyed the process of drumming they enjoyed the art form of drumming and and they were committed to it they they they loved it for for the energy that it gave them and and and those you know those sort of things and this is what we need to remember in photography is that you can express yourself as a photographer as a personality in so many different ways you can have fun with your photography and still talk about you know conceptual concepts and and and layering and all that sort of stuff but you can also have fun by being silly by by doing ridiculous things by going what happens if I do this what happens if I photograph a wedding with a plastic 1.8 50mm on my Canon you know it's you know you may recognize the voice of experience in that one and you know and then you tell people that you did this you say I have photographed wedding on a plastic 1.8 and they look at you and they go but well why why would you do that don't you aren't you serious about your photography and you go well yes I am and you know that was it was fun it was an experiment and it was cool it worked it was great you know so you don't need to behave in a silly fashion to be fun you don't need to be if you are the person who who is you know a little bit more upright a bit more old-school if you want to call it that that's also fine so long as you remember why you're doing this and that is to not please other people not to become a version of the photographer they think you should be and behave in a certain way that they think you should but because this is fun man you take a photograph and you see the world and it's and it's awesome whatever enjoyment you take from photographer whatever you get from it don't let other people stop you being fun with it having a fun and enjoying the process I have been guilty on this channel of occasionally being a little bit high but a little bit earnest and I think you know Chris has called me out on this a couple of times and and I've felt over the last few videos that I'm finding my feet with with the channel the channel is almost a year old the 20th of November 2020 I put up my very first video it was a video about Richard Aberdon if you haven't seen the half hour epic of me talking about a book I'll link to it at the end of the video it's certainly worth checking out because I would say that wouldn't I right but but here's where I would go with this is that this this video here has been more conversational it has been a lot more chatty than then certainly my earlier attempts at photography or videos about photography work and and this is because I have taken Chris's advice on board and also introduced into into this channel which is I started this channel because I wanted to talk about photography was something that I enjoyed it was my way out of rediscovering the the the the the the fun that I was having with with my photography by doing something that I enjoyed which was talking to other photographers now the reason I kind of moved away from scripted episodes and more kind of just conversational things while talking about photography is that if you were sitting here next to me or in front of me this is in my lounge and this is this is my lounge where we're finally getting around to doing some decorating um you know after the move then we wouldn't be sitting here with you sitting there going mmm yes it's all very very interesting and stuff you know and and it would be a proper conversation it would be back and forth back and forth hey you know and it would be fun we would be feeding off each other's energy and obviously in in youtube land it's a little bit tricky to to feed off but that's kind of why I'm moving away from the the more scripted more rigid formulaic sort of uh you know sort of very like here's a photographer and we're going to discuss their life and yada yada yada right into more kind of like do you know what we're going to look at these photographs and remember why that we enjoy them why do we like looking why why do I look at somebody like Tim Walker you know Tim Walker creates worlds a bit like David La Chapelle that do not exist that they they create these these fantastically worlds and I don't think that you know you would look at some fashion photography per se and say that has deep and layers of meanings and things like that it's just it's it's made because it's fun there are certain photographers who take their work very seriously and I believe that you know they have a a method and an agenda and something like that and they they will you know be more the Charlie Watts kind of photographer but then there are also photographers who are the Keith Moons who are the you know the the lunatics who you know would jump off the stage blow up their drum kits and all sorts of things like that because they can because they're not worried about you know conforming to some idea that comes from a you know a camera club or some sort of academic who says you must do this and they're not trying to impress that person they're just trying to be themselves so so with you just you know do your own thing man just I would implore you right if you are in a camera club right now if you're a member or you know if you're part of a group of photographers or you're in a phase you know whatever if you're if you are around other photographers who are not making you happy who are saying things that you kind of go well that's really not how I see photography don't waste your time trying to convince them that your way is is is good or is acceptable or whatever because it's just it's just a waste of time it's like it's like arguing on the internet nobody ever won an argument on the internet move away if they're if they're if they're being downers man just just move away from them right surround yourself with people who make you excited about photography and if you are excited by photography by being around people who talk in an academic sort of way little stroking bits that's cool that's absolutely fine but also if you want to be surrounded by people who are kind of maybe on my side of things where I'm a little more like do you know what I'm just going to see what happened I'm going to photograph a wedding with a plastic lens and I'm going to you know I'm going to photograph on holgers and all that sort of stuff because you know why not because it's fun you know then then do that just whatever you do just surround yourself with people who inspire you who inspire you to be the very best photographer and expressing yourself in a way that makes you happy that makes it fun for you that's really what I want from this channel is is to kind of just say to you look you know any way you want to express yourself is perfectly fine that that ultimately you should be finding fun with all sorts of things I don't know we keep coming back and talking about fun and stuff and that's because as I mentioned earlier this this video is not scripted this is me talking to you this is me reaching out and saying do you know let's let's forget about this idea that there are people who come down from on high and dispense their wisdom whatever word and and just throw it away you know or just yeah most people listen to their wisdom and throw it away but you know it's not like you've come down from on high and say look these are the things and you should and then I disappear again and I come back and I disappear and I come back right I from talking with you listen to the comments from from reading the emails that that you guys are sending me you know it's it's wonderful to see that there are so many people who watch the channel who enjoy photography who are either you know seasoned photographers who've been doing this for for many years but also there are people who are who are just new to photography that there is a common thing that runs throughout all of them and that is that at one point or another all of us picked up a camera and and we loved what it was that it made us feel it made us feel something and that was obviously a positive thing because we stuck with it you know we didn't take some pictures and say well I'm not really into this chuck it to one side and try you know a drum kit maybe you know Charlie Watts or Keith Moon had done or something like that we stuck with the hobby and for some it turned into a professional career and you know so like myself and and and I drifted further and further off what it was that initially connected with me and for some other people they have never wanted to do anything more with their photographs and simply just see the world in a certain way take pictures and you know if somebody else likes them that's cool all right because ultimately we got to take pictures to to have fun and and and that's just kind of I really want you know if you're ever feeling like you're not having fun with your photography I'd employ you don't just don't don't chuck it in don't just give up on it because you know I was very close to giving up on it as I mentioned earlier and I really would have regarded that I think it would have been a crying shame it's such an important thing in my life that that I would just become disconnected from so if you are struggling with your photography if it if it does feel like it's a chore if it does feel like it's a job that you are unwillingly doing then take a breather take a breather do something else you know put your cameras away for a while and just you know take a walk in the woods without your camera something like that come back to it come back to it later or if you if you really want to keep taking pictures take pictures of something that is of a genre that you have no interest in or no idea about at all because you're not going to be working under preconceptions you're not going to be forcing yourself to do something you can just take any you know it's just just go out and take pictures of whatever it is that you want and don't worry about whether or not they're good or bad they're just they they just are they're refilling your tank of of of happiness in your in your photographs so this is kind of like the third time I've recorded this video and and the reason I've done it three times is because each time I went well that's not right doesn't follow a structure and doesn't do this and might not hold attention and all these things that have gotten in the way of me kind of again drifting away from the enjoyment of of sharing this content with you sharing my love of photography with you and this is a big step for me is to take this leap and say well do you like the conversational aspect of these things you know what do you think because this is a two-way chat you know I I can sit here and talk all day to my lampshade which is behind the camera but ultimately I want to talk to you I wanted I want to have this as a conversation with you I don't want this channel to to drift once more into talking at you about things let's make this a back and forth so I'd love to hear your thoughts in the comments it'd be fantastic really just to to get a feel for you know how you like well how you connect with the channel how do you see it is it is it a learning resource or is it more that you enjoy you know possibly the the thoughts that pop into your head when you watch it like oh my god that guy is always wearing the same waistcoat it's just like what's going on right or or would you you know what is it you would like to see I'm happy to talk about photography obviously the core of the the channel has always been talking about photography about photographers and I'll be I'm trying to find a balance between introducing as many of the great photographers who I enjoy who I love looking at to as many people as possible but also in a way that isn't just like oh I look at look at this photograph I like it so it's kind of cool so we'll look at the next picture and oh I like it so it's trying to find the balance between sort of you know academic-y kind of stuff but also you know the enjoyment the the the excitement about photography how it moves us in many different ways so please let me know in the comments below that would be fantastic anyway earlier I did mention about my very first video if you haven't ever seen it you are in for a rare treat so here it is it's rigid avidon and his book autobiography thank you ever so much for being here and I'll see you again soon


Hi Psych2goers, do you have times where you just feel out of touch with yourself, your friends, or your passions, or all of the above? Everybody has off days. But do you get the sense that these events are happening a little more than you'd like? If so, you may be experiencing burnout. Burnouts are your body's way of telling you that you're getting exhausted emotionally, physically, and mentally. It's usually caused by extreme and prolonged stress. If you go a long time without addressing these issues, you may spiral and worsen, and it can cause lowered self-esteem and even depression. So to help you be more aware of your mental and emotional well-being, here are seven signs that you're burnt out. Number one, you're procrastinating a lot. Are you constantly putting off things that need to get done? One behavioral symptom of burnout is withdrawal from responsibilities. The laziness you're currently experiencing may actually be a cry for help. This continuous act of task aversion may also be because you're afraid of failing tasks you're supposed to complete. It may help to talk to someone about the current pressure and stress you're feeling, and to take some time off until you're feeling better. Number two, you're isolating yourself from others. Are you tired of socializing? Do you frequently want time only for yourself? Because of exhaustion, the act of seeing and talking to people may feel too tiring to think about. You may feel that you only talk about work, life responsibilities, which may add to the stress you're trying to avoid. Remember that time alone is important, but emotional isolation is dangerous. This disengagement might be a symptom of depression. Talking to a therapist may prove to be a great help to your mental state. Help is always available. According to statistics, only a small percentage of you who watch our videos are actually subscribed. So if you haven't, and at the end of the video you enjoy what you see, do consider subscribing. It would help a lot with YouTube's algorithm in promoting more of our mental health content. Thanks for being here. Number three, you're becoming very impatient. Is everyone getting on your nerves? Does every little thing, no matter how trivial, make you irritated? This may be a sign of underlying stress and anxiety. A lifestyle cause of burnout is working too much, without enough time for socializing or relaxing. This onslaught of negative emotions may be a result of not having enough support from friends and loved ones. So having a healthy social life outside of your work or school life is beneficial to your mental health and may reduce the chances of burning out. Number four, you can't sleep. No matter how tired you are during the day, it's going to sleep at night a struggle. There was a study that observed the association between insomnia and job strain. They discovered that insomnia is strongly linked with burnout. Lack of sleep may also bring about higher chances of high blood pressure, heart disease, diabetes, and more. The bottom line is that you need sleep. Some home remedies for insomnia are to stick to a sleeping schedule, stay active, and to limit caffeine and alcohol from your diet. Although insomnia is a common sleep disorder, it can really bring severe issues to your health. A physical exam performed by a medical expert might also help you get a diagnosis and treatment for your lack of sleep. Number five, your previous hobbies no longer excite you. Do you still find joy in the activities you used to love? If the answer is no, then this disinterest may stem from being emotionally drained. This disinterest and lack of willingness to do anything is also another symptom of depression. It may help to reach out to those who are close to you and tell them about your troubles, and to spend time doing new things. Try to limit talking to people who make you feel bad about yourself, since they can only worsen the situation, and instead you can find new friends and enjoy their eccentricities. Keep in mind that you're not alone in feeling burned out.  Number six, your work or school performance is deteriorating. Are you frequently coming in late? Are your numbers of absences starting to tally up? Burnouts can be overwhelming, so you might find yourself doing almost anything to avoid your responsibilities. At times like these, it may help to think back on why you're doing what you're doing. Why did you choose this field in the first place? When was the last time you genuinely smiled? Go back to your positive days and surround yourself with the thoughts, people, and acts that make you happy. And number seven, you turn to addictive habits for comfort, like smoking, drinking, or eating, etc. When hopelessness, fear, and many other negative emotions drown you, self-medication may seem like a helpful way out. Self-medication is the use of alcohol, drugs, and other methods to manage a mental health issue. What is often overlooked is the fact that this is only a temporary solution to a permanent problem. It may lead to addiction and increased health problems. And yes, even food is a form of self-medication. If you recognize this symptom in yourself, it may help to recognize your triggers and to slowly change your harmful habits to healthier ones to help you cope. There are numerous ways to adopt better, sustainable habits, like exercise for one. It's proven to boost your mood and promote calm feelings. And of course, a visit to a therapist or a licensed medical professional can help in further treatment. Do you think you're burned out? Let us know in the comments below. If you found this video helpful, be sure to like, subscribe, and share this video with those who might benefit from it. And don't forget to hit the notification bell icon to get notified whenever Psych2Go posts a new video. The references and studies used in this video are added in the description below. Thanks for watching, and we'll see you in the next one.