 Okay. Well, this was more of a teaser title than anything else. No, my intention is very straightforward. You guys have had a very, you know, sequence of technical talks. So what I wanted to do was to have something completely different. So essentially the question I wanted to ask is, and that's why I thought, you know, I'll go be the last one, is to have a kind of a panel or a forum or whatever to see, ask, to answer a few questions. So the first question I have is, and I don't have it up on the thing, I should have put it there, is why do you use Git? What has been your motivation so far? It's for you to answer. Why do you use it? Or... Yeah, you said you tried, what else? In other words, CJ, you have a lot of stuff that you use Git for. So if I put you as 100%, where do the rest of you fit in that scale? Where do you think you fit? How many would say 50% of the things you do, not programming alone, is using Git? So programming in documents. Documents. Okay, what else? Anything else you think you would have loved to use but you cannot use it? Images? Give and save files. Yeah, config files. Config files? So do you think that's one of the things, I've spoken to a lot of people and config file seems to be one of those things that will be very, very useful to keep track of. I mean, we all try to do it. Or your .files and all that. Is there something that you think... Dropbox. Did you just drop? Your files into a Git directory. There's two. Oh, is that right? SparkleShare. SparkleShare. It behaves like a Google Drive, one drive, dropbox. You drop your files in. Into a .git directory. So it goes out too? It depends on where you set your remote as. Oh, okay. For example, you can have as many as you want provided that they all have individual remotes and your remotes. Whichever hosting a service you're using allows you to share that size of data. So if you have a habit of dropping images, large AI file files, it will not make very much sense because you run out of space very quickly. It doesn't change and because Git doesn't forget, in that sense it doesn't behave the same way as a dropbox. It does keep track of everything which it does. So, you know, one of the things I've loved to see is Git being a standard way into tools like, you know, office tools. Like LibreOffice or something like that. Because I think that's where there's a lot more value that we can get out of Git. So, what do you think we can do with that? That's one area because the reason I put for Git for my mom is for those of them who are not doing any of these things. They are using their spreadsheets. They are using their word processors. How do we get them to be able to do version control? Because I see them sending emails with attachments and this version to the name of the file, dash, mine, or dash, you know, my boss. We know there's a better way to do it. So, what can we do to put that in there? So, I like the idea of the .Git directory. I mean, maybe that's something which I don't know whether that's a good one. What else do you think we can do? Do you think this could be a project that we collectively... Sorry to think of. Instead of sending around a zip file, you could send a packaged archive, which is a git. But the tooling you'd need around it so that people could extract it and use it. It's all there, but it just needs to be... Yeah, it has to be put together. Yeah, so that's my question. That's one of the things I would love to see happen. Because then we have a whole new group of people coming on board and actually using it, not knowing that they're using it. I mean, that's really... it has to be very transparent. But all the benefits they get, but not necessarily the confusion or the pain as it were. So, I'd say one of the barriers to this is the fact that even mainstream Git users, or advanced Git users are mostly using a centralized store. They're not really distributed. It's where you'd share a document, where the boss needs to see it, where you see everyone's editing it. It's possible to merge all those changes. But I think the orchestration is still kind of tricky. So do you think that's something that we can try and build? It's a suggestion. It's what I'm putting out there. I think if you have a repo that's a SQL document, it's totally doable, yeah. But it's a SQL document. But there's a real difficulty in trying to make sure that that would happen. But if you combined kind of DHT kind of distributed hash tables and blockchain kind of idea, plus... I don't think it's interesting. Directly graph storage like Git, you can have these kind of things, but ultimately you end up with a... I think like a magnet leak, basically, but it's... It's like a torrent. It's also... yeah, it's basically... It's like a torrent. It's a torrent, but it's a changing torrent, right? So a torrent is a static resource. We're talking about a dynamic resource that you have... Basically, you need a front-end header key plus the change key. And it could work. But do you think... I mean... You've got to socialise it. Yeah, you have to socialise it. So if we as this meetup group starts experimenting and trying something like this, simple enough, easily packaged up, delivered via plugins or whatever, as the equivalent may be, into any of those tools. It starts with a simple set of tools. I think an office product is probably the best way to start. So just to get them socialised, get them to start using it and see how it goes. Because then I think the value of Git itself, it becomes so much more useful and a lot more people begin to... But they may not fully understand it. But that's okay. But they benefit from it. The understanding may not be there. So that's my first question. So what are the kind of things that you could possibly be doing? The second question I had was... You guys... I'm making assumptions here. You're all upstream contributors in whatever you're doing. Am I correct to assume that? Okay, so upstream. In other words, your organisation has got no issues in making that happen. So do you have projects that you work on, internal to your organisation, that are not upstream at all? Or is everything that you do all upstream? That's my question. That was my second question. Can you elaborate a little bit? Yeah, so the reason I'm asking that is I'm trying to find what kind of mental conflicts do you have when you have to split your mind between what is really upstream and what is sort of internal, even though you may be using the same tools. Because I find that that's like having to keep track of different things in different places, mentally not... Because in an open public environment, if you make stuff, you make a mistake, that's okay. I mean, you can always fix it. But what if you took what is meant to be internal and you put outside accidentally? So you have to have a firewall in your mind to keep track. Is it upstream you mean user facing? Well, it doesn't matter. I mean, any upstream project. Like public? Yeah, public. Yeah, when I say upstream, I mean public. Yeah, not internal. You want to pre-push hook for that? No, it could be something that you may already do automatically for yourself. I find it very difficult to keep track of that. So, I mean, the classic case is credentials. Not pushing credentials to a reproduction. Also private branches. So, did you have any horror stories about that kind of stuff? I'm sure. Yeah, yeah, sure. I'm sure. 20. So, in the company I work for, we have GitHub Enterprise. Okay. So, it's internal and no one can access it from outside. There has been cases where I developed accidentally purchased a public GitHub. It's still very random. And there is an activity that actively scans public GitHub, big bucket, and GitLab. Oh, seriously? All these repos of this. Wow. So, it's a gigantic project involving thousands of servers, but there's just one thing that they do. Oh, that's a lot of... I don't know what the name of the software is. It starts with black and something else. I think it has something. Black, black. Sounds familiar. Anyway, what it does is it doesn't just find Git hashes. It also finds snippets of code. So, sometimes people do take an entire fresh repo and make a brand new commit output. And that gets black as well. So, even if you put it on Bitpocket, including a private repo? Well, obviously, if it's a private repo... So, it's only in that industry that I have it. Yeah. I guess this is one of those horror stories that I've not really mentioned or talked much about. I mean, how real is it? And how prevalent is it as a problem? Because it's actually, to me, it's keeping your presence of mind to exactly what you're doing at the point in time. Unless you say, okay, I only do public upstream projects in the morning. And so, you have some kind of temporal, you know, segregation of stuff that you do. Oh, anything in the afternoon is always internal or something like that. If you're going to mix and match, then... Generally, if I have a situation where it's a very project that I push both to internal as well as external GitHub, I would usually prefer to put them as separate records, as in separate working directories. Or your own system, that's essentially... Yeah. I mean, that would be like the best practice, right? Yeah, that's the best practice. So, when you do a git push, it's only pushed to wherever. Yeah. So, do you use pre-push hooks? Sorry? Pre-push hooks. For... Even for LinkedIn and... Well, for LinkedIn, but I mean, you use a pre-commit hook for LinkedIn. But pre-push would be... You want to protect certain branches. So, okay, some people, no master pushes. You've got to push to an absolute... Yeah, right. So, if you have that, it's fine if you're the only one using it, but usually you have to manage a team of people. If you usually have a privacy hook on the server side... Yeah, if you've got server control... So, if you're on GitHub, you don't have that. Yeah, they control. But yeah, I mean, you could do all kinds of scanning on a pre-push, depending on... But to... Well, you either trade off diligence every second of the day, or you have a team of people working on making sure that certain patterns are never pushed, certain branches are never pushed, and certain practices are always adhered to. Correct. But there's an overhead no matter how you slice it. Except after probably years, right? Don't have been. Generally. That's a big picture. The other thing is, if you don't think about it, how do you even know you can do it or not? So, the largest problem is just people who are not aware that they could be doing this. It's kind of like people tweeting really stupid things to the best of the world and losing their job on Monday, you know. The biggest problems online always happen because people are just unaware of the dangers. So, it's... So do you think there is an opportunity to educate and teach or... You know, that kind of... I wouldn't call it best practice, but behaviour considerations to make sure that you don't do that. This is your therapy session, right? So, this is... Get up anonymous, right? That's good. So, we do have a couple of options here for me. I mean, the question of... Temporal separation is probably one way to do it. I think that does make sense, right? Pair programming. Pair programming? Yeah. Pair programming, I think it's probably... The challenge with the bank is that... I would like to... Generally, the projects that are meant to be public, they are... They are usually... Usually, most people only have one remote, which is whatever origin they are, and they usually tend to be public or internal. And these days, in terms of package management, we depend a lot on package management to help us with pretty much everything. So, that is one of the common practice. So, for... No... No, especially, it's most relevant for it. You deploy everything through no packages. And there's a public registry you depend on to download. Unless you guys remove somebody upstream. Unless... They are pissed off on a private matter. Like the last pet incident. The point is that... Don't depend on Git for deploying software. You depend on... Which have dedicated package managers to handle it for you. Ubuntu, you have... Debian packaging, and with Red Hat, you have YAM. DNF, right? DNF. DNF. Whatever that stands for. So, what about the other... That's the other thing, right? I mean, with all these ideas of containers and stuff like that. So, where do you think that would be? How do you think that would be? Because the idea behind containers and the layers that you put inside is, you know, it's like having... Git-like feature set or features, but it behaves like you add your different layers on top of it. So, do you think that's something that could help in... You switch to a different container for that purpose and it's probably just, you know, locked down to only to go to a particular place and nothing else. So, you don't make a mistake. Letting the system anticipate that issue rather than best practices. I mean, if it's the same command line, you just... Well, container is just another... I think it's more complicated for developers. You think so? Right. It solves that problem, but it also introduces a whole stack of different features. Yeah, sure. I think all of it ends up indirecting education. So, you either jab it or you shouldn't be allowed on that system. It goes back to the same question where should you rebase or should you merge? Yeah. We're not starting there yet. We're not starting that discussion, but at the end of the day... We're just referring to just one point or two points. At the end of the day, whether you are going to encourage your team to perform rebase or merge, nothing beats actually educating them what the tool action actually do and how they're different and give them the option to choose when they want to do a rebase and when they want to merge. Yeah. I mean, you can ask other lines, but you should allow certain levels of freedom for people to do things. Yeah. But also have very hard rules about certain other things. So, you know, please don't push all of our private keys into your gist. Yeah. But it's a secret gist. No, it's not. Okay. Out of curiosity, how many of you work on open source projects exclusively? Really, as an exclusive? In other words, there's nothing that you create even in your organization that is private repose. Everything is public. Don't think many companies can have that privilege? Well, some can. We have. We have that privilege. Everything's in public. So, I'm just wondering, in this audience here, how many of you? I assume no. None. We encourage open source contribution. If you... How is that encouraged? How is it encouraged? What is the... What is said to make it encouraged? Perks, fame, some publicity. You get a free t-shirt. Well, you can print t-shirts and distribute them for your open source project. It's covered by the company. That's better than we want. So, no, which is quite common. So, my question here is... And this is where... You know what I should do? Do I have it in here? Let me just quickly check. It's actually a slide that I want to show. I forgot to put that in this deck. Hang on. Let me just get that. Okay. It's the wrong one. Come on, come on. Okay. Let me show you what we have. Oops, the wrong one. Okay. This is something that we have within Red Hat. And this is a... It's a document about code of business conducts and ethics. And in this document, it's about three or four-page document. It's available online. You can have a look at it if you are interested in reading it. We have to sign off on this every year as an employee. And when you join us for the first time, I put this paragraph out here because this is the basis for everything that we do. So, it's essentially a participation and open source project, whether maintained by the company or another commercial or non-commercial entity or organization does not constitute a conflict of interest even when such participant makes a determination in the interest of the project that is adverse to the company's interest. So, in English... That's awesome. Yeah. No, absolutely no issue. Essentially, in English, that's a project. You are at a decision tree at some point to go via A or B. A is the right thing for the project. B is social for the project and you are a member of the project team. You happen to be a Red Hat as well. And it turns out that A is actually negative impact on Red Hat. But B is kind of neutral to Red Hat. So, what should you vote for? This says vote for A. Make the project succeed. Let Red Hat figure out what to do. Not against you, but let's figure out what to do to manage this because the argument and the understanding is we want the project to succeed because the project is a weaker thing than a company. Technically, a company is a little bit stronger than a project because projects come and go. Projects can die. Projects can have issues. I really don't interpret it that way. That's what it is. That's the reason I'm still here. Otherwise, I won't be here. But surely legal conducts this any way they want? No. If that is the case, there will be a lot of people who will say, Sayonara, you're not interested in this. This is fundamental to what we do because this gives me the freedom to do what I need to do upstream. And this is something, and every year, by the end of the calendar year, we have to online click, click, click ESDS that you've read this document. So, the only thing I read in this document is whether the paragraph is still there. In the last 14 years I've been here, it has always been there. It's been clarified and made shorter, but the idea is still the same. So, to me, this is a very fundamental, so this is the question. In your employment contract or your code of ethics or whatever that you may have signed up to, assuming you read them, what's a clause like that in it? Because this determines how you can contribute upstream. Because you don't have to look back on your shoulder and say, can I do this? Can I do this? Just do it first. Make it happen. And let the business figure out what to do. Not because you did it, but because that's what the business has to figure out. Okay? So, this is something which I would like you to think about. So, let me go back to what I wanted to show in the first one. Oops, sorry. So, the only pitch I have is for Red Hat, like my colleague came here earlier. So, jobs.redhat.com is where you are. If you're interested in anything at all, please look at that. I'll send an email to jobs at redhat.com. The challenge we have, and I can tell you this here, we don't have 100% type of engineering type of jobs in the Singapore office. But that does not mean there aren't any available. Where they are, if you are in Singapore, it will be remote. So, you will be a remoteee to a project team or engineering team or quality assurance or whatever the team that you think you want to be part of. So, I think that's great. In other words, you don't have to be in your office to do get anything done. You come to the office when work stops, right? It's wherever you are, do whatever you need to do. So, think about it if you're interested in it. And I guess the last one is just this. I'm sure you've seen this. Quick question. Singapore is the only office in the region? No. Red Hat is organized in this part of the world. We have six regions. Singapore happens to be the Asia-Pacific headquarters. Also, ASEAN headquarters and the Singapore office. Plus, all the overheads, HR, legal, blah, blah, blah in the Singapore office. In ASEAN, we have it in Malaysia, in Thailand and Indonesia. Actual offices. That's within the last two years. We never had them for all this while. So, it's always there. And engineering happens out of Pune, Bangalore, Beijing. Beijing, we have two offices for engineering and Brisbane in Asia-Pacific. So, there's always opportunities. You name it. So, I would encourage if you're keen on looking at anything, like exploring, please have a look at jelps.redhat.com. If you find something, if you think that's interesting, there's a code for it, whatever the job ID is, send me the link, because then I can make a referral for you if you're interested. So, with that, this is the last slide I have. So, I kind of like this one, because I've seen it in many offices on a front door. So, not the back door, but the front door. If that's a case of fire, get commit, get push, and leave building. Do not go on social media. That was supposed to be in there somewhere, but... So, with that, thank you very much. If you have any questions, comments, or anything that you want to discuss. I like the first part. To see what we can create, I would love to see something like that happen. For mom. Whatever your mom is referring to, you make out to be. The get commit and the get push need to have dash dash, no verification. So, file up here, file up here, and yeah, that's a good point. But that would be too long for the guy to put, and by the time he goes to the back of the door. So, I think it would be good if we can create some kind of a tool to get one project. So, I don't know what it is that we can do. I don't know how you want to drive this. I think it would be interesting to experiment and try build something, because otherwise moms won't get into the picture. And it would be kind of nice to have them in the picture as well, so that we talk the same language more or less. Well, within inverted commas, right? All right, thank you very much, guys. And thank you for coming to Rehab. Thank you.