Lars Wirzenius <l...@liw.fi> writes: > Gegerly, Moray, and Lucas: > > We're currently in the middle of a freeze for the next release. We've > been in this release since June 30. That's over eight months. That's a > long time, even for a project the size of Debian. Releasing when we're > ready is all well and good, but it's a problem when it takes us so long > to get ready. > > 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 fundamental reason is that fixing bugs isn't all that rewarding in many cases, and considerably harder than doing packaging, especially in cases where one can't rely on upstream help either (for any of the million reasons). What we could and should do (and this includes everyone, not just the DPL) is to make upstreams, downstreams and everyone else involved realise that if we work together, we'll release faster, and if we release faster, we'll have more up to date software, which benefits everyone. I've heard many an upstreams (and users of downstreams too) complain about how old packages in Debian are. I myself am annoyed too about this from time to time, when I'm wearing my syslog-ng upstream hat, for example. But the only proper way to make things better if we combine our knowledge. To do this effectively, we need to learn another thing: we are not our packages. There is no shame in asking for help, or even giving up a package. There is no shame in joining a team. There is no shame in working together. All these things make us better, make the packages better, make Debian better, make the world better. Why we need to learn this? Because there are many half-abandoned packages in the archive, that make the release a lot slower than it needs to be. These should be found and taken care of *before* the freeze, and we should be doing this continously. We have a lot of data points that help us recognise these cases, we need to solve the social issues if we want to avoid these problems in the future. For that to happen, we all need to realize that we're not our packages. > 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? I feel the collaboration between Debian and downstreams is far from perfect, and that is usually a fault of both sides. Tiny little speckles of dust in the machinery some of these problems are, but if enough dust accumulates, the machinery will suffer. We need to figure out if - and how - we could work together more closely, to reduce the workload on all sides, as that also reduces the annoyance we may have with one another. > 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? Most of the challenges I foresee in our immediate future are non-technical. We're fairly good at solving technical problems, so no particularly huge challenge there. At least, not anything we haven't seen before. Nevertheless, what I do find worrysome, is that there seems to be a trend of upstreams bundling third-party components (often slightly patched) into their zillion-component, big and complex solution. Untangling this mess, packaging it, and keeping it functioning is very challenging, to say the least. Persuading upstreams to not do that is - sadly - simply impossible, so we need to either work around this, or bite the bullet and package the forks too, either separately, or bundled with the application (yuck). Another - at least partially technical - challenge would be to improve our own infrastructure and processes, in order to attract more (or at least, drive away less) potential contributors. (See https://lists.debian.org/debian-vote/2013/03/msg00157.html for more details) -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc8reess....@galadriel.madhouse-project.org