1 |
begin quote |
2 |
On Thu, 22 Jan 2004 18:34:05 +0100 |
3 |
John Nilsson <john@×××××××.nu> wrote: |
4 |
|
5 |
> I do belive that the issue tracking system is flawed if these kind of |
6 |
> bug-reports is a problem though... |
7 |
> If all bugs was attached to a specific ebuild, this wouldn't be |
8 |
> problem would it? |
9 |
|
10 |
|
11 |
*cough* |
12 |
|
13 |
No. It would be an even worse problem. |
14 |
|
15 |
take a bug like this : |
16 |
http://bugs.gentoo.org/show_bug.cgi?id=38835 |
17 |
|
18 |
in this case it was simple to detect, just for me to check out the |
19 |
latest tree, scan versions and compare to information given. |
20 |
|
21 |
However, as seen here, its not an easy thing for users to know what |
22 |
causes a problem, if it is a library subdependency or something else. |
23 |
This is even worse when some testing library breaks interfaces, and then |
24 |
they install it, together with the updated development set that matches, |
25 |
and then -downgrade- again, however, parts are still linking to the old |
26 |
one, using the new interface, that one is rebuilt afterwards, and you |
27 |
are left with library mismatch and symbol relocation errors because of |
28 |
the changing interfaces. |
29 |
|
30 |
Yes, I've tried to debug such cases for users, who technically are |
31 |
correct, they don't have any "development" stuff installed anymore. |
32 |
That doesn't matter, their system is still borked when it comes to that |
33 |
library and all things inheriting. Causing developers a real pain. |
34 |
|
35 |
|
36 |
So, attaching all bugs to the single place of failure wíll obscure |
37 |
matters even worse. inviting people to a testing/bleeding edge tree |
38 |
managed by users will give us a severe headache. |
39 |
|
40 |
|
41 |
//Spider |
42 |
|
43 |
-- |
44 |
begin .signature |
45 |
This is a .signature virus! Please copy me into your .signature! |
46 |
See Microsoft KB Article Q265230 for more information. |
47 |
end |