Gentoo Archives: gentoo-amd64

From: Beso <givemesugarr@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re:
Date: Fri, 06 Jul 2007 18:21:40
Message-Id: d257c3560707061117u311357cx6e6c918d3c85a202@mail.gmail.com
In Reply to: [gentoo-amd64] Re: by Duncan <1i5t5.duncan@cox.net>
1 2007/7/6, Duncan <1i5t5.duncan@×××.net>:
2 >
3 > "Dustin J. Mitchell" <dustin@×××××××.us> posted
4 > 20070706152051.GA25052@×××××××.us, excerpted below, on Fri, 06 Jul 2007
5 > 10:20:51 -0500:
6 >
7 > > Well, keep in mind that I run in what is probably a slightly different
8 > > circle -- server admins.
9 > >
10 > > Gentoo has a *lot* to recommend it technically for administering a
11 > > server -- fine-grained control, careful management of the upgrade path,
12 > > transparency, extensibility, etc.
13 > >
14 > > But the cultural shift is painful when folks like me try to interact
15 > > with the Gentoo user or developer community. I think I'm a fairly
16 > > technically adept person (hey, I passed the ebuild quiz), yet several of
17 > > my bugs have been blown off fairly rudely, by developers who had
18 > > obviously not read the entire bug. Of course, interactions on IRC are
19 > > even worse.
20 > >
21 > > The result is that I don't file bugs anymore -- I make a fixed local
22 > > copy of the ebuild and call it a day. Since I can't recommend that my
23 > > clients and employers do the same, I set them up with a RedHat-derived
24 > > base system and then hand-compile the necessary software on top of that.
25 >
26 > I'm not a server admin and not dev, but I hang out on the dev group/list
27 > (group thru gmane), in large part because that's one thing I can do to
28 > get a heads-up on stuff coming down the pike before it affects me. I'm
29 > also tech literate enough to generally understand development principles,
30 > but have only done bash scripts (with kdialog on occasion) on Linux, and
31 > VB back before MS decided they didn't want customers that actually cared
32 > about their privacy any more and forced me to jump to Linux. (Yes, I owe
33 > MS a bit of the credit for one of the best moves I ever made, OFF of MS!
34 > =8^P ) Maybe someday I'll be a dev, but it's slow going learning the
35 > stuff as a hobby, on one's own.
36 >
37 > Anyway, so I hang out on the dev list. Having done so since I switched
38 > from Mandrake (with Gentoo release 2004.1), I've been around awhile. You
39 > think they're rough on you, try the dev list! They are equally as rough
40 > on each other!
41 >
42 > Basically what it comes down to is that people have to develop much
43 > thicker skins. I had to. It took awhile and I still believe things
44 > could be far better if people would just be a bit more tolerant, and read
45 > things in the light most favorable to the other guy instead of the least,
46 > particularly when there are cultural and language differences thrown in
47 > as well.
48 >
49 > So yeah, don't take the rudeness personally. If you can, learn to live
50 > with it. Reopen the bug if need be, asking why it got closed without
51 > even being fully read. Keep in mind "invalid" doesn't mean what it might
52 > look like, they /think/ the bug's invalid, but they aren't really calling
53 > you a know-nothing. (Yes, I've had the invalid thing happen too, and it
54 > bothered me greatly at first.) Sometimes you may have to jump thru a few
55 > hoops that you don't believe are necessary, but if it gets the bug
56 > fixed... Not trying to name names, but in particular, bug wranglers is a
57 > tough job, and sometimes they get pretty cranky and even the devs think
58 > they've gone too far on occasion.
59 >
60 > One thing I had occasion to learn, that I've observed many tech oriented
61 > folks haven't. For years I was used to being the guru. Then I joined an
62 > ISP (and the ISP's newsgroups) where there was a VERY high level of
63 > expertise, one guy was one of about 12 with full commit rights to one of
64 > the BSDs (I'm a Linux guy so don't remember which one), and they ALL (or
65 > it seemed that way) ran big web and mail servers and the like. I was to
66 > them the newbie tech illiterate they had to explain things to, much as I
67 > was used to explaining things to others.
68 >
69 > Well, let's just say I learned to shutup and listen pretty fast, and to
70 > qualify my statements much more accurately or cite references when I
71 > could.
72 >
73 > That's an experience I've decided every tech oriented person needs to
74 > have. It's REALLY an eye opening and humbling experience. Unfortunately
75 > not so many get it.
76 >
77 > Another thing is that many of these devs are still in school, college,
78 > even high school. They're immature and their blood runs hot. They may
79 > know their stuff decently well, but they don't have the perspective of
80 > years and it shows. They may know their stuff, but they don't always
81 > know what they /don't/ know.
82 >
83 > So anyway, yeah, I've learned to have a /much/ thicker skin. I
84 > personally try to always be respectful and give the other guy the benefit
85 > of the doubt, but I know that's not the rules everybody plays by now, and
86 > if I have a point to make or a bug I want fixed, I'm a bit more insistent
87 > on it now. Sometimes I shutup for awhile, but following the dev list, in
88 > a few months, there's often an excuse to point it out and effectively
89 > appeal the decision. I've had several bugs eventually fixed with
90 > variances on the theme, and in fact just got a bug reopened that someone
91 > else had filed as well, that I stumbled upon myself. (In this case it
92 > was a gcc-4.2.0 related bug, filed while that version was still masked.
93 > An announcement on the dev list just said they intend to unmask 4.2.0 to
94 > ~arch in a few days, so it's time to reopen the bug and get it fixed. I
95 > mentioned it as a reply to the announcement, and low and behold, less
96 > than an hour later, reopened it was, and reassigned to toolchain, with
97 > amd64 in the cc as it was amd64 -fPIC related too.)
98 >
99 > Now you may or may not be willing to hassle all that, it's up to you. If
100 > you can develop the thick skin, tho, and with a bit of patience, you can
101 > get some of those bugs fixed.
102 >
103 > OTOH, even if you can develop a thick skin, it's still not something you
104 > can really recommend to others. That remains true. Maybe someday, but
105 > not ATM. So with RH/Debian/whatever I'd recommend they stick too.
106 >
107 > --
108 > Duncan - List replies preferred. No HTML msgs.
109 > "Every nonfree program has a lord, a master --
110 > and if you use the program, he is your master." Richard Stallman
111 >
112 > --
113 > gentoo-amd64@g.o mailing list
114 >
115 > i can understand that they are pretty pissed off with bugs that cannot be
116 reproduced but if you mismatch the place of some bug, they should
117 automatically switch it to the right place, as the people do on other
118 bugzillas.... if they cannot control themselves, maybe it would be good if
119 they would have some people that only do the mediation between them and
120 users....
121 another great disappointment is that sabayon problems wich regard ebuilds in
122 the gentoo general tree are encouraged to be unanswered by users.... i think
123 that this is not a good choice.... take kubuntu/ubuntu/edubuntu - you can
124 try to mix the 3 versions without any problems (and i know that cause i used
125 to use a very tainted kubuntu with also fedora and suse packages).... i
126 don't really understand why problems with packages of sabayon (which is a
127 dev branch of gentoo in the end) that are installed from the official gentoo
128 repo cannot be questioned on the official gentoo forum.... right now i'm
129 downloading the sabayon dvd to try it and see what are the changes inside
130 and i'm currently using some stuff from their repo (which didn't installed
131 from official repo) as ati-drivers (which in some way are more stable and
132 with which i can run beryl, while with the official gentoo released ones i
133 cannot).... another very important question is why the gentoo branch doesn't
134 pass on to paludis, which is really,really,really greater when compared with
135 portage (at least for dep resolving which is about 40 to 50%).... an example
136 is that paludis has found some packages that are installed on my system
137 without any reference.... these were installed by portage and when i've
138 removed them i didn't have any problems using my apps.... i cannot do any
139 more without it and only have installed portage because some gentoolkit
140 tools are still emerge based as the.... the last thing is why continuing to
141 use etc-update when you have dispatch-config that is 1000000000000000 time
142 better than the etc-update idiot output?!?! i really think that gentoo has
143 lost its innovation character which was its racial trait when it was
144 born.... that's why i've decided to have a look at sabayon, which seems to
145 embody these traits....
146
147
148 --
149 beso
150
151 d-_-b