 Okay, well small turn out today, but I've got the big room. So that's good Couple of familiar faces Jonathan, I think from Academy last year who might have seen some of these slides But I'll try and make a little bit more Debian specific rather than KDE specific and Potentially KDE is still a bit of a dirty word in Debian although. I thought we'd got over that a few years ago But we'll see how we go Little bit about myself. I've been using Debian for 10 probably 12 years I've been a Debian developer since since 2000 And and I guess I've been doing a number of roles within within Debian On the package maintenance side I've worked in a couple of teams and my teams are up there on the screen But I've also worked as a sort of a singleton package maintainer and still maintain a couple of single packages So really what this talk is about today is is what's team maintenance about? What are some of the issues I've seen with team maintenance? What are some of the issues that Debian's going through when we go to this new model of team maintenance? And I'll try and sort of pull out some of the things that I like and some of the things that are working really well some of the things that aren't working very well at all and and and try and pull out some some some case studies if I can Using some bits and pieces. So I'll go through go through my the portfolio of packages that I look after as it were The KDE extras team is is really sort of an adjunct to the the main Debian QT KDE maintainers and We look after the other packages not the core packages think I've lost the microphone Not the core packages So KDE base KD network all of those that the extras team don't look after that We tend to look after a whole bunch of Singleton applications, but but we try and do that in a common framework. There are some other KDE applications Amarok works sort of outside the Allioff teams And then some other packages like Gwendu are just just maintained by Singleton package maintainers and and I guess We're all adopting a slightly different approaches and I think Martin talked this morning about how You can get a whole bunch of different channels or different teams working in different ways Trying to deliver the same thing which I guess is a coherent set of Debian packages Popcorn and and these are the packages which which we're currently looking after in the KDE extras team Updated this slide from Academy and and the popcorn numbers have sort of jumped by two or three In sometimes five from from where they were six months ago So it's a huge increase. I guess for the for the KDE extras I really draw the line at about the thousand mark Anything below a thousand is really sort of a bunch of niche users But what I gained from this are the actual numbers aren't that important what I gained from this is the sort of relativities People really want media players people really want Sort of digital photo management and those sorts of things Some of the other bits and pieces down the bottom things like Strigi Is going to be a big part of KDE for It's going to be really integral to the desktop But as you can see very low adoption rates at the moment because I guess people don't realize its potential and people don't know What it's gonna what it's going to do for them By comparison one of the other teams I work with is the the VoIP team And you can see up there the Speaks codec and libraries 40,000 libc's got 46,000 So for some reason everyone's got speak on their on their on their machines Down to port audio pwlib and opal which are really the sort of the h323 stuff up in the sort of the 28 30,000 And and you can see in comparison to the the KDE extras where where we think 3000 for popcorn is a good number in one of the other teams I'm dealing with 40,000 is a good number and and I guess it does land itself to a different style Of maintenance and a different style of package maintenance you get something wrong with Speaks and You're going to get 40,000 people turning around and being very upset if we get something wrong with with caffeine or something like that The the user community are going to be a little bit smaller, but not necessarily less vocal These are the members of the team Well, some of the members of the team I went back through the commit logs for the last two months and anybody who had done a commit for the last two months Has got their name up there and is and is over there in the corner I think I met Mario the other night at the key signing and he joined the team as of yesterday, I think so There's there's a few people anyone else is not up there if I left your name off just yell But the the team is quite interesting and and and I'll talk about it when I go through the individual packages Because not everyone up there is is a developed Debian developer And some of them are upstream some of them are just people who work with Ubuntu And and I guess the bulk of them are Debian developers and that actually I think adds to the strength of the packaging and ensures that We do have consistent set of packages And we're not just sort of Debian totally Debian focused We are getting inputs from other ways and other areas and where we are working with upstream or we're working with Ubuntu I think we get a better product as a result We've got a read me in the top of a SVN tree and and really that's trying to document some ways of working and and the way that we think that the KDE Extras team should be working as a team It's interesting sort of comparing some of the different teams that I work in how The ways of working with individual teams are completely different in the package Allegro team Which I work with everybody just looks after their own packages We aren't really a team In fact, the only thing we've got in common is we use a common SVN area In the KDE Extras team, but we have tried to document a common way of contacts a common set of IRC channels a common set of mailing lists We have tried to adopt a commons SVN layout and that's that's been working reasonably well a Common way of working through SVN build package and commits and I'll admit When I first transferred across to two sort of alley off and trying to use things like SVN build package It was a complete nut a nightmare It's not intuitive There wasn't a lot of documentation around at the time and it really took a fair bit of effort to work out what's going on How are you supposed to edit patches? When you're not working in an export tree and all sorts of stuff like that and and it was a real effort to Transfer over but I think once once the efforts has been made and we've all transferred over to a common way of working The benefits and the strengths of team working have really come out and we can have more than one person working on On the same package at the same time, which is really good however And it came up in the security discussion a couple of days ago team maintenance isn't isn't the answer to all ills Certainly we get a lot of security security bug reports and and CVs from the security team mainly on the on the vibe side and The you'd think that being in a team with with 10 or 20 people in the team that everybody would jump to and and fix the Issues straight away, but that's not really what happens. It's really that the specialists Who are jump in? Versioning what we use a special distribution Called unreleased and and I'll talk a little bit about that in a moment But what we've one of the things we've got set up is a thing called bill server net Which is a bunch of bill days, but it builds our current SVN archive across both the the Debian The Debian releases and and the Ubuntu releases and and that's actually been really quite powerful for both Uncovering bugs, but also being able to provide different versions of packages So people who want back ported packages or want packages from from other distributions can do it and and finally We've got a mechanism in there for some some automatic back port hooks So we've got a directory layout and and the the the package maintainer can stick in the package If they want to make changes to build the pens to take account different distributions, they can do that build server net I think this is this is a Good way to go and and I think this could potentially be picked up across the entirety of Debian It's not really a special thing for the Katie extras didn't actually come from Katie extras killing crouse is is part of the Package VoIP team. He is a Debian maintainer and he basically built a build D Which which builds both Debian and and Ubuntu packages from the same SVN archive The the package I guess the releases up there are a little bit dated on both the Debian and and the Ubuntu sides But that's that's currently where we're at We need he needs to go in and update to pull Lenny and gutsy and all those other bits and pieces But the concepts really good and and I think the concepts quite sound and I think it's somewhere that Debian as I said Debian does need to look at going for forward with Because what the what this build server does is that it takes the Debian directory from a from a SVN archive We've we've got a Debian rule script To pull the upstream source now that might be either pulling the upstream source directly Through some some scripts or I might just go to the Debian archive and pull the the latest version of the Debian Dot all dot G zip And then it goes away and and and does its magic does its build D magic and and produces the binaries and as you can See down there sticks it in an archive in a format Which is suitable to stick in your app sources line and a lot of people from from various bits and pieces Drop us drop us email and the like and say yep We've pulled this package or we've pulled this package and effectively what these build these do is for every SVN commit We make it will generate a new set of packages Provided the dependencies can be met and and there aren't build packages I think it runs on about a six-hourly cycle. So it isn't actually picking up every single commit sort of every every commit over over six hours and quite powerful and Here's here's one of the example outputs This is the DigiCam package a little bit dated. This is this is building 8.2, but you can see up there It's it's it's in sort of a standard build D layout With sort of installed and needs build and and building or failed Fails on Sarge because it can't meet some of some of the Don't know why it fails on Sarge But that's a sort of interface you get and and we can we can dig up into those logs and actually have a have a good look At what's going on? I'll just jump into some of the applications now and pull out some of the application specific issues Which we've seen in building the packages caffeine you saw was at the top of the list in terms of popcorn and That that that we did have some issues with the documentation because it came under the free documentation license But but Debian was happy and and we could consider them D. DFSG DFSG Because it didn't contain any unmodifiable parts. So we've we've been able to pull that across Great for digital TV. I've been using it since I've been here in Edinburgh great digital TV in Edinburgh K media player or KM player was originally only available through Christian Murlats Debian multimedia archive because it did use the non-free M player and KM player has has been moved along a bit and it it's now able to use both G streamer and Zine Which we do have Debian. So we were able to package this up and and stick it in the Debian archive Digicam Really good photo management works probably equally as well outside of KDE as it does in inside KDE And and we've had some real success here Tom Tom Albez Who's one of the upstreams from the from the Digicam project? He's also got a few other projects He regularly commits and H&B on it does some Ubuntu packages and some other stuff for us Neither of which are Debian developers. So that's really good We've got 0.9.2 Actually uploaded the final in in experimental due to some library dependencies and library transitions which are going through And and the only comment as it says down there is is what's happening with Digicam is upstream Are spinning off a whole bunch of libraries? Lib K decraw Lib K Xov2 and Lib K exif and I guess the state and the maturity of of the library development isn't quite there and We are having issues and and almost education issues with okay Well, we'd like to get version symbols in the libraries We'd like to make so not so name changes that add sensible points rather than every release of the application and and I think binary distributions like Debian and like Ubuntu probably see the impact of of of I guess immature Library maintenance ship more than than people who are just building things from source because we really do depend on it But but through guys like Tom and HM We've been working fairly successfully with upstream and and we're getting those libraries into into a reasonable sort of state Kyle Again the documentation with Kyle is under the FDL But but we didn't really have any issues because it doesn't contain any invariant sections So we we we've got that in the archive KPI plug-ins again, we've got Tom Albez from upstream who's working with us and and regularly commits We've been pulling patches from upstream in into ours It does use some non-free components like MJ pegged tools Which is a bit of a concern because we obviously don't ship it But but Derby and multimedia do But and the other good thing about KPI plug-ins is it works across a whole bunch of KDA applications not just to be Digi cam twinkle It's a voice over IP package, but we maintain it in the in the KDA extras team. I think maybe not There have been a few issues with it that there was a an audio codec called ILBC internet low bandwidth codec And and what upstream and twinkle had done is they'd taken this this this ILBC library And included the source verbatim in the twinkle library in the in the twinkle code And also doing a bit of a code audit across some of the other packages we had in in in the VoIP archive asterix also included a copy of the ILBC source code and Open H3 2 3 included a copy of the ILBC source code as well as a few others Problem with that is is the ILC be source code isn't is non-free There's all sorts of distribution issues with it It's got a really bizarre license We have to notify them whenever you want to use it or whenever you want to change it Which obviously fails the Debbie and free software guidelines. We worked quite well with twinkle and Got ILC be removed And and he now has a build time option Where if people do wish to use ILBC? Then he's provided our upstream for twinkle have provided a build time option where if you have the ILC be libraries installed on your system You twinkle will recognize that but that that was quite a good case. We're working with upstream. We are we we we got a Good result Works well with the KDE address book But we also like to have a non KDE dependent variant in the Debbie and archive We're currently building this with CDBS Ideally, I'd like to be able to just sort of run CDBS twice on the on the package once with the with the address book integration in the configuration flag in a second time without The address book dependencies in the configuration and spit out two packages Can't find a really straightforward way of doing this at the moment Happy happy to take suggestions Coding another media player. I quite like this. It has a very slick interface as you can see up there Not a whole bunch of buttons and toolbars and all that sort of stuff fairly small footprint We have re-badge this or we repackage this as a dot-death SG package and that's because it has a really bizarre redundant FDL doctor that doesn't have anything in it, but we can't ship that one directory with the one file in it So we stripped that one file with that single file out and and then we can ship it in Deb Debian quite well KIAX is a is another VoIP User interface it only supports the IAX protocol. It doesn't support SIP So its uses us fairly specialized asterisk does support IAX and a few Commercial VoIP providers provide IAX Again, this ILBC library was was embedded in here So so we stripped it out repackaged the upstream table made it DF SG and George Danshov from Was he from Bulgaria did the original packaging He's not a Debian maintainer, but he needed the Debian packages. So we worked with him He's a he's a member of our alley-off team. So he has commit rights And and works with us to to keep this package up to date So I'll just do a little bit of a talk about Debian QA This is not a dissimilar slide to what I put up at a cabinet Academy last year I know there's been a little bit of a flame fest about who's in front and who's upstream a bantu or ourselves So for the packages we've been talking about I've done a little bit of a comparison And really there's not much in it at all people are pretty neck and neck The two reds up there Km player and Digi cam. I think guts guts is sort of one release behind But I'll give you an example asterix the top line up there that one point four point five release I did while I was up here at deb comp and you can see guts is already got one point four point five One a bantu one so so the the bantu guys are pretty quick off the mark and and pulling things across The changes in yellow Really just sort of minor. I guess point releases That does seem to be a little bit of reformatting in terms of change logs and and and a bunch you are adding in some really minor sort of control file Upstream maintainer lines or something like that So it sort of seems as if each one's going to have a new sort of a bantu version on it Even if there isn't any substantive change to the source. I don't know if anyone else has experienced that I'm talking a little bit about Debbie and quality assurance. I presume everybody's seen this page From my perspective, well, probably not that Katie extras team But probably the this pack page for packages. You're interested in or packages you look after I Really find this and I think the team finds this quite invaluable because it really is a good switchboard It has access and links out to most of the places where you want to go links to the BTS Links to the package tracking system Links to excuses and build the repositories and things like this and I'd certainly say on a sort of a daily basis So I use the this this QA page to check up on the status of packages Work out what the to-do list is and and and try and sort of work out where where where the effort needs to be placed Having the popcorn line in there Is quite useful because that helps focus the priorities as to which are high priorities and and which aren't high priorities So so I think from an infrastructure perspective. This is this is a fantastic resource that The Debbie and does provide One of the things I would like to see in here is perhaps a little bit better integration with with with the bantu for example I mean you go into the package tracking system and you can get all the a bantu packages for the relevant package I don't see any reason why the the the version fields here She couldn't be tracking both bantu versions and and Debian versions because sometimes there are patches in in one or the other That that are relevant and and and quite useful Just a little bit about the bug tracking system and and synchronization with the the KDE bug tracking system And really what I'm talking about is the BTS link facility and you can see up there a few of our bugs are sort of forwarded upstream to to the relevant KDE bug number or bug report and Like if you look at the second one down caffeine you can see there. It's confirmed. It's been tagged as fixed upstream And it's it's been tagged as upstream and and what the BTS link function does is it actually goes and has a look at Upstream links and when the upstream Actually changed the bug status of the upstream bug status to fix That then comes back and provides a user tag and into the Debian BTS So we get an indication that that the bug has been fixed upstream and and potentially we can we can pull forward that change that particular bug is actually a Zine bug so we need to move that bug across design The system doesn't work as perfectly as it always should because if upstream marks a bug is invalid or resolved Because it's outside of their scope. It'll just appear in the BTS as being fixed even if it isn't fixed So we've had some issues where? Bugs haven't been resolved as easily as they could Little bit of discussion about the interaction with the KDE and the the Ubuntu developers I think and and the couple of examples I've used so far where we are working closely with upstream or working closely with with the Ubuntu teams I think have yielded real results and real dividends But but I am a little bit disappointed that that the Ubuntu guys when they make passive patches All I've got to do is throw a line into the BTS into our BTS and say hey, we've made these patches Would you consider them? Would you would you think about applying them? I have on the odd occasion? received patches from Ubuntu, but but it has really been quite a rare event and I think there could be a lot more work done Because at the end of the day we're all trying to package up fundamentally the same set of software in Fundamentally the same the same format With the KDE integration, I think that's working really well We've we've got the synchronization with the with the BTS and we use that a fair bit And we are engaged with with the sort of upstream developers and and where we are engaged I think it I think it has real benefits for both parties the upstream developers get access to real live users real-life problems That that can only come about through a binary package distribution I guess traditionally your average user of a binary package distribution is going to have a lower Knowledge threshold than than your average user of a who goes out and rolls their own so it is a different a different community and Finally my little advert advertisement I I really think that the way we're using SVN.debian.org and Building the packages straight out of it in to build servers great I think it has real potential for just having one one source and one one version of the truth Rather than a little archive over here and a little archive over there and and and nobody really knows Where where where they're going and and what's what's the what's the true authoritative source? Anyone can have an account on alioff And I guess the guys most people here probably do so I'm probably preaching to the converted But but again a bit of a advertisement for the KDE extras team To try and get some people some other people. We've got some interests other Ubuntu users or Upstream or whoever else come come and talk to us and and and if you can I say if you can spell SVN and Debian rules a bit tongue-in-cheek But yeah, I think it's it's quite useful and it's quite easy if people know what they're talking about Then then we're probably quite happy to give them access So that's all I have to say. I guess I've galloped through it. I haven't been any questions throughout So I'll open the floor if anyone does have any questions or any observations I guess the the other thing I should mention is we've got a boff on When's the ball banner Saturday? No, it can't be nine nine fifty ten. Yeah, something like that 930 I won't actually be there. I'm heading off tomorrow but some of the the KDE courting gonna be there and Have a little bit more of a cozy Discussion rather than sort of standing up here and talking. Anyway, you have a question. Hi I'm just wondering what sort of packages you want to take up and into your TV Are you just pretty much taking up everything that looks like KDE or are you strictly limiting yourself to what? Upstream KDE has in their extras Yeah, no, it's not it's not focused on just what upstream KDE considers to be their extras Although there is a upstream KDE extras archive. I guess Really what we've tried to do with this is just sort of have a common area on a common way of working Where people are building KDE or? acute Dependent packages because I guess there are similarities in how we interface with libraries and all that sort of stuff But yeah, if you think you might be vaguely interested or Fall into the sort of areas that we're working. I could unload a couple packages onto you know, I don't but I'm a sort of listen to you online downstairs. I might have sort of missed it, but what sort of Assurances, do you think you'll have that? You know, it's not just like another Java team where like people are just maintaining their own packages and having a big mailing list together And it's really not a team anymore at the end Because ultimately I can't see like every developer being interested in all these packages No, no, and I think that's a that's a fair call to I don't think every developer is interested in in every package But where there is a common repository I think sort of dropping packages through or offening packages or just dropping them through the QA team because The current maintainer doesn't want to to maintain them something like the KDE extras team is Could be quite a useful staging ground. I guess there are a few of us who are specifically interested in a few of the packages in there But if if sort of other packages rather than dropping through to the QA team and and being often are looking for a home And are going to be relatively straightforward to maintain And if they are KDE packages them Fundamentally, we should understand sort of how they work and and how the how the build cycle works Then then that could actually be quite a useful team or quite a useful place to Drop them into I guess one of the things that we are going to be seeing over the little next little while Is there will be some packages transitioning? This is this is upstream with KDE There will be some packages or some applications transitioning from sort of standalone applications into into the KDE core Strigging for example, I think is going to be one that's definitely going to come out with with with KDE 4. Is that true? Yep and Digicam there's been a lot of talk upstream about whether Digicam should move into The the the graphics archive and I think the Digicam guys have decided to keep themselves on a separate release cycle But I could envisage where packages might move into the into the KDE core might move out of the KDE core I guess it sort of depends on popularity more than anything else And that's sort of the other issue that came to my mind Why didn't you why did you think you had to make a one KDE extras team and not just sort of use the KDE Team as it is Well, we are actually sort of a we are almost a sub team within within that within the KDE team We actually use the KDE team SVN archive and and we have our own our own Branch off to one side within that But we do have our own mailing lists and and really I guess okay, so it's that you actually the same Group on Ali off to just sort of a yeah With the same group on Ali off, but we do have two different mailing lists Okay, I see and there are some people who are more active in the in the KDE core team Right, and there are more there are some people like myself for example I'm more active in the KDE extras team and and I really have little engagement with the The KDE core team Hello Your your comments about Ubuntu are Not unfair at all that Pretty accurate. I suspect I I I make Ubuntu for anybody who doesn't know and although I try to Send patches upstream and not Firstly, I sometimes forget about it just because I'm a bit useless that way and Secondly, I'm not quite sure what the best format is for sending patches upstream And as for well having a different general Obviously the whole of Ubuntu is interested in having a smaller diff as possible from from Debian and in every way most of those are caused by Us packaging things slightly before or at exactly the same time as Debian and It's kind of hard to avoid that for example with Amarok I don't know is Amarok done by your team. No Amaroks and I did have the Amarok up as an earlier one It's not maintained by the core Debian KDE team and it's not maintained by the KDE extras team and and there is part of a Yeah, but it is maintained by KDE people, but I think it's using bizarre on on people.debian.org account and And I mean the whole point and and it's been I guess a bit of a recurring theme through DevConf is is We've got a whole bunch of teams and all the teams are using slightly different methods of Achieving the same thing and I think that's one of the things I really admire about Ubuntu is is because it has been set up Sort of mid-cycle and hasn't grown up over the 10 or 15 years that Debian's grown up Yeah, Ubuntu has been able to sort of implement a standard process and a standard workflow across across across the the team So our yes that example of Amarok I just uploaded it from downstairs, but Because it's just been released probably why you've been talking and it's hard to be able to coordinate that with Debian because We both well in Ubuntu. We certainly want to be the first with every package that's a bit out and Debian packages may or may not want to do that, but it's hard to coordinate things while you're both Racing towards the same deadline of it's going to be released in this hour and we want to have packages available for this hour And a lot of the the disc the smaller this the packages He said the Ubuntu packages have a very tiny diff what often causes that is we need a patch for Rosetta support, which is the web translation thingy on launchpad And that means a small patch for every kitty package There's probably a number of packages that if that patch was taken upstream by Debian wouldn't have to have any diff at all anymore But I'm very reluctant to say to Debian Please take this Ubuntu specific patch because I think You know I'd word that would there would be a backlash if I started sending up patches Requesting Debian to take patches which are only for us That particular case would actually not exist if those packages were using CDBS, right? Which I understand was to It's a patch to the code so it To the source code of the of the KDE package. Oh, it's oh, it's actually in the source code Okay, then I must be confused now with the language pack support. I think that was another one. Okay. That's different. Okay, then Yeah, one of the things that I guess possibly Debian and Ubuntu could explore would be to have a common Repository common version control system for where we both keep Debian directories and if we want to create an Ubuntu branch and a Debian branch I mean, do you think that would that would be workable if I mean if if say you and I know the Ubuntu models a bit different because You're not necessarily the one person who's uploading Amarok, but if you had to commit rights to the the Debian Amarok Archive and then you could work together as an Ubuntu and a Debian team And if one releases ahead of the other you could branch your fork But then merge back at that at the end of the process seems to be what would be useful. I don't yeah That's possible. There's a couple of issues with that mostly in the in Ubuntu in general we only like to use BZR and Me in specific because I'm an employee of canonical. I can and they use BZR because Cononical puts a lot of money into that and if I go around using other revision control systems, then they get very upset And also subversion isn't very good at doing branching and merging stuff So I would be reluctant to do any of the subversion just because it's not that good for it So if Debian moved to BZR and it's interesting that Amarok is in BZR. I didn't know that I'll take a look at that That that certainly becomes a lot easier Of course, I'm very reluctant to say to Debian that you must move to BZR just just for the sake of Ubuntu I think that might get quite a lot of backlash too. Yeah, the other patch that I don't really understand is like this one up here Where you change it from you change the maintainer to a sort of a maintainer and a What is it an XSBC original maintainer that is done because they've been requested for all Ubuntu packages So packages which are synced from Debian will have that automatically automatically done by our build demons But if there's any slight diff then we have to make that change manually Because they've been said can you please not have Okay, so so if there weren't the other the other little diffs that were in this package It wouldn't get that that would be my time of field change. Okay. Well, that would happen automatically And we also have a slightly different packaging style for build prep pack patches Debian puts in these large lib toolizing automate patches for For updating the kitty auto tools files into whatever Debian happens to be using And I just for simplicity On half of the packages don't tend to bother making those into patches and just have them directly in the dot diff dot gz And I must admit I find the whole build prep Voodoo that will go away and Katie for yeah really quite confusing and and and difficult to implement So, yeah, and what was the other similar thing? Oh, yes, Debian tends to take branch patches of the main KDE core packages which I Tend not to do just because if it does introduce bugs then KDE developers get annoyed that that we're not releasing standard KDE releases. I Mean, I mean, I know the cases where we've pulled bugs for above we've pulled patches from upstream It has been to fix specific bugs And I guess there is always the issue that that whilst it's fixed one bug it may reintroduce something I don't know if the core KDE team pull many much from upstream Call Katie tends to just do a whole branch book further For uploading KDE packages. Yes sure We can talk about it on Saturday more anyway Okay, well, we're at the five-minute window. So if there are any further questions that might be time to close up Thank you for coming along