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

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

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, which one is blocking the whole release
>   process and ought to be ignored for testing propagation, etc.
>   Naturally, such entity is the Release Team, and their criteria don't
>   seem bad.

Hello Yavor,

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. Other teams (security, toolchain maintainers, …) are
qualified to tell if releasing a port with that given subset would perturbate
their work and therfore the other ports, and the release team would then be
the one to take the final decision.

I think that a simple reorganisation of our archive's sections and priorities
would open the way to such lighter releases. Efforts of developers would be
rewarded earlier. Architectures that lose their mainstream position and therfore
upstream support in popular heavy-weight applications could survive much longer. As
Wouter noted, it is probably when the core toolchain is not maintained anymore that
the port is severly compromised.

By the way, I would like to react to one of Wouter's comment, that package
maintainers should fix the porting bugs themselves. I really disagree. As a
pakcage maintainer, I found myself a couple of times in this kind of situation,
where nobody wants to do the work. This is a totally fun-killing situation. The
port threaten's my package's seat in the release, and my package threatens the
port's existence. Yet nobody ever complained that the package is not available
for that port…

What I mean by my not-so original ‘more fun, more trust’ credo in my platform,
is exemplified in this situation by the fact that 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.


Charles Plessy
Tsurumi, Kanagawa, Japan

Reply to: