Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Lucas Nussbaum <lucas <at> debian.org>
Subject: Re: All candidates: Development and technical issues and challenges
Newsgroups: gmane.linux.debian.devel.vote
Date: Monday 11th March 2013 13:19:14 UTC (over 4 years ago)
> 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
 
CD: 3ms