[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: All candidates: Development and technical issues and challenges

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 helping.

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 servers.

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.

Reply to: