 I hope there are some people here who have prepared a mini presentation. If not, maybe you can take the time when the first presentations happen to come up with an own presentation. As we don't have too much time, I'd rather keep them short so maybe you can stick to two, three or four minutes, something around that, so that we have time to discuss afterwards, too. During the presentations, I will try to collect interesting topics, issues that we can discuss afterwards, so that we can keep the discussion focused on several points and not just talk about everything that comes to our mind. Yeah, then we'll see what the summary will be. So just as a reminder, that's a shorter version of the questions I've sent out via mail, and I just leave this slide up there. Maybe it helps some of you for the presentations. And that's about all I wanted to say at the beginning. Yeah, Lukas? Lukas is asking about the copy session. Well, I could start the copy session if someone tells me how to do it. The other thing is I've asked Tim if he could take notes during the buff, and he kindly agreed to do so. So I think I will be able to produce a nice protocol afterwards with Tim's notes. If that's okay, fine. So, which teams do we have in the room? Image magic? Okay. We have some, yeah, a camera? Okay. We have some people from the Debian Pearl Group. I know them. Ruby? Okay. Andreas? Debian Meet. Debian Science? Science. Science. Science. KDE? Okay, so... I work on the GNOME one. Pardon? GNOME. Okay. So, we also have some large packaging teams. It was a VIP, but I don't do much work in a team. Yeah, maybe you can still just give us an overview spontaneously. Okay. So, who wants to start with giving us a short overview about what you're doing, what you're using, and what the successes and challenges are that you might want to share? Microphones running around? Thank you very much. Well, just to start with your items, the communication is basically done with a mailing list. We try to attract members wherever we can at Debconf. I try to get my grip on people who are working in the medical field. They are not showing up. They are looking on their keyboard currently. In infrastructure, we have done a lot of QA-related stuff, which is basically to build web pages of the interesting packages for us. We have some bug overview. We have some QA page, and I also listed some packages we are interested in with descriptions and translated descriptions. We are doing sponsoring for non-debian developers, and somebody has written a policy how our packages should look like and how we are working with VCS. We are using SVN Repository on Elliott, and we have some tools to build this web stuff. We want to also spread these experiences. I have a very interesting experience done when I prepared my talk about these healthy CDTs. Perhaps you have seen it, and I will present it in a lighting talk on the last Debconf day. It is very interesting if you look at who actually is posting to the mailing list. I found out that many, many mailing lists are driven by a single person. I have done some graphs about the 10 most active posters over several years, and you see if the mailing list is driven by a single person, it can die. It can just die, or the team will die, and you have tried to make sure that this will not happen by making sure that you get other people involved to make a team that is not only needed by one leader. This is a basic idea. So you are constantly trying to recruit new members in order to keep the group running? Yes, that's the idea. Is there anything special you do about the recruitment and induction? Well, being friendly to new members, try to ask them for just giving introduction to become known to the other, and being helpful, this is basically what we are doing. More social engineering. Should I give to Debian Science? Do you have anything that is currently a problem and why you would like to get input? Well, I think the team is fairly working well. The good thing in the Debian Meet team is that it is more or less unimportant. This is a small user group and we are doing things on not so many packages, and this makes some things more easy than in other groups, to be honest. But it works fairly well in this area. Okay, thanks Andreas. So, Frederic Leobé, I am one of the members of the team, Debian Science. I followed the items. For the communication, we have the Debian Science mailing list, and also the Debian Science Maintainers mailing list. I would first stress on the fact that we are not only a packaging team, but we see ourselves as a fallback for packaging when there is not a better team dedicated to such focus. For example, there are other teams like BKG's SCI Comp, or DB Chem, that are mainly focused on Andreas, who told everything at the CD session, that when people focus on packaging, then we are happy with that. But we share experience when people want team maintenance with respect to science, but without having a dedicated team. That's where Debian Science shows up. With respect to the members, they are listed on the Alliot page. I think four people are running this currently, the main leaders. In infrastructure, we have Geat Repositories on Alliot. With respect to the packaging, it's very new. The policy has been written currently, so I would say we have something like two months of experience. It's too short to make feedback. Yes, as I said, we have a policy. We have written a policy and we take inspiration from the other groups, just to take the best practice somewhere else. Tools, Geat, I said it. The challenges are to welcome new members always because the scientific tools require sometimes very specific knowledge that are not well shared even among the scientific community. As Andrea said, we try to be friendly to the newcomers. The general idea is to take advantage actually. What we do is to take advantage of all the tools already existing for the Debian Med CD. Everything that Andrea's works on, then we take advantage of it. I think I said everything. Couldn't maybe say one or two other sentences about your relationship to the other teams because you said you are trying to be a fallback? Yes, so we try to follow, it's mainly done by human process. There is nothing automatic that we try to follow the mailing list of the other packaging team just to know what happens by them. We follow the ITPs with debt tax so you can find all the... It should be more integrated into our process maybe thanks to the CDD tools Andrea's is working on but now on the Debian Science page or on the Sentinel page automatically generated you can follow the ITPs from the other group. If someone outside Debian Science is creating a package then we follow the ITP. We are using Meta packages for following that. That has been described in the CDD talk of Andrea's. There will be one more talk around Debian Science from Andrea's tomorrow afternoon if I don't mistake. That's an interesting point which we should remember. Okay, who's next? Voice of IP. As I said, I don't really have a good complete overview of the whole team but we communicate mostly by our mailing list and also a bit directly through SVN commit logs. I mean, sometimes I read the commit logs, I find an error, I just fix it. Infrastructure-wise we actually have a private mobility farm which automatically builds once per day I think the SVN trunk for seed as back ports for different versions of Ubuntu. It's quite a large spread and we find that really useful. You're removing the list of points. Oh sorry, I just need to take a note because otherwise I forget everything. We have several non-DD members and they commit to the SVN so the changes get uploaded with the next upload. As I've already explicitly said, it's all SVN with SVN build package and no upstream sources in our SVN. Is there anything specials non-DDs have to do to get a package uploaded? Sorry? Is there anything special that non-DDs have to do if they want to have a package uploaded? Is there some regular workflow for doing that? Not that I know of. I think they just bugged the orders, bugged the DDs on the main list. It's ready to go. We seem to get new members mostly by finding that they file an ITP that goes into VOS of IP. We email them and say, do you want to do that in VOS of IP? And say, oh sure, they come. As far as I'm personally concerned, I'm very happy of having put my packages there. I mean, they're often a bit even faster than I am for new upstream versions so often when I get to that item on my to-do list, oops, it's already done, I must say that also once it was badly broken and uploaded broken, it happens. So I don't think anything else to say. Anything you'd like to add to my list of topics for discussing later? Well, personally, as a low intensity member of several teams, I find it difficult to remember and to adapt to the different working flows. SVN with upstream sources, SVN without upstream sources, I have to learn two tools per package roughly. No, a per team. Even if teams share tools, they use them in different ways. Frankly, it's getting to be a barrier for me. Okay, thanks. Sek gets two microphones. Okay, hi, I'm Zak. I'm a member of several teams, but I will just introduce the OCaml team, which is a team maintaining a fairly large amount of packages. We have about 100 source packages. I'm very happy about the result of the team, because we are frequently referred by our upstream as the distribution with the best OCaml support in the field. So we are quite happy about our results. We communicate as I think all large packaging project with both a mailing list and IRC channel. As an infrastructure, we used to have subversion repository with Debian-only layout of SVN with package, but now we are slowly moving to Git. We had an experience with enabling commit access to every DD and every alias user on our repository. I think it's the way to go, but I don't think everybody outside our team has ever committed to their repository actually. Other infrastructure parts are GNOME-like status page, which we see the version in the package distribution in Debian, what needs to be rebuilt and blah, blah. We have our own policy, which have been floating around I think since 2002, so it has quite an history. I don't think any team-specific problem with our team, but I was just going to make the very same point Lionel just made. So I'm a member of several teams, something like 10 teams, and while I don't see any way to standardize on a single tool chain, because every team is willing to have its own convention and it has the right to do so, I see the lack of a way to document, a lack of a common way where to document these team-specific procedures. So stuff like starting to use more readme.source to document branch layout or something like that is really something we need to do to adopt. And the other point I was mentioning with you yesterday night is that I don't see a common usage of the distinction between maintainers and applauders. And I think this should be addressed Debian-wide like saying that in the applauders, as the people in Grom is doing, in the applauders there are the last 10 person or five person who worked on the package and anybody else is not in the applauder's field or something like that. I am currently working on two groups. I've been mostly inactive due to work the last couple of months, but the group I've worked closest with is the Perl group, which Gregor kindly didn't introduce because he wanted to be polite and allow the audience to do this. The Perl group and the Ruby Extras group both are very, very similar in what they tried to package, but working quite different ways. The Perl group, well, we handle the communication mostly around, well, some of you were in tincture stock, around the PET, the package entropy target. The correct name, yeah? The correct name. Well, a single page where we can basically see the whole overview of what our group needs to work on. And of course we coordinate more finely on lists or on IRC as I guess mostly everybody does, but that's our main communication tool. The membership is also, I mean, by default every Debian developer is a member. The Alliot repository, as Zack said, accepts commit from non-members, but I think we have had some, right? Well, it's some... Yes, yeah, right. So yes, we're using that. And we have our packages listed also in the low threshold enemies. Well, infrastructure that's more or less the same. For sponsoring, one of the main goals of this tool, the PET, was to not to require people to write to the list asking for a sponsor. You just upload and when it's ready somebody will upload it. We have a set of policies that say, well, even some things we haven't written down, but a good deal of the communication is even by writing invalid change log entries. So we know if there is an invalid change log entry something must be fixed in that package. Of course sometimes we don't remember to validate it again. No, it gets fixed. And we work around the SVM build package. Well, that's basically it. I think I'm very happy with that group. I think it's a great success story on how those tools are integrated and built. And well, this is not to say the experience with Ruby's group is bad, not at all. But it strikes me that it's so different the way using the same tools we get such a different result. I am not so much involved in the Ruby group, so I think I'll throw this over to Lukas, who's also here with the microphone in the hands. Okay, thanks, Kola. The microphone, please. So I'm involved in the Ruby group. As Gunnar said, I agree that maybe we don't get as much good results as a bold team. But still, so it's a fairly standard team, I think. We don't do anything really special. We use SVM build package. We standardize, oh, something that is interesting maybe to discuss later is that we standardize on a CDBS class so that all our lives are really simple to package. And I'm not sure that all teams do that and it should be interesting to discuss why some teams don't do that. And we developed something that is specific to the team, but that's actually something that should go to Uscan. We just developed a wrapper around Uscan that allows to get the upstream source since we use the debian layout. Something else that I don't mind notes is that we should maybe discuss about... It's similar to what Zack said, but it's how you organize inside teams with responsibility for a specific package because often you have some people who are more familiar with one or two packages and it's difficult to know who is mainly responsible for some packages and how that reflects in maintainers and uploaders. So just to get it right, the question is if members are responsible for specific packages or for all packages or something else that would be a question we could discuss later. The question is whether... I know that some teams don't have a specific responsible person for each package, so everybody just maintains everything, but that leads to people not knowing exactly what is happening on every package because they are not very familiar with the package. And what we do in the Ruby Team is that we try to... In the Ruby Extra Team is that we try to have at least one person that feels responsible about each package, even if the other are here as backup. So when there's a problem, at least someone is supposed to react. It doesn't always work, but maybe that's a small improvement. Okay, thanks. Hi, Martin. I was answering to what Lucas said and that's something that I've been thinking about sometimes. And I think one of the strongest points in the back group is that although there is nobody in charge of a package, I still manage to keep them more or less in good shape. And also I think that it's good to people who want to help somehow to not restrict them to some packages because I have the experience in some groups that you want to start working, to just pick a package, start working on them, and then you realize that that package was not meant to be touched by anybody else, except from the designated maintainer. So I think that more or less makes that package not in a team, it's a one-person effort. And I think that makes the group less strong. Before we get into the discussion, I think it was good for showing the two sides, but still, are there some other teams here who we've missed so far? Any other short presentations? Ah, yeah, Known team, thanks. I don't think I have much to add. We communicate through a mailing list and IRC channel. Our members are, we have quite a few active members, but there are two or three who really push the work forward. We're always trying to recruit because Known's a very large piece of software and very complex to maintain also. I think the main problem we have is actually bug triaging infrastructure. For infrastructure, we use SVN with SVN bit baggage using a very Debian-specific, I think actually even Known team-specific layout. I don't know of any discussion of moving to another VCF, VCF at this time. We do have some work being done on policies and specific tools on the Known team, but most of them are already integrated in Dab Helper and PoliSee if needed be, so it's not something we actively have to work on. I think we do have lots of interactions with other teams like, for instance, the Just G streamer team, but mostly the most people who work on the teams are related or the same people, so not a lot of problems there. Yeah, right. We have a status page also, which has been written by, actually we had lots of revisions of a status page, written by members of the team at Sandhawk. Okay, thanks. I wanted to add to what he said. Well, actually we recently discussed, well, very shortly, but discussed on whether to stay on subversion or to move to a distributed VCS, but we decided that we're staying with subversion because, well, our group's work needs to be precisely centralized, so if we used any other kind of tool, we would still be using it in a centralized way, and we decided that the current way works as it should. Now, the Perl group works with the, also with the layout tool, right? And with the full upstream services included in the tree, so our subversion tree is huge. Well, it's a long time since the last time I tried to do a full checkout and I will not do it ever again. No, it's ridiculous, but this is a bit in contrast, for example, well, we have 900 packages and I don't know how many revisions for each one of them. Everything is in full. On the other hand, in the Ruby group, the upstream services are not tracked. Yep, so the full repository can be checked out at any time and it's quite light to work with, although it's a bit more problematic sometimes to, well, we have to separately get the packages in order to make the patches. So it's different ways of working and what people think differently. Just to add another point, an extra point which Guna just made in your mind, I would like to have better tools to do changes to all packages in a given team in a batch fashion. So sometime you change your best practices and you need to actually deploy the changes to all packages and it's not that always easy. I think there are quite a lot of ad hoc tools to do that and just one, I think, contribute script in SVN build package, but for example, for other VCS I'm not aware of any tool. Okay, so do we have any other presentation? It's about half past, so it's not bad if we don't. All right, so at this point I'd like to thank everybody who has prepared and shared their experiences. That's what I've just been writing down here, so probably nobody except me will understand it and I'm not sure if I will understand it, but these were some of the issues that were raised now in the last half hour and we can use the remaining, don't know, 20 minutes to, well, pick one, two, three of them and try to bring them a little further. Which one should we start with? Any opinions? The third one, the question about bringing the different workflows, tools, documentations a little bit more together. Okay, Zach, do you have already any ideas or is this just, do you already have any ideas for bringing the tools workflows closer together or documenting them better? Well, there is already a mechanism to do that, which is in policy, which is debianreadme.source. I understand, so this is a way which is package-specific and actually, Debian is mostly package-specific or package-oriented, so it is a good place where to document like branches layout for distributed VCS or stuff like that. And actually, we also have a way to do that per team, which is the wiki-debian-org-slash-teams pages, which is supposed to be a set of pages with similar layout to document team-specific stuff. It is just, need to be, I think, advertised more, the two of them. I mean, we can look for some new mechanism to do that, but we already have them, it's just a matter to use them. Okay, so readme-source and the wiki-slash-team would be places for improving documentation. Well, I'm not aware of any objection about using them, so it's probably just a matter to spread the word. Okay, Lukas? Something that makes sense to do is to have a specific package for each team that contains all the developer-oriented stuff, like for us, CDBS class and documentation for standardized things inside the team. So it becomes a big dependency for every package in the team, and I think that's maybe better to document things there instead of documenting on the wiki, actually. So it's in the package, it's accessible when you are offline, et cetera. Okay, so using a separate, how do you call it, meet the package? Well, not the technical, but abstraction package. Yes. The point is to have less things in each package and to have the common things in a single package. So you don't have to exchange readme-source in 900 packages. For example, yeah. Okay, any other opinions? Maybe we can also take this maintainers and uploaders topic here. I think the question was if it might be useful to have a more common way of who should be in uploaders or not. If it's not useful, then every team can continue to do so like they are doing now. If it's useful, then is there something that might be okay for everyone? I haven't checked, but some time ago GANF filed a lot of bugs on each package where the maintainer was not a real person, where the maintainer pointed to a team. How do you do that in the Perl team? Do you have maintainer, yeah, you have the maintainer, Debian Perl group, I think. And you didn't complain about this? Well, the thing is, all of our packages, the maintainer is a group but they all have uploaders. Okay, so yeah. I think that's also what Linzian is checking for now. Yes. Something like no human being or something like that. About the uploaders thing, I think that's a GNOME team. They do something that makes a lot of sense, is to use the last five or last ten uploaders, change log entries actually, all sorts of change log entries in the uploaders field. That's the least of the last persons that were active. And so it expires over time. Yeah, I was aware of this practice, which I really like. It's just a matter to bring your tool and put in some standard place where everybody can use it. More generally, I think this raises the point of if we have a place where to put tools for teams. And I don't think we have one such a place. We could use dev scripts. Yeah, good point. Dev scripts. Well, dev scripts might be appropriate for small scripts, but I've also been thinking about this web-based tools. It seems like at least every other group has some status page or some other web application. Now at least we know about some of them, but still it might be helpful to bring them together, at least as a first step, make them easier available. Can we do a quick poll to know who is using what? There's Pet for the Perl team. And what else? There's SVN build stat. I don't know if some tools are using it. Something else? I think then there is the GNOME status page, which at least me and Schemelys copied for the OCaml team. I don't know if there is some other variation of it around. Well, the DebenMet team has, I think, also some web stuff that might be not yet mentioned. And there was also some DebenScience team. You said you're tracking bugs on some web page. Well, this stuff is based on these task files. You have to create some task files with interesting packages. You can do this in principle for any group-maintained packages. If you want, I can give some short introduction in a silent room or so. And then you can use these tools as well, yes. It's really interesting that someone writes a specification, that summarizes what every tool does, and then that we write a single tool that everybody can use, because it's really stupid to have so many different tools that do basically the same thing. Yeah. I'm not going to do that, but that's... Well, what I, of course, can offer is if people send me an email with these descriptions or with pointers to where these tools are or whatever, I can try to create an overview of all this stuff. That's no problem. If it comes to more technical questions, then maybe I will need some help afterwards. Okay, so that's one point we can add to the summary that we're trying to collect together an overview of the existing tools with the, well, long-term or mid-term objective of bringing them together and making them useful for everyone. Good. Regarding this standardization of documentation or maintain and uploaders, do we have something to write down to? Actually, one last point on the tool stuff. Right now we have a lot of tools, but they are opt-in, so it means that every team needs to ask someone, like SVN will start or tinge of a pet to install the tool for them or something like that. It would be really great to have it by default, so that if I'm used to use some tool, I can go to whatever team and see its instance for the team. So that part is, of course, discovering the documentation or the configuration details or something like that, and so I think it would benefit to have something like the team's page, I don't know, in a standard format that you can just extract the URL and configure it by default. Would that be possible, for example, for pet? Yes, the only problem is that if you enable it for every group, some of them won't like it because it takes a little time doing commit. So maybe it's not a good idea by enabling by default, but you can enable it only in Chrome jobs, so it will not be instantly updated, but it will work anyways for everybody. Yes, it can be done easily. Okay, so coming back to my last question, it's fine, is there something we can agree on on this common documentation stuff, on this maintainers uploaders, how many, how long, how often, or is this just fine how it is that every group does it, how they like it? Andreas? Well, I think the groups are so different that you can't really compare these points. We just upload, if there is anything to upload and other groups have some other means, so I don't think that makes sense to compare this. I think this needs to be fixed because right now it is the meaning of the maintainer and uploaders field which our user can see in the package, which is really different according to where the package comes from. So probably this is something which is worth standardizing by policy. So deciding what is the real meaning of uploaders and what is the real meaning of maintainers is something which already needs to be done, I think. I thought you wanted to say something. Okay, so let's keep that in mind that there's at least some confusion here. Good. We already started the discussion a bit early about the advantages and disadvantages of members being responsible for specific packages and members of the group being responsible for all packages. I think the main points where Lukas has said if someone is responsible for one package then he knows about it and others might break something if this summary is... Just a minute, please let Lukas clarify. The problem we had in the Revit team is that some people just came to the team and dumped the package on us and then left, disappeared. So we are quite understaffed and we have to maintain packages that we never had any use for personally and that really sucks. So the goal of having one person responsible for the package was to have at least to know who to ping when there's a problem and when no one else has time to fix it. Okay. And Tincho has presented the other opinion. Well, the teamwork is about everybody can't touch each package and it's better for quality because if someone has time then he just... Okay. I'd like to add just a little more. I think that in practice what we had seen is that if you really know some package you end working on it quite often and the others know that you know better so they will ask you but if you're not around they will try to fix it or wait for you. I think that's part of teamwork trying to talk with each other. I think Renit wanted to say something before. I've skipped you. Okay. I think the main reason why this works so well in our group is that it's so... Perth packaging is so homogeneous. Most of the C-Pan, which is as large as it can be follows one out of three possible ways of building so we don't have much variation. So we have mass-adopted the orphan packages and so and they're not so much of a burden because they're not updated often. But it doesn't mean the same thing will work in... For example, we will later talk about how broken Ruby gems can be. Okay, so it might be a different situation for different groups. Yeah, it makes sense to me. Anything else on this topic? I just think that what Martin was saying may work with a person being the official maintainer for a package. I used to be official maintainer for Glade, for instance, and I just didn't care if anyone worked on Glade in the GNOME package, in the GNOME team. So our team usually works as... Just like Martin said, but with a person usually being the responsible, the specific responsible for a package. But there's no policy on that. So it would be good to have some kind of decision on what should be done because I agree that we not being a project opinion on what maintainers and uploaders, for instance, although I agree that a GNOME package team way of doing it is the best one. It would be even better if we had a specific decision of the project and what it means, because I agree that the users get confused about it and that even us when we're reporting bugs don't know who to ping and or to harass to fix a bug. So I tend to see things a bit in the middle that I like one person or a small subgroup that works well to feel responsible for the good state of a package that they consider that if it doesn't happen it's their failure, but that anybody in the larger team can do any useful work on any package of the team. That's what we do in the Ruby team. The point is not that only one person is responsible for each package. Everybody is responsible for each package, for all packages, but one person has to feel responsible, mainly responsible about one of them. Just out of curiosity, before you give away the mic, is this documented somewhere or is there something to do with the uploaders and maintainer fields? We set the maintainer to the mainly responsible person and the uploader to the team, I think. And to maybe the other persons that really feel responsible about the package. In the Ruby group we have a very interesting 3-aging tool called Paul van Tilburg. He usually pings the right person when there's a bug which hasn't been taken care of. On the IRC, they're asking, who is this, Frank Thomas? He's asking to relay a question. Can somebody, please, what should one do if there are several people on a team, but only one maintainer is really active and working on the packages? How can the other members be motivated to also do some work? Well, a method... Sorry. Well, a method that I've seen work in that context is for the person that does all the work to stop doing it. Then two or three or four people step up and start doing work and you can come in later again. Sometimes it works. Any other ideas on this question? I think this is also related, and maybe we can use the last two minutes, something like that, to these social questions, especially to this how to recruit and induce new members. I mean, one of my opinions is a sledge survey has found out that the work has to be fun. So maybe we can shortly think about what makes it fun to work in groups. Not about the fun, but about recruiting people. I think that it's very good, both for the groups and for the newcomers, to make the people that are starting to get into DBN, starting to get into NM, to work in teams instead of working on independent packages. I think it's much more enriching to learn from a group, than to learn from policy and Google. In my experience, I learned much more in the group than any other place, even in NM. Okay, get the sign times up, so maybe one last comment. I kind of wish that someone else would say something after me, but as far as the fun point, one of the most fun things is the package to try to fix to say, oh, I haven't worked on this in two months, and it had this really bad bug that I really wasn't looking forward to trying to fix, and then discovering it already has been fixed. Okay, so we have being friendly to people from before, trying to grab them if they file ITPs or ask on mentors for uploads or whatever. We have this, it makes fun because others help me, it's just good to see. Yeah, and we have that learning is easier in a group than just at home reading documents, which might not apply for everybody, but I feel the same. So, well, I think that was this buff. Thanks, you're all for coming. I will prepare a summary protocol minute, however, that's called in proper English with Tim's notes. Thanks a lot to you. And if I get some pointers to the existing tools, I can also try to prepare, well, a summary of the existing tools, which might help to improve the situation. Do you think that we should have another buff about this? Maybe tomorrow or Saturday after you go through all the notes and summarize things a bit? Okay. I'm not sure. I would like that, but I'm not sure if it's just me or... Yes, it's not just you, I support this, I think it's efficient if we can do this while we are all here, if it's possible. So I support the CASID. Okay, great. Yeah, well, I think now time's really over, as I get the time up sign for the fourth time, so thank you all.