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

Re: Q for all candidates: (Old) Architecture Support



В Thu, 18 Mar 2010 00:02:56 +0900, Charles Plessy написа:
> Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit :
>> * There should be an entitiy within the project to decide which arch
>>   gets released and which not
> I do not completely agree with this:
> 
> I think that the porters should have much more latitude on how to what
> their port contain. If they can assemble a reasonable subset of Debian's
> packages into a working system that matches the expectations of the
> users and that Debian can be proud of.

Interesting.  Are you suggesting that bugs (mostly of the FTBFS type)
should be ignored at the discretion of the porters and other important
teams on a per-package basis (e.g. "Nobody in their right mind would
install `foo' here, so it's OK to ignore the bug")?

I think that this is a dangerous path to follow.  IMHO it is the
fastest way to *prematurely* kill an arch.  Problems will start to
accumulate, and issues with non-trivial inter-dependencies
(e.g. resolving one major bug depends on the fix for another,
sometimes in a different package) will pile up on the TODO stack,
which at some point would inevitably lead to "enough, this arch is
problematic, so we have no choice but to exclude it from the release".

Ideally, all architectures should be equal (in practice they are not,
but theoretically the criteria are the same).  If the project allows
the lapses you seem to suggest, that would be the end of all but
mainstream archs.  IMVHO.

> Architectures that lose their mainstream position and therfore
> upstream support in popular heavy-weight applications could survive
> much longer.

I seriously doubt that if your view/plan is in force.  IIRC, this plan
was discussed on -m68k (at least) several times in the past, and this
is a plan to hide bugs, to sweep them under the carpet.  YMMV, of
course.

(Just as a side note, you would be surprised how much "impossible to
use" complex/heavyweight packages people install and run (even for
testing purposes) on slow architectures.  It is hard to predict the
limit of users' patience, therefore I conclude that it is not possible
to state with certainty "package foo is not suitable for arch bar
because of performance reasons".  And yes, I say this from the
standpoint of experience -- my home machine park is "Jurassic", and
still I manage to do what I intend to do with the tiny computer power
available.)

> if nobody wants to fix the bug, it is a good indicator that
> everybody has more important, more rewarding, and in the end more
> fun things to do, and that we should trust their judgement by
> changing our release strategy instead of maintaining an institution
> that opposes people.

I disagree with this sentiment, but who am I to disagree...

If nobody wants to fix the bug, this probably means that the majority
of users are not affected by this bug.  However, it has always been my
understanding that a Debian package maintainer should look a little
bit more forward than her own packages, and should do her best to
ensure that everything she maintains is at least buildable on all
Debian architectures, including unofficial ones (whether former stable
ones or new, struggling to become official).


Reply to: