 Different color scheme, different talk. I want to show you how I moved my C-Pen development work to GitHub. Anyone of you with your modules on C-Pen? 1, 2, 3, 4, 5, 6, 7, 8. Wow, OK. Well, I have quite a number of modules on C-Pen. Somewhere in 2001, I was a professional trainer, mainly UNIX, and then I had to learn Pearl to teach people to program in Pearl. And then I got really addicted to Pearl. And since then, I published all my projects, and some got really large. So since 2001, I published about, say, 70 modules on C-Pen. And for instance, my email work is in total about 245 PM files. So that's quite large. And I made over 1,000 releases. But I used a very simple model. My model was released often. I just fixed some things. I'm making some additions, some regression tests, publish it. If people complain, just fix it, publish it. So every month, I saw you get a new release for dynamic modules. And some modules, they don't need much maintenance. Sometimes you see modules which are 10 years old on C-Pen and you install them and they still work. And some modules, they need more maintenance. And so it's quite a mess. And my directory, my working directory, was also quite a mess. Well, let's first see on C-Pen. This is my mess. It's about two or three pages more. And this was how we did it 10 years ago, at least. But more and more people have moved to Duke It. And I have to use it for all the projects, professional products as well. So I thought, well, should I use it? And I hesitated for a very long time. Oh, by the way, are you using a search C-Pen or are you using meta C-Pen? Meta C-Pen. Meta C-Pen. So this is meta C-Pen. It looks more modern. And this is a search C-Pen. So I thought I had no need for version control. And yeah, it's nearly true. I release often, as I told you. I'm the only developer. So Git is very useful if you have more than one developer. I had quite a good memory. So I could remember all my codes. I have a route and exactly which module and where I had to be when something went wrong. And my main complaint about contributions is that 50% of the contributions you get break the code for other people. And 90% of the contributions lack regression tests, documentation, and so on. So actually, contribution to other people, I really welcome them. And I really like people complaining, finding bugs. But the usefulness of contributions is not really high. They're code contributions. So I have to rewrite it anyway, usually. So what's the advantage in publishing everything via Git and people forking it? So that's a bit of a problem. The other thing, I have a difficult release process. I will show you a bit about my release process. I have my own documentation system. And I have, well, OK. So this is about my documentation system. If you have very large modules, and certainly when you have object-oriented modules, you will find out that POT is quite limited. The plain old document system can be used to document one single PM file. But if you're writing object orientation, then certainly if you have three or four levels of inheritance, then you have to copy parts of the documentation from lower levels to higher levels and maintain that. If you have a lower level in the hierarchy, you find a function, and you document it there, then it will not automatically appear another levels of your documentation. And well, that's really a hassle. So I extended POT with some features like methods. You can define a method instead of add to or item. You can say, OK, now I define a method. And the format I will decide how it looks like in your manual page, examples, and so on. This is a class method. With methods, you can define options and defaults. And on different levels of hierarchy, you can change the default because that happens. So I have my own text. And this saved me a lot. It saved me for my mailbox modules about 70,000 lines of code in the manual page, which is produced. So this is the output. It automatically shows you the inheritance relations with other modules and so on. There's some formatting, it shows you the options, and where the options with level of hierarchy in the object oriented tree, it gets these from, and so on. It also produces real HTML, not what Meta-C-Pen is producing, or because my POT is smarter, and it knows it is a method. So it can produce all kinds of extra links to collect manuals which are closely related, methods, indexes of methods, so you can find it back in the class hierarchy, and so on. Diagnostics, error messages, explanations, and so on. So this is what OODoc does with only a few lines of extra configuration. The name of the module is wrong. I called it OODoc, but after that someone created OpenOffice, and then I got stuck. It should have been called OOPOT, maybe. That will be a more useful name. OK, so anyway, this is my system, and I have to integrate it somewhere in my Git and in my GitHub. So I doubted for many, many years, but at the moment, I'm more in favor of going to Git GitHub. Release often. Well, in the beginning, the first 10 years, I remembered all my code, but now I have some code in maintenance, which means that I didn't look at it for 10 years. And then when I release it, I forgot that some of the developments were halfway, and so on. So I hope it helps me a little bit in stabilizing this code. I would like people to feed me patches, and it happened the first week already that I put things on GitHub that people started to give me things. My memory is going down, and the patches are still bad. But a little bit more involvement, or at least people who are tempted to help you, is welcome. OK, so well, let's try it. 17 years of garbage, oh yeah, I really had to clean up license texts everywhere, add metadata on this way, also referring to licenses, referring to GitHub, and so on. To standardize all my modules, my idea about how code should look changed over time a little bit, what order of the use statements, or those things. So I had to clean up this mess. Well, actually, this is already without the 30 modules I already moved to GitHub. So this is my current mess. Still things to be solved. And for instance here, I have four versions of mailbox, zero dot something, two dot something versions, and so on. And then I make a big step, so you change your major number. But you still have to support the older versions. So I create a different directory. And I have to merge them back again into GitHub some way. So this is my old process. Here is the real location of my files in which I develop. It's a nice thing about OODoc, by the way. It's using the syntax of POT. So it just runs with Perl. It doesn't complain about POT statements. It doesn't recognize. So I can just use it for testing. And then when I make a release, or this is part of my framework, then it produces, extracts all the POT from the PM file and create next to that a real POT file. So it translates POT into real POT. And did you know that this is possible to make a POT file next to the PM file, that you don't have to have the documentation in the same file? Well, OK, it is possible. And also the files I work with, I publish them as well. Sometimes people help me, and they work based on their role files instead of the distribution files. And then I upload them to POS for CPAN and to my website for my own generated documentation. In a new situation, I have a new directory where I put all my already translated stuff in. I still have this file, oh, this. So this start of the release process can still be used. Then you add Git control. I will detail this later how it works. And for GitHub, you need to read me. It's very useful to have references to search CPAN and licenses and so on in the read me file. So the publication process is a little bit harder. First I have to call this. I upload this by hand to POS. There's also a script to do it, but I do it by hand. With R-Sync, I publish my produced HTML files. And I have to put it into Git there with POS. This is nice. So I will show you what I did to move all my old releases to GitHub. In GitHub, you know how it all works. You have these tags that stand up Git. You can tag a certain version of your code. But in GitHub, it's releases to tags. Release means it doesn't mean that much. It just says, we call this a release. And you can have release notes. And you can have extra information with this release. But actually, it's just some trick around a tag. Here you can't read it, I think, expect. But this is from my changelog file, automatically extracted from my changelog file in my insert process. Here you see the release as it went to C-Pen. And this is from GitHub itself, and from Git. The first task, if you start, is trying to get some administration how far you are. So I had to redo my overview of all the modules. One of the reasons I need my own overview and not just meta-C-Pen, is that many modules are clustered. They all relate some way or the other. And on C-Pen, I cannot show that to our meta-C-Pen. I cannot show that they are related. So I have my own page with some extra information why they are related and how they are related. So I cleaned up this. And this is an important field. GitHub, whether I already have converted it or not. And here you see, to-do, to-do, to-do, to-do, to-do. Still about 40 to go. This took me already a whole day. Then this is about the process, to move from the old version to the new version. First, I create this mailbox directory where my new work set is. I initialize kits there. And then for each of the distributions, and gladly, I kept them all in the directories. I have all these raw distributions and all the release material to C-Pen. So I have them all. I just collect them. And then I unpack the raw distribution because I put that raw version in GitHub and not the processed version, which is in C-Pen. And then I put the unpack, the raw distribution, then commit that. And then put an asset, as they call it. So you have this release, GitHub release, and the GitHub release has assets. And one of the assets is the distributed version. And then I clean up. And at the end, I have my whole working environment, which is many more files than they are released. And I copy that onto the same spot. And then I get at all the files which are in the manifest, automatically. And then I add by hand, the read me. And then I go and clean up my module a little bit. And I get pushed. So this is the general form, a little bit more detail. And the nice thing is, I hope you can read it, but the nice thing is that it's very simple. We have really great, two really great modules, the GitHub module and the Git module, Git repository module. And they make your life very easy. I will show you about five slides with code. But that's nearly all the codes. That's mainly, it's 80% of all the code. What you really need to get is to work. So in this case, GitHub has two versions. It supports version three, which is a REST interface. And version four is a Graph ML. And Graph ML works very differently. I won't explain that one, but I like the version three version better, the REST interface much better, how it works, it's clearer how it works. Well, I try to, you have to set some defaults. You use a name and the Git module you're working on. Then you try to get the repository, so my mailbox repository. And if it isn't there, I get an error message back in text and I create it. This is all everything you need to create this GitHub repository. That's not much, is it? Well, here is, you get back the URI, where you can upload the newer files to. It's a huge hash, what you get back from creating or from the getting, with all kinds of information how to use GitHub. Then start Git. Well, first, let's see whether I crashed in the last one. So I only created in its slides, when it didn't work last, didn't work last time, when I was never run. And it's as simple as this, a Git repository, and this is directory where my Git stuff is in. That's all. Then with archive.tar, I unpack one of my raw releases in a directory. I run at all. This is Git run at all. And then I collect some information for the release for instance, I can see on the check before you do is, if you unpack an archive, whether your timestamps are preserved. On my system, unique system gladly by default, but that's not always the case. So my 2004 release will have a 2004 timestamp in GitHub. Okay, then commit all. So now it's in Git. And then I add a tag because the releases on GitHub are based on tags. So I tag it, my release, and then I push it. This is a weird thing. You can only make a connection to the origin once you have made a commit. If you have never made a commit, you cannot do it. So yeah, that's a bit weird. But okay, work around. And I push my release to the currently unpacked release. And then I clean up the directory again, the whole directory, unpack the next star, the next raw version, and do this process over again. Then I change, I take the changelog file, gladly I'm quite nicely maintaining my changelogs. So it was quite, not so many failures on grabbing the changelog component. And I create a release again, default provided by the GitHub module. How to produce a release. Add, now set, that's what I uploaded. To see pan before. That's a bit of pity that GitHub doesn't support compressed star as meta data type, only zips. But maybe in the future they will understand this. And then, oh, I add a readme. I add this above each of the files. That's one of the hurdles. My release process, my Odoq adds the copyright text in all the files. And then I release it. But now I published my raw file, so I had to add something like reference to the module. And top of each of my files. And it works, that's all. So 80% of the code you saw, the rest is just a bit of configuration, command line options and so on. And here, this is 2008, you see all my releases for the 30 out of 70 modules, which are already converted. So if you are planning to do it yourself, you can get my scripts, they are not generic enough that you can use them out of the box, but you can move to GitHub as well. That's it. Questions? No time for questions I think, but. One minute. One minute, ha. Any question? Now come and talk to me out tours. Thank you ma'am, available. Bye.