 Hello, welcome to the Debconf in Debian Boff with Holger Lampson, Gunnar Wolf, Stefano Zacheroli and Moura Ellen. It's working. Is it on? Okay, so welcome everybody. This Boff is essentially a debunking of last year's Boff, which was called Debconf versus Debian. And the question that we have been trying to clarify in the past year or so is the relationship among Debconf and Debian. And I think among me and the Debconf team, we essentially reached the agreement that essentially Debconf is Debian. So Debconf exists because of Debian. And so this all debate among being separate was just a mood debate that we don't want to push forward anymore. So during the past year, we have been working on, I think we have reached consensus on this point. So Debconf existed because of Debian. And we have been working, especially thanks to Moura on setting of clarifying what are the main goals of this conference. So we have reached an agreement on the primary and secondary goals of the conference, which you can see on this slide. So the primary goals of Debconf, the main reason for Debconf to exist is to enable face-to-face interactions among people who are working on Debian. Among the members of the Debian community. To provide talks and video for people who are working on Debian but cannot make it to Debian. And to provide time that we can use to work on Debian shoulder very near together and essentially a mega sprint that we can have in one week on Debconf and also in the remaining time during Debconf. These are the main goals for the existing of Debconf. And the secondary goals are essentially some sort of byproducts to actually motivate contributors. And as you all know, if you have attended some Debconf, the enthusiasm at the end of the conference is something which is very important for Debian. And also to motivate the local community. So Debconf has a kind of a dual role for the Debian community and also to the local community where their conference is actually run. And this essentially explains why we try to move Debconf around the world year after year. So we have an agreement on this. We think this is the reason why Debconf exists. And having said that clear, we needed to essentially do some work to better integrate the infrastructure and the process of Debconf into those of Debian to avoid duplicating work, duplicating infrastructure. And essentially avoiding that we spend time on user's duplication and actually are more effective in both running Debian and running Debconf. So what has happened in the past year is that we have clarified the relationship among Debconf and Debian in the sense of that we have essentially made a delegation, which is the only tool we have according to constitution to provide a formal relationship among the Debian project and something. And so we have delegated Olga, Moe and Gunnar as the Debconf chair, which are not the people who do all the work or the people who decide everything, but are the people who try to reach consensus with the Debconf team on how the conference is run. We have also worked a lot on the Debconf finances, deciding that Debconf budget is essentially a part of Debian budget. For making easier to handle money, we fork off essentially a sub-budget of Debian at the first time we need to make an expense for a given Debconf. During the period that sub-budget exists, the chairs are responsible for approving expenses and this kind of stuff so that I do not have to approve any single expense that is needed to run Debconf. And as soon as possible, after Debconf is over, we merge back the budget into Debian budget. So essentially the idea is that every year we have a tentative budget, we say Debconf is going to cost this amount of money, that budget is ideally approved by me as the DPL, forked off and managed by the Debconf chair and then merged back as soon as possible. By discussion with the Debian auditors, we will also have soon some sort of auditing of the Debconf budget by the Debian auditors so that they will be able to monitor what is going on as well as any other Debian initiative. And this is the part of the finance, do we want to add something? That the goal is to have a zero budget, zero income, zero loss over the years. It's fine if Debconf does a loss one year but on average it should zero out or give a little profit to Debian. Yeah, correct. So that's why if you've attended my talk on Debian money, I have essentially stated that Debian overall, Debconf is overall not something that Debian spend money on because on the average it's a multi-year cost. And even if we have only set this goal starting from this year, it is actually what has happened in the past. So if you look at the archives of the Debconf team, there is a very nice made by Richard Das which has done some archaeology on Debconf budgets and it has been exactly like this in the past. I don't remember three Debconf I think. And then we have already fixed various parts of the infrastructure overlap we used to have among Debconf and Debian. So the Debconf has been migrated to Alias. I don't remember when but sometime last year. Debconf 5, okay, thanks. We have essentially merged the Debconf press team in the Debian press team because it was not clear whether the Debconf press team was running or not. And so starting a few months ago I guess the press team of Debconf is the same press team of Debian. So this is all great I think but we still have some other aspect on which we want to work. And essentially we have some infrastructure overlap which still exists. We have a separate weekly for Debconf. We have a separate list server for Debconf. We have Debconf websites which are not handled by the SA. We have a separate instance of the authentication based on UDLDAP. We have different set of system administrator for Debconf. And we also have some administrative staff which is still separate. For instance we have Debconf org domain which are not owned by SPI. We have hardware which is not owned by SPI. And we have a separate team which does fundraising for Debconf while we probably want to have a general team, global team which does fundraising for Debian as well. So by discussion at this conference which we want to discuss with you and in the future on Debconf team, we have some set of proposals and open issues. So for what concerns weekly Debian org, weekly Debconf org, we think it should be merged in weekly Debian org on some sub pages slash Debconf or something. And that would require a step of conversion because Debconf wiki is media wiki while Debian wiki is moin. So there will need to be some conversion step but then all the pages can be moved to wiki Debian org. The list server, the list which we now have on Debconf can be moved to list Debian org except that there is some discussion on short-lived list which is something that historically lists must have had some issues with. So we need to talk with them before actually doing the move of all the lists. We haven't discussed it yet explicitly but we think that Debconf website should be moved to some DSA administered machine and managed by the Debconf team via some group. UDLDAP is something that I think is still open for discussion. So there is a need for Debconf team to actually be able to create account during the conference on the fly but that maybe can be managed by having some subtree in UDLDAP which is managed by Debconf team. And we have right now another system in special situation is not terribly clear. I think you know more about that than me but the idea is to start with enlarging the current team so that it's clear that the team is an expression of the Debconf team. And then there are some other issues like Debconf org we agree that should be moved to SPI, the domain. We haven't yet discussed hardware ownership and we haven't yet discussed also the idea of merging the Debian fundraising team into actually converting it into a general Debian fundraising team. Andrew? What's the rationalization behind the need to merge? What is the reason behind wanting to merge the Debconf wiki with the Debian wiki? Well in most of these parts the reason is that we don't want to be at the burden of maintaining the various services where we can maintain only one. The content is quite different to the content of the Debconf. For me it's mostly and foremost having the same wiki syntax. Whether you have two wiki instance or one is rather not the important part for me. Again it would reduce the problem a lot if the wiki maintainers would... I haven't asked them and I don't know whether they would be willing on it. If they would volunteer to maintain a Debconf wiki on the same machine using the same system that would basically also fix the problem. None of these really from my point of view are short term problems at all. It's more from my point of view it seems not that sensible to be creating a long term maintenance burden for each of these systems where we're requiring different admins, different people. Again things like we end up creating separate solutions to wiki spam for example in case of the wiki. Before we jump into discussion I have already finished essentially I just wanted to mention that the parts with the question marks are part in which there are still some discussion to be made. The parts without the question mark is stuff that is going to happen but it will happen sooner if you help. For instance the conversion of the wiki needs someone doing the work and what we would like to discuss with you in this buff is essentially well if you have a take on the issue that still need to be discussed we would like to hear your opinion but in particular also if there is other stuff that needs to be clarified and fixed with respect to the relationship among Debian and Debconf. Those are also not really hard requirements but things we see which are double... the work is doubled if there are reasons for the double work and if it's going well it doesn't have to happen right now there's things... there's lots of duplicate work in Debian which has reasons. So go ahead Andreas. So first of all I would like to thank you for doing that because I really think in the middle to long term we would just waste lots of time for doubling solutions. So I think it's a good thing to do for Debian as a whole. I know as the Holger said there might be places left where we say yes we duplicate the work because it's less effort than to do it some other way. Then there's of course a well spent effort but in other cases I just don't think we should double work just because there is Debconf in Debian. And so yes congratulations to that step. Thanks. I just wanted to mention I spoke with Pabs at lunch and he seems happy to work on the wiki conversion and merge. I'm sure he would appreciate other people working with him but yeah that does sound like something that he's up for working on. He's at the games ball right now. Thanks Pabs. Pabs for DPL. So about the websites you're mentioning moving them to DSA but this is not the important point about the websites. The important thing is the web thing. And you haven't said what you're going to do with it. If you're going to move it to the Debian webmasters team or... Personally I think the DSA is wrong there should be the web team. It is open issues to do less things we are thinking about. Something I wanted to say really to the website too is that I think it's great this kind of idea of merging stuff with Debian but what I'm worried about is that usually in Debconf so far there's many things that are a little more ad hoc or there's people working that are not yet part of Debian proper. So I wonder if this will not be an impediment for them to continue participating. For all the websites are already... We have a new website every year as you notice. All these websites are already work managed through SVM which is on Allios. So the people doing the website work have no need at all to be logging into the machines to fiddle around with stuff unless something is broken when the admin should fix it. In any case, regarding what you said, who needs an account? We have some infrastructure that will be set the week for example the interface to the lists. It was different due to the personal preference of the person who set up the list at some point and it will need some fixing and well we don't want to lose the links we have currently but a few people really require to have accounts on our machines. There's a question there. You didn't mention Penta in your list. Is that just to forget about it? Good point. I didn't mention it because we didn't discuss it. It's a good point, definitely. Penta is such a huge... So the question is you didn't mention Penta which is the conference management system. We need somebody to maintain Penta to fix the bug to make it better usable or to set up something else and setting up something else is very easy set and quite a lot of work. But I think it should be to the list that Penta maintenance is suboptimal to say at least. Yes, the problem with Penta is that well few people have access to it because it's very hard to set up so I mean I don't have it in my laptop. I have it in a couple of live servers following the instructions of the gentleman who just raised his hand. It's quite hard to set up. It's quite hard to understand. Once you understand it, many people can hack on it and it's worth having more people in the group of possible hackers. The thing is few people are able to work with it but we don't have anything better. We don't have anything that remotely gets as close in functionality to what we need. Again on the other hand, Penta is quite over what we require. So it introduces for example to approve a talk I must click on five separate things in separate screens. So well there are problems. If you have any better suggestion, please come and we should discuss it. Well, Fredon. So this is not something that you decide but in the spirit of that Debian or close to each other and basically Debian. I really like to see Debian members who are not Debian developers like maybe Richard Darst or other people that are involved a lot in Debian and have them perhaps as delegates for some things like that. So they are welcome in Debian but we cannot force them to join. We've tried this quite hard with Richard. He's not so keen. I was just going to say that it looks like just a quick overview having worked on both teams over the years now. The only thing that's going to be difficult is the user management. UDLDAP just isn't up to the task right now so working on that in the next year is something on my plate already so we can try to add in ACLs to a lot of people to add users of certain types and things like that. We'll just need to think about it and as always guys patches. I would really like to have a comment from you, Jörg, but the other thing is are there other issues you see with StepCon or is all going fine except these things? Can I just raise one more point about Penta which is that while we currently don't have anything better we are also currently on a heavily divergent fork from upstream. We are not contributing our changes back and we have no Debian package for Penta so just on the issue of sort of dog food or whatever we need to if someone wants to step up and try to fix those problems then the problem with that is that well this is the third conference management system I have tried to make completely generic and I think making a generic complex conference management system is a fail from the beginning. This is a Debian management system it's been heavily altered to suit the needs of Debian most of the changes we have made are not useful for upstream because we even introduced a namespace called DebConf and it introduced a whole layer of complexity because everything must be checked on the regular tables and on the DebConf tables so I think maybe others will disagree but I think the fork is irreversible and the flow that our conference follows is completely different from anything else. That is true I agree with what Daniel said we should be proper upstream then and publish our code in a repository we have it on the get repository I think and to create Debian packages also the original upstream is kind of missing an action so but if we decide we become our own upstreams maybe we should also try to simplify Penta to remove all the craft we don't use and let's make it then the barf I think before everyone piles on to the idea of making becoming an upstream of Denta Darf or whatever Denta Darf or whatever it's going to be I think what Gunar is saying I think is wise but I think the Debian specific changes to Penta are one thing that can be separated into a patch set like we do in Debian packages that get applied and then the other things that are actual bug fixes that we do to Penta can be pushed upstream which we're not doing and we can also receive upstream fixes from the upstream Penta development which we're not able to do because all of our code is just jammed all together into a big spaghetti mess so there are ways to actually separate out our specific needs for our specific conference and then apply them to what is upstream that requires managing our changes upstream changes into that which is in my opinion less work than becoming upstream of an entire source code project which is really quite a lot of work if it's going to be done properly I have looked it's frightening yeah but I think that is if you want to help Debian conference are not involved yet hacking on Tenta and maintaining it could really be a very very very good way and it's good for an outsider test instance setup and it's not that hard to set up I mean another thing people often look again they start talking about Penta then they look at the Penta code and run away a bit there's been suggestions of of course people of replacing it entirely I mean one thing that could be done in principle which would solve wouldn't solve our overall problem but would help some of the attendees actually it might be possible to make a if there's a volunteer in the room it might be possible to make a simple registration UI which has not got all the let's do move things around the screen hide them with JavaScript and so on and just lets you register but I'm certainly not volunteering to do that myself also another important thing to keep in mind with Penta is that we don't want to break our past conferences and all the information in it are still since Edinburgh are still back up in Penta and we don't want to lose that yeah so while upstream of PentaBuff might be missing an action to the best of my knowledge it's still used by the Chaos Communication Club and they will have a big camp in two weeks from now so clearly publishing I think would be appreciated by them also and while you say the fork itself is irreversible I think there might still be room for bug fixes flowing two ways the CCC is also looking for a maintainer for Penta so everyone who wants to work on PentaBuff can just check out our code we are having a git tree for it and mainly since we are trying to have our our own data that we are using for DevConf in our database area and we are having a lot of SQL files actually setting up that extra area so there is already lots of split up where we are not very good in splitting it up it's actually in the RXML files which are producing the websites later on in there it's pretty hard to me we have some good stuff for it public so have fun anything else so we do DevConf twice a year or other suggestions about DevConf and Debian what? one other point since most of the people in this room presumably if they didn't get the wrong room are interested in how DevConf runs in Debian not all of the people in this room are yet members of the we are looking still for more volunteers to do things this doesn't need to be a big job it can just be you pick one thing that takes a couple of days once a year to do for example like someone Anna for example has been doing room allocation but trying to not have our life taken over by DevConf the rest of the time obviously we are also looking at any of the different levels or different areas because we have kind of had the same few people doing a lot of the kind of core work and obviously there's always some rate of attrition so it would be nice to get a few more people in as for every other team in Debian of course so yeah if you're interested then it's unfortunately the normal Debian approach just start doing work and it works that way I think it by the way is a very interesting way I think of contributing to Debian without doing I'm not myself member of DevConf team shame on me but as far as I can see can be very rewarding actually even if you do a small job once per year can be very rewarding despite my comment about just doing work we are an area where it's easy to pop up in the list and say I want to help with something and we'll generally have ten easy tasks that will take not very long each to do ready I think this well the last the main people in the local teams have not been Debian developers so well this is a a very obvious thing we can also consider while promoting this maybe a way to get non uploading Debian developers as one of the tasks since Holga asked for two DevConfs a year I had the idea it may be worth thought if the DevConf infrastructure could be made available to teams that make many DevConfs it is available everyone doing a Debian conference no matter how many days it is or if it's even one day only they can have whatever resources they are needing they can go to the Wiki to the list they can have a website they can have whatever kind of mail they need and if it's large enough enough people we can even do PentaBuff stuff in that case we want to help from you with PentaBuff but you can have whatever DevConf offers basically just talk to us we are having we had the Panama mini-con I think last year it was or the year before we had India mini-con for 2010 and for 2011 and PentaBuff in the future so we might get more people there this time but everyone who is doing running a mini-con just come to us and talk the same is also true for the new video equipment which we can maybe chip to the locations we need to see with Irel who is partly owning the hardware but it is possible to ask and if it's possible from Irel we can send the stuff to other mini-debcoms and you can have free streaming included because we keep the streaming you just need to talk to us mini-debcoms in Paris easily get the equipment obviously we just change the room of the equipment it's not a big deal there's nothing else to discuss or no other suggestions complaints thank you you too there are many many people in this room who made this DevConf possible thank you