 Good afternoon. Welcome to the last session before lunch. This is Christoph Berg's talk on the future of the NM process Thanks, Nettie for the introduction. Actually, it will be a discussion round So I thought originally it would be a much smaller forum. So I Haven't prepared much slides. I just took the mail I sent to Debian project and Debian you made some days ago some of you might have already read it and Put it into some slides So that's why the first slide is that disclaimer. It's only meant to be proposal. So nothing has been said yet and credits for that proposal gay go to Anthony Towns who made In his block a proposal that I'm going to extend here and Mark brought it with whom I've been discussing this Recently so the the aim here is to get input feedback and finally To get this eventually or something else Implemented or maybe something else. So if it turns out that Our ideas here do not fit in the current she more. There's something that's much better So the current process works like a prospective new developer maintainer Creates a package gets a sponsor to to upslows it then works on the package for a bit Hopefully with some bug fixing new upstream packages versions and so on so this Work done on the on the package then he gets an existing developer to advocate his application Then he applies for the new maintainer process waits for an application manager this Last time I checked that step took about seven months. I think we're down a bit at the moment Then there's the nm process which can take anything between Some days and several months or even years depending on how fast the the mail exchange is how fast the am is how fast The new maintainers and so on and then wait for the devian account manager to create the account the last step used to be also some Real big delay in the past, but this has been Reduced greatly a lot and the queue has been even down to zero just before dep conf So there are quite some problems with that approach at in the meantime, so I've mentioned something as some before The people who apply are frustrated because their application managers are Unresponsive they have to wait at several stages and finally they might even have a Wrong impression on how long this is going to take so They might think they would they apply now they can rush through immediately, but that's not really the case on the other hand we have Haven't had enough application managers, which is Maybe also the case because the whole process takes too long. So application managers get exhausted get bored or whatever and Finally it's the current scheme is a bit boring for either side the the templates have to be filled out and And so on it's some people that have fun Answering this quiz questions some some don't We've been discussing Or talking about AM stuff this morning so We now have maybe a better a better idea of how the templates are actually supposed to work So we will not talk that much about that here, but More on the next slide. By the way, how many application managers are here? So about let's say 10 or so People in the new maintainer process People who have completed it recently Okay, two and people who are not applying because they think it takes all too much time or something like that to Okay, so three Okay, so the idea is to Make the process a bit to introduce an intermediate step in the new maintainer process which is called Debian maintainer the term is due to Anthony and the ideas to Let the maintainer of that package upload the package himself after some initial time of sponsoring and then When when they get a bit more experience with that May proceed to becoming a full dev in developer developer So this is not meant to reduce the amount of people becoming a developer, but only to ease the process a bit so What I'm proposing is the the initial phase works like just like before You create create a package get it sponsored then You contribute to Debian in various ways You work on the package do bug fixing Whatever then you might get the second package do other contribution and Whatever contribution you can think of and then finally after a Minimum amount of three months You can apply for the new Debian maintainer step in between the idea why we are introducing a minimum time here is that We have the impression that way too many applicants a play way too early and not yet ready for the process which Makes it quite tedious to for the application manager to go with them through the process because they have to The applicant has to look up everything gets the answers wrong and the first try the Application manager has to nitpick in all sorts of answers and this is not fun for either side and And the things I put in italic here ask those Where I think needs really discussion, but of course I said at the beginning we can discuss the whole thing and do something entirely else so as before you get an advocate apply for Debian maintainer then you get an Application manager assigned which is hopefully much faster than before Then there's the DM process which looks like Very light version of the previous new maintainer process though There's an ID check As before so we know that who you are when you are uploading packages and there and then there should be some Really really stripped down version of the nm templates or whatever scheme the a m wants to to use Which just contains the things you really need to know to work on a single package Then When this is finished you can use your GPG key to open this to upload this very package There's no account yet. No Debbie not account yet So it's pretty much similar to the the sponsoring scheme before except that you can upload yourself and Every upload which would go to the new queue would Need another sponsoring upload. So this is so named bumps other packages and whatever Okay, the next step is then More contribution again for a minimum of three months to have people a bit more skilled Of course time is not the only factor that into Influences that and then in the second step which Actually looks like what we have now. So there's another application Application manager and then there's the DD process as before and then you get to become a developing developer So there are some random notes on that. I'm going just to skip that now Some things I've been thinking on there was a big discussion in I think April it was when mark posted is his new maintainer process thoughts on project, I think it There were some proposals to Call developer something else and so on. I don't think we can Recently change developer to to be something else So we just keep that and I like the term Debian maintainer very much because it's just that's what people are doing They are maintaining packages Maintainer is a familiar word in the Debian context and it just sounds all nice There was some Proposal naming it concontributor, but I don't really like that Okay, hi, I'm I'm madduck and I wonder what we're gonna do with translators, etc. People that Contribute but aren't actually maintaining Okay the question is Which types of Debian developers do we want to have at the moment? We have packages and you can use the documentation track to apply for an M there have been a few people who went through that and some of them ended up releasing edge and I think the discussion Would whether we want to have translators artists lawyers and so on as Debian developers is a different from that one here That's a different discussion. We should Have at some point, but that's not what we want to cover here Nettie. I'm relaying something from my RC from Basak Sutika He says this proposal seems to rely on the idea that magically they're going to appear more ams However, these ams also need to do more work if I understand it correctly So it doesn't seem likely more ams will step forward. Could you comment on that? Yes, I said in the beginning. I think in my opinion the current process Is bad because there are too many board of the whole thing and If we have an intermediate step, which is easier to to get to and people will Be more skilled when they apply for the full Debian developership So it will be more fun for the application managers to work with them and on the other hand We don't intend to People to stay in the Debian maintainer stage, but of course they can so I can imagine that Maybe half. I don't know fourth or three quarters or whether whatever of all people Won't proceed to the full Debian developer ship and then there will be less applicants. So Again, that's not not the intention to have less Debian developers, but I think there Will be more successful applications which will Make Working as an application manager more fun a bit Like adding to what you just commented what Maddox said and similar. I think that We should I mean if we go this way, we should integrate all these well Finally, it's an ovumism. We Search for a better word. We don't really have people who are not maintainers Being developers in Debian. So I do think that on one hand this Like intermediate step will make the process shorter or maybe two processes which change together will be a bit longer A longer, but people will be happier But it also opens the door for having a the other roles recognize officially and it will be it will really allow people to To officially join the project doing something else than coding So I think your proposal having it together with parallel proposals for the different roles that Debian person maybe the term will not be devian developer anymore a devian official member will do Is it is bound for success, but if we take into a into the project the other tasks I am here. I Agree with I agree with Gunnar on this completely and I think that Debian is in a problem problematic position where it Focuses too much on technical people and forgets about the community part where The community needs to have a balance between technical and less technical more social oriented people We must not forget that community is a social thing not necessarily a technical one and by Creating a monoculture of technical people. We run into more problems Yeah, and I agree with this Debian person whatever concept that Gunnar suggests Okay about that As the first point on that slide here is that I think it we will have to we will keep the term devian developer for all Debian persons be they Laura's or artists or whatever just because it worked I don't Think that this proposal is meant to get To enable other tracks to get into Debian It's just meant to because we have the the the vast amount of people applying for NM at the moment are Packages and we have a problem with that getting them through in the in a time that doesn't suck So we have to do something that they are what what I'm going to do here Well two things we are changing a couple of things for internationalization so We are adding France give the idea and others talk. We are adding the concept of Translation our new ownership So it will be easy to treat the translator as a developer because he would take care of some Translations, so it's not that different anymore. So if you have Significant translations inside the project will we will able will we will be able to track this and So it's almost the same track of developer for translations and probably for documentation also And the other thing is today in the morning We speak with the game to developer that is attending the conference And we are talking with him about how is the process to get to became into developer and they use mentor kind of Approach you have to be in contributing for at least six months And I'm not sure about every every detail But you have to be in contributing for six months then somebody start to taking care of you and volunteer to be your mentor inside of the process and Takes some responsibility for everything that you do and after that Eventually you became again to developer with less responsibility, but both rides and after that You can apply but with very deeply technical tests and it looks like similar what we are doing now like adding a Middle stage and that's one of the things that I at least would like to discuss about Changing I saw a couple of ideas about changing the application manager for mentorship So it's one of the things that I would like to comment from people that are Applicant managers or something like that if you think that could work better or worse Or if what depends depends on the new maintainer process or on the on the applicants or something like that? One thing that was clear from the cushion the discussion this morning was that the the application manager is really free to do Whatever he wants with the applicant so most are using the templates as we know it at the moment, but If the application manager wants to do a mentoring scheme Or whatever that's perfectly fine We the W an account manager even said that he's fine with an applicant that didn't do anything in the process Well, the applicant just the application manager just Provided enough pointers to mailing list postings bug reports and so on which is based on previous work by the applicant so Kind of in that scheme here is a bit of orthogonal to How the actual application is done in the end? I don't know was first France We had an interesting discussion I think yesterday that we may even have to reduce the size of Debian in some respects Because there is a lot of technical discussions Or the project is kind of lacking direction Sometimes and it would maybe be easier easier to Make decisions after as project if Some decisions would be taken by less people So you could think of going to Debian core developer and having the larger body of People that are really only interested in maintaining one package or translations or documentation around it That's Yet another different issue I Personally don't want to to reduce the number of Debian developers at the moment or reduce the number of people successfully applying Maybe it will turn out that Let's say 50% of all people applying at the moment are just happy with uploading their own package They can do pretty much everything with a With it they want then if they can upload it. So Maybe it will turn out that we get some kind of meter Developer around there, but that's not the intention of that scheme here On the other hand, I don't think that Debian is actually to that big too big at the moment There are lots of discussions on devil or whatever that end in nothing because no one steps forward and implements stuff So I I think if you just go ahead and do stuff You can get your solution Although this prompts that the idea that it should be kind of easier to get into but it should also be kind of Easier to get out of Debian. I don't mind if we started coming out with a process in which packages Which are effectively not maintained get orphaned and people who are actually doing nothing Stop being Debian developers and it's not a bad thing if it's easy to go back If someone hasn't been doing anything in Debian for three years then probably That's that doesn't count as a Debian developer anymore But once this person wants to come back maybe a little bit briefing of what changed and Persons back in we have a married to stuff which kind of worked Which was to a bit of a respite reply to France what I wanted to say about your process It's got it's got a couple of things. I don't like one is it's 12 points And that is more than seven plus minus two Six yeah, that's twice as much as it should be which means I mean It's it's hard to remember all the points because it's more than seven plus minus two obviously Which means it's it's too bureaucratic If it's too hard to even remember what the points are it's Sounds like too complicated Which for something which is getting accepted into Debian if you are too complicated to begin with then Then you end up in In an exaggerated amount of trouble when you actually deploy when you get to the corner cases And that that's what scares me the most the most and the second thing that Quite scares me is if it's too easy to get upload privileges I see like a mass of Ubuntu more two people started uploading stuff in Debian which wouldn't be maybe a bad thing But when installing packages, I may want to have a choice if I really want to install packages from people who haven't read the policy Very well, and that sort of things So I'm kind of scared at the idea of what kind of packages would I find in my aptitude list if I Opened like if I made it too easy to put packages in yeah, yeah, right That's one of the concerns. I also have here To comment on the complex complexity thing. I don't think it's too complicated. It's just two times what we have now and the Step this is step zero step one and two just look the same It's just the slide looks similar because I was too lazy to too lazy to format it and the ideas that there is some Really visible amount of package that is has been done on the in the BTS Uploading the package and so on before the people get to to up really To get the upload rights So it's just like you have been your sponsor and you have been sponsoring That guy for some time and he did three or four or whatever uploads and it all works fine And you expect the next one to be the same. So why should the funders still be bothered with that? Yeah, I will I have one little comment who Enrico right now if you are going out of the project leaving this Defined procedure by mailing the key key ring admins and many given private There's an easier way to get back in if you are outside for a long time. We have defined Some templates for the emeritus developer which have less than half the questions of the other stuff Just to ensure they are up to date with what's happening in Debian So it's not that hard to get back in Debian if you really want to I was wondering if There was any research being done on the normal or average behavior model way of behavior of Uploaders, I guess there are very different people around people who fix bugs lots of bugs and do NM use people who do group maintenance ship and people are perhaps others who only care about their single mp3 player or so has anyone Done this research and what was the result? How are these distributions and? Which answer do you which questions do you want to answer in with that proposal? No, I wonder about what kind of persons do we have as Debian developers? if You suppose to have this Debian uploader. I'm I forgot the name Debian maintainer How many Debian maintainers do we have already I? I Can't say anything about the numbers, but from what I've seen browsing the archive it's Maybe half of the the maintainers that only have very very few packages that get Two uploads a year or something like that So others want to comment on that Have I led the question for some time now Thank you. I just wanted to reply to an encore as well Concerning the Ubuntu Moto stuff. I mean if we introduce this intermediary level Debian maintainer it's only to give rights to people who have been sponsored like usual It means people who do good work and we check who have package which are policy compliant. So I don't see any problem here and if over time problem appears, I mean bugs in RC bugs will be tracked like usual and They will be fixed if they don't get fixed by the maintainers themselves and we remove the package again and I mean it's just a normal way We're working the reason I mentioned Moto is because I have been visible for a while in the Italian in the Ubuntu community and I regularly get requests from Moto people who would like to upload stuff in Debian because it's kind of cooler and So that kind of scares me a bit So I tell them that like well, yeah, it's nice. You're a Moto. It's really good what you do But well, there's lots of like policy stuff like in that been you have to follow and you should Most than ever you should have a goal for yourself for being a developing not just look cool But it's usually like half an hour long talks trying to work out What's the real motivation and not just you know, you were Ubuntu user you became Ubuntu Moto It's cooler. You want to become a Debian developer It's even cooler and that's just not like what it works That leads to a lot of frustration and since I see there is a request Then that kind of scares me a bit to make to open too many doors at least every is the cooler distribution That's why we want to ensure that there's Reusable amount of work done in Debian before they can apply those. So this is the biggest open question So far so Manoj has had a question for some time. I have a comment in a rather Somewhat inflammatory question. I'll go with the question first What are our goals? Do we want to be a social club or are we trying to improve to produce the best? Distribution of Linux ever if we are trying to be a social club then yes We should lower the standards and the lower the barriers of entry We all has anybody asked the release team about what they feel about a whole bunch of Not quite experienced people directly uploading Rafael mentioned that we can just fix RC bugs Anybody has had a look at the RC bug count recently. Are we sure we want to be lowering? The what it takes to get a package into Debian without anybody looking over your package My comment which is not so inflammatory was about People who have gone away who are missing its simple security, you know principle of these privilege If they have not uploaded packages in 12 months, they don't need the privilege of uploading packages and that privilege should be Removed until they ask for it again. It can be just a simple matter of saying yet. Okay. I'm ready to upload again Give me my privilege back So in my opinion more still a technical project. So we don't need Everyone who contributes socially on IRC to be a developer I see a reason for Acknowledge others to be a member of the project, but as said at the moment We are talking about the technical side of the project. We have packages distributions and so on and have Want the people that do want to take care of that to get in less painfully funds I tend to agree with Enrico's and and also managers concerns and One solution could maybe be that packages uploaded by people like that stay in unstable Until they become DD or unless a Debian developer is willing to accept responsibility for those packages by By being an uploader for that package so Then this won't change anything. So what you're proposing is just a sponsor scheme we have now So the intermediate step here What the proposal doesn't have is a no-op Well, but why should they upload packages that are not released? And the idea is not that they are not maintaining it anymore. Okay, the the question or the answer for Franco what what happens with if those people do not Proceed to become a developer and we have lots of packages in stable by those people if they are they not going to be maintained anymore So I don't think that's a point. I do see the point that We have people uploading there that have not gone through full Nm yet, but on the other hand we have at the moment we trust every developer to handle his packages correctly and No one takes care of that anymore. So it's pretty much the same So there's a couple of questions on the other side of the audience Okay, it's open. Okay being that I have the microphone. I have the next word a Well, this is a very hard point to address I think and that's the reason everybody's jumping on it. I Am of the opinion that this first step well for current nm. We have to go through a the technical part and through the social part and I think well, yes, we have to focus on technical quality our distribution is widely known as the as the most perfect one as the most Carefully prepared one. So maybe the the answer will be okay. If we are allowing a People to contribute directly to the to the beyond before being completely committed and completely tested to it Maybe the first step should be the technical one in the end we will not allow for example for a Debian maintainer to upload the new packages without being sponsored that rules out problems with licenses unless the license Changes a half way through the process. Yes. We're not allowing them to do nm use. We're not allowing Many things. Yes. So I think we we could implement something like this focusing first on technical abilities and again, I take again this idea of of Putting many parallel processes for the different kinds of contributions But for maintainers we will focus first on the technical things and then for people who want to be a developer and want to vote they will have to go also through the DS a D the guidelines, I mean Spelling in English is terrible a well If I really quick point to So if I could raise a really quick point about the sponsorship thing if you are sponsoring a package in Debian That means that you personally are responsible for the content of the package the person who actually prepared the package It's great if they fix RC bugs. It's great if they keep track of the package in stable It's great if they help as a real Debbie maintainer should but when you sign that upload and you make that upload You're saying that you are personally responsible for the contents of that package if that Debbie and maintainer or if that person who's not yet a Debbie developer falls off the face of the planet You're responsible for that package if you don't want to be responsible. You don't sponsor it And so I mean that's one of the things that sponsors Maybe we need to improve the process for sponsoring so that people who are sponsoring packages understand what that means But that's really what it means to sponsor a package Manage earlier on said that or ask the question whether we are a social club or whether you're producing the best operating system And I would say we should do both because the social club that we are I mean look at us We're partying every day here depth confine. I think it doesn't necessarily decrease our productivity I think as a matter of fact in the long term it really adds to the project and enables us to do a lot more So you shaking your head right now Manage, but That that's my opinion. I do at this I really as we have a little time left, but I quickly want to throw it another thought About how Debbie and keeps increasing increasing and this is you know, don't comment on it There's nothing to do with this talk But there's also some security issues to me Involved with the fact that we have 1,000 maintainers currently that have right access to the archive We keep adding more and more, but we're not really dealing with these security implications That as a matter of fact introducing children's that's going to be really easy Just think about that and talk to me if you want to Okay, I would like to add a remark agree with medic and Manage said we had about a thousand RC bug. That's true. But how many bugs of Are due to people who are not deviant developers? I mean if we have a thousand bugs because we have many deviant developers who suck doing their work and having more deviant maintainers will not Increase the percentage of person who Suck at their work. So what we have to do is fix our process so that we manage them But I don't think it's right to point the deviant maintainer or new maintainer process as a guilty of this problem and a second and a second remark I would like to Share see that I know someone with a tech expert and it would really like to manage some tech packaging within the band But it was really scared with the full Devian developership it would be perfectly happy with this deep and maintainer process It would have like three tech packages that no one else wants that are currently orphaned and that would get Removed in a few months. They would take care of them without any problem So I do think it's a good thing to introduce this level of deviant maintainer Yeah, I mean I also share the view that at the moment a sponsor should be responsible for the package They're sponsoring. Can you say why well, can you say can you give some concrete examples of checks that you think we need to Perform for a deviant developer, but not for some a deviant maintainer who can or who can upload directly And why we don't need to do those checks As Kunar said the the whole DFSG stuff could be skipped because they are not allowed to allow new Sorry, you can check the contents of packages are not static. Yes, but Well, you have to cut it at some point and how often does that happen quite often packages For example link add some other bit of software into different license It may be incorrect may be an invalid combination of licenses some documentation under a non-free license, so on Well, but that would be the responsibility of the visit is sorry That would be the responsibility of the to check the spawner that from the beginning Of course if the the contents change that they can now upload directly. So how does Yeah, but okay the I think that the case that the content or the license of the package actually changes Doesn't have happened that often Okay, so if you agree that's a problem, we have to discuss it here. So but time is running out quick I have one two things that I will as a proportion Propose I will propose two things one is that you should probably have a Role that is called the band community member Kind of person that are not developer, but I'm making rollouts installations Helping people using the system This is just a thing. I will propose. Okay, the other thing is that in DBM 80 you have a lot of people committing a lot of things to our own Repository and we use to the DBM developer to do quality insurance if you're gonna have some packages new things Uploaded and or improving some things that we have 50 people contributing with just five DBM developers That really doing the as I see the quality Insurance and have a standard to rise to so this should be a negative thing It's just positive things that people can help each other and then Somebody are probably much better persons making a contribution to DBM. They should be leading that part of the branch of the project so we have To be too strict on how to do this you exclude people that can't contribute so put this together You have this is also a different issue here We want to have this we are talking about the process that gets people into the debbing key ring and Gets them access to projects machines. Well, that's really the process. We are talking about And I think be Dale had a question a comment or yes There are There have been several concerns about allowing too many people in Debian and the risk That are very computer and technically and that we can We can see them sometimes have some examples often in the note Someone who is very competent and we need him to be a developer as soon as possible And there are several You can be Now and not in six months now So to me that means we have to make the new maintain our process more technical More because we have to be more strict about people And we have the other side to be to lower the barrier for people that can help a lot the The proposition was to that we have a lot of people helping and we want them Into Debian as fast as possible and that we Well need a way to get people in Yeah, this is how the the precise process works was discussed this morning, so I'm not going to repeat this I think we are running out of time really really now so be there I just wanted to comment that when Manoj asked the question earlier about do we want this to be the best Technical distribution or a social club to me the answer is completely and unequivocal It's completely obvious what the answer is and that is that we're trying to create the best distribution the extent to which people are willing to sponsor events like this one and other things which Help to improve our social interactions or as developers are entirely because We understand that these sorts of activities are crucial for helping people to be more productive and working together Not because there's any desire on anybody's part to provide Sponsorship for free vacations to strange and exotic places or things like this I think it's important for all of us to remember this it is really pretty Fundamental and when we're thinking about all of this stuff while I am completely in favor of finding ways to recognize and to Thank people who provide Contributions to the project in ways other than fixing RC bugs We really have to stay focused on what the core objective of the Debian project and the surrounding community right Simon's I think sort of to sum up the discussion here What what I've noticed from all of these comments is we don't actually know why We want to change the new maintainer process We haven't figured out like what requirements are like who who what kind of people are we trying to get into Debian? like because yes, it is a good idea to get people who are Who are good at working with one another who we can all work well with as well as Be of a high technical caliber But which kinds of people are we selecting and this is why we have all all of this discussion because I don't think we all agree On the type of people we want coming into Debian We have to figure out that before we can actually design a proper new maintainer process Thank you Okay, how many time do we have left none? Man minus more than Chris, okay. Well, it's lunchtime. So At the ground I Was just one last remark I'm interested in your opinion on whether this is a good proposal or not So can we just make us a quick poll who thinks this proposal like what Chris have said is good Just what we have now, of course, so who thinks this should be implemented in some way Similar to this raise your hands Who thinks it's about Ten people and who thinks it's not a good idea About About the same. Yes, who has other plans or would no opinion so everyone who has Remarks that have not been addressed in the discussion and wants to as an idea of a different scheme what we should do should please talk to me or AJ and So we can see what we can do here so well, I think thanks for coming and We are all for lunch now