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

Re: Question for all candidates: Release process

Hello Bernhard and everybody,

I think that the ‘RPM hell’ that you used to comment my propositions is more
related to a situation when independant distributions are using the same
package format, than when a distribution offers multiple repositories that obey
to a policy that keeps the whole system functional. We actually enter in the
era of the ‘DEB hell’ since the success of Ubuntu, with users asking support
for cross-distribution package installation. In the end, it is more a
communication problem than a technical problem. We should make it clearer that
it is not because the packages do not carry the distribution name that they are
not specific to a distribution. Perhaps a page about ‘our packaging system’ for
end-users on our website?

Regarding my proposal, that is internal to Debian, I do not think that it is
impossible. What I propose is a way for package maintainers to signal that
their package is peripheral in the Debian system, in an opt-in manner. Debian
is running out of manpower, and I think that it will be useful to let know that
a given package can be given a low priority for tasks. In my experience,
trivial RC bugs on not-so important packages attract volunteers because it is
very rewarding to close RC bugs. Also, I learnt a lot by participating to the
‘bug sprint’ organised by Josselin for Lenny, that we should not be discouraged
to challenge a bug that is far beyond our technical capacities, because help
like triaging and pinging the reporters is very useful and frees skilled hands
that are much more useful at other tasks. So in my opinion, not all RC bugs are
equal, and a better priority system would be useful to help volunteers to chose
their focus.

Our current priority system does not fit that task. Because of the rules about
conflicts, important packages like postfix are of priority extra. By
refactoring our priority system, we could make a much better usage of a
priority level that really means ‘extra’ in the sense of ‘do not bother if you
have more important things to do’.

With a priority system improved along this direction, I think it opens the
possibility to let some architectures release without the least important
packages. Once I reported upstream that his scientific software was not working
on Sparc. ‘I know‘, was the answer. This software, I want to bring it to the
scientific communauty, and like the upstream author, I know that no researcher
is seriously considering running it on Sparc for work.  Why not distributing it
only on amd64 until a user requests it on another architecture? Even on the
other platforms where it builds, I have no clue if it works. And in my
experience, the more regression tests I enable in my packages, the more I
realise that they do not work on the platforms that neither upstream nor the
users are using.

I am very tempted to go even further and would like to distribute some packages
for the stable distribution only through official backports for instance. Also,
in my field, while people usually want to have the latest version to start
with, they also do not want to change in the course of their analysis. I hope
that the future package snapshot system will help us to satisfy this need. In
conjunction with system image builders, Debian pure blends and ‘cloud
computing’, it will be very powerful.

Will it make the release easier? I think so, even if it is definitely not a
magical wand. It transfers some responsabilities, and the work load that comes
with, from the release team and the porters to the maintainers of leaf packages
of low priority. I would like the Debian project to trust more its maintainers,
and allow this transfer.

Have a nice week-end,


Reply to: