1 |
On Sun, 2004-06-20 at 18:55 -0400, Travis Tilley wrote: |
2 |
> well most maintainers are on x86, no? i was venting valid frustrations here. |
3 |
|
4 |
At this point yes. My suggestions actually pave the way for that to |
5 |
change, I expected that to be something you would appreciate. |
6 |
|
7 |
> do i really need to defend myself here? if you think i shouldnt have cvs |
8 |
> access, feel free to let the right people know. i'm already suspended for |
9 |
> snapping at you. to quote another dev (anonymously) "we've been wanting to |
10 |
> tell foser that for a long time", so i'm assuming you've been pissing off |
11 |
> mips devs too. perhaps we should all have our cvs access removed :) |
12 |
|
13 |
Well, that makes it a lot less anonymous already. Personally I don't |
14 |
expect people to like me when i tell them they do things the wrong way, |
15 |
but someone has to do it. It used to be perfectly alright to tell |
16 |
someone an ebuild sucked, but nowadays we have to sugarcoat everything |
17 |
to not upset some fragile ego somewhere. I guess it's the size of the |
18 |
project thats interfering with getting to know and respect eachother. |
19 |
|
20 |
The dev in question can tell me in person how he thinks about me, that's |
21 |
alright, I won't hold it against him. The only thing that bothers me is |
22 |
that I always get criticized about _how_ I say someone something, never |
23 |
about _what_ I say. So in the end it usually turns out I do have valid |
24 |
points, only it gets snowed under in a personal attack on me. It's not a |
25 |
shame to learn. |
26 |
|
27 |
> the maintainer's arch cant always know about problems... for example, i was |
28 |
> pretty confident about gcc 3.4 after doing a 3.4 only install on amd64 and |
29 |
> ppc64 just to realise that this was still not really possible on x86 (at the |
30 |
> time)... and i only realised this from reading the forums and bugzilla, not |
31 |
> because some interested x86 dev came to me and said so. |
32 |
|
33 |
Other devs have 'special cased' the toolchain ebuilds archwise in this |
34 |
thread previously and I agree there. They don't really fall in the |
35 |
category where you can apply the basic QA rules, that doesn't mean the |
36 |
whole tree should be treated like that. |
37 |
|
38 |
Off-topic, as far as gcc-3.4.0 goes, in my experience with earlier |
39 |
stable gcc updates we never really moved on after at least 1 or 2 minor |
40 |
releases to smooth out the rough edges. .0 releases just tend not to be |
41 |
good enough, so x86 wise there's no rush in my opinion. |
42 |
|
43 |
> > Actually 'i haven't marked this as stable yet on my arch' is a good |
44 |
> > reason if the ebuild maintainer tells you so, for the simple reason that |
45 |
> > you lack the overview over the full package maintenance outside the |
46 |
> > scope of your arch. I cannot believe how you can so easily disregard |
47 |
> > this form of basic QA. |
48 |
> |
49 |
> if it's the ONLY reason, it is NOT a good reason. if there is another reason |
50 |
> WHY it hasnt been marked stable, then THAT is the "good reason" for not |
51 |
> marking it stable on another arch... did you read my argument or are all my |
52 |
> words pointless to you and not worth your time? |
53 |
|
54 |
Same question to you. The problem is not so much that it isn't a good |
55 |
reason, it's more that the arch maintainer just doesn't know if there's |
56 |
a reason or not. The lack of knowledge is the problem, that's really the |
57 |
basic background why it _is_ a good enough reason alone. |
58 |
|
59 |
> i was aware of the issues involved here and thus didnt touch this version on |
60 |
> my arch until it was stable on x86 for a good while. /then/ i marked it |
61 |
> stable... you made it very well known that there were problems, as did the |
62 |
> bug reports on bugzilla. there was a good reason here for not marking it |
63 |
> stable other than the fact that it wasnt marked stable on the maintainer's |
64 |
> arch (x86). |
65 |
|
66 |
Well, I made it as well known as possible that it was problematic as you |
67 |
say, still some arch maintainers didn't know or forgot. That's exactly |
68 |
why there should be the basic safeguard of 'package maintainers' arch |
69 |
moving to stable first, before any other. It's just a simple precaution |
70 |
to prevent things like this happening. Obviously from this example the |
71 |
basic developer interaction (irc/email) isn't sufficient : you did it ok |
72 |
this time, someone else didn't. And with 2 or 3 arches and 30 devs -like |
73 |
when i started- this is quickly resolved, but it's not like that |
74 |
anymore. |
75 |
|
76 |
- foser |