Re: All candidates: Development and technical issues and challenges
Lars Wirzenius <liw@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]
Reply to: