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

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



Hi Yavor!

On Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov wrote:
> This asset is not something to be proud of because of shallow
> marketing reasons -- it benefits the whole Free World as many bugs are
> uncovered, reported, and fixed, quite often by Debian people.  It
> would not be incorrect to say that, having in mind how many packages
> are available in the archive, and the GNU/Hurd + GNU/kFreeBSD ports,
> Debian is the most comprehensive testground of the GNU system.

Absolutely, it is one of our distinguishing values that we should
cherish more than we currently do.  FWIW, there is nothing wrong in
using it _also_ for marketing reasons. In general, the kind of marketing
based on our distinguishing features (and this is one of those) is our
best chance to attract new contributors.

> - m68k was the first "kicked out" arch.  AFAICT, it is essentially
>   dead now and not even a miracle can save it.

That is was kicked out by the current rules is true (actually, that is
what it seemed to me as a DD non-porter, people like Wouter surely knows
more than me about extra details, if any). What I don't share of this
sentence is the feeling of causality it gives between being kicked out
and then dying.

I sure do not want to deny that a non-release arch is looked at by less
eyes, and that the project in general cares less about it (e.g. as the
bugs are not RC, they are less likely to be NMU-ed). But an architecture
which is suffering anyhow---for instance no maintenance of the toolchain
or no buildd admins for it---would not necessarily be any better
supported for end users. Also, the process of arch qualification goes
both ways, and the entrance of GNU/kFreeBSD as a new release arch is IMO
evidence of that. In fact, if the above impression of causality were
true, we would risk to be stuck to not having new archs in the future,
which luckily is not true.

Ultimately, I believe that when an "average" package (i.e. not a monster
package) is properly maintained, the maintainer will be happy to apply
patches that add support for an arch, even if it is not (yet) a release
arch. You might argue that there are several average packages which are
not properly maintained, but that's a whole different problem ...

> * Support for old (and not only old) architectures cannot be infinite;
>   and there's a line to draw somewhere when it comes to a release.
> * There should be an entitiy within the project to decide which arch
>   gets released and which not, which one is blocking the whole release
    <snip>
> * There's not much a DPL could do except some publicity and
>   RFH-oriented efforts which are known not to work well...

AOL

I was thinking along the same lines while reading your post thus far,
thanks for sparing me to write these :)

>     Porters are an extremely valuable resource, and the survival of an
<snip>
>     Therefore, it is essential to preserve, and even grow, such
>     resources by doing all possible to attract people with sufficient
>     knowledge and also pass that knowledge through.

Agreed.

> What do you think the project should do (with or without or regardless
> of your help as potential DPL) to preserve this goodness (maximum
> supported architectures) for as long as possible?  Do you think it is
> "goodness" or you're in the "good riddance" camp?

I'm surely on the goodness side. More generally, I'm for defending and
advertising more all of Debian distinguishing features, and our range of
supported archs is surely one of them.

On the side of developers, ideally we should not accept maintenance
behaviors in which patches that add support for non-release archs are
regularly ignored, but that can hardly be imposed to people. Let's just
aim for packages which are in a good maintenance status (more QA, as
usual) and I believe that more reactivity to porters patches will come
for free.

On the side of porters, we cannot create them magically. All we can do
is (1) do our best to attract them (because we know such rare entities
do exist :-)) and then (2) put them in the best possible condition to do
what they like.  To improve their work condition I fear the DPL can do
little more than ensuring our arch-specific machine park is up to par.
To attract them, advertising arch support as I said above would be a
wonderful start.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature


Reply to: