 Okay, so we're going to talk about Modzilla and OpenOffice, and I guess most of the problems we have with them is something that anybody with big packages like that are going to have. So we're going to introduce these packages slightly, how we got involved in them. So for example, for the Modzilla package, my first contact was actually six years ago. And at the time, I didn't really want to package these things. I didn't even get involved in Debian for that. But at the very beginning, I was packaging extensions for Modzilla at the time, and then there was Firebird getting in, and we had to get the extensions working in Firebird, and it was mixing some support, so I sent a patch. And well, you know, now I am maintaining all these things, or maybe not, because basically I often, the package is in March, but it's a big fail because I did some uploads. So Modzilla in Debian is basically all these things, and I already simplified a lot because that's what is maintained by the team. Well, we are free. I'm doing most of the stuff. So this is all the Modzilla stuff. We have libraries here. We have iSAPE and iSDOV, which are the Modzilla suite and the mailer. iSweasel, which is Firefox, basically, and ZooRunner, which is a kind of framework to make applications like iSweasel. We would hope that iSAPE and iSDOV would be built on top of ZooRunner so that the security support would be better, but it's not possible. And all these are all using the Modzilla framework in some ways. So applications like Epiphany are using the unbending API to get a web view in the window. So you have Epiphany, Galleon, LifeArea, this kind of stuff. There are another category which are actually doing only like a binding for this unbending API to certain languages such as Perl, Python, Mono, stuff like that, and a bunch of plugins. And unfortunately, since I'm basically the only one to do stuff, that's what we cannot do. So for example, the security support is not done in the Debian way, which would be like just putting the actual security patches, but upstream is actually doing like a big mix between security and, yeah, the feature changes and stuff like that. So we're basically packaging every new upstream version for stable, which is that's something we're doing normally in Debian, but, well, we cannot do much better. We don't really test widely the security releases while we should. We have a really big problem with the BTS. If you accumulate all the ice apes, ice doves, ice weasels, ice everything, and Zulwarner packages bugs, we have more than a thousand, well, 1200. We could and we should, but we can't do better integration within Debian, which would mean like having a plugin system, like if you have, if you go to a page where you don't have the plugin, you could get the plugin from APT, Ubuntu has something like that. We could port it, but, well, it's still something we still need time for that. And we really should package upstream better releases in experimental much earlier than we currently do, but I don't have the time for that. So, well, basically it's the status for Mozilla in Debian. So I leave, run A4. I'm going to briefly talk about how I got involved in this package. I've looked around in the archives and the first sign of me on some open office main list was in 2002 where I just tried to get the preliminary packages which were available at the time and get the German version build of it because I wanted it in German. And the build failed as you see there and, yeah, I asked for help. Okay. A few months later, I actually did my first small contribution where I wrote main pages and fixed some Linzians of permissions and so on. That's the first public sign I was in a ShaveShark entry where this graph is a bit greedy, but it should show what I, what I was aiming at. The packaging started with a three person team, Chris, Jan Hendrik, and me. Peter was out before I even joined and it's more or less frequent patches from other people, but people get busy and now it's a one-man team. Because Jan went busy with university, Chris went busy with his own company, and I'm left. Now I'm maintaining OpenOffice.org and libraries it accumulates to, it needs to run, including Java stuff because as many of you might know, OpenOffice.org is a big user of Java, made from Java libraries used for more or less important features. I actually am able to keep up, but really barely, and with immense work and even though I don't really use that package. So every few months needed for some presentation or at work for some stuff, but I don't regularly use it. I find the FH, I don't remember any more, I forgot to put it on the slide. There was some replies to it, but when people came to me and asked me, okay, can you please explain me how I start, I guess there's some pointers and then there were never, many of them were never seen again, probably because it's just got scared of the packaging, of the code, of the complexity. So what eases the stuff a bit is that we currently are having a repository which enables us to share patches or even packaging stuff, packaging concepts with other distributions. The most important one is, there's another guy with Susie. So if I am doing some adaptations to packaging for integration, Susie one can adapt it for their packages and vice versa, which in many cases simply helps because you don't have to re-identify. So that's the part where you get involved. So we're going to ask you what you think about these things. So how can we get more developers, Debian developers involved in these packages? How can we get more users involved because we actually need users to test the things? Because we cannot test everything. And what can we do to be more appealing? Because when you have a package which is more than a million lines of code, anybody would be scared and it's normal to be scared. But we both are the proof that you don't really need to know everything since the beginning because we just got involved like it was kind of random and we are now crawling in bugs. But actually at the beginning we were clueless. Yeah, please. Is this on? It is. Hello. Okay, I can give you a bit of feedback. I've contributed a little bit to the open office packaging briefly. Now I was getting paid for it. That's helped. But there's a really steep learning curve in contributing to the open office packaging. To give, I don't know if everyone knows quite, if you want to start fixing bugs on open office. At the moment I don't know if this is going to change or if it's still the case. But the ORO Build Tree is in SVN still. It's in Git right now, but it's still a separate checkout. Yeah, and the Debian branch is in BZR. And then so you need to check out the ORO Build Tree, check out the BZR tree, figure out and learn how those work. Building the thing takes on our machines, you know, on a sort of normal PC. Well, we needed to run it overnight. And a built source tree is about 15 gigabytes. Which gives you an idea of sort of the scale involved here. So it's a big project. In terms of actual, the packaging wasn't actually too complicated. I mean, that was understandable. Well, except the point that you need to understand the relationship between ORO Build and the whole of the system. Right, right. So currently you can't just take away, you have to unpack the tar wall, because it's a tar wall in tar wall system. So that should be changed sometime anyway, but it's currently is not possible. I mean, that would be a great thing to change. So really, if I could ask a question, it would be what can you reasonably expect? How do you want people to contribute? Is it fixing upstream bugs in open office? Personally, I don't really care, because fixing upstream bugs, of course, would be nice. What I currently do because of limited time is, at most times, I simply forward bugs upstream and wait until upstream fixes it or not. So that, of course, would be nice. It shouldn't mean that people shouldn't help or don't need to help with simplifying or improving the packaging or doing BTS. Because I'm quite sure there are many bugs in the BTS which are simply, which would simply be able to close if we had a deeper look. But I don't have time for this either. So I'm currently barely keeping up with new bug reports. There was one effort of the Okaplan where he did extraordinary work for closing really old bugs which don't apply anymore to the landing release. Currently, it's more or less helping you in every part. I'm not able to pinpoint one part. Basically, any help would be appreciated. Well, the problem is that I still find it difficult. Actually, one of the biggest problems I had was that any work by the time I'd actually managed to fix a problem, Rene had already committed it to VZR. That was for easy ones, but yeah. It's quite a bit of a problem because packaging stuff or whatever actually tries to be quite fast to fix the packaging bug. For absolute bugs, it's very different. I don't want to monopolize this. I would suggest that if you could get the open office job in fact, if you could perhaps get it all into Git and have a branch of the OO build Git repository, then that would make a immediate difference. I also thought of going away from the tabloid and tabloid thing sometime. The problem is that as long we are using OO build, which is using the tabloid in the tabloid system, we can easily switch. But of course, we could do the first step and put both trees into one Git and remember OO build in our repository. It would be the first step in that direction. Come on. No idea? Just to underline some of the stuff, there was an earlier bof yesterday, I think it was, that we were talking about this similar sort of problem, but specifically for bugs in large packages. One of the things that I've been hoping to do and was mentioned as well by other contributors is that we need to try to organize or set up a field that indicates which bugs require action. Because that's one of the problems right now is it makes it a little bit more difficult for people to get started. And so that's something that hopefully will be able to change. However, as far as getting more triagers involved in the process, that's something that, I mean, I don't really have a good idea yet on what to do. One of the things it was thought about was better documentation overall for what triagers should be doing. And it also may be better to see a little bit of documentation as to per package... Specifics... As to per package specific stuff that maintainers could do. So for example, especially for the big packages that have lots of bugs, to sort of clue triagers in, this is the sort of thing that you should be doing. These are the areas or the people that you can talk to, the coordinating channels and stuff like that. That's not immediately obvious to a brand new contributor. Especially one who, I mean, I'm sort of envisioning that most of the triagers that you're going to get, this is going to be their first time contributing to Debian. So they may not have any idea where the development channels are. So some place where they can be pointed to, to get started, you know, triaging bugs in the packages that they use, for example, would be helpful. So just some thoughts out there. And again, if there's something that anybody who maintains large packages or people who don't find that suboptimal in the BTS file wishlist bugs against Debian bugs. Speaking of the BTS, there's unfortunately one big problem with these big packages. When you have more than 500 bugs in one package, basically the users don't even look at the old bugs. So they report the same bugs again and again, and it adds up to the noise already. So it doesn't really help, but actually there's not much we can do about that. Yeah, so one of the things there that probably needs to be cleaned up is, there currently is a full tech search of the BTS that's actually fairly advanced. So if we ask the people put the error message or something in, especially for large packages, when they're reporting the bug in report bug, that may help with this issue slightly, because at least it'll have a chance of pulling up the right bug that theirs is a duplicate of. Because error messages are usually kind of unique, but at least something that's easy to search for. You have no clue what the actual problem is. Is there any way you could find dupes or bugs? So yeah, I mean if somebody tells me a good algorithm to run over a set of packages to point out possible dupes, and I'd be glad to look at implementing that for a set of bugs. But right now I don't have a good idea of how to do that besides, I mean looking at the difference in entropy between two reports or something silly like that. So yeah, I mean if you tell me a good way to do it, or give me pseudocode or something that actually works, then yeah, I'd consider figuring out how to group bugs in the package report output. Or maybe it might be a good idea to actually get more users involved to just hack a splash screen into an open office and firefox which actually tells people to help. Of course there will be something which will drop again when a stable release is coming, but why not simply add an additional, like, we really need help. Because in the RFH buck it's basically no one sees this kind of stuff. You actually need to get to a rather obscure place in the b... stuff. It's so working. And I don't think many people actually see this, maybe it's simply also in need of increasing visibility. I would suppose that at least half of all the Debian developers are not even aware that there's help needed for open office or all the whole ice weasel stuff. Because quite a lot of people aren't following like Planet Debian Orca or other means like the, for example, any mailing list where you've asked for help. So what are you proposing to do instead? Adding a splash screen to both ice weasel and open office that when you started that phone, so this package needs help. Please, please get in touch with us. Isn't that a bit intrusive? I mean, if I'm a user I would be bothered by it, even if it's a noble reason. If you have a splash screen anyway, you can just hack the sentence in. If you have no splash screen anyway, okay, it might be annoying. If you have one anyway, it shouldn't matter. Yeah, well, there's one on open office, there's not one in ice weasel. But you have a start page, so... Yeah, but people can change it. Oh, sure, but what you want to do is when the default starts up once and you tell them about it and if they change it immediately, well, you've done your best. I mean, you don't need to continuously nag them about it. Just tell them once and then hopefully they'll learn. That's a good idea. Not sure if it was already mentioned, but well, as you have many bugs, maybe you should try to put on the sides. There's a few ones that are easy to start with so that, well, people can get used to help you and not directly be confronted to difficult RC bugs. Well, so it's the same idea of the Debian love or whatever it was called. So you pick up a few bugs where people can help. You tag them with a user tag and you make some publicity around that URL so that they can start. It's something that can be generalized for all package. But well, we're never able to commit to it. I don't know what we can do to improve ourselves on that point, but nothing more. I'm not sure about users, but developers would probably see the package tracking system and I think the RFH does snap on that. But maybe also I think you can add static boxes in there. So maybe a link, you know, explicit sentence that we really do need help. It's not just this RFH and here's a link to some handy documentation about exactly how you go about getting involved. Because I think getting over that inertia is the problem. Well, if you have filed a request for help on the WNPP stuff, it automatically appears on the PTS with direct link to the bug report so you can read it, what they wrote and where they need help. So basically it's already done and I don't think it made a significant difference. The problem with that is that before you look at the PTS, when you look at the PTS of the package you are already interested, you are already wanting to at least have a look at the state of the packages. Some people might not know yet and if you don't look at the PTS, they won't see the RFH. Well, it's the people who are already interested who you want to actually get the last bit of the way. I mean, so I've looked at a lot of these RFH bugs and you see that firstly they're generally really old and people have already replied to it. So you don't really know whether it's up to date and there's no further information about, you know, or links to exactly where to start. And admittedly you might then see that there are 1,200 open bugs, but apart from that it's getting those sort of people that last step of the way that you want to look at, I think. So do you think it would be helpful if the request for help bug has already gotten some replies but no new maintainer came from it to close it and open a new one with the current information? Possibly. I mean, it sounds like a really stupid idea but if it's really stale then I think, you know, find some way of making it really up here, you know, now. Now we really do need someone now. One idea, Yard, is what really, it's the spirit of the demon love stuff, is to write some sort of history uplet for potential contributors who are interested to help but don't know really where to start. They could just pick up a few skills that they have, I mean in programming language or I don't know what language they do speak and everything that we might need to direct them somewhere to help. And then you could pick up tasks and we could, well, based on the list of packages that they have and the skills that they have, we could easily implement stuff like, well, create one bug a day or stuff like that, which has been quite popular in Ubuntu. They did several events like that, which was five bug a day for them, so it's an idea that I would like to explore, that's what most of my projects, I don't have enough time to do them all at the same point in time, but I don't know what others think of such an idea. It would be interesting maybe to use this opportunity to discuss it because I think it would be really interesting. I mean, at least we could, instead of promoting each sub-project separately, we could work together and promote only this applet and maybe have a broader impact and still be able to focus on a specific sub-project depending on the time because, well, we could organize a campaign while the applet would contact some Debian server and the Debian server would give hints. Okay, this week we want so many people looking at this package specifically and we can even assign bugs if possible. I mean, we have so many stuff to do that we can surely find some way to assign non-conflicting tasks to many people. Well, I don't know, if anyone wants to comment on the idea, does it sound really strange to you? I actually had a similar idea to have an application that would get a bug, like a bug a day or something like that, for people that opt-in to help. But I don't really know if it would work out. I'm not sure. Well, it's worth trying, but well, we also need time to do that. And we already lack time to do the other stuff, so it's actually very hard to begin to do something. I understand the concern, but you already have to keep up with the urgent stuff first, but any same maintenance requires some preparation, long-term preparation, so it might take time, but if we decide to each take one or two hours a week to prepass this, we might do it in a few months, even if a few RC bugs are fixed later. Well, no big deal if it really helps on the long-term. Can I ask how are you feeling about this talk? Are you feeling confident that you will get more developers and users involved at the moment? Well, I actually got some help. Somebody came to me, anybody introduced to me, somebody who would like to adopt Zoo Runner. So I actually thought at the beginning that the offering thing wouldn't work, and well, it appears it had worked. So maybe that's the solution, offering the big packages. My fear in this case was I was very to try it because I would have guessed that no one would have pictured it anyway. It might be untrue, but the size of the package scares so many people away at first. I don't know, for your question, I really hope that people here or people in the stream or in the video later will at least consider to help a bit, but you can't be sure in any case. Who's using Ice Whistle here? Okay, so who's using OpenOffice? So why aren't you helping? I mean, that's the point, isn't it? These two packages are actually huge, and they're also two of the flagship products for free software. And the quality of these packages really affects how users find Debian. So maybe there's some motivation there to actually get more involved. Exactly, right. Well, one of the sad things is that if you do the count, I actually ran a slope count yesterday on Zoo Runner. And if you remove all the stuff that is not really Mozilla stuff, it's more than two million lines of code. And, well, according to, there was a talk on the first day on Debian, and we have 300 million lines of code in Debian. So the ratio is quite huge, actually. And if you see that we're a thousand developers, the ratio is, well, it's kind of strange, actually, because you have these huge packages where you only have a really small amount of developers taking care of them. But, well, you know, I remember a couple of years ago that Sun Microsystems, as Simon felt, was actually claiming that, you know, Sun had contributed some huge proportion of Debian because in terms of lines of code, I think they'd done, I think it was mostly open office and huge amount, but they made quite a big deal about their contributions and Java. It's quite interesting, this remark, and it might, merging that with your other idea, saying that the solution is to keep the package orphaned, maybe it's true, maybe we should keep it on the list of orphaned packages until we have 10 developers for maintaining Mozilla, because, well, Mozilla is one person of the code base and we have 1,000 developers. Maybe, maybe, yeah. Because, well, it's true, if you see someone maintaining, oh, it's good, why should I look further? But if you really say, well, this package really needs five people or seven people to maintain an irregular basis, maybe we can find more. Can I ask about, I think the current WMPP bug that is all being orphaned was about these copyright statements. That's actually part of the reason. So it's actually more than that? Yeah, well, it was the trigger, because, well, I was pissed off by the discussion at the time, but it was something I was considering for quite a long time, and that just put me in the situation that I really wanted to do it, because before I couldn't, but, you know, if you get back here, you see, I orphaned the packages, but I did 14 uploads, and it's not even including Ice Whizzle, because I did some for Ice Whizzle, too. So, you know, I cannot stop doing it. I just care too much. Maybe I shouldn't, but... I mean, I think you both do great work for Demian. It's really useful, you know, necessary thing. But that may be the problem, actually. I mean, yeah, the problem is if you stop, then, yeah, we're kind of screwed. Maybe we should start to do bad stuff so that people would like to fix them. I really don't know how to arrange it with Demian, but the thing is, it's like you say, you should get more support from the community, because like appealing for users to get involved and help, that's important, but this is like a very long run solution, while you are drowning right now, and so the community should support you. And there's two things that came to my mind. One is like, Tim, you said you were paid for what you were doing. Perhaps that can help, say, for students who are involved in Demian, maybe they can be paid to do some work during the summer or something like that. But what I think should be arranged somehow is to have concentrated effort to clean up bugs that I understand is part of what really dragging you down and making it harder for you to make progress. And maybe decide on like a concentrated period of time that people would contribute to dealing with a certain package, cleaning it up. Sometimes it's not even fixing bugs as much as I understand, just checking if it's still relevant or stuff like this and make an operation kind of stuff of concentrated effort from developers who know something about the Debian tools and that. I don't really know how to advertise it and how to make it happening, but I think that's something that should be done by the community because especially these two packages are very important for Debian. Debian without it will be crippled. Sorry, I'm monopolizing this almost. Actually, that's a good point. In terms of getting users involved rather than developers, bug tree arching is the obvious first place for people to start. If you look at, well, the big place where I've seen this happen is in GNOME, actually, where they really encourage users to tree arch their huge collection of bugs, maybe using the confirm tag on bugs which have been tree arched and have a mass confirmation that all these bugs didn't exist, that could be helpful. If you advertise it with your blogs, and I know people who read Debian and appeal to users directly to start trying to reproduce these things, or tag them either confirmed or reproduced, but they're more informal. Because if I forward some bug, I just market it forward and be done with it. Sometimes I simply also, if I don't forward the bug, because it's packaging or whatever, I sometimes forgot the confirm tag here. So I have to be a bit more disciplinary to add a confirm to every bug here. Maybe we can get some help from Don there. I'll talk to you later about something, I think. Feel free to ask questions too in my talking about an hour or so. Well, thank you, everybody.