 I'm glad that there are so many people interested in backports. We will be tracking some of this stuff in the goblet document, DC-11, both backports. So if you want to add something or drop some ideas, please go to this document and write it in there. GobletDVNet is also accessible from the outside world, so people watching the stream can join us in here too. I expect most of you know what the backport service actually is. We are providing a place for new packages with newer features for stable. As we all know, there is no new code allowed into a stable release once it gets released. Only security fixes and bug fixes are allowed therein. For some things, people want newer features within the packages. So we have the backport services where we offer versions from testing for recompiled in a stable environment, so that they can directly be used on a stable system. Since last year, we are an official service, which means we are using the official infrastructure, like the official build demons, and are also included in the main archive, sort of, at least on the official FTP servers. But there are still some areas where we would like to be better incorporated, and this session is about naming them, potentially finding out who we might to involve, who we might to address, and ask what needs to be done and how to get it incorporated. The most prominent part is the bug tracking system. We are not included there yet for several reasons. The bug tracking system currently can just store a single maintainer for a package, and often, in some cases, the person who takes care of the backport is not the official maintainer in the main archive, so it would need to be able to track two different maintainers. The other thing is it doesn't know about the versions within backports yet, so it might need to incorporate the backport changelogs also into the version graph to be able to do the version tracking there. I think maybe you are able to give an insight if there are some more areas that need to get addressed, just these two points. The multiple maintainers is an issue that would need to be addressed. Version tracking, I'm pretty sure, would be able to handle it. It would do it similar to the way it does it for security. Not unstable the experimental. It would pretty much be just another release that's tracked separately. Experimental releases are tracked separately from regular releases to unstable, and the version tracking already handles that. To some degree, I would hope that people who do the backports would subscribe just to the back edge through the PTS so they get bug notification, but on the other hand, some people do have a strong opinion and objection in respect to doing that, so I think the best option here is really to get multiple maintainers support into the backtracking system. Another point is that the packages side doesn't show the changelogs yet. This has been on my agenda for a while. The FTB master team offers us already extracted changelog files and copyright files, not only for the main archive, but also for backports and also for security. So the benefit would be for all of these parts. The package sites currently does neither display the changelogs for security uploads, but this would get done at the same time. If someone is familiar with Pearl and Template Toolkit probably, please get in contact with me if you're interested to work on this task. Also, Deput does complain about included ORIG source in the first upload to backports. Which it somehow should not because it's a different archive and it needs to get the ORIG source uploaded there on first upload. So this is just a minor issue, but it also needs to get addressed still. I think that I'm personally not using the upload, but it might have the same issue. I'm not sure if it does check something like that. This also includes it's deep package scan changes. It would be very convenient if it would include the ORIG source, figuring it out either through the version or through the changelog, which Buxy once suggested to me when I asked him how to do it properly. This is also a piece of pearl code. So it would be quite nice if someone is willing to invest a bit of time. I think it shouldn't take too long, but it should be done properly here because this is really an issue. A fair amount of people do forget to include the ORIG source on first upload and then get annoyed by receiving the reject mails and have to upload again. It's a bit cumbersome, so if this can be done, that would be really great. Also, there are quite some Lintian warnings which should be silenced with respect to backports like the NMU check comes to mind, but I think there might be some other Lintian warnings which could be addressed or maybe even added to make backports better in that respect. There's one thing that I haven't put here yet. After a year spinning around, I started with a small script like an upload queue that you can upload at any time, and it will check the version both against the testing and the backports archive and would put it into the real upload queue when the time has passed to get it included. This would enable people to prepare the package at the same time they do the upload to unstable, drop it there and not have to think about it and do the upload when the testing transition happens so they can already upload it beforehand, have it done, have it tested in their environment and they still should be able to get it removed in case they find troubles, but that's usually an idea behind it. It's not finished yet, but it's one of the ideas that are spinning around in my head. That's more or less the ideas from my side. I would like to know if there are some other services or improvements that you would like to see, even if it might not be software that's unrelated, sort of unrelated to backports, but even within the backport service directly, if there's some enhancements that you would like to see, please bring up. How are you currently tracking security issues using security tracker Debian? Yes, backports is included in the security tracker for a pretty long time even before it became official already. I'm very grateful, very thankful that Florian added backports to the security tracker. There are obviously some false positives at some point and I think there is no possibility yet to mark security problems specific to backports or not relating backports, but at least it's possible to get a list of issues that potentially affect backported packages. Are there any plans to move the backports archive into the main Debian archive so that all the Debian mirrors carry backports? ETA? Yes, there is a plan to actually get all the archive security and backports migrated into the main archive. We don't have a real ETA on that because it needs some coding. Come to the buff on Thursday for duck coding. We need more coders. So if there is a potential for an archive merge, would that remove the issues about the fail to upload the original source in the backported packages? Yes, that will reduce that issue or get rid of it completely. Also for the security team. Related to that, could we get the backports archive automatically pull the original source from the main archive if it's not uploaded? Send a patch for duck. Give me a patch? I'd like to mention something that more or less more often appeared on the backports mailing list in recent times that I responded to. The backport service is not for working around getting bug fixes into stable. The backport service is about having new features available in stable. So if you are annoyed by a bug in a package in stable, please try to get it fixed in stable and not get a backport of the next version just to get that bug fixed. That's the wrong approach. Did I cover everything up so well that there are no more ideas spinning around how to improve? It isn't actually an infrastructure improvement question as such, but one of the policies for backport uploads right now is that the changes file include all the changes from the last uploaded version that you are uploading right now and that's really painful for no apparent use. So is it planned to change that policy? No, not change logs, changes files. When this point is done, that will get this point removed from the policies because you can do then you can do aptitude change log and get the change log for the backport version. You can look it up on packages dvnorg before you download the packages and that's for me the reason to get rid of this specific point in the backport policy. No more further questions. Can you publicly comment on the policy that packages from unstable that are installable as is unstable should not go into backports? That's more or less, it depends. If there is a user base that would like to see this package available on stable then that's a clear sign that it can go to backports even if it's directly installable from unstable. It is there to not have every single package that you maybe just use for yourself and other users might not use, you put into the backports archive to not make it explode because every single package might affect something else. Like we had, I think it was Xulrana which had severe influence on even GNUG hash. Yes, and there might, especially with libraries, there might be some influence on other areas and the fact things that you might not foresee and because people use backports on their stable system they expect a certain stability from these packages and therefore we really would like to keep the packages at a minimum area. But I know that pinning can be quite a pain in the ass so you really go feel invited if you have a certain user base that is interested to have the package backported or if you'd like to have it installed on a DSA-administrated Debian org machine then there's no way around to get it into backports so just do it. Is anyone following on the IRC? Maybe someone commenting there? Do you have a good way of determining whether or not there is a user base that might want a package in backports that if, of course, you're not aware yourself? Well, it's always the judgment of the maintainer. We also expect the maintainers to upload us to the unstable archive to make proper judgments in that respect. Like Thomas Koch mentioned some package that he got removed from the archive again because he wasn't very keen on the quality of the code of the project and to some degree we expect similar judgment and we have a certain trust in our Debian developers that they make proper judgments in that respect. What's the status of allowing all Debian developers or Debian maintainers ability to upload to backports? About Debian maintainers, the person that would be able to answer that just left the room. He knew I was going to ask that question. I think it was planned but I don't know the details. Yeah, it's definitely on the agenda. I think there are some sort of technical problems because the code to some degree differs from the main archive to backports and I'm not involved in encoding duck directly so I can't really comment on that part about allowing everyone to upload directly. We usually approve everyone that wants to upload. On the other hand, we want to have this certain that the reason behind the exact hearing to some degrees to make people aware that these packages are directly installed on stable machines and want to remind them that they should just upload with special care and it's just an additional reminder for that. It's not like we are blocking requests to get added to the key ring. You're back. There was a question directed at you about the status of Debian maintainer uploads for backports. So it's on hold. It seems we have happy users and happy developers. That's very great. So thank you all for using backports. Of course, thank you all for contributing to backports, taking proper care of your packages within backports, responding to bug reports specific to backports and for not getting annoyed when someone else uploads your package to backports and you get bug reports about that. We will continue with the service. We get good feedback from a lot of areas and we see that it's really needed and we are glad that it is also appreciated. Thanks.