Re: All candidates: Development and technical issues and challenges
> 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
Reply to: