Re: Question for all candidates: Release process
* Charles Plessy <plessy@debian.org> [100327 06:17]:
> 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.
Even repositories from the same project tend to diverge enough that
everything fails apart from a user perspective. One of the biggest
practical advantages of Debian is that there is one Release of
virtually everything. Everything fits and no incompatiblities of the
different 'unimportant' things (Remember what is unimportant for the
general is still important for most the people using it).
Thus splitting the archive in "core" and "non-core" can at worst create
multiple diverging no longer matching repositories for the different
tasks. And at best causes one core system freezing earlier and then all
the rest freezing based on that, which is something Debian already tried
without splitting things apart and I got the impression people did not
think that lead to anything but problems.
> 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.
We lack manpower in core tasks. In the packages that are "too big to
fail". People never had much problem to keep packages unimportant for
the general out of releases (even to the point of packages I miss desperately).
Some system to direct focus might be nice, but I really doubt it would
change things much. Anyone with a little bit of knowledge knows what the
core packages are and that fixing those is more important. You can't
tell me that the hordes of "gosh, there is a bug in some little game
that is RC since 3 days, with a one-line fix that is already in all
VCSes but in no package because there was no upload for a year,
let's NMU fast" people will suddenly stop reaching for low-hanging
fruits and instead look at bugs that cannot be fixed without looking for
at least a week at it?
> Our current priority system does not fit that task. Because of the rules about
> conflicts, important packages like postfix are of priority extra.
How is postfix important? It's not installed by default, the majority of
people does not need it.
It may be important to you and many other people, but virtually every
package is important to at least one person.
> With a priority system improved along this direction, I think it opens the
> possibility to let some architectures release without the least important
> packages.
What is "let some architecture release" supposed to mean. Being
subscribed to some architecture specific lists, I cannot remember people
active for some architecture ever requesting they do not want some
package. Usually that is the maintainers of the packages that complain
that those architectures are not enough like i386 to simply choke code
that should never had been open source because even the possiblity that
a human would look at it is a crime against humanity.
Not having some package in some architecture makes that architecture
much less attractive, because differences suck. Most people having more
than stuff still booting in 16 bit mode usually have multiple
architectures. Having one Debian that is the same everywhere is a very
big advantage from the point of the user. I cannot imagine some
architecture no longer wanting that, because that would mostly be
suicide.
So is this "let" supposed to mean "allow" or to mean "force"?
We also already have a possiblity to release without some package on
some architecture. Just stop building it and request removal from unstable.
There is a reason we frown upon this. Building stuff everywhere and make
it work everywhere is a big investment in quality and making things fit
for the future. I doubt without years of fixing bugs everywhere to make
things work on alpha (which could be seen to be mostly an architecture
born dead in a commercial sense quite early), introducing amd64 could
have been done thus smootly as it comparatibly was. And all those
alignment issues on most architectures usually also speed up code in
i386 if fixed properly...
Hochachtungsvoll,
Bernhard R. Link
Reply to: