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:
http://wiki.debian.org/Mobile
http://wiki.debian.org/TabletAndTouchScreen
http://forum.xda-developers.com/showthread.php?t=2070139
(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.)
--
Moray
[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: