| 1 |
On Sat, Apr 27, 2013 at 2:38 AM, Alan Mackenzie <acm@×××.de> wrote: |
| 2 |
>> If GNOME has to support PA and non-pa systems, they need to code, |
| 3 |
>> test, support and bug-fix 2 different sets of of systems. If they need |
| 4 |
>> to support ConsoleKit and logind, the number grows to 4 (PA/ck, |
| 5 |
>> PA/logind, non-PA/ck, non-PA/logind). With 3 different optional |
| 6 |
>> requirements, it's 8 sets of systems. With 4, is 16. With n, it's 2^n. |
| 7 |
> |
| 8 |
>> That's exponential growth, which in CS is always no-no. |
| 9 |
> |
| 10 |
> WADR, that is simply false. With features which interact chaotically |
| 11 |
> with eachother, yes, you have exponential growth. With distinct, |
| 12 |
> self-contained features, each one is merely an incremental test effort. |
| 13 |
> ALSA and pulseaudio are self-contained, and are also well tested in their |
| 14 |
> own right. Only integration needs testing. |
| 15 |
> |
| 16 |
> If you were serious about this exponential growth, how on earth could, |
| 17 |
> e.g., the Linux kernel or Emacs, both with thousands of options[*], |
| 18 |
> possibly get tested anywhere near acceptably? |
| 19 |
|
| 20 |
I just have to point out that this is a misunderstanding. Neither |
| 21 |
Linux nor Emacs get the whole shebang of complete formal testing of |
| 22 |
all code paths. What they have is an informal "let the users |
| 23 |
participate in the beta", which is basically the _opposite_ of |
| 24 |
testing. (Well yes, we also use the English word "testing" to describe |
| 25 |
what's happening, but it means something else). |
| 26 |
|
| 27 |
That GNOME has a different opinion on their approach to testing such |
| 28 |
things is their opinion. After all, they're a _desktop environment_, |
| 29 |
and their users are _regular users_, they have an entirely different |
| 30 |
dynamic on beta testing from, oh I don't know, an OS kernel. |
| 31 |
|
| 32 |
>> But hey, the source is there; feel free to patch whatever needs to be |
| 33 |
>> patched in GNOME (and probably GStreamer) so it doesn't require PA. |
| 34 |
>> Just be certain that those patches will be rejected by upstream, for |
| 35 |
>> the reasons stated above. |
| 36 |
> |
| 37 |
> Making minor changes to free software is impracticable on a casual basis. |
| 38 |
> Only forking a project can do this. You know this full well. |
| 39 |
BULLSHIT. |
| 40 |
|
| 41 |
_EVERY_ _MAJOR_ _DISTRIBUTION_ DOES THIS. ALL THE TIME. Even Gentoo. |
| 42 |
|
| 43 |
Heck, the whole point of ebuilds is to make this easy to do. |
| 44 |
|
| 45 |
Case on point. For more than 5 years now, team wine has been |
| 46 |
stubbornly refusing to ship a pulseaudio plugin, even when there was |
| 47 |
wiiiide clamor within its userbase for one and 2 maintainers |
| 48 |
voluntarily stepped up with out of tree patches. Said out of tree |
| 49 |
patches have made their way into every major distro. And eventually, |
| 50 |
wine team wine bit the bullet and admitted they should have. |
| 51 |
|
| 52 |
http://bugs.winehq.org/show_bug.cgi?id=10495 |
| 53 |
|
| 54 |
Take a look at the files/ subdir of almost every ebuild you have and |
| 55 |
you'll notice that there are patches in it. |
| 56 |
|
| 57 |
-- |
| 58 |
This email is: [ ] actionable [ ] fyi [x] social |
| 59 |
Response needed: [ ] yes [ ] up to you [x] no |
| 60 |
Time-sensitive: [ ] immediate [ ] soon [x] none |
Archives