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

Re: What demotivates debian-arm? [Was: Re: Bug#425011: gcc-4.1: FTBFS on m68k and arm, multiple definitions of ffi_prep_closure]

> You know I luvs 'ya, so we can get all of this out into the open.  Don't
> hold back anything, ok?  :)

Well, my opnionion is that flaming is the best way to demotivate ;)

(about the armel port)
> ... seems to be pretty good.  Maybe the internals aren't all that pretty
> (I haven't looked), but given that it's only been in existence since
> January '07, I'm willing to suggest that it's not really mature yet.
> But in the abuse I've been giving it, it's held up pretty well.

Well, for example the toolchain issues (fortran, java) are still in the
same state as in January. On the other hand we have now armel buildd's
(with responsive maintainters) and many of the patches have have merged
to upstream packages. There is still a long todo-list[1], including
setting up a developer access machine.

> >If I read the annual report correctly, ARM-the-company sold 2.4
> >billion ARM core licenses in 2006, but now we can't find ARM CPUs
> >anywhere?

> The limited resource hasn't been hardware, it's been the attention of 
> people with the right skills.

Indeed. For etch, we basicly fixed the "available hardware" issue with
nslu2 and iop ports. You can get a debian arm machine for 80€ from
almost any computer shop. Finding someone who can take responsiblity
of gcc/gcj on arm is harder. Kernel is another hard case, but so
far arm kernels have been well supported upstream.

> >Since we're on the subject of "things that demotivate people to work
> >on the Debian ARM port" anyway, knowing that someone else is being
> >paid to work on some issue or might be paid to work on that issue is
> >a very good motivator not to work on that issue yourself.

> For the people who "don't know what to do", having someone consistently
> available to them who DOES know what to do is a real benefit.

It's more complex issue than that. Sure it's easy to appreaceate to see
someone who really knows their stuff gets paid who's work helps making
debian better. For example the abi port would be nowhere without
codesourcery's work. But if it is the opposite - You know someone is
getting paid and you have to help him constantly to get his job done..

The other side is that volunteers might skip tasks that they expect
someone else might need more. "someone else needs this badly so
they will do it themself (and perhaps get paid for that)".

> >(Which is incidentally also the reason why a Debian ARM EABI port took so 
> >long -- if there was no money involved we would have had an ARM EABI port 
> >6 or even 12 months earlier.)

> And in that announcement, which is dated January 10, 2007, you claim to 
> have not started working on EABI until November 24, 2006.  So I don't 
> know where your "6 or even 12 months" is coming from.

I don't think his is referring to his own effort, but rather a previous
effort that failed produce visible results.

> If you want to work on a volunteer basis, you're certainly free to do so 
> (if you don't, that's fine too but it'd be a real loss and I for one 
> would miss you greatly).  


> Finally, the fact that I get paid money to develop embedded systems puts 
> YOU off Debian?  

My theory is that embedded Linux people have not learned to co-operate
same way Linux server people have. Most embedded linux vendors and
manufacturers do not talk with community, create crappy forks
and in generally get things done as cheaply done as possible.
Thus volunteers often end up feeling exploited when they find their
work being used in some crappy glue-together. The volunteer gets the
feeling that "someone got paid to do THAT crap?". To be clear, 
I don't believe that your consulting belongs to this category :)

[1] http://wiki.debian.org/ArmEabiTodo
"rm -rf" only sounds scary if you don't have backups

Attachment: signature.asc
Description: Digital signature

Reply to: