Features Download
From: Moray Allan <moray <at> sermisy.org>
Subject: Re: All candidates: Development and technical issues and challenges
Newsgroups: gmane.linux.debian.devel.vote
Date: Monday 11th March 2013 19:30:59 UTC (over 5 years ago)
On 2013-03-11 01:35, Lars Wirzenius wrote:
> 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?

On one level I'm cautious about answering this.  I don't think that a 
DPL should try to impose policies on teams like the Release Team, or 
push their own ideas on this kind of topic rather than trying neutrally 
to push forward a project discussion.

However, to give some of my own views, since you ask for it:

Background: It seems to me that part of the problem comes from the 
Release Team's own past success.  Individual maintainers have got used 
to Debian releases happening more or less painlessly, and just assume 
that the Release Team will get on with the work, and release when it's 
ready.  But, of course, the release should be the responsibility of all 
maintainers -- and if too many of us just look after their own packages 
and leave the Release Team and a few helpers to do the rest, we will be 
waiting until the slowest maintainer has fixed the hardest bug.  At the 
same time, as a freeze gets longer, and without a specific immediate 
deadline, it becomes harder to motivate people to put energy into 

Earlier removals: I wonder if removing RC-buggy packages much earlier 
in the freeze would help -- even if it's logically no different to 
saying they will be removed later, it might wake up maintainers into 
bug-fixing action faster, and especially maintainers of packages that 
are removed due to their dependencies.

Flag up RC bugs: To tackle things earlier in the cycle, perhaps we 
could push use of some tools[1] that more actively flag up new RC-buggy 
packages to users of testing?

CUT: I think that some form of Constantly Usable Testing would be 
preferred by many desktop users to our current releases.  This would 
solve the freeze problem for that group of users -- though I worry that 
it might further reduce the number of people putting energy into our 
current type of releases.  Equally, I wouldn't expect the existing 
Release Team to make CUT happen, both because of lack of time, but also 
because they're likely to be self-selected as people who like the 
current style of release.

When to release: I would also note that we should continue to be 
flexible about "-ignore" tags where appropriate.  In some cases leaving 
a package in the release with RC bugs is more useful to users than 
removing it altogether.  Indeed, we always release with quite a large 
number of non-RC bugs, some of which make the packages in question 
unusable for large groups of users.  At any point in the freeze we 
should ask not only about the state of the frozen release, but how it 
compares to the previous release.  Maybe it doesn't even need to be a 
single date -- we could badge the new release as ready for the desktop 
before we close it off as final and suggest that people upgrade their 

Infrastructure: We should consider how we can help things by 
improvements to our technical infrastructure, in particular by making 
package source available in a shared DVCS, with tools that will 
automatically transfer patches to and from the BTS.  We should be able 
to find a technical solution so that source is automatically committed 
at upload time for packages where the maintainer doesn't (yet) want to 
shift to the DVCS workflow.

> 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?

For the freeze people work under lighter NMU assumptions than usual, so 
this is not so relevant there, but:

I think some work is made much less productive and interesting by the 
strong idea of package "ownership" that we see from some maintainers.  
While their intention may only be protective, to make sure that the 
package stays in the best possible state, we should recognise that we're 
only working with software, and it's generally easy to reverse or fix 
changes later.

> 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?

For me, the biggest challenge over the next five years is to keep being 
a "universal" operating system.

We're doing very well on servers, and I don't see that changing in the 
next 5 years.

We're providing a great free desktop ... but will it work on any 
hardware people will be using in five years' time?  More and more of 
people's computing is being done on phones and tablets where we mostly 
don't run, or only run as a toy within a special sandbox.  Even if we 
package upstream software that is great for tablets and phones, at the 
moment it's very hard to find devices where we can tell users that 
Debian will work.  And we have related issues to face even on computers 
of a traditional form factor, with worries about how UEFI Secure Boot 
will be implemented.  I think we can rely on there being being good free 
software for all these classes of device five years from now, but will 
you be able to install Debian on them?

If we want to keep on being a universal operating system, rather than 
relegated to servers, we need to gather people interested in this 
challenge and support them in their work.

A few relevant links:

(A somewhat related non-technical challenge we face is that even 
someone who only installs free software from Debian main is now likely 
to spend a high proportion of their time using non-free software 
delivered from remote websites.)


[1] Plural because different kinds would work for different users.  I 
don't mean to limit this to something in package managers, but e.g. 
desktop notification items for people who like that kind of thing.
CD: 3ms