 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