damjan.jov at gmail.com
Mon Jul 4 23:13:32 CDT 2011
On Tue, Jul 5, 2011 at 4:50 AM, Keith Curtis <keithcu at gmail.com> wrote:
> None of the Linux kernel developers are paid by Linus nor can be fired by
> him. Linus never forces people to respond to his mails or to work on
> anything. What has happened is that the team has realized that having goals
> and leadership has led to good results, and Linus is a good leader, and so
> they follow along. If Linus says something needs to be worked on, it
> happens. The rest of the people keep doing their own work.
> I'm not suggesting to force people to work on iTunes. However, it shouldn't
> take too much prodding for people to want Linux to work with one of the most
> important hardware product lines.
> It is sad that Linux in 2011 cannot run iTunes. This is the fault of WINE
> and Apple. Maybe the work has been slow. I can't speak to how quickly you
> are moving, only the results. I have read through your code some years ago.
> The software that existed was high quality. You keep getting bigger and
It's easy for Linus to ask people to fix regressions, and they get it
done in a few hours, under threat of their patches getting thrown out.
Unlike the kernel (and to its detriment), we have regression tests
which work even better for that, because they stop bad code from
getting committed in the first place, and during a release freeze
extra efforts are made to reduce regressions. But adding a new feature
is something completely different, because it's not a matter of fixing
existing code, but producing new code.
> I understand you have a lot of work to do. That is why I suggest priorities
> or goals. They help manage large workloads. From the outside, you appear to
> be working on things randomly, and you can do better.
I = importance of a bug
W = work needed
then I/W is the probability the bug gets fixed
eg. Wine doesn't compile -> I is huge -> fix is rapid
a small typo -> W is tiny -> fix is rapid
iTunes has native alternatives, few people have iXxx devices, Apple
fans generally use MacOS anyway -> I is small
fix requires device drivers, changes to multiple systems, knowledge of
Windows and Wine internals -> W is large
So the I/W for iTunes is tiny. In fact the only reason it might get
fixed by me is because iXxx devices are part of the larger group of
USB devices, thus making I larger without increasing W.
It's worth noting W is always large for hardware problems. Serial port
support in Wine has also dragged on for years, had many bugs and
regressions, needed kernel changes for some USB to serial converters,
and still doesn't always work because the kernel API is too limited.
Relative mouse events needed X changes and have also dragged on. Sound
support in Wine has also taken forever. From what I see this isn't
unique to Wine, hardware support is the bane of every open source
project - even the kernel doesn't always boot. We could really use
some kind of public hardware test farm.
You're convinced me to prioritize my work on USB support, but it will
still be +/- end of 2011, with luck.
More information about the wine-devel