| 1 |
On Sun, Apr 28, 2013 at 12:12 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 2 |
> On 28/04/2013 18:11, Canek Peláez Valdés wrote: |
| 3 |
>>> What we complain about here is basic low-level software changes that |
| 4 |
>>> > affect much more than just their own little universe, and will do it ON |
| 5 |
>>> > ALL LINUX MACHINES NOW AND IN THE FUTURE. |
| 6 |
>> The source is out there NOW AND IN THE FUTURE. If there is enough |
| 7 |
>> developers interested in maintaining something, it will be maintained; |
| 8 |
>> but you cannot force no developer to maintain nothing. |
| 9 |
> |
| 10 |
> You keep saying this, over and over in many places for many reasons. |
| 11 |
> |
| 12 |
> But it just is not true. |
| 13 |
> |
| 14 |
> It's easy to get a dev to support something - you just ask them. |
| 15 |
> |
| 16 |
> Have you ever asked a dev to support something you needed? |
| 17 |
|
| 18 |
Yes of course; you can ask a developer for anything: you can ask him, |
| 19 |
for example, to throw himself over a cliff. Believe me: he will |
| 20 |
probably not do it. |
| 21 |
|
| 22 |
I said: you cannot *FORCE* a developer to maintain nothing. You want |
| 23 |
to *FORCE* them to support PA-less systems (in the case of GNOME, |
| 24 |
perhaps, in the future) and /usr-separated systems without initramfs |
| 25 |
(in udev case), only because *you* think is the right thing to do, or |
| 26 |
because it was previously "supported" (in the /usr-separated it was |
| 27 |
actually a problem waiting to happen). |
| 28 |
|
| 29 |
The developers in those projects made their choice: make yours. Stick |
| 30 |
with those projects and accept that the developers word is law; or |
| 31 |
contribute so that your word has weight; or fork the project; or |
| 32 |
switch projects; or whatever. Complaining over choices already made by |
| 33 |
the people in charge is not very productive. |
| 34 |
|
| 35 |
Of course you can express your opinion. But without any code behind |
| 36 |
it, the most probably outcome is that it will be ignored. |
| 37 |
|
| 38 |
Even more in a place like this list: some Gentoo developers read |
| 39 |
gentoo-user, and from those even less are upstream in certain |
| 40 |
projects. But the majority of the people writing the code (the kernel, |
| 41 |
systemd-udev, PulseAudio, GStreamer, GNOME, |
| 42 |
whatever-application-you-use) most of the time don't read this list. |
| 43 |
|
| 44 |
Complaining here about PulseAudio being a hard dependency on GNOME is |
| 45 |
basically yelling into an echo chamber: you will most of the time get |
| 46 |
only responses from people with the same opinion as yours, and they |
| 47 |
all will get into a long rant about the evils of who-knows-what new |
| 48 |
fangled project that goes against "old Unix principles" (whatever that |
| 49 |
is). And. Nothing. Will. Change... because the people coding the code |
| 50 |
are the ones making the decisions. And they do not read (in general) |
| 51 |
this particular mailing list. |
| 52 |
|
| 53 |
The developers in several projects are making their decisions; |
| 54 |
sometimes they listen to users, sometimes they don't. If we don't step |
| 55 |
in and contribute code to said projects, arguing here about what |
| 56 |
constitutes a "good" or a "bad" developer is pretty pointless. |
| 57 |
|
| 58 |
To finish (this mail and my participation in this thread), you know |
| 59 |
what developer is famous for not listening to users? Linus Torvalds. |
| 60 |
Google what has happened whenever someone has tried to set up a |
| 61 |
petition campaign to get something into the kernel. |
| 62 |
|
| 63 |
And he's certainly one of the best project leaders we have. |
| 64 |
-- |
| 65 |
Canek Peláez Valdés |
| 66 |
Posgrado en Ciencia e Ingeniería de la Computación |
| 67 |
Universidad Nacional Autónoma de México |
Archives