 So, welcome everyone. This is Boff about how to get your packages into Debian. It is being presented by David Bremner and was based heavily on notes by Ashish LaRoya, who is not with us right now. But he's fine. He's just traveling. He's fine. He's just on his way out. He's got other conferences to go to. So, yeah, this is going to be, there probably will be a bunch of questions and discussion. I'll be running a microphone so that your questions can reach the folks out on the internet, too, if people are following along online. So, welcome, David. Thanks. Yeah, funny story about this Boff. A few weeks ago, Arno and I were chatting on IRC and said, hey, should we have another sponsors, Boff? And I looked at Penta and I said, oh, great, Ashish is doing one, so we don't have to do anything. Well, and yet, here I am. So, anyway, Boffs don't have to be too organized, right, because it's all about audience participation. I do have some slides to get us started. I think the model of, I talk for a while and you fall asleep and then you wake up and participate is suboptimal. It's not as good. So, I really encourage you, if during this sentence, you want to ask a question, you stop me and say, hey, what about, you know, why did you tell that stupid story? It was a waste of time. Whatever you want to talk about, right? So, right, it's not a lecture, even though I'm standing up here lecturing. That's just because I can't reach the laptop otherwise. So, what's it about? Well, it's about getting package sponsored. So, uploading, right, for people who don't have a magic key in the uploading key ring. How do you get your packages into Debian? And I think I expect it's a mix of people who are both doing the uploading, doing sponsoring and being sponsored here. And I think we can talk together about the process and hopefully, I think all of us can learn a little bit about the process and maybe think a bit about how things could be improved. Because although I think we are making some progress, it's certainly, there's plenty of room to improve things. So, I'm going to talk a bit. Like I say, please stop me at any time. I think to encourage collaboration, it would be great if as many of you as want to fire up Gobi. So, who is, since this is maybe the first bof of the conference, let's take some meta bof time and get people, everybody, has Gobi installed? Anybody needs help getting it installed? There's help. It's okay. Just pause a few minutes. So, I guess, do we have somebody to speak for the people on IRC? I do, the one IRC right now. And the channel is hash debgonf-talkroom1. Right. So, some of the people who actually know about this topic should be, hopefully, show up on that channel to answer questions. So, it may be not only people on IRC want to ask questions, but we want to ask people on IRC questions. As well. And once you fire up Gobi, then you can look under debcon's 12 bof packages into debion. So, would anybody be kind enough to volunteer to make some notes for some minutes or keep some notes on what we're going to talk about? Nobody? Should I just start naming the people in the audience I know until one of them volunteers? It's a good plan. Odyx is volunteering preemptively. Very good. Okay. So, and I think it's not a rule that only Odyx is allowed to edit this. You'll see when you get there, there's a big mess of notes that we, well, why delete them, but we can just start the minutes at the top if we have minutes. Okay. So, any meta questions about editing with Gobi or, it's pretty straightforward. It's not Emacs or Vim. That's very sad, but, well, anyway, there's a long sad story about that. Okay. So, why should we care about sponsoring? Well, if we look at SID, we have about 19,000 packages, and we see that about 3,000 of those are sponsored. So, it's a noticeable fraction, and I'm willing to bet that every one of you would miss some package in that set if it went away. It would say, oh, it doesn't exist anymore. What happened to my favorite editor game? What have you? Maybe not all of them you would miss. That's true in general. I guess for a random sample of 3,000 packages in SID that some of them you would miss, some of them you don't understand the point of, that's Debian, right? I mean, we don't all have to like all the packages. You notice not so many of them are NMUs. So, only about 140 are NMUs. In general, there's a big barrier for people being sponsored with NMUs. It's a social barrier. There's no technical barrier to having sponsored NMUs. We can talk about whether that's a good or bad. I don't know. It certainly exists. It's even more impressive, I guess, or convincing if you think about the people involved. So, it turns out that most people who are having packages sponsored are not uploading, say, like Gregor, 3,000 packages or however many, no, 1,000 anyway. So, most people maybe three or four packages and, well, it's a lot of work to get packages sponsored, right? So, you can see why. And generally, I guess, as people get more and more involved, maybe they become DDs. This is so sponsored here. I'm not sure because I stole these statistics, I'm not sure if that's counting DM uploads or not. That's kind of an interesting question now that I think about it. Okay. So, how about the audience? How many people have never had a package uploaded to Debian but think they might like to in the future? Great. So, there's some other tutorials. I know Gennar's running some tutorials on packaging. And so, in this setting, there's going to be a big step where I say do packaging, which is somehow not covered here, but definitely there's plenty of help for that available. So, by the end of DEB CON, I think you should be able to know everything you need to know, which is a really nice head start. Most of what you need to know for packaging is much better documented than what you need to know to deal with the bureaucracy, say, of getting or the social context of getting packages uploaded. All right. So, these statistics, I mean, it's not critical, right? But give you some idea that sponsoring matters. I often think that it matters more as a source of people, as a source of contributors to Debian than as a source of packages. I mean, it certainly matters for both. But when we see we have as many people involved as sponsors, as we do DDs, then that's clear that that's, you know, it's a big impact. It also means that since most people who sponsor sponsor three or four people, there's lots of people who don't sponsor anybody, right? Okay. I'm not trying to make you feel guilty, but if you do feel guilty, then I don't feel guilty about that. Okay. So, this is a mix of things, this buff. Well, so far it's not really Buffy, but please feel to make it more Buffy. Luciano, perfect. Uh-oh. Also, someone who could teach me to use events, that would be awesome. How many sponsors are in the room? Or potential sponsors? I mean, I want to be a potential sponsor. You want to be a potential sponsor? Great. Yeah. And I should not have skipped that question because I know at least one more person in the room came up to me beforehand and said, is this part of what's going on? And absolutely, this is, so, what's involved with sponsoring from a mechanical point of view? I mean, there's packaging quality control, which you probably know about, right? I mean, I guess. So, but then there's procedural stuff, which is less obvious. And it also keeps changing. So, okay, so let me ask that question, which I should have asked before, how many potential sponsors or people who are already sponsoring? So, and if you feel extra honest, how many people who could sponsor but don't want to think it's too much trouble or fair enough? No, it's good. I feel that way myself mostly, except when I'm sponsoring. So, I don't, I sponsor, I tend to, I tend to take three or four or five packages and sponsor them and I sponsor all the uploads and until that user becomes a DM or they don't need my help anymore. That's my own personal style. Other people, I mean, other sponsoring happens in team contexts. So, I think we have about half of the, or more of the active members of the Pearl team here. So, I won't embarrass them by saying what a great team that is, but it is. And it's also been very successful at bringing developers into Debian. I came into Debian through, at least, partly through the package Pearl team. Salvatore, I guess you came that way too? Yeah, so, it's a success story. There are other success stories somehow. So, because we don't want to get too conceded on the Pearl team, we have to admit that somehow it's easier packaging CPAN modules than a lot of these other teams. It's so homogeneous. Okay. Right. So, yeah. Okay. So, what's the big picture? Well, the first thing you notice, or I notice when people come to the Debian Mentors IRC channel is there's kind of command line shock. People are used to tools like Launchpad where you can initiate processes entirely through the web. It's not going to work like that for Debian right now and maybe never. I don't know. It doesn't seem to be moving that way. Right. So, we like it apparently, right? Right. So, fine. But it's a first step to adapt to, and I guess I'm one of the people that thinks, well, you know, the whole process is going to be quite command line oriented anyway, so you might as well just get used to it. Okay. So, the next step, file an intent to package. You have found some package that you want to package for Debian and you file a bug. This does a few things. It helps avoid people packaging in parallel which can be a bit frustrating if you invest a lot of time and then somebody else scoops you with the upload. Eventually, you learn to be less attached to maintaining packages but it's still irritating. We could all find other things to do with that time. So, one of the things, you can go package. You can get help from the Debian Mentors IRC channel or from the Debian Mentors list. I guess for sort of questions about how do I do X packaging, it's usually faster to do it on IRC and people there are quite helpful. Some of those helpful people are here and some of them are hopefully on IRC in DevCon Talk Room 1. Now, one thing that you'll discover is that, and I'll talk a bit more about this, is that intent to package, get feedback from Debian Devel and that feedback is almost always negative. So, sorry about that. I'll explain why. This is somehow the system is set up this way. So, just brace yourself. You'll either be ignored or people will yell at you. So, ignored is actually the good case at this step. Then, we have Mentors.Debian.net is the central place for uploading packages and it runs some basic quality assurance checks. It runs Lintian. It does some other things and it helps organize things. So, one of the things I want to briefly mention is sort of ongoing work with that. And finally, well, not finally. Okay. So, one of the things that's changed recently is we started processing sponsorship requests via the bug tracking system. It's not mandatory. Like so many things in Debian, it's not mandatory but it seems to be the way things are done right now. And so, I'll talk a bit more about that. Then there's this stage after you wait for, after you ask for sponsorship, you'll get more feedback and this feedback will actually be friendly. So, don't panic. It's confusing because the audience of the request for sponsorship understands it's a new package. You're probably a new packager and maybe there's some mistakes that we all make and they will typically be friendly about that. The audience for the intent to package doesn't make any distinction between packages from new packages and packages from people like me who should know better. But sometimes don't. Okay. Finally, the package gets uploaded and, well, then you, then that's another talk, right? What happens after the package is uploaded? You fix bugs and so on. Okay. I see I'm way over time and nobody's asking any questions at all. Okay. We have a question. Excellent. Oh, just in case. So, okay. So all you people who are interested in uploading, does the big picture, okay. Maybe there's too much. Yes. Audix, you're interested in uploading. Very good. I will sponsor you. Maybe. So I have a question. In these steps, which one do you think is now the bottleneck? The bottleneck is that after request for sponsorship are filed, then somebody has to actually sponsor the package. And there's more requests than there are people doing this sponsoring. So it's not a, we don't have somehow, I don't think there's a technical fix. Maybe we should make Phil ask a question because he just wondered in. He doesn't look very keen on that. Okay. Another question. J.P. So I'm showing off that I know his name because he's staying in my hotel. This goes back maybe one slide. When you're packaging something that's already, that's part of a team, like the Ruby team, for example. Do you have to coordinate with them first? Is the process changed because of that? So the question is, suppose you're updating, I guess, a package or packaging a new package. An example would be a Ruby gem. So you want to upload a new Ruby gem. So it's a new package. New package. There's a Ruby team, Debian team. Do you coordinate with them first? You probably should because as soon as you write a generic request for sponsorship, the first thing that people are going to say is, have you talked with this team and that team? Because sponsors are a scarce resource and at least in principle teams are a good way of getting things sponsored, that's how people are going to direct you anyway. So I mean, it would certainly be fine to CC the team mailing list with your request for sponsorship. I think in Debian, there's no rule about all games must be packaged by the games team and all Ruby gems must be packaged by the, and in practice there are people who do and don't but it's, there's already enough friction in the process that you want to find the smoothest way and I think the smoothest way is almost always working within the team. Daniel. I just wanted to add that it's not just about being the smoothest way but that those teams actually tend to have a lot of experience and have probably struggled with some of the same things that you struggled with in packaging like Ruby gems. Like Ruby gems or like games. The games might have a similar set of issues around licensing that you didn't expect or they might have a similar set of issues about ways to integrate them into Debian menu or whatever. I don't actually know what details are with the games. Licensing of artwork, right? Yeah. So talking to the team is not just a clever way to find someone who would be a sponsor for you although it is that but it's also a great way to find someone who can actually give you advice on the parts that you were less sure about in the package. Right. Right. So that's a really good point and I guess to sort of wrap those two things together. The point is not that the teams are an administrative barrier but that they're a resource. Oh. Any other questions? Okay. So we just did this, right? Okay. So intent to pack it and I sort of foreshadowed this and we had a recent discussion on I guess Debian Devel about what appropriate responses are and so people often find software that they think is really cool and they want to contribute it to Debian and that's great and then they're a little surprised that Debian doesn't want it. So, well, that's so these intent to packages don't have anything to do with sponsoring per se, right? Everybody who makes a new package for Debian, Debian developer, non-developer is supposed to make one to avoid this duplicated work and also to allow some kind of sanity check. There's still a final sanity check by the FTP masters before the actual upload happens but like everything else in Debian we like to metal so it's part of the sort of group control over what packages are going in. So I don't know what the right answer is. People have suggested that we're unreasonable about how we respond to new intent. Gus recently opened up a debate about this. I don't know, I don't think that we necessarily are in this room going to change that. It's a cultural thing in Debian and I think it's part of our self perception of technical excellence is that we reserve the right to be honest about the worth of a new package and sometimes the new packages are from my point of view slightly dodgy or extremely dodgy. So I think some level of this feedback is necessary and the best thing that I can think of right now but I think this is actually a good spot to open the floor up and at least briefly see if people have any other feelings or feelings, ideas which is just to sort of be warned that when you throw an intent to package out there you're throwing into the deep end of the pool of the Debian social process which can be a little more rough and ready than say the Debian mentors list. So anybody, well, find that blatantly false or? So I guess one way that I look at the difficulties about getting a new package into Debian is that when you say, hey, here's this package that I made, I think it should be in Debian, the people who receive that are probably thinking about it slightly differently. They're not hearing, I want this package that I just made to be in Debian but they're hearing a request that something goes into Debian and Debian will maintain it. And package maintenance if new versions come out or if there are problems reported with the package, maintaining a package is actually an additional chunk of work beyond the first action of packaging. And so some of that pushback I think that you see with a new package is pushback saying are you really committed to maintaining this thing? Because if we put it into the archive and then there's a problem with it or a new version comes out and it needs to be uploaded, are you going to step up and say, yeah, I'm going to continue to maintain this thing that I sponsored, that got sponsored in or is it going to become an old stale package that's not actually being actively maintained? And so if one of the ways that I find I can think about that resistance is a little bit of a test to see how committed you are to maintaining. And I know that's not a very polite way to do the test, but if you look at it that way you can say, listen, I am committed to maintaining this package for at least the next release cycle about two years. I'm going to try to fix the problems with it. And if you can communicate that back I suspect that you will find the barrier, the resistance to be much lower if you take the time to communicate your commitment to maintenance. Any other comments? So I guess if you hang around long enough you will hear the term vanity package tossed around in a derogatory way to refer to a package that is of interest really only to its uploader. And that's not always so obvious to the uploader, but one thing when you're thinking about what should I, you know, I found this great thing and I think it should be in Debian, think about what's the community for this package. We have lots of very specialized software in Debian and I think personally I think that's one of the things that drew me to Debian was that the specialized software that I needed for my work was a lot of it was already in Debian, but at least I can imagine there are some people at least in a work setting like me who need this same kind of software. So when you think about what makes a great package, part of the sales pitch, I mean it's a kind of sales job to say, hey, this thing should be in Debian is, well look it has this big user community, right, or it has a user community of more than one, right, somewhere between those two statements. It gets more convincing towards big. But you know, if you say look, there's, you know, a small group of us that use this software but it's really important in domain X and then I think that's enough. So another thing that can happen is occasionally our request for sponsorship if the discussion just Peters out and there's nobody really expressing interest in sponsoring it then those bugs can be closed, which is obviously not so nice as the person who asked for sponsorship. On the other hand, it is a response to something that Arno asked last year when he was a frustrated sponsor rather than now he's a frustrated sponsor, which was, you know, if something's never going to be sponsored, then it would be better to find out earlier rather than let the whole process drag out for four months. So this is a bit experimental. It doesn't happen very often. I guess Ansgar is the expert, right? There have been maybe five or six times in the last six months that a request for sponsorship has been closed. And typically this has not been packaging issues. So I would say that whatever packaging issues you have, people on the mentors list, so don't panic. People on the mentors list will teach you to package and on IRC. But what sometimes happens is that the upstream software itself fails what to some kind of consensus of developers fails a certain sanity level. And then it doesn't, then that might happen. But as I say, it's pretty rare. And I think it's more going back to this question of what's good software to upload to Debian and software that has a community with some exceptions is generally more or less meets these sanity checks. I guess PHP is the big exception there. But all right, my biases are showing. Okay, so any questions about this? Like I say, the feedback from intent to package could be discouraging. But I think as Daniel says, you have to see it in the context of your being treated on the same level as every Debian developer with what you propose to be in Debian. DJ. One thing that made me think is maybe the problem is not the package that gets up, that ends up being maintained by Debian. The thing is what we need for a package to be reasonably in Debian is that we need someone to take care of it over the years. And I mean, what we don't need is someone just uploading and disappearing after one or two uploads. And I wonder if we're communicating this commitment that you have to your package correctly. Because I mean, once you upload to unstable, if you're at the start of the freeze, you have to wait like one year for the freeze plus six months for the release plus two years plus one year for the package to stay in stable, including security support. So that's just three years commitment that you have to do. Otherwise, this will just end up being on others' shoulders. So I mean, it's quite big. I mean, even for small packages, you might end up doing a stable, stable release for something and that you have to handle security, whatever, blah, blah. And yeah, I'm just wondering, I don't know. I have the impression that it was in the new maintainers guide, but it certainly is something to stress that what you're committing to is, you know, is a long term thing. Feel free to put it in the minutes. In your opinion, what are the guidelines to decide whether a package is good or not good for Debian if Debian is interested? So for better or worse, it's completely subjective. But okay, it shouldn't have obvious security flaws. It should have a user base, some size. It should, this is somewhat controversial, but I think that if it duplicates an existing package, then it should differentiate itself in some way. It should provide some value to the users of Debian to have another, we had this long running, still have this long running joke, right, about a file deduplicator package because we have so many file deduplicators in the archive. And of course, in practice, I suppose many of them have different strengths and weaknesses, but when you bring up a new file deduplicator and you ask for it to be sponsored, you should know, it's good to know what's in the archive already and say, well, I think this combines the best of these other ones or it's faster or, you know, you should have some reason for it to exist. Thanks. Sure. So Kusanagi on IRC says, I don't really see the problem if someone is not committed for two years. It's work that's being done. Take it out if the maintainer disappears fast, but keep it where someone can take it over. This is a comment from IRC. Right. So that's a kind of counterpoint to the orthodoxy that we expressed. To be clear, the speaker is someone who has been trying to get a package sponsored and has not had it happen yet. Right. Okay. So I don't know if anybody wants to address that. Yeah, well, the thing is that this burden of detecting this package that is not any more maintained and having it removed and blah, blah, blah, this still falls up on the shoulders not of the maintainer that disappeared. It just falls on the shoulders of Debian and the release team and the FTP masters and stuff. And it's boring work that no one's wants to do. And it's better if packages stay in shape and stay maintained than some, than relying on someone else going to see if, if we can remove this package. So maybe we should also teach people to say, okay, if you're leaving Debian, please leave with the packages. I don't know. So going back to my original question about who thinks sponsoring is just too much work. This is actually something that discourages people, I think, from sponsoring or some people I've talked to, is this sense of responsibility for the packages that you upload. I don't know what the right answer there. Certainly this point is, well, you can always just, if your response re-disappears, you can always file for removal of the package. But, you know, removal of packages is also not cost-free. It has a social cost, if nothing else. Somebody's using that package, right? And it, so I think almost every package, well, not every package, but many times there's controversy about whether a given package should have really been removed just because it seems the maintainer is not active or, and it had, so I mean, if you remove a package that has no release critical bugs, then somebody will criticize this decision, perhaps correctly. So another question is, does the package need to be in English? If Spanish is the main language, is it okay? That is, I guess that's a policy question, right? And I guess I don't know the answer. Somebody here knows, Ansgar, put your FTP master hat on, and it doesn't, the microphone's coming. I think we don't need that, but at least the copyright notice and description need to be in English because we need to read it. And of course, it's way easier to find a sponsor if the package is actually in English, because the audience is just greater. Sure. Okay, so was that an answer for the person on IRC? I guess the, oh, hello. Okay. I can also say something maybe on removing packages. It's, I think it's not wrong to remove packages early, because if people notice it, it's more likely that maybe they will take over maintenance, because, well, if the package is actually removed from Debian, it's not like it can't be reintroduced. That's a very good point. And I think some of us feel like someone has died when a package removed, but actually all it needs is another upload to revive the zombie package. So it's not so serious being removed. That's an excellent point. Okay. So we now have this BTS setup. And I think that I should talk quickly. I planned on running out of slides, right? Or time. So that's good. So you can use Reportbug. If you're packaging for Debian, you will learn to know and tolerate Reportbug, because it's just way easier than making up the mail messages yourself. And that is a sales pitch if I ever heard one. So oops. So one thing that's new is you have different severity for different kinds of bugs. So release critical bug fixes, normal for updates, and wish list for new packages. So this feels a bit like discrimination. It is. But so since I don't have much time, let me just mention that so there's been mixed feelings about this experiment. One thing which has been not so great is that there's been a lot more noise on the Debian Mentors list machine generated messages, which this is a technical problem. And thankfully those kind of things we can fix. And we're just waiting for the list master to get some time to set some things up. And we will. One thing I didn't realize until a few days ago when I made these slides up is it's actually pretty cool that just having things in the BTS gives us a way to see how we're doing. And I don't think we really had that easy access before. So in six months, we had 28 RC bug fixes sponsored. Okay, it's not a huge number, but it's not nothing either. Of the updates, you can see that it really works pretty well for getting updates for existing packages. 172 out of say 210. So so that you can have some hope for. You see it works less well for new packages. And I think that's just about the process of of getting packages into Debian. Most sponsors are happier to sponsor existing packages and bug fixes for existing packages. Yes, there's a comment from IRC that says, you can easily end up with non sponsored previously developer maintained packages, which are now effectively orphaned. It is real life that people vanish. I do not see the necessary connection between a sponsored orphaned package and an otherwise orphaned package. I think the person who's writing this is using the term orphaned loosely, not sure literal sense. So that was a statement. Okay. So I think here, the good thing relating to that comment is that those packages would be counted under updates here, and would seem to be being processed reasonably well. So whether they're orphaned, I mean, this doesn't distinguish who the maintainer is. So that's the way that we see it normally. Formally, although, as we saw earlier, there is this NMU barrier. Sorry. They enjoy the back of my shirt. It's the same as the front. You're all reading IRC anyway, so. So I guess we should, I should stop and it's too bad that Ashish wanted to tell you all these great things about the new features of DevExpo. And I will post the says I should stop. So we have time for maybe one question. Okay, thanks a lot. It was better than last year the sponsors buff, so if we make it a bit better every year, I think it helped that we didn't hold it on the last day in the evening. So we're not as tired yet. So thanks a lot everybody for coming and contributing to this buff.