> In your opinion, what are the fundamental reasons the release freeze is so > long, and so painful, and what do you propose to do, as DPL, to fix them?
The release process is hard to grasp. The most visible side of it is the number of RC bugs (which I contributed to increase :p) As a DPL, I will continue to support QA tests, because identifying bugs early is much better than running into them late in the release process. I will also explore ways to make fixing RC bugs more rewarding. For example, in the Debian Project News, we could list the most efficient RC bug squashers. But then, while in the ideal world, all RC bugs would be fixed, it's not that much of a problem to release with some RC bugs. There are other critical part of the release process: to release, we need an installer, release notes, etc. Those are parts of the work that are unfortunately not very rewarding and visible, and for which we have always had problems to find volunteers. There's probably a small margin of improvement for the release team to explain what are the requirements for releasing (a "why releasing is hard" presentation). As a DPL, I will encourage/help them on that path, and also try to recruit people to work where it's most needed (installer, release notes, release team, etc.). On a more personal opinion, I would welcome more exploration of gradual freezes. I understand that it's important to freeze early packages that affect the installer, and maybe also the base system. But freezing all packages with the hope that it will force people to fix RC bugs in other people's packages does not work: many people just stop working on Debian during the freeze. This was discussed a bit already, but I'm not sure that we really were throughout in the discussion. As a DPL, I will reopen that discussion at a good time (after the release, and not just after the release). Another possible area of improvement is the focusing on the more important RC bugs. One way to achieve that would be to remove as many leaf/not-so-popular packages as possible at the start of the freeze. If they get fixed, they could get back in. But then, if those packages are not so important, it's better to focus the (scarse) manpower on bugs affecting packages that we cannot live without. Another way to achieve the same thing would be to improve existing tools, such as http://udd.debian.org/bugs.cgi (which I developed) to indicate bugs that are release blockers, or bugs that affect leaf packages that could be removed. > What other development process problems do you see, ones that do not > directly affect the freeze, but make the development of Debian less > productive or less interesting? One thing that I find very frustrating is when your work is delayed because of things you can do nothing about. In the past, packages were manually signed on buildds, and it sometimes took a long time before the packages reached the archive (this is now solved thanks to buildd-autosigning). Another example is the NEW queue. While it's clearly improved a lot, it still happens that packages stay stuck there for a couple of months. When you spent hours packaging something, it's very rewarding to see the package in the archive ASAP, being available usable by users. However, besides making sure that teams are properly staffed and understand how harmful those delays are, there's not much the DPL can do there. Longer delays are probably quite unavoidable in a volunteer-based project. > Finally, what are the main technical challenges you see for Debian in > the next five years and what should we, as a project, do about them? I have some things in my platform about that, so I'll just copy/paste: State of the project [..] However, I often have the impression that the project is losing momentum, positive energy, and slowing down. It feels like we are living on the benefits of the past. A lot of very cool things happen in the Debian ecosystem, but very often outside the Debian project. It is good to be a solid basis for many innovative derivative distributions, but should we content ourselves with the package supermarket role? What should Debian be in 5 years? Debian should aim at reinforcing its position in the center of the Free Software ecosystem. It should be the main active intermediary between upstream projects and final users. Of course, providing a good basis for derivatives is important, because derivatives users are Debian users, even if some of them do not acknowledge that. But we should also aim at reinforcing the visibility and the impact of Debian itself, because the extremely important values we fight for as a project are often neglected by our derivatives. Yes, that means working on getting some of the cool stuff done by derivatives back in Debian, and creating more Debian products. For example, we have been providing a fairly good rolling release for almost 13 years with testing, but we totally fail at advertising it as something supported and usable by end users. And now that Ubuntu is considering switching to a 2-year cycle + rolling release, they might get all the good press instead of us. Couldn't we work towards addressing different needs and use cases with different products (rolling release, maybe live images), without compromising the quality of our stable releases? I even think that getting more users of testing would increase the quality of our stable releases by having more eyes to find bugs (reminder: the bug reporting rate has been decreasing). (also read "How do we get there?" later in the platform) More specifically, in terms of technical challenge, I think that we see more and more large pieces of software, with very complex set of dependencies. Stuff like Cloud stacks, Sage (maths stuff), OFED (infiniband networking for HPC), etc. Packaging those beasts require huge efforts, and it's not clear what's the best way forward: adapt our tools? (but how?), talk upstream projects into sanity? Lucas -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
