of the Turbulent Mixing and Beyond Conference in 2017. And in this section, we will have talks which are discussed in the Turbulent processes using experimental data and analysis, as well as the mathematical works. And it would be, maybe, I will see, like, you know, if I will be given my own presentation. And then after this, we will make the program closure. And then the members of the organizing and evaluation committees will be staying for evaluate to compare the results for the best, post of the world and the unsidest of the world. However, we are still in a good shape, I think. We should proceed now with the work of Professor Redonda. Professor Redonda and his collaborators on admire mezcal mixing and fractal analysis. OK, thank you. I think that you can hear me. Well, I will come in on several aspects. And first of all, I would try to convince you that there is more to see in the complex interfaces, and not only in admire mezcal. For example, this is, let me see how. OK, this is, I have to go forward like this. Well, some of the motivation spans to astrophysical and environmental flows. But this is one of the important examples of a enormous galaxy, sort of Rayleigh Taylor, or rich by a mezcal, like a super galactic structure. And at the same time, you have very small scale processes in shops. And we want to understand from the large scale to the small scale. And I will be concentrating on scaling, basically. This is an old story, because you know Takanawa's wave. OK, and you notice that this sort of observed filamentary structure is probably more revealing to what it seems. Because not always we see all that is there, not even in the experiment. So you sometimes have to go to higher order processes or to non-linear processes to detect really what is there. Because in simulations, David Young compared different types of simulations. And of course, you see that the topology is totally different from simulation to simulation. And you don't have to perform a multi-fractal analysis to see by eye that, well, the resolution really is very different. The same type of simulations from above. And this is well-known. It was published by Shershanna. And you see that, well, they have some sort of structure. But when you zoom in the interface, and I would say a bit further, when you zoom at either side of the interface, you find a different story. This is still to be examined. OK, well, this is something which I will leave you to read. While I comment a little bit on the two basic aspects of when do you decide it's Rayleigh Taylor, when do you decide it's Rick Meyer-Meshkov, well, if you have the acceleration, and you have it in time, and it is smooth, and it increases that Rayleigh Taylor, in a limiting case, like in the shock experiments, we did that, and this was Paul Lindens' experiment and many other setups paid by the atomic weapons establishment in Cambridge. And eventually, we would get these growing fronts. What happens if you just give it a shock? And our interesting idea that Jacobs has exploded in the Lawrence Livermore lab is to do like the typical, and I want you to try it with a tequila glass. This is what Mexicans were doing for many, many years. You just bang it into the table, and you shoot up the, OK, you can do a more or less sophisticated Rayleigh analysis. But if the density with height in the basic Rayleigh Taylor analysis, it began being heavier on top and lighter, stored DL, and I would not feel at all between 1998 to 2018. Has tried, you know very well, the different configurations. You can have something like this. And with this configuration, it's possible to measure something which is very difficult. It's a mixing efficiency. But you do it per unit area, and there's different combinations between how the potential energy goes to kinetic energy and again to potential energy. And this is a complex process. But I will concentrate on what happens, for example, when this hits the floor. Then you shoot and have a different type of flow because the main difference is that here the acceleration is just a heavy side function. And there's no or you can have something like this.  This was one of the problems in the initial test because everything that goes up, it must come down. But I will continue with some more detailed visual analysis. And I will set up for the second fractal. It's important to notice that there can be different fractal dimensions for everything. Even in the same experiment, you'll see that the fractal dimension of the vorticity is not the same as that for the helicity or the hyperviscosity and so on. But going to the real detail and reach my front, OK, the velocity jump, like in a shock. And I will not go over the experiment, but layers, theses and what Lazarou has and all the group have been doing with a plane and modified interfacial waves is really very important. The interesting thing is, and this is all history, but the interesting thing is, well, what do we learn extra from things like that? And you've already seen this very, very often. The type of all experiments were like this. This was the first configuration, but now it's improved a lot. But I must tell that many of Jacob's experiments, they include, well, even if there's mixing some di-frontal number or either there is artificial smoothing, not only because of the surface tension. In cases, there are clearly different fluids, but also because the other processes are taking place. Many of the experiments initially were done on heli-show cells, and then you could have a, I could call it a tertiary Kelvin-Hellholz instability coming from the shear from the two sides. And these were some of the interesting new experiments in which you say, well, where the hell is a secondary line coming from, and Andrews showed that for very large-scale shear Rayleigh Taylor. But again, as Shersana said last in her talk, it's not the same to investigate the structure of a Rayleigh Taylor or a Kelvin-Hellholz instability than an accelerated or a non-uniform. And non-uniform can be in time or in space. So this comparison of different interfaces is what I would like to point out a little bit in a parameter space. And when you have differences between the number of boxes on the sides of the box, you're really looking at some of the isolines you were seeing before. But if there is mixing, if there is not just scalar detection, but velocity detection, the problem is that now you can get three-dimensional velocity profiles with resolution. And it's very difficult to do that in the experiments. But what is true is that an infinitely sharp interface is impossible. And within the range of intensities, each of the fractal dimensions of the different intensities, here you just count the number of boxes which is covered by the complex interface. And it has to be between if you have a long, long plot. This is the scale of the box. Well, it would be the inverse. So this is the scale, the higher the numbers. If the slope is 2, then the whole surface is covered. But again, this can be a 3D or a N or a multidimensional space. And the experimental information. But notice this is for one value. You can have, even in the same process, you have different processes that modify the topology of your flow. And if here you have a dominant voltage or a secondary or tertiary instability. And for example, this is what you normally see very clearly. But you don't just see this. You really have secondary and three dimensional complex instabilities as soon as you increase the rate of number. Of course. This type of parametrization sometimes it doesn't show in the first order statistics. And notice if N is 1, again, it's the mean. If N is 2, the second order, it's the diffusion. If N is 3, it's the skewness. If N is 4, it's the cool process. And here is where you begin to look at intermittency. And from structure functions, you know that a PDF does not tell you much. And you can say the mean, the variance, square root of the variance is a standard deviation. The skewness, you're going to have it like this or like this. And all half the same mean, I like. And it was the first time I realized that certification has a huge effect on the kurtosis, which is really talked about like the intermittency. Because if you have something like this, you have a huge intermittency, which it really means the very strange far away from the mean. On the other hand, if you have a flat, kurtosis in Greek means actually flat, then you have something like that. And basically, this leads you to the intermittency. Everybody thinks there's only one type of intermittency. It doesn't matter if it's in time or in space. And of course, Taylor's hypothesis should not be valid. But the important thing is that, well, we just compare this distance. So what you actually measure as the six order structure function, so the relationship between topology and intermittency is very close. And of course, the topology in filling up the space is given by the fractal dimension. So the main point is that I will comment something which is not different at size of, OK, that still has to be proven seriously. But how you define it? Well, as a single intermittency, it's just twice the third order structure function minus the sixth order structure function. But OK, if you really measure that, you get a wide range of intermittenal models, 0.1 and 1. Intermittency is not a unique parameter. So probably, yes, this is, well, the actual intermittency also is related to the Kolmogorov basic hypothesis. But K61, it really eventually says that it's like, eventually, mu prime Q over L, and that leads to the straight line. But because this is related to the correlation, this should be squared. So what is important is all of the type of structures, because in stratified flows, you don't only have the, well, annual number. I prefer to call it the richest number, but some relationship, let's call it density interface, or density difference, or annual, OK, but the average, or it's normally twice. But for example, you can have a rainbow number effect. You can have, I prefer to use a richer zone. It's a number, but it's similar. You have a rosary number effect, rotation, and other type of compressibility and all sorts of body forces. And in principle, I will just show you this complex parameter space, where if you point out different fractal dimensions in different interfaces, you get a chaos. It's not the same at all. And I will show some more, these were basic experiments for a range of annual numbers, which of course, if you use mercury, then it's smooth. Everything is smooth. The density difference is so high. But the density difference really influences more surface tension than other things. This type of complex structures, which you will see, were calculated in Moscow. And you begin to have these secondary and tertiary spikes. But still, the actual inner resolution is much more complex. And for example, if you can detect the basic topology of the growth of these rigmaribusco scales, well, to fit a line, if you would fit a leopold of exponent, which is not a bad idea, is that it goes exponentially. And the exponential has all of the possible power loss. So when you have, and this is a secondary structure, or a large or an initial eddy, that really has a surprising long memory. And it also has a surprising long memory on the structure of the fractal dimension. And how different parts of the interface have different fractal dimensions. And not only that, different qualifiers. Because Fritz wrote his whole book on homogenous flows. So you need another freezer for that. So you need another freezer for the students. It's an interesting reference, but it's not the Bible. So it's not the, and of course, the color effects at both sides of the interface will be different. Not only because the solute or the diffusivity can be different, but because the topology is different. And there's a whole thing, OK, you can compare it with, and remember, Malik's in the presentation. Now we will do a large-scale, intermittent fractal force experiments. But for example, these are some results of what I was telling. The fractal dimensions go all over the place. And they have to be treated, OK, from the simple to the complicated. Here, for example, we compare the multifractal flows of single plumes or multiple plumes. Anya Matulka participated in these experiments. So you know that the work. And even this type of analysis, and now I will generalize, can be applied to helicity in the atmosphere or even have vorticity and helicity cascades. And look at the scaling, like you did for acceleration. For example, this is a vorticity evolution. And here you also have to compare the multifractal self-similarity of velocity, vorticity, higher order intermittency, et cetera. And I will finish more or less showing some more wind information, which is really Yahweh and Edel and some other colleagues. And Claude Cambone is here, every yogurt, like me. But this was in Villanova in La Gelture. You're only invited, eventually, to come before the Marseille conference. We have to arrange who wants to lecture, basically, for the students, Ercov-Tac, Euromake, Simne course. But I think Marseille will be to Jean-François, knows very well Marseille. But perhaps you don't remember Robert Keane from the state. And well, this is just what I wanted to say. And well, I will not extend. Yeah.


I want to talk about recuperating the maintenance in the orphan packages and especially by external contributors. Actually, Rafael had a discussion with an external contributor at the Alasam this year in Dijon and this discussion led to some proposals which were posted on the mailing list and here is a summary of what is intended to be done and it is presented here in order to have some feedbacks from you and advise them and if it's a bad idea, corrections and stuff like that, of course. So basically we are going to present the current life cycle of an orphan package to present what can be done better and then to explain our proposal and to conclude with some interesting side effects and what's done, what remains to be done and we will let you ask your question or end comment on what we said. So what's the life of an orphan package? The maintainer opens the package or some don't know that they love or fund it for him. The QA group maintains it or not and there are contributors that submit patches in the BTS and sometimes those patches stand there for many weeks, months, years without any attention. So the QA group is intended to apply those patches and upload new versions when necessary when we have to fix bugs or things like that until the package gets adopted by another maintainer or when it gets removed from the distribution. So here's a static overview of what I just said and I'm going to explain to you the proposal. So when I drew up the situation which is currently done with orphan packages so we are here drawing and it shows what you all here know. And I will now explain to you what we had in mind after all the discussion for showing you. So first of all what could be better if we look at this situation. First of all there's not always a new maintainer for the team application. Maybe this package could be useful for some users. But if this package doesn't attract interest in the community of data developers it remains alone with no interest at all. So that might be a problem. Second thing external contributors may, the only way they have to contribute to the package is to submit a patch in the BTS. This can lead to a couple of patches sleeping in the BTS for a long time. And the problem is that maybe you can have a user interested in an orphan package. There are patches in the BTS but you just have to pass the patch as a knowledge to apply the patch in the source package, give the package and then we have the package we want with the patches. That's really the hardware for users. And finally there might be volunteers outside of the event wanting to give a hand but who doesn't want to go through the event because it's a really particular trouble to go through the event. Don't be so afraid. I think you will like the global idea. So you see the whole picture of the new maintainer. Here is the global idea in the BTS. First of all we thought that it was a good idea to welcome external contributors. That's why we are talking with you today. So the first idea is suppression in the middle. You will see in detail how we want to use that. Having suppression in the middle means that we have to automatically inject the source packages of orphan in this register. If not, it would be a pain to manually inject a package in suppression and start from there. So we think that we need a trust of the router which could be run by Chrome or something like that. This is the prototype written already. I will explain to you what it can do later in this work. Then we want to allow commit in the suppression for a particular package in the register to external contributors. So instead of submitting a patch and waiting, praying, the external contributor could be employed to submit a patch in the BTS and to commit it in the register. Then enters in the game the QA. It's always to review patches down by external contributors. And if that's okay, it can use a vendor package or something to review the new package. Then we are divided to work. And it's not only to go into the BTS for reviewing patches manually, but to just perform as we have. Can you just say something? What is said here is already true. We can only review patches with BTS and apply them for reviews. We're not doing it, but the whole goal of the project is to provide tools that enables us and the QA members to do this more easily. To have tools ready to check the deeps between the actual version that we did in the last version that we put in the unstable so that we can check the work that we did down. And things like that. That's why we're trying to have something instinctualized as well as coherent. So what's better with this proposal? First of all, we spoke about users who might be interested in contributing to the package, but who really don't have the time or don't want to go through it. With this situation, they might have less access to the package they want to contribute to. And then, we don't have to find someone interesting in the DVM community for enhancing the shape of this package. First of all, that can attract new contributors to our phone package because it may be something which could be a new get to the DVM. That's the idea of Mark, really. It could be the idea of Mark. You want to do task-based things to do maintainer. Do not want to be new maintainer, but maybe they will after some time when they get used to the work that they think is not the deal. We're going to stop that. And then, as Raphael said before, we believe it will enhance and simplify the work of security because there will be a last yes, in fact, in the centre of the work of our phone packages. Just to give an example, if we have this central subversive repository, we can generate our web pages with the list of packages which have changed because someone externally commented something. So we can directly see, oh, here we could review with us, deploy it from them, and it would be easier than having to mail everyone or finding a sponsor or things like that. That's why it could be even broader than the off-hand package. It could be a set of tools that we want to use for off-hand packages, beginning, but maybe people doing team maintenance like a package, they maintain many packages in the same way. They could use that to benefit from the work that they make. One thing that the problem I have with this proposal and we have discussed this also on the main list already, if I do a QA upload, this is mostly, oh, I have here a few hours and let's do some work and I just get the source packages, apply some patches or make some changes and we upload them. And especially I don't care about the history of the package. I don't care about versions and when was this patch applied. I just fetch the source package, we upload it and delete the whole stuff again. So what I would like to see if you make a wrapper, like the source package gets automatically added to the repository, but I would like to see that also if there is a package ready for upload, make automatically a new source package out of it so that I don't have to care about the SVM, I just get the source package and upload that. So that you can add a new depth source line to my app sources and I see there is a package ready, I up get sourced, I make a diff with the old one and I upload it. I don't want to use the whole subversion thing for it because I have to think about how was the URL and... Now I can export it and... That's why I want to write some script, like they have script really with a new tool column name, or I don't know what's a good name, which would basically hide all the URL stuff. But you write that, we have the problem also when you introduce such an infrastructure that you can't make it a habit for everyone in one day. So we will have systems that will fetch new uploads that were done in Einstein without going through the structure, they would reintegrate it. So we could work on something like... You can put in a commit hook that export from SVM and then source the file from the directory. Essentially, my point was to make it as easy and possible for people that just do some QA uploads at one time in a month and don't have to remember anything about it. That's the essential point. That's the idea. I get tons of calls for requests, but I can't afford that. Because if I accept one, I will have to accept the second one and the next one becomes an official sponsor. They do not have time for that. But if I can't effectively be sponsored by someone once a month or several persons once a month, I would do that when they have time. An important point that was raised yesterday is if you do a sponsored upload, you are effectively responsible for every change that was made in that upload. That wasn't the case of non-material uploads. Yeah, but it's exactly the same for all the packages that are included in the non-material. The advantage is you don't have to subscribe to the PTS because all the bugs against all the packages already go to one at a less. So you can only do a sub five to one. There's one other thing I would like to mention. Isn't there a risk that you will blindly approve my QT? Yes, that you will not check as well a patch and what effects it has. And if there are maybe dependency changes that an external guy overlooked. A point to see is, okay, speaking of packages which have very low impact. I mean, we have packages which are broken, but nobody noticed because not many people are using them. So in that case, it's the very few people which are using them and want to contribute a bit. I think we can trust them for this specific package. It doesn't mean we don't have to review it. That's not true. We have to review it. That's why we will provide tools to make it easy. We don't want to introduce... No, definitely not. We don't want to introduce new tools here, but we want to continue to support tools which were already integrated this way. As long as we have a few users for that. Two problems with this proposal. The first one is relatively simple. They go to a website, pick a package that was fixed in the last two weeks, and do a div and then upload. I don't use it. I can't see if there are some broken changes. It's not a new problem. It's not a new problem, but normally sponsors are usually people who are interested in the package. But that's the problem of CIF notes in general and not the proposal at all. It's a JPLOT problem. It makes the problem worse because you're not doing changes yourself. So you have another person doing changes. You have to understand what he wanted to do, what she wanted to do, and you have to check everything and have no idea what you are doing. It's completely... Yeah, but it's not a new problem. There are so many ways... I would say this is a good proposal. If, for example, a patch that is uploaded by the developer and it's signed in the BTS, there would be a way that I could compare if that patch has been applied exactly as it was in the BTS in the package, in the subversion. There wouldn't be a way to reduce the rates because a person with the key in the rate has already applied the patch and probably has tested it and is working for him. So I would just immediately see that this patch with this change set, which was already put in the BTS, it's applied immediately. If the developer would have loved directly. Yeah, maybe not. What's the purpose of the BTS? I'm not submitted by developers. Yeah, but there would be a way that, for example, I go to the BTS and I can review the patches and then I can have the tarbox with an assurance that exactly the same patches were in the BTS are applied to this package. If not, I have to do all the work backwards. So take the package, take the previous one, have a leaf and then review the leaf. But why do you check the patches in the BTS in the first place? You don't have to check them. You only have to check what you upload. You don't have to check the patch. You can't trust the patches in the BTS because mostly they are not provided by... Yeah, but you don't have to ask anyway. But that's why you have to review them. But anyway, you have to check them some time. And it's not different if you do it with BTS or do it with object. So only if there's a patch by a non-developer who's working with the package, you could skip that part. But if you have 10 patches and you have separated in different functionalities, that would be good idea. It's much easier if you go through the BTS, check these patches on this. It's applied exactly in the same way. And you don't have to open the tarbox everywhere. That's the problem with subversion. Yeah, subversion is not the best choice. Because subversion is not a decentralized tool. And in this case we have to come and people who are doing like four people are joining together to maintain one package. It could be a good idea to not use subversion but one of the more modern systems like DAX or DAX or whatever. We're not going to do this comment. I won't even tell you that ATVK exists. ATVK, which is a distributed product. Anyway, Dato is a level concern with it. One of them is that it may lead to people having commit access to this repository to somehow lose responsibility about their changes. I mean, if you just say, I commit and somebody will take and will do love and if it introduces books, well, they will take care of them or something. When a person has a mistress in a package and he intends to adopt it, he prepares the package, builds it, makes sure it works well, he puts his name in the maintenance field, will handle bags and all that stuff. I don't know why I would make an exception for these packages, why they can be prepared without nobody caring for them. That's not a problem. I have no problem to put the name of the external maintenance in the maintenance field so that people can make sure that they are subscribed to the video so that it works. I mean, those external contributions are supposed to interest the package. Is that unnecessary for a person to become a developer just to maintain a package? No. He can't access the service. She pushes it. Yeah. Really? Well, I don't see it. I don't see it. Will this be maintained or not? We may not be perfectly united, but when you see the same people, would you stop where they are afraid to go to the new antenna? No. They are knowledge people. I mean, just a quick example, maybe we can continue. Just we have an example to show you. And then we can discuss. Okay. Okay. Okay. Got it. So, this is a quick show of how we see the SDM repository. Basically, it's divided into three sections. The first one, often, is a section where packages are automatically injected into the repository. And if we have an external contributor who comes and wants to contribute to the package, we will move the package from often to next month. And we add the ID with referral that maybe, if this is an external contributor, after that time it seems to go through a name and look for a sponsor and so on. Well, he can have sponsors without going through a name. It's not needed to become a developer to just upload a package. I mean, it's a completely misunderstanding. You don't need a developer account to maintain packages. It's not needed. Yeah, you know, there are so many developers. There are so many people that are saying... I don't see that as a question. I'll make some developers say I wouldn't sponsor you if you don't plan on becoming a developer. Yeah, but there are so many people who have just become a developer for one package. And it's not needed. It creates security reasons. It adds to the role of a new technology. I'm also an administrator and I create dozens of projects for only a suppression repository. And if we add a suppression repository with many good tools to work with the version, we could at least open the service to usually maintain it as well. That's why there's the dead end part. That's okay. Okay. I think we're talking about two different topics here. One is, what can be used to get more people to work on often packages? And this would most likely be one-time contribution. That's the point Dutton somehow mentioned. If they are going to actually maintain a package, it's no longer often. So it's a different topic. They would put their main in the container field and so on. And they would get a long time and so on. Another topic is how to make sponsoring or maintaining easier. And that's what's up version or any other original and so on. And we should decide now which topic we are talking about. I don't want to discuss as in build package now. I do want to discuss how sponsoring is made easier both for often packages where I just get one-time contribution and general in the general case. Yeah, that's an important part of course. Yeah, but we are talking about technical details which really many know. But before constantly mixing these two topics like organizing sponsoring and organizing QA upload and some people here at least me have very different opinions on this path. I find it a very good idea to offer these tools for sponsoring. But there are some areas where you have to handle the packages in a other way when they are really often and the contributor doesn't want to be listed as a maintainer. These are two cases and they have their differences and you need sometimes to apply different policies for these both cases. I think we should let them this I think the main difference between often packages that don't have a maintainer and packages that don't need a sponsor is that for often packages there is really a minimal maintenance policy. Yeah? Only release-critical bugs are in general fixed. You don't do new upstream releases. You don't do minor bug fixes. If you want that out. If you want to keep the stable as it is. If you say that you can find someone in the world who is not in the development world who knows this software who wants to patch it but he doesn't have the time he doesn't want to become a deviant developer. This proposal is also for providing a way to access that. Yes. But then you know how you can change your state. The package is no longer orphaned. It is being extremely maintained. But that person is the maintainer at that point. Right. But he is not a deviant developer. It's the maintainer. Right. We do agree but we have problems with the world. Yeah. I mean that's really what we told you. The external main part was for packages that are not orphaned anymore because we found people to keep them in a good state. But since they are not deviant developers we have to solve the problem of workloads. And because sponsors are difficult to find we need to have a system which makes it easy for other developers to make the work. I think you should finish presenting your proposal and then maybe you have time for discussion but... Yeah. So we will do quickly. So this is the script that automatically injects packages in the search machine. So it's really simple. It will fetch the source that she said file from the archier and we'll look which package it doesn't already have in the search machine and if it doesn't here it will use SVN inject. It can even directly for you see importing only one package or it can be one micro on the default way. This script is already with all the works. So I think we already say the proposal but this is a quote that doesn't our definition of package. So Gouda contributes to us they are users of our package they know how to patch it they like to contribute to that deep end package but they don't want the program and they don't want the package to be removed. So this is this is what we have in mind in fact so you see SVN in the middle so the experiment was under committee here I'll check to as there were packages from here and then as a query would work is to go there and then we will design was already mentioned here in the in the trouble I think if you want to go on this proposal you should you should replace this QA group thing there with something more broad essentially you should also especially if you want the people to really maintain the packages over time and to care for them you should also include DBM mentors and many lists like that and people that are there it's not only QA group but only the QA group should be involved but it's essentially especially DBM mentors should you should propose there too and ask for people that want to do there too because there are also a lot of people that don't do QA but they do sponsor it very often and also you should move the orphan packages away that's where you get them from but as soon as you take them and they get to be maintained this way they're not really orphaned anymore I see it that's important because you don't want unrestricted changes to orphan packages right I think this has to cost a bit of misunderstanding yeah there's a harmony having orphan packages and you have two three branches and one which is orphan as soon as you're moving between branches so if the external engineer stops working on the package you have to orphan it again yeah and moving out of the repositories the point is that the orphan packages you receive very few coming because as soon as you detect the person you should be correcting that one thing about is that going to be for a package do you have that in mind? no I don't have that technical data yet but my idea was to use IOS project on the old infrastructure we need to go further to protect the comments right so I wanted to write a script and protect this script with so that they can't modify the rules I would talk with you about that later for my way friends we told you we need a package for lint just pay me and I'll read the project and show you so now the proposal is I think so this is just a couple of interesting side effects we saw that's that's that's that's what caused the confusion because we start with the final package in mind and we boarded our view during the discussion but we haven't changed the word in the way how much effort I have from mentors and sponsors once exactly like what they want to do plus the original idea of doing nothing but often packages which I really like and don't really find anymore in you I know what makes us interesting but what you said it's very new I think but they are working together so but some interesting I think yeah came from there and this sounds interesting I don't know how it technically works you get something you might like to sponsor it automatically catches the last version from and so everything you can want to sponsor so as I see you are really ready yeah I'm glad to reuse or work with other people but just a matter to know so send us maybe some pointers we'll check with really okay yeah I I I think I think the same problem I mentioned before but I think it's just not reinventing the wheel but it's also like adding a new step in the middle that won't provide much benefit because when I get a package from here I will have to review everything so I will do the same process downloading the source original package and then I find the patches to see that everything applies perfectly and to see what the guy has done so it's basically like going back in time no because you have to read it for the if you they update and it's final they don't see it would be more difficult if you I would say it's more difficult like something that might not end up helping in any way I think it would for instance it would make it easier to submit a patch because you can just submit a patch against the inventory if you don't do that you have to use the patch or a patching system you have to extract your from from the gift of GZ or the full source sorry but the version repository put the full source to the package yeah it's used as we build packages that's the point so if you do as we did and you've done it so it's it might is the the thing for submit patches you profited the history also doesn't make that I don't see the advantage there because it's simply doing up get source package name copy the package directory do your change incentive it's not no difference to doing as far as and say as far as I mean it's like the same work I would you you can apply patches but on the bts and sort them I would disagree I I maintain all my packages in the version control system I also maintain all packages that I regularly point about this whole thing is that don't every sponsor have to in make their own repositories of this of the packages they sponsor or make their own earlier projects for each package that they sponsor but that you only I have created a project where I want to maintain package and where I want to essentially sponsor someone and it could be another I have one huge repository where you have all the infrastructure only once and all the sponsors can work on it together I don't know if this works out and if the sponsors really will do it but I don't think it's like broken by default so I think it's there could be a lot to gain there but a sign effect of that is allowing external people to do the commits that you will also have to teach them how to do properly with proper commit messages with unified commits for one problem you do a commit then you work on the next problem you do a commit and there should also be a very easy way to say okay this is shit revert all the way back to the current release source that's my good son and ask the person who worked on that to start again so I want to talk about my concern like for 20 minutes now probably with the fixed repository and website which is saying which packages have been updated in the last time need to be uploaded is that you have no personal relationship between the sponsor and the person who's doing the maintains so you can't go simply and say hey guy your package sucks I mean you shouldn't do it anyway but you should say your package sucks because it's ABCD and without this personal relationship you have a really big problem to educate people to do better it's so detached and so complicated to just contact someone you have no experience with and say okay I've looked at your package and I would sponsor it if you do that blah blah blah we have both both problems on the one side we have many people who don't need any help who can't do anything because they don't sponsor and the other one is the problem that you're really telling me yeah I'm seeing a lot of persons who are nearly devil or post and most of them are still I can assure you on this content we could show that maybe as a kind of user rating no not user rating but the problem with the whole proposal is that you detach sponsors from sponsors you have like a group completely in partnership you go to the pool take one package the person you don't know and upload it so you don't have a usual point of contact which you can when you can ask I know to do something that's a problem with the proposal it's not something you can solve but it's one side of the whole proposal we can't try to think about it but as I to the rating it's not done but I mean when you start to upload this way you could have a system where we can't or maybe upload the response so I mean the first time we need to make a solo check and give them more advice but when you need already 10 upload then we could maybe trust even more and so you could have some kind of system this way maybe it would be nice to have one big repository to coordinate sponsorship and do better than now because we have one mailiness Debian Mentors which is flooded by requests most of the packages are simply crap because they are first twice and people who have no experience and sometimes don't even want to maintain Debian packages but say I have this project and I want to see it in the main archive but haven't read any Debian documentation so if we have a repository you can say okay you can upload your packages your package source your package diff there and we provide a form for sponsors to go there and pick a package which they like and then become a sponsor for this package for a longer time we could maybe we have no we have not that at the moment because we have no repository they are not version control systems but simply one web interface to find a sponsor and one very nice tech to put your packages in yep it's more like a dating service than a yeah it would be nice whether it's a plan much in between months I had for a longer time we wanted we wanted to merge Debian mentors and the whole new maintainer process for a long time because there are many places where this interacts and where we should merge some stuff and if we create one place for people who want to sponsor where they can put the packages and receive comments and find a sponsor in a more organized way than now we could do a lot better than now but yeah but it's not impossible we could create a new section which would be really more called mentoring meeting yeah or something like that but someone could never in one section we would have more trust in the other section that we know we have to check and explain and people would and people have the time to make good advice and to the sovereign check and take more time with the external contributor we work in package and people like do we have anything after this or yeah I wanted to do a release talk something about it's not important but still don't begin doing it can't we do a release instead of a release talk the the question is what point in this proposal do you think Hinders sponsors from only doing selected packages and only doing them right I don't know you said a big repository is good but this proposal this divides the sponsors and sponsors but I don't see your point where is the difference so where does it break which is the important part that you don't the break is not the tool the break needs money the way we described it yes I have a problem with the description of the project I like the idea of a common repository for sponsored packages and I like the idea of a common interface to find a sponsor and to find a package you can sponsor it's needed because the mailing list we use for that is completely useless at the moment because I don't know like 50 posts a day and it's just too much to follow it mostly catch up and don't read most of the posts and so it's a good idea to have a better way to do it but it's not exactly a good way to maintain often packages from external computers it's a good proposal but for something different it makes it easier for to to get into the sponsored state it's perfect for that and that's why I also think it won't be a bad idea to upload every orphan package by default because then you will just create a huge repository for which 90% is not used I think we should really stop now and continue discussing somewhere else because other people want to listen to the next talk completely and might have go to go and we won't finish it anyway okay thank you thank you


Good morning Hank, it's Tuesday. I've been thinking a lot about this lie that's proven very durable on the internet, and yes, I know the internet is made out of lies, but I find this one particularly interesting. By the way, head over to Pizzamas.com before all this Pizzamas stuff disappears forever. Okay, so I wrote about this lie from my podcast, The Anthropocene Reviewed, but the lie turns out to be even more interesting and false than I originally understood it to be. The lie goes like this. Years ago, the anthropologist Margaret Mead was asked by a student what she thought was the first sign of civilization in a culture. The student expected Mead to talk about fish hooks or clay pots or grinding stones, but no, Mead said the first sign of civilization in an ancient culture was a femur that had been broken and then healed.  A broken femur that has healed is evidence that someone has taken time to stay with the one who fell, has bound up the wound, has carried the person to safety, and has tended the person through recovery. Helping someone through difficulty is where civilization starts. In the last six months, this has become probably the most famous Margaret Mead quote, despite the fact that there's no evidence she ever actually said it. It has been shared millions of times, including in one recent case by a user who wrote, I fact checked, and it's legit. But just to actually fact check, putting aside the made upness of the entire story, as the bioarchaeologist Stacy Hackner has pointed out, it's just not true that animals never survive broken femurs long enough to heal. In fact, one review of such fractures in primates found the healed fracture rate higher than expected. Also, it's just not true that healed femoral fractures are a marker of civilization. Definitions of civilization are inherently fraught, but they tend to focus on things like systems of writing and concentrations of state power. When Margaret Mead actually sought to define civilization, she said, it means keeping accounts, keeping records, it means some kind of taxation and revenue, it means a great deal of division of labor. What civilization does not mean is healed femoral fractures. We know this because there are many, many examples of healed femoral fractures among humans who lived in non-civilizational societies. Also, surviving a femoral fracture was not particularly common in civilizations. Like as recently as the start of World War One, most people who suffered femoral fractures died, and whether you survived was largely down to whether you happened to live near a good bone setter, a role that has been around for many thousands of years, and lots of different human communities, both those with and without systems of writing and taxation. So it's a lie, the whole thing is a lie, but I think maybe the reason the lie is so seductive is that at its core, there is something true. Many of us have been taught that only the strong survive, that life on earth is about the powerful doing what they want and the weak suffering what they must, as the Athenians put it millennia ago. But in fact, the human project as a whole becomes much stronger when we do a better job of protecting the vulnerable and affording all people the same rights. Like we didn't get good at healing femoral fractures by believing that the strong do what they want and the weak suffer what they must. We got good at healing femoral fractures because humans have a capacity to understand that serious illness or injury does not negate the value of a human life. Civilization gave us a system of writing that allows us to compare best practices for bone setting across wide expanses of time and space, and civilization gave us the kind of complex tools that allow us to heal bones better. But civilization did not give us compassion or empathy or self-sacrifice, all of which are values that predate human civilization, and in fact values that are not limited to humans. Maybe we need to believe this lie that civilization is where human compassion and healing begin, but I think the truth is actually more beautiful and ultimately more encouraging. All kinds of people in all kinds of times have found ways to help and value one another. Hank, I'll see you tomorrow.


Ahoy-Hoy and welcome to the channel. I'm Dr. Sumerian, not a real doctor, and today we're going to talk about a video the SCP Illustrated did yesterday, which really is something that a lot of us SCP YouTubers have been thinking about, but not saying out loud for quite some time, which is how the SCP animation channels are destroying the rest of us, which, to be fair, that's a great title for the metrics. But I feel like it maybe overstates things a little, but only a little. I could go into the metrics of other channels to show that this is a similar trend, but the important part I can say is that it is a similar trend for other channels. I'm going to go over some of my own metrics, so you have an idea of what I'm looking at, and I'll probably put some of the graphs up on the screen as best as I can. So, when we talk about, let's just talk about what the results have been. SCP animation channels on YouTube really got started about, they started in early parts of last year, but they really started ramping up around, I'd say, September, October-ish, little August, September, October, roughly in that general area, is when not just, there were channels that were doing it up to that point, but that's when more channels started to pick up on it, and then more channels started to pick up on it. And now we've got a glut of SCP animation channels, and these SCP animation channels are able to create long enough content to drive, you know, watch times on the SCP YouTube channel, which for a lot of SCP YouTubers is difficult. I mean, if you're the Vulcan or SCP Illustrated and you're committed to covering the SCP in its entirety from start to finish, you could spend 30-40 minutes on it. I've seen this before, and people will be like, well, people watch television, or people watch movies, yeah, but most people don't go to YouTube to watch long-form content. And the few people that are watching long-form content on YouTube are watching very specific things that they're big fans of. I guarantee you if, say, confinement put out like a 30-minute long video, people would probably watch it. And I should mention, when we talk about SCP animated channels, I don't think it's fair to lump confinement in with them, because what we're talking about are people who are doing videos that are very unoriginal. There's no really other way to put it, and I'm not saying that's a bad thing. And a lot, and the other half of this is this, if you ask the average site author about what SCP YouTube channels do, they'll tell you it's the same thing. They take other people's, and I'm not saying I agree with this, this is just a general opinion, that they take other people's content and make money off of it. The problem is that that approach and that view is a little bit simplistic. And then, so you might say to yourself, okay, well, if that view and approach is simplistic, is it fair to say that the SCP animation channels are doing the same thing? And I don't know that it's completely fair. The SCP animation channels have found a formula that works. And if I found a formula that worked as well as they have found, I would do it too, right? I mean, there's a certain, personally, I like to think that there's a minimum level of quality that I would guarantee before I would like, you know, there's a certain level that I won't stoop to, but like, if I could make the kind of money they're going to be making off of these channels, I would do the same thing. But that doesn't change the reality that SCP YouTube channels, the original SCP YouTube channels are facing. And I'm going to go over my metrics in a way, and the easiest number to look at is subscriber growth. Because subscriber growth is the driver of all things YouTube. If your subscriber growth stagnates, your views will slowly go down as the people who are currently subscribed to you either lose interest or just never unsubscribe or just become dead accounts. Over time, if you don't grow, you don't keep viewers. Period. So I just crossed 70,000 subscribers yesterday, and that was a milestone that I had been expecting to hit. I don't know mid to late last year, not mid last year, but late late last year. I figured I'd hit that in November ish, and it's taken an extra three months to get there. So when we talk about the metrics, this, and I'll put it up on the screen right here, hold on. So this is my subscriber growth starting in September, and this is when everything started to go downhill. And you can even look at the metrics itself and see how it's gone downhill towards the end of that month. Yeah. Worse yet, actually, and this is something I found interesting. My YouTube videos, when I put a new video out, it doesn't matter what the content is about, it doesn't matter what I'm doing. My subscriber growth actually goes down. And that's to be expected. When you put out a new video, you're reminding people who are subscribed and who don't watch your content that you exist. So those people unsubscribe. The problem is that my videos are not reaching new viewers to make up for it. It's natural to lose a subscriber when you upload a video, and it may sound counterintuitive. But when you look at the net numbers combined together, you never notice that normally. However, since my videos are not hitting any kind of, and their search engine optimization being what it is, maybe I need to work on that a little bit. But because they're not reaching anybody, then I'm not getting new subscribers. So you can actually see here, and this was a pretty good, it was pretty okay month. I gained 3,000 subscribers in September of 2020. And this was my last good month. And you can even see when you look at the chart here that somewhere around around the first week and a half, things started to trend downward. Now, this is a chart of every month starting in October 2020 to the end of February 2021. You'll see big dips. Some of these dips are somewhat more understandable. Like, for example, there's a dip of about 55 subscribers. And when I did your wrong about Trump, there's a dip of, you know, 1717 on two different days. When I did my is 2% of the wikis content about to be deleted. And then yeah, I mean, so those are the two, to me, those are the two important days that I actually lost, but they're the more understandable of days. But as you can see on here, there's not a whole lot of like subscriber growth. Like the best I got was the new copyright strikes on SCP content was the best day. And that's the worst part. The best day in this five month period was only a subscriber growth of 89 subscribers. And if you look, I don't know if I've got it up here depends on I don't want to be I can't show all of the data because YouTube's weird about that. It's a little bit like not talking about how much you get paid. They don't want individual creators comparing with other individual creators how much money they're making per click per everything. But the five months following September of last year, my subscriber growth was a total of 3.1,000 subscribers compared to just September, which was the month that things tended downward the month before that was like 4.7 September alone got me 3000 subscribers. August was 4.7 subscribers and so on and so on. When we talk about this as like an existential threat, we're not kidding. It's a huge deal. I thought honest to God, before the September came, I thought by now, I didn't think it'd be like, what's the best way to put it? I didn't think it'd be at 100,000 subscribers by now. I thought I would be in the 85,000 range, like closing in on it before the end of this year. At the current rate I'm going, let's say the average of my growth over the last five months is going to hold true. Like right now, on average, I'm getting about 600 subscribers or not, which is anemic growth. If we multiply that times 12, then we get a total of only 7,200 subscribers. So I shouldn't expect to even get over 80,000 by the end of this year, unless some video of mine goes particularly viral, which sometimes happens or something changes. I, hmm, what's the best way to put this? I am slightly more insulated against this problem because what we're talking about here is also, we talk about the subscription numbers because those are the numbers I can actually talk about. Those are public facing numbers. When we talk about the money that we're making behind the scenes, like a major, I'd say 25 to 40% of the money that we make on a particular year comes from ads being run in December. So it's important, really important, that a video of yours gets popular in December. Because the end of last year was so anemic, and I'm only speaking for myself, and I guess this reflects on other people as well, money that last year was probably down for everybody by a lot, I should say by a significant percentage. And a lot of these people are less insulated against this problem because they upload less frequently. I upload a video every, two every week. That's what I expect on average between five and 20,000 views on any video I do. That's not a lot, but because I upload so frequently, it's sufficient to maintain a minimum amount of ad revenue. It's not a lot, by the way, but it's enough. That combined with my Patreon, which is also down during this time not attracting new subscribers, the only way for me to get Patreon backers are always going to eventually go away. There's nothing I can do about that. The important way of dealing, well, not everyone. Sometimes you have true fans that stick around for forever. But they're going to go away eventually. People's situations change, so on and so forth. So what happens is, without new subscriber growth, without strong new subscriber growth, even Patreon numbers will start to slowly sag over time. And there's not a whole lot that can be done about it, other than re-approaching how I look at the content that I produce. So I feel as opposed to other people who create SCP content that I am probably in one of the better positions, maybe, who knows. But probably in one of the better positions to make a go at it else-wise to fix this problem. What I do for you, generally, is cover news and deep dives and opinions on the fictional content that exists in the SCP wiki. I could do that with other content. I think the other creators could probably do that with other content too, but the SCP content is what's really driving their fan base. I could start working on other content. I could start talking about Marvel movies, or DC movies, or film in general. I have a lot of strong opinions about these things. Start talking about whatever popular television shows are coming out at the particular time. These are things I could probably do. I've considered in the past, but with the SCP content doing as poorly as it is, I am strongly reconsidering the idea of refocusing my content. Maybe it's still doing SCP content from time to time, but refocusing on a more general sort of thing, like picking out what's popular media at the particular time. I don't know how well that will go over, and I'm sure that there will be growing pains to switch. Because all 70,000 of my current subscribers subscribed for SCP content. How many of those people are going to follow me to other types of content? Some, not all. The other solution, and this is something I've also strongly considered, I'm probably going to put up a community poll today to cover this. It's not going to be binding what I'm going to decide, but I'm curious what the community, my community thinks. Because I have another solution as well, and that's invest a lot of money in reusable animation assets, and learn how to animate myself. Write my own episodes of an ongoing SCP-based animated series. There will be more adult focus than the current kids content, I think. And this is doable, especially when the US finally issues those newest... I think if I invested, say, $1,000 in reusable animation assets, I could get started. It wouldn't be enough to sustain me for forever, but it's enough to give me some basic models that I could then animate myself. Not going to be great, I think. And the important part is to myself to find out if investing $1,000 in something like that is going to work or not. Because the guy could end up doing that and get nothing out of it. But something's got to change. Either the content's got to start doing better on its own, or I've got to do something different. There is no middle ground. And it really, really sucks to say that, but it's true. I think I'm going to put up a poll after this video goes live sometime and just kind of get an idea.  It's got to be one of those two, I think. It really does have to be one of those two. And I don't know when I'll start working on it. Actually, I do know when I will start working on the animation thing. I've got ideas for that as a project. And it's something that I have been probably going to work on before this problem, but now it's like redoubled my interest in doing it. Yeah. Let me know what you think in the comments down below and then in the poll that I'm going to put up after this video is live. Thank you very much for watching. If you enjoyed the video, please hit the subscribe button. I mean, I just broke 70,000 subscribers. And the funny part is like I'm posting a video today and I feel like I'm going to go below 70,000 for posting a video, which would be really disheartening because I've been waiting for that for a while. That's like a fun milestone. 70,000 just feels more significant than 69,000. Anyway, please hit the subscribe button and then hit the notification bell next to that so you're notified when I upload new videos. And then head on over to patreon.com. Again, if you can pledge at any level, like everybody here on the screen already has, including Dr. J Redacted and Synderiki, who independently are basically keeping me afloat at this point. I think they represent 60% of my income from Patreon. It's nice to know that I'm not alone out here and I will see you all again on Tuesday.