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 |