 Okay, I'm AJ, that's Andrew, that's Francois, we're all, well, we're developers and you're still a maintainer, right? So how many people in this room are developers, Debian developers, and how many are Debian maintainers? We've got one, and how many people have something, have a program that they think should be in Debian, but isn't? Okay, so this is kind of you guys. How many of those people were Debian developers? Yeah. How many people work in Google is apparently a question someone wants to ask. Yeah, whatever. And how many people have PPA in Ubuntu? Nobody, gosh. Wow, okay. So basic philosophy of getting something into Debian, find some software, make it into a dev, upload it. Yeah, profit, not so much, but whatever. Seriously, my indentation went away. Okay, so in all the rest of these slides, the top bullet point is meant to be what's happening, and the rest of the bullet points are meant to be how it's happening. So if you want to package something, it's generally polite to talk to the upstream author and say, hey, I want to distribute your software to millions of people. Checking the license. You're in a Debian mini conference, I guess you're obsessive about free software and license checking and stuff like that, or at least are familiar with people who are. If not, talk to the person next to you. Sorry. It's generally good if you're trying to package something to actually look through the compiler warnings that spits out or the warnings that spits out at runtime if you're packaging something built for KDE or GNOME. Running the test suite, stuff like that. Good idea to do that stuff before shipping stuff to other people. It's rarer than you might hope. Packaging software has, how many people here have not ever actually packaged something as a dev? Have you ever tried? Okay, so it might look hard, or if you try googling, there are many, many, many pages of instructions. It's not as hard as it looks. If you try and do it perfectly, then it gets hard because it's kind of a long tail of bugs to fix, or policy to comply with, or little tweaks you can do to make packages better. What? Okay, so packaging, the first things you want to know about is dev helper and DH. Make DH or make dev helper will basically take most packages and turn it into a dev for you with almost zero effort. You'll want to install things like dev scripts and depot. And if you install that package and have a look what's in it and look at some of the main pages or the help, that'll give you a fairly good start. The developers reference dev and policy, good things to start reading eventually, put it on your nightstand or something, and read through a chapter as you go. I personally think they're quite readable, but your mileage may vary. Once you've actually got a package run it through LinkedIn, it'll complain at you, fix the bugs, run it again, it'll complain some more, fix those. And once you've completed that cycle and it's not whinging, mostly people won't whinge either. And a lot of Debian folks are on ISE or mailing lists and it's fairly easy to ask for help there too. So once you've actually made the dev, then you want to get it into Debian. So I don't know how many people have tried this or heard gossip about it, but that was my take on what you probably expect. So you get a GPG key and then you get it into the Web of Trust by getting a billion people to sign it. Prove you can recite all those documents that I just told you about backwards. I probably should have put in something like become a legal expert on the GPL and stuff. Then you put in an application and wait five or 10 or 20 years. Then you're a Debian developer and then you can do whatever you want, which mostly means go to conferences and not actually package draft as far as I know. Consider that all wrong. If that was your worry, then try and throw it out. The best approach is go through the Debian maintainer approach, which just means get a key, get it signed by a couple of people. You can do that by the end of the day, if not the end of the week, or I'm doing that the other way around I guess. You have to agree, sorry, yes. Why do we have a key? Because we need a class hierarchy so that the aristocrats like you and I can live off the labor of the serfs. Does that clear it up? The real answer is because making things easier is hard because DDs have to be super smart for some reason. Politics is the real answer probably. You're welcome to propose a GR to get rid of the distinction, I don't know. This policy is basically how I got to be a DD back in the day. The DD processes have created rules and bureaucracy since then for good and bad reasons. If you had a time machine and could go back to 97 or so, this would be your process to become a developer. Agreed social contracts, agreed to the Debian machine usage policy, I won't post spam from Debian machines, subscribed to the Debian developer announce list, get a DD to say that you're a good person, you can code, you won't introduce crap into the archive. Again, you can do that here this week. Then the mechanical processes, you file a bug in the bug tracking system, referencing all these things, and that will get you into the Debian maintenance key ring, at which point a Debian developer can grant you access to help do uploads for whichever specific packages. You can do it, so if you can already make a package and you just want to get it into the archive, if you go through those steps this week, you're set. The other bits, if you want more help for stuff like this than things to know about are all of the counts, the various subgroups that may be relevant, so Debian Perl, Debian Python, Debian Haskell, Debian Med, Debian Science, I think there's still a ham radio group. There's the collab main group, which basically says, yeah, these packages are just maintained by everybody, and there's a bunch of stuff like packages QA to help to QA analysis of Debian packages, and those are some links, and I figured anyone who wants some questions who's got a key that they want to get signed is basically the rest of this session. So the collab main thing, when I tried to get repository created for a couple of us to maintain a particular package, the Allioff maintainer said it's kind of a pain in the backside to get individual group things set up, so use collab maintenance and it'll be all be fine. So while it's true that it is meant to be committable by anybody, I think there are certainly formalisms around that, so rather than just jumping in there and committing something and uploading it like I was planning to do this afternoon, you really should ask the people who are on the uploaders and the maintainers list, mostly just because it's convenient to have a single repository. What I'm not sure about with respect to the Debian maintainer thing is it is a separate keyring, but once the initial upload has been blessed, in theory that person can continue to upload that same package without further oversight by the original developer. So that was the way it worked originally. The way it works now is there is a separate database table that says which Debian maintainers have permission to upload which packages, and that's controlled by Decut, so any DD can basically say, yes, this person can now upload this package or no, this person can no longer upload the package. So it sounds like Debian maintainer is actually the correct solution for somebody who has one package that they care about deeply and they want to upload, but they don't want to be bothered with the rest of the fruit. Yeah, or a particular subset of packages they care about, yeah. So the other thing is that the Debian maintainer, being a Debian maintainer is basically considered a step on the way to being a Debian developer these days. Just wondering if you had any advice about what to do if the upstream is very unkeen on your packaging efforts. It depends in what way they're unkeen. Like it's free software, so you can just say screw them and do it, right? But that's not the best way if you kind of have some bugs and you'd then like their help to get those bugs fixed. Okay. And just what is... Okay, so I'm looking at some large Java libraries, unfortunately, and there is a gigantic kind of trail of dependencies and dependencies for the dependencies, and of course there's test dependencies for the dependencies. So is there any kind of minimum level of usefulness? What's the kind of threshold for getting something into Debian? I mean, it seems to be rather kind of, if you're interested in it, then go ahead, but is there any more comments about that? You guys want to... I think this threshold is basically kind of an informal one, which is like if you're willing to maintain something in Debian, then you pretty much can. You can upload it, but if you're a DD, you can upload it. If you're just a random person in the community, then you need to convince the Debian developer to upload it for you. At that point, you can maintain it. As long as you don't have too many release-critical bugs, well, any release-critical bugs that you fix them quickly, and it's not a big burden on the security team, then you can pretty much maintain a package that only three people use. That's like... We don't really... And that's off to the good first step. Can you repeat that one more time? You can repeat it if you like. Yeah, you can host all... You can build your Debs locally and host them locally without having to upload them to the archive. So that's particularly not a bad idea if you've got a whole bunch of dependencies. So you want a package, open rocket, and it's got a whole bunch of new Java dependencies every release. So you then have to package all those dependencies as well and to actually make sure that those work, then you might as well do that, or locally set up your repository, rebuild stuff against the repository to make sure it builds, and then you can upload them all at once. Yeah, I've ended up packaging two... another two kind of Java testing frameworks, which I'm not sure how many Java testing frameworks Debian needs, All of them. So if you look through the packages that are in Debian, you'll find things like Chiak Utils, which is some stuff that Ian Jackson and some of the guys in that run the Chiak server in the UK happen to find useful and figure other people might find it useful to. I'm sure you can look through a popularity contest and find some that only one person uses, or one person who runs popularity contests and reports uses. It's not really very nice to upload something and then not maintain it when it starts getting RC bug reports or something later, so that's a limitation, but it's all pretty informal. Okay, thanks guys. Yeah, I was just going to add on that there's probably some, as Ajay just sent it on, I guess there's some kind of social expectation that you will continue to maintain or you upload for at least a period of time. Otherwise it's going to get dropped. Yeah, and if you don't, the expectation is that at the very least you'll be, you'll orphan the package to make it explicit that you're no longer maintaining this thing. Like there's a process for getting something into Debian and there's a process for signaling to the rest of the project that you have no interest in this package anymore and you want someone else to take it over, or you just want to rage quit the package. So as segue on from that, and this is just a hypothetical, I haven't run into this in Debian, but I'm going to go back to the C-Pan, is what do you do if you want to help out on a package but the current maintainer or person in charge that isn't being responsive or doesn't, yeah, maybe it's on its way to being orphaned, but what do you do if you can't work with the person? Well, so the first thing that I would say is try to get in touch with the person and like some people will be unresponsive when you ask them for help, but when you offer help they become responsive, especially like would you like to have a co-maintainer? I've picked up a few packages where a person was like, no, I'd like you to be the maintainer if you don't mind, and then it's like, sweet, I want to fix this. So that's one thing, just offer help to the person that's not responsive. If the person still doesn't respond, then basically what you want to do is there's a process called the MIA process of missing in action, and you can report that person as potentially missing in action and then there's a team within the end that will try to contact that person and if it fails they will offer the package for you and then you can pick it up. But the other thing you can do as well is you can do a non-maintainer upload in NMU. So if there's a bug that annoys you and it's not being fixed, you can't contact a person while the MIA team is trying to get in touch with them, but you can do a non-maintainer upload, which is basically like, you get a debut developer to upload something and you tell the maintainer, here's the patch where I applied, here's the patch where I applied to the package. The package has been uploaded into a special queue so that it will actually enter the archive in 10 days. If you disagree with this, feel free to block it. If you don't do anything in 10 days, it will go through. So that's something you can do. Did you have something to add? No, I think you nailed it. There are occasionally hostile takeovers, but they're not that common. The solution of contacting the maintainer and offering to help, and perhaps being an uploader, I'm pretty sure we'll often end up with, you can have it. I've certainly done that from the other end. Somebody's been really keen to help on Debsongs, for example, and I said, it's all yours. Take it and run. If you're looking for packages, you want to be involved with Debian and you don't know what to package, one good thing to look at is actually, what is it that you use that's not very well maintained? Maybe there's this particular tool that has had five new upstream versions that haven't been packaged. So you can think, oh, that's interesting, and you can try and get in contact with a person. It's kind of likely that you'll end up the maintainer if you ask nicely, and the person doesn't have any interest in it anymore. Along those lines, also checking the list of packages that have either been orphaned or upropped option to see if there's anything they actually care about and might be worth picking up, otherwise they may not be in the next release. And there's a tool in Debian called, I think it's part of the Dev Scripts packages called WNPP-Alert, and what that is, WNPP is work needed in prospective packages. So it's a special meta-bug within Debian that keeps track of packages that have an orphan that need help and all sorts of things. So that tool, if you run it, it will show you of the things that you have installed on your system, which ones have an orphaned, which ones need a new maintainer, those kinds of things. So that's a really good start. I've picked up a whole bunch of packages myself and I have this running as a cron job on my machine so that whatever is a new package that gets orphaned that I use because it's installed on my system, that I'll get a notification like I'll get a cron job hotel, and then I can look into either adopting their package or at the very least, subscribe to that bug where it was orphaned to keep an eye on it to make sure that it actually gets picked up by someone at some point. So people here have not filed a bug against Debian. Not filed a bug against Debian. And how many of those people have not experienced a bug in Debian? Okay, so you should be able to file those bug reports when you actually hit them. I assume everyone here, because you're at LCA, is kind of smart and knows how to help debug problems and do sysadmini tasks and maybe compile programs and whatever, because that's really all it takes to contribute is file a bug, help debug it, help produce a patch that resolves it or makes it better in some way. Filing bugs, getting patches, that's like the first step in getting stuff into Debian. Just on the bugs, if you discover a bug and it's quite clear to you that it's a bug in the package itself, not in the... Sorry, a bug in the software itself, not in the packaging of the software, do you prefer if it's just handled upstream? Do you prefer if it's submitted in both? It depends a lot on the package maintainer. The debug bug tracking system in Debian has a feature to let you forward bugs upstream so that you file it in Debian, you forward it upstream. The upstream fixes it depending on how... on what bug tracker they use it might even get tracked back down to Debian when that bug's closed upstream. Being a... If it's... I don't like the way the GUI's put together on this program, then that's probably something you might as well just keep upstream, but I don't think there's any rules on saying, no, this is an upstream-only bug, don't file it in Debian ever. I think the observation you made that it depends on the package maintainer is quite true. For some packages, the maintainers will be heavily modifying the upstream source for whatever reason. Ideally, we try to avoid that, but sometimes it's inevitable. In those cases, you're probably better off if the Debian version is heavily patched, you're probably better off submitting the bug via Debian because it could be one of those patches. On the other hand, if you actually get the source from upstream, test it out, see that it has your bug, then you may as well file the bug upstream. What you can do as well is you can file a bug upstream and then file a bug in Debian market as forwarded upstream, that way it's tracked in both places. Especially if you have it patched forth, then go for it and file it upstream directly. Because the maintainer's going to have to do that work anyways. The other interesting point along those lines is that if it's an active, if it's a project which is reasonably dead upstream, then often it's more active in Debian having bug fixes done within it. And there's been a few packages where the Debian project has ended up adopting those packages and effectively become the upstream. So again, depending on what the package is, if upstream is pretty much dead, then the Debian bug track is probably the best place to put it. One of my upstream is actually hosted on GeoCities. Is there any rhyme or reason to the new upload queue? Just looking at the packages going into and out of the new queue, some of them seem to have been there for literally years. Sometimes it takes a week, sometimes it takes a day. Yes, there is rhyme or reason to it, probably more rhyme than reason. So library packages will tend to go through fairly quickly. One's where there's no complicated licensing stuff, will tend to go through pretty quickly. Stuff where the licensing is hard, like one file says it's licensed under this license and another one says it's licensed under the other license and they're not the same. Or when you're dead in copyright, notice says these are the licenses and the C files disagree. All of those will cause either ejections or delays. I wouldn't have thought there was anything, so there's a freeze on at the moment that causes delays. Stuff gets prioritized within the new queue, so if something's needed to fix an RC bug, then that'll tend to go through quicker. As far as I know, it's going reasonably well at the moment, so I would have thought anything that was over a cup. When did the free start start of December or November? Yeah, so anything that's more than two and a half months or so, that probably means that there was something really odd about the packaging. It might be that the license is really clear, but it's not clear if that's actually open source or not because it's some funny one, or there might be some patent stuff about it. So new checks of when things get thoroughly reviewed by a third party, basically. So the FTP masters check the licenses and check the packaging, it's not completely crap. And if it's clearly crap, then that's easy, it just gets rejected. If it's clearly fine, that's easy, it gets accepted, but if it's somewhere in the middle, then it gets left in the queue to make a decision. I guess there's not much visibility from your point of view unless you email someone about it and you just get to see it. It's in the queue and how long. That's all the information you have. Yeah, you can ask the FTP masters what's going on. I think they usually actually ping the maintainer who uploaded it if there's questions or whatever, but if they don't, then yeah, you should definitely ping them. It's the people watching from the sidelines who don't have any idea what's going on. Okay, thanks. Yeah, because often they will, you get a lot of information when they reject your upload because then it'll come with like it failed these checks and you need to fix this licensing thing or whatever. Yeah, you don't have a lot of feedback while it's weighing in the queue. My experience is it hasn't taken that long recently. A couple of years ago, it used to take like a month or two or sometimes more to get something through because the FTP master team was not very many people, but now they have FTP assistants that help out reviewing these things. I guess one thing I'll just say is that I went through the demon maintainer process and it was incredibly painless. So if you are thinking about trying to upload, have a package that you would like to get into the event, don't be scared of it. It really is pretty straightforward. My sponsor, who's this guy here, did come back with some feedback on my packaging, but it was all pretty trivial stuff to fix up. So yeah, don't be afraid of it. I certainly recommend it and I said as a step towards becoming a DD, which I will do at some point in time. Yeah, and in fact you don't have to, if you want to get involved with Debian, you don't actually have to apply for any of these official titles. If you want to just maintain a package in Debian, there's lots of people to do that. There's a bunch of upstream developers that happen to use Debian and they want to package their own software in Debian. They want to be responsible for it because it's easier. They get all the bug reports themselves and they can fix it and they have no interest in packaging anything else, but they're quite happy. I've got a sponsor, a couple of those upstream developers, they package their own stuff in Debian. They're quite happy doing all of the packaging work for their own stuff. They have no intention of ever becoming a Debian, a DM, a Debian maintainer or DD, but they get a really easy way to get into Debian. You just need to find someone like a Debian developer who's willing to sponsor your uploads. If you're not familiar with what sponsored uploads mean, it basically means that you do all the work of actually doing the packaging and then you find a Debian developer to upload it and they get all the credit. The other thing to point out is that we're also talking about getting packages in Debian. Debian isn't all about packaging and the packages that are in there. You can also get involved with things like documentation, triaging the bug system. There's huge amounts of other areas of work that Debian needs to have done that people can do within it. That if packaging or maintaining software isn't your thing, then that's not the only way to get involved. There's probably a major load of other tasks that could be done by people that people definitely want help on. For example, if you're really into licensing stuff, then I'm sure something that Robert Collins would be really into, but you can volunteer to be an FDP Master Assistant or something like that to do these checks and help reduce the new queue. If you're into other things, then you can find different teams within Debian that you can contribute to. Some people get started with something that AJ mentioned earlier, the little packaging teams on Aliath where you don't have to have access to the archive. You don't have to be a DD, you don't have to be a DM. All you need to do is to be interested in, say, Perl packages or Python packages in Debian, and then you'll get access to a Git repo where the work is done and you can contribute to that. There's a mailing list, and then some people will move from there to becoming Debian maintainers or not sometimes they just care about the quality of CPAN modules in Debian, so it's an easy way to get started. Are there any other questions about any of this kind of stuff or even other generic questions around Debian that people got? I guess I have a question. Has anybody ever run into problems? Has anybody wanted to get involved in Debian and run into problems where they hit a roadblock, they couldn't find a sponsor for their package or anything like that? Only from the perspective of reading what's involved and basically just getting scared off at the pass. So what in particular was scary? Honestly, it was the time commitment involved in getting involved in Debian beyond... So I'm far more in the camp of there's a few things I care about, but I don't really want to commit to the Debian political sphere. So when I looked at what was involved, it seemed to be take two years of your life and deposit your soul here, sort of process, and it just looked like far too much work, to be perfectly honest. I think that's what Ajay was talking about when you said you have to get your key signed by 50DDs and then work five years and do a couple of recite policy backwards. I think if you think of being in Debian as being a Debian developer, if you have never done any Debian work and you want to be a DD, there's a few intermediate steps, but being involved in Debian is not necessarily about being a Debian developer. That's if you really care about a project and you want to increase your involvement, that's not the way that people first get involved in Debian. If you're using Debian on your machines and you run to bugs, submitting a bug in the first place is extremely helpful because, especially if you have a workaround or something like that, but even if you don't, just exposing a bug is really useful. Then the next level up is kind of fixing it, submitting a patch. Then you can get involved and do sort of little drive-by contributions by doing a non-maintainer upload. You need to find a sponsor, but if you find a package that's not being maintained very well in Debian, you can fix some bugs that way and that doesn't mean you have to take over the maintenance of the package. It just means that you're doing this one upload to fix a bug and that's really useful. I fixed a couple, for example, in the Jesse release cycle. I've done a couple of NMUs to clean up a few things before the release to make sure that Jesse... those packages actually work in Jesse. Then you have other things where you can be a co-maintainer for a package, so that means that you're not the only one responsible for a package. You can help out the other maintainer. So there's lots of ways to get involved in sort of small doses. And also the other thing is if you take over a package that almost never gets updated, I've got a couple where, well, I've got my GeoCities one where obviously the upstream is pretty much dead because the GeoCities doesn't exist anymore. So that never gets any new update, new upstream versions. All I have to do to keep that package in Debian is to fix the occasional bug, but the code doesn't change, so there's not that many bugs that get reported. And just keep up the packaging stuff. So I can probably do one upload every year to that package. There's a very low maintenance, and that's under the primary maintainer, the only maintainer for that package. So the amount of work that you do on a package varies immensely from one to the other, even when you're the maintainer. So that list of things up there to become a Debian maintainer or up there, whichever, are you able to do all those this week if you're still interested? Because, I mean, that's the sort of time frame that should take. Some people can take much longer, I don't know, Eric or Tom Marble might be watching this on the video once it's up, but they can take years just getting those steps done just because they're lazy basically, but it really shouldn't take any time. There was another question up there, while there's another question over the side now. We have time for one last question, then it's lunchtime. It was just about you're asking for friction points, and one friction point I have is just the documentation on the Debian website, and I understand documentation's hard, but there's a lot of orphan pages, there's a lot of how-to guides that are missing the juicy bit of detail. They'll have the very overview, but they won't have the steps where you actually need help. It's just something I wanted to highlight, an issue I have is trying to find my way through the Debian website to find that bit of information. Like the other day, I tried to find where to download the Jesse Bieder installer, and it took me through like seven or eight pages, and I ended up going to a seat to the archive and chopping off bits to find out that, so... It's a recent thing, and for every man that's probably able to do it, they will be able to have the relevant information. Fair enough. But there's a lot of orphaned documentation I find, or on the website, but the mailing list might be a better way of doing it. I'm just used to googling for stuff, so hence I'm more a browser help finder. I just want to point that out as a point of friction, and I understand documentation's hard. Yeah, I mean, I have the same point of friction, like finding stuff on the wiki that thoroughly documents what I'm interested in is hard. The other thing as well is, like on the wiki, is finding some of that information there, maybe out of date as well. So you do have to sort out, you know, some of the way from the chef. I find searching for stuff using your favorite search engine is usually a pretty good way. I typically find the information. You may have to sort through a few different hits to get what you actually need, but I tend to find it to be pretty good. But yes, digging out some of the obscure commands or how to do that particular thing you need to do in your package can be tricky. I don't know, at this point, there's been a couple of times where someone started on an engine that's completely inside too, and it's a long time, so I don't think you get to the level of the data and start to be done. Yeah. To be important. Well, a lot of that stuff's on a wiki, so once you actually do search the mailing list and find the answer, you put the answer in the to be done part, right? Plus one. OK, lunchtime. We're now out of time. Thank you, my fellow panellists, for assisting with this. Lunchtime, we'll be back here at 20 past one. Thanks guys.