 So, can we start? Ah, great. Well, thanks everyone for coming. I'm rather really happy that we have the opportunity to have a second BoF workshop meeting. The sound is not working? Have I turned it off? No. Okay. Yeah, I think most of you have been in the first BoF on this topic, on the team package maintenance. So I won't have to spend much time for starting and introducing myself. I'm still regular for those who don't know me. Yeah, I've been thinking a bit yesterday what we can do today. And my ideas were that I'd like to continue working on the ideas we've collected. We found several issues on Thursday that might be interesting to look into more deeply. Maybe we can manage to come up with some concrete detailed proposals, at least for one or two of them. We don't have too much time. And I'd also like to have some kind of roadmap, time structure, whatever, to see how we can move on with these issues. By the way, Tim has agreed again to take some notes. They were perfect the last time, so thanks a lot. So we will have a nice protocol, a nice minutes again from this session. Okay, what can we talk about? I'd first like to well pose a meta question to all of you about what are the best communication channels for this kind of meta discussion around teams, so which don't know mailing lists, IC channels, whatever should we use after we leave Madelblada tomorrow. Then we have several topics where we can choose from, and at the end I'd like to, as I've said before, come up with some assignments to look who is going to do what. Is that okay? So the first topic, I've posted the minutes of the last meeting to the DebConf discuss mailing list because we are at DebConf and the minutes related to a meeting at DebConf, but in general what do you think would be appropriate places for sending minutes or for putting documentation like this collection of tools we've been talking about? Well, I think for results this might work, but for work in progress, for putting proposals. Yeah, okay. Yeah, right. And is the mailing list you think would be appropriate for discussing these issues? Is this a QA issue? Is this something else? Okay. I find that to be a problem. It's cool because it's fast, but nothing gets documented. Right. When you come to the mailing list, you can go and search the documentation by yourself because you can take your time to read the mailing list and search. That's why I made the list. Yeah, me too. I have an idea for ILC. I also don't like ILC, but there is a good habit of making ILC meetings for specific day, once a month, or once a week, whatever is necessary, and gather people for one hour and make a meeting with a fixed agenda in minutes of the meeting and notice that if there are new people, say, well, if there's nobody volunteers for minutes, we don't make any meeting. I don't know what strict you should do it, but this is a kind of an effective way to use ILC instead of like to introduce this. Okay. I guess ILC is very useful when you are, with good time, for example, a release or a release of the system, or for example, that happens to the local team in the last two weeks, ILC was the bad thing because it was as fast as we need to do some things that need to be done very fast. And I guess with software, it happens the same way. Without mic. No, no, we can't do mic robot. Yeah, just a few. I think one issue with ILC is the lack of data after discussions. Do you know of any good software for ILC logs or for publishing them as web pages that will be away for minutes? Yes. We use it for the rest of the outcome because it's actually running on there, and it comes out. The only problem is that we need someone to do as a chair meeting, but it's actually pretty good for us to make IHT and all the notes and everything. So it works for a meeting, but I was thinking of logging everything? Well, it could be used to that. Perhaps we need some modifications to allow it to be organized, but it's actually working pretty fine for us. Okay. For what you proposed, I have organized a semi-distance conference, and yes, most of our talks during the sessions are via ILC. So, well, almost any client logs ILC, but what we have found to create usable minutes or usable colleague proceedings, if you wish, is the ILC format is very good for following a conversation, but it's not a good format for documenting, not a good format for transmitting, because it's not ordered and it's full of not important expressions. So in the end, we always have the role of a human in rewriting what was said. It's a relator. Okay, so to sum it up, that was just the introductory meta question of me. We can use the Debian Development mailing list as it should be of general interest. We can use the Viki for work in progress, and if we come up with something stable, we should aim to get it into the developer's reference. That's okay? Okay. So, back one slide. These were more or less the four broad issues we had last time. I have one slide for each of them with the main results from Thursday. Yeah, which one would you like to start with? Tim suggests maintain and upload us? Yeah, because that was... I'm going to stop dying for a moment. Yeah, I had a thought about this the other day, just after meeting, and that's that I think it would be better to standardize having the mailing list in the maintenance field, because the bug reports will automatically go to the whole group, and not just to the core maintenance. Actually, I think I found the Viki list itself really soon. As soon as back, it does its own work. Well, actually, as soon as Lucas changed to the Viki, it will go to the base. Yeah, you can do that as well. One problem with the mailing list in the maintenance field is actually that the mailing list of all your stuff will figure it in thousands of different ways, and most of the time, you get moderated and it tends to be really annoying. So, yeah, it's a technical problem, but it's annoying. Yeah, someone should talk to me as your admin is about that, so we have a comment configuration. For example, we put a low-send mail without... I'm not sure that... I think when you cut your bus, you will see optionally both of the bugs for which you are uploaded, but I'm not sure that the last complete point which was more about receiving mail is right. And I think that actually having standardized to add the mailing list in Montana would be good, but the last time we tried to do that on Deben de Val, maybe two years ago, something like that, there was no consensus about it. So... Actually, the whole issue of receiving mail about stuff in Debian is a mess because you get sometimes things three times because you are the maintainer of the package and you subscribe for it on the PTS because you want to care about something that is not provided elsewhere, and then you get them through the mailing list of your teams, so you get them three times. I get the test immigration emails three times each time. So maybe... Well, that's really long-term and hard to solve, but someone should... Well, nice to have it in the notes, at least it's a message that should be fixed at some point in the long-term future for the COV-12 or... So, okay, if... Yeah, if the group is in the uploader's field, then it must be assured that the bug reports also go to the uploader's field, otherwise it's rather difficult. Yeah, I think that the only team that tasks the main responsible person, the maintainer and team in the uploader's team is the rabbit team. And what we do is that we subscribe the mailing list to the PTS, so we get the bug reports. Yeah, but the more general question is in the first line, someone I don't remember who it was, I think Zach, said it would be good to standardize on these definitions what should be in the maintainer field and what should be in the uploader's field for group-maintained packages. So, yes, do we want it? And if yes, how could this standard really look like? But we could standardize on the two different ways to do that, one way is... Maintainer is mailing list, uploaders is active people in the teams working on the package, and the other way is main responsible person in the uploader's team plus also responsible person in the team in the uploader's, I think. Well, you got my point. I think for the second one, what would have a real quality in the... Why? Because in the past, in the rabbit team, we had maintainer set to the team and we are not... I think that was the second line, what you said. And what happened is that nobody cared about some package and that was really annoying. So, at least if you have one person that is supposed to feel responsible, then... If you have my policy, that one person should be at least an uploader, then all the group gets the main without having to subscribe without getting clutches. Yes, if you are not in the main in those fields, you get no mails about this product or whatever, and it's better that more people with sizes and in the mailing list, everybody else would have to subscribe or we just change this policy and the uploaders is also included in every... Yeah, that's what I've been talking about before. If the group is in the uploaders, then uploaders must receive emails. The team tasks... Yeah. They generate to the last two person. Well, if... If someone that you can blame or not take it... Well, that's the change for that. I think the point of maintainer is the contact point for the users, because if you want to blame or praise, okay, let's do it in two possible ways, you always have the change on it. Also, one of the things that we have seen in the Perl Group is that, fortunately, it's not very often, but when somebody leaves the group, he doesn't have to orphan his packages. He will still be listed, and if he wants to be delisted, somebody else will have to take them, of course, but it's... I know it's just a psychological difference, but for me, touching any package in the Perl Group makes me add myself as an uploader and then become responsible for it, while as if it were taking maintainership, it's a bit more of... I mean, because it's not that I am the main maintainer for it. For example, this package I just took in the Ruby Group. Well, I took it because it was basically orphan, but not because I use it. I think, for Frederick, Mr. Nexplan... It was almost to say the same, is that in the case of the first option, you have the names of the responsible persons in the uploader's field, so I don't see the problem at all. If you have five people in the uploader's field, if you have five people in the uploader's field, will you know which one is to blame if it doesn't take care of the package? All of them? Yeah. But sometimes I'd like to make a change to all the packages in the Ruby team without having to feel responsible about all those packages for six months or... But if you're really looking for blaming or blaming people, you should really look at changes. It's not the usual use case. The use case is, oh, I have to contact about the impact. Well, the other problem is... Or who should take a look at spots? But in the end, if we are group maintaining, the spots should be the responsibility of everybody. Yeah. Well, the other problem is will we manage to standardize on maintainer is the team? Because we are... Yeah, maybe... I could change it for the Ruby team. I'm not really strongly opposed to that, especially if we switch to the GNOME thing where you automatically get active people in uploader's. But that doesn't mean that everybody will agree in Debian. And it will be really hard, I think, to push because there are many different cases. And currently, which teams are represented actually here? That's Ruby Extras? Okay. So you are in the group of group maintainer groups? Yes. We can try it, but it doesn't mean that we manage to standardize on that. No, sure. But if we say we do it this way and give an example and make this available for other groups, as a model of good practice. This is something that will be interesting to check. Okay, but then what we should really have easily available is the GNOME thing that automatically extracts the change log and hits the app with us. This is a question. Why don't we put something that should be created for tools or dash scripts? Yeah, dash scripts, I don't think so. I think that's in the next slide. But before we actually switch to that, so something like what the GNOME team does with this automatically generating uploaders, is this something we all think is reasonable and we want to try out? So I'm not sure that everybody will agree on using it. I actually don't think that everybody agrees on it, but for the people who want to do something like that, it should be available and easy to use. Okay. Yeah, sounds reasonable too for me. Okay, thanks and thanks for the keyword, for the transition to the next slide. Yeah, we've been talking about tools, about the question that you've raised again now. Do we need a package for common tools? Should we put them in an existing package after we have collected them, which is the task before, or after we have written them? There was also the question about tools for changing all packages in a team. So what are their opinions on this issue? Dev Scripts for that, because Dev Scripts has tons of dependencies, many parallels I think. So... They recommend. Well, so that would work. But I think Dev Scripts is quite big and I'm not sure, but this package will be used as a build dependencies for many packages, so it's important to have something that is easy to install. Actually, its total size is the one megabyte and an half. Yeah, that's big. Depends on PPDG depth, span and PTC. Well, one megabyte and an half is big if you just want to store a few CDBS rules or... Well, you are assuming that the tool is to build a build, because it would still be... Yeah, it would be... It depends in depth. I think it depends. Well, the other thing is that, we are using PCH to play with the chainsaw. Yeah. I think there are two possibilities. The one is having scripts you use for manipulating the package, manually, automatic, whatever, but then you don't have it as a build dependency or to have some magic going on automatic during the build. I think that it just said dash i in the control file. What is it doing? I think it said build time in a CDBS rule, but I'm not sure now. So if you have just this tool, it's not worth to have a package. What is the question? Do we have actually any other tools used for team maintenance that we want to identify with a package? I think there might be some tools. I mean, I only know the Perl group, and we have some, I don't know, four or five shell scripts that of course everyone can write in half an hour, but still, if we collect them, they might be useful for others. We don't have such stuff, too, and this, well, could be collected and could be maybe merged together and, well, there have been ways to have it in a package, so maybe we should put it into a package. No, it is not. And then we switch it out, because changing it out might be a problem. It is not allowed? Okay. So, for example, we are used to use it in the camel group, and then we switch off of it. There is just one package remaining, which actually needs it, because the architecture is dynamically computed, and that is done before creating the source package. The release team was complaining about that, because it breaks in some weird ways. Elsie Bag. Well, another tool which we need, and we have discussed in the part of the booth, is to do actions in batch mode in several packages, and this is a good candidate to be put in such a package, actually. It is something which will need, like, awareness of various possible subversion layouts and do stuff in all of the packages. Well, I think we should do... Well, at the beginning, probably we will just have the subversion specific, but I really hope to extend to other VCS, so it is probably worth keeping a separate package. It doesn't really fit in this topic, but we have to remember, whenever we do repository-wide changes with such tools, well, those are known to kill Alliot as a whole. It was you who did it, or Tincho, who did a mass... Well, a series of commits, which triggered a series of post-commit hooks, which killed Alliot. Yeah. And it was a problem in the post-commit hook. Okay, so we have some ideas about which scripts could be there. I hope we decided if this should be, I don't know, a dev script for teams package, or if this should be a build dependency yet? Well, actually probably the best idea is to add stuff to dev scripts and have a separate binary package. And? Have a separate binary package. Ah, okay. That's probably the best idea. Mm-hmm. That's called dev scripts teams or whatever. Yeah, sounds like we could add here. Dev script is quite open to contribution, so it won't really be a problem. Yeah, yeah. They are adding a lot of fancy stuff. Okay. Is this all about tools? We have to discuss now? Totally, well. Yeah. And we suck. Completely. Well, it's a reference between Ruby, so it's an improvement compared to you. I think what also belongs to this topic is this whole web application stuff. Maybe we can spend a few minutes on that. There are quite a few things out there. So on one end, the other day I thought about including stuff like pet in such a package, but on the other end it would be better to have it installed in a central place and just have one code base. Yeah, it doesn't help on the desktop machine. I have no idea if there are other web-based tools which would make sense to have in the package. Yeah, for sure, some things in the dev-in-science and mid-community, which might be worth merging. Yeah, and we've been also talking about DDPO yesterday at the bar, and there's this whole issue with, how is it called, D-E-H-S, those watch file stuff, which is a bit separate, too. I don't know if there's some decision yet on that. The thing is, all of those tools, it will depend on how UDD works out. If UDD becomes the standard place to get such information about packages, then writing tools like DDPO will be really easy. And I think that one milestone that we should target for UDD, for those who work on UDD, is be able to do DDPO in just one SQL query. And that would be quite well, just in a few SQL queries, and have all the information in UDD. And we are not quite far from that, actually. We might reach that in a few weeks. So then at this point, writing something like DDPO, rewriting DDPO from scratch will be really easy. It's only a matter of presenting data, and that's quite funny. Yeah, it's a bit over-focusing. About what? I think we solved all the print performance problems in UDD now. It works quite well. The last queries I made were all working instantaneously. Well, just a lucky good-bye query. Maybe they're better optimized. UDD is currently running on DOMU in a not-so-fast DOMU with not much RAM. Moving it to another machine would really help if you can get a 4GB RAM on this machine. That would be much faster. Well, I have to admit that I actually like the idea of having essential storage with us talking yesterday about adding the information from the version control systems to UDD, because that's what PET uses, heavily relies on. And if that simply works, then have it all in one database and produce different outputs seems like a better idea than storing data here and there where and twice and stuff. Well, the real point is determining what are the current tools in use by all the teams. So we need a list of features that each tool does. And then we can see how we can get all of those features into UDD. For example, if you only use the changelog, for example, it's the only file from the VCS that you use is the changelog. It's easy to import changelogs into UDD and then do some funny stuff with comparing version from the changelog in the VCS with the version in the archive. That's not really hard to do. Someone just have to write the script. And you are the contact person for UDD at the moment? Well, you can contact Digian QA in general, I think. Okay. Good. Anything else on the tools? Except that I'd like to remind you to send pointers to me. Those who have not done yet. I have a question. Does anybody know about Tinsho's use-can-ng and plan to write the watch file format or whatever? It results with what DPKG does. And it found bugs in Tinsho's code because apparently Tinsho brought it from policy. And there are several implementations of version comparison, of Debian versions comparison that all are basically the same code just translated from C to Python, Perl, Ruby. And wait, yeah, that's all. So there was already a Perl implementation that works in the BTS and it didn't use it. And I think it's just because you don't talk to people before writing that. Use-can-ng is totally counter-productive because it doesn't replace use-can. Use-can is not really nice code and it could replace use-can and it doesn't need to be called use-can-ng or to be packaged separately. That's wrong. Okay, so are we finished with tools? Good. We are missing just the roadmap. So who does what? Like should we start assembling tools from different places and submit them as bug reports against dev scripts or what? Well, what I still can offer is to do the first compilation of existing tools. Yeah, existing tools. Both web stuff and local tools. Local scripts just by teams. Yeah. Can you just send a mail to DDA about the report of this meeting and then ask people to send you a short report. Oh, maybe you could ask. I'm not sure that Steve asked about that in his team summary. No, don't think so. Send a mail to DDA with a report from these buffs and then ask people to send you a short report about each team and what specific tools they use. Yeah. So you have a global picture. Mm-hmm. So... I suggest you use the QA to discuss the further actions. Yeah, yeah. I'm even subscribed. We don't have poison with people there. Okay. Good. And then we had this point about documenting the workflows of different tools where there were the proposals of using Rhythmisaurus of using the Vicky team's pages and also this idea of the abstraction package per team that also contains some documentation about the team. Should we look at this a little further? I think it came out of this. It's difficult to know how different teams work and stuff like that. I think that's just stated and I think we don't have much to argue on this topic. We just have to do it and it's something that each group should do according to its rules. Yeah, but if each group does it differently than where we are now. No, but as it stated we should document what each group is doing. Rhythmisaurus is only used where standard when there are patches or strange building things which even in a group can happen in different ways although we try not to have it. And well, yes, explaining I think both in the group's page in Alliot and in the Vicky explaining in a human-readable way. But besides that this is geared towards explaining to other humans and I don't think there's much guidelines to agree completely often. About how to encourage teams that do not have yet an entry and slash teams to have one. They are just not aware of the impact. This is something that should be written in developer reference or whatever. If you have a team developing stuff or packaging stuff please add your entry under slash teams. Yeah. Do you remember about that and your idea you made? I was just thinking about directly contacting teams but we don't really know which teams and how many teams we have. And also there's a very wide definition of teams. We are packaging teams. That narrows the things. For example, I don't see anybody here from KDE. I know they are a well-known team or the games team. But formally every commentated package is maintained by a team. There's someone who did a kind of script to extract the maintainer which matches some concept of team. It's a link.txt file named teams of 2007. But there is no script. We used to do that. That's interesting. Good. Try to remember the others that they should use the wiki slash teams to make it easier for others to find out how the team works. That's it. Okay. Two, we have something else. While I've also put this non-technical stuff about the new members. Oh, we have ten minutes left. About the new members here, I'm not sure if it's of general interest but I admit that I am interested in social things. That's why I propose to spend a few minutes on it again. Well, these are the things more or less that we have collected on Thursday. Is there... Well, now the pre-ultimate one, encouraging Amps to join teams was more an idea of me. I don't know if it's useful or not. How can this be done? Well, there are several problems here. The first problem is get people interested into Debian development and then get them into teams for different issues. And I think that many people just don't realize that it could contribute to Debian development by joining a team and helping the team. And that was actually my case for years. I was a user of Debian and just couldn't see why Debian needed my help. And we really need to focus on sending this message that if you are interested in Debian development you don't need to have someone, something that you want to package. You can just come, join teams and help with the existing package. That's not a message that is really well given out. Well, I will speak as a user trying to have a group. I was trying to join a group in Debian. I am trying to not say which group of course. But the first thing I did was to login in the IRC which in the web page they said that's the best thing to do. So I did that. I asked, okay, I'm new here in which way I can learn and help. And they told me start closing bags. Okay. Yes, I read the documentation in the web page which is helpful but not a lot. It's a collection of separate things that you have to mix and try to understand. And then you have to wonder if this group contains a big thing actually it's the KDE group being the QT KDE group. And what do I do? I have to start wondering all those bags for all those packages I can understand that the people in the group are working the bags and perhaps they're not thinking about training someone to do it because when you're working you're trying to close bags and get things done which is what most of us try to do but I found quite a problem to start doing it because I don't really know how to do it. What steps should I take? Perhaps I closer for example my first bags and I wasn't sure I was really doing it fine, I asked in the mail and they said you forgot this thing okay. And that's everything but nothing that you did well perhaps I'm missing some part of it. So actually this is a bit of getting a bit of topic but this is exactly what are the gift tags which look as a proposal actually so if you're part of a team or even a single maintainer and would like to mentor someone which is new to Debian in doing stuff you can just tag your bags with a gift and then they will show up in the PTS and the idea is that if you tag a bag gift you're willing to mentor the interested guy in entering Debian. So going back to the relationship between NM and teams I think it's a really good idea actually because usually in team it's easier to contribute smaller part than with just going and creating bags or fixing bags or whatever but this brings us back to how to know which teams do we have in Debian which is really not formalized and but if teams if we know which teams do we have and if teams follow the template actually in that template there's even a list of things the team is in need of so in theory newcomers can just go to the wiki page of a team and look at what they need and then join, contact them and start to work on the to-do items Yeah I think if the wiki page is complete and that's a good point interesting thing is how to get the people there to make them aware of as Lukas has said you don't have to package new stuff, just come a team and help out and then, oh five minutes left and then as Nisandre has said you need to be welcomed and inducted, mentored whatever in the group and maybe I'm wrong but I don't think that there are a lot of concepts in the group how to deal with new members in a systematic way might be interesting too to your point I think you could be more self-confident people are sometimes a little bit grumpy and will not reward your work but normally they do I don't say this good but we try to invite people and be friendly to them this is one point another point is to maintain a wiki which lists something which can be done by developers and by users we divide this but are there any experiences how it's possible to maintain that a wiki is really up to date it is so nice and so good to have a wiki somebody has an inspiring idea and puts it on a wiki and three years later it's always there, perhaps some other ideas but are there any experiences mine are always quite bad not everyone at the same time please I have the same experience here okay so that's an open task let's go to the last slide which just says who does what until when well so what have we got that has to be done Tim has right nice minutes I will take a look at them and and send them out in yeah that's my job and I think I should that gets done today yeah then we have this collection of the tools offline and online should we have a deadline for people sending the pointers to me what would be a reasonable deadline for that yeah one more question did you got the nice stuff which Sledge got according to his request for how groups work together so is there any possibility it was private so okay thank you okay so I will also look into my own calendar the deadline in well probably in September usually people respond to email in a timely manner and the problem is if you set a deadline people which will wait until the last one reply to the mail if you said no deadline I think they have to reply no that can happen too yeah okay anything else that needs to be done in the near future anything this because it was really great for well thanks you all for the great cooperation and I really like to work in teams and also like to work in this kind of meta team and yeah I hope we can continue this well maybe we could have well I won't be able to attend but we could have a meeting in extra Madura or a meeting at first them about that maybe and because then we'd be better because it's also really appropriate for the QM meeting actually so another open topic for which we have no solution actually as far as I understand is how to list all the team we have yeah so I think this is really important for various reasons for example if you have the list you can automatically retrieve the list of to-do for the teams and show them in suitable places and this will diminish the probability that they get out of date so we should really think how to standardize, formalize which teams do we have stuff like that okay so I think that's it thank you all