Gentoo Archives: gentoo-dev

From: Lance Albertson <ramereth@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
Date: Sat, 24 Jun 2006 14:31:59
Message-Id: 449D4B5B.8050106@gentoo.org
In Reply to: Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work by Patrick Lauer
1 Patrick Lauer wrote:
2
3 >> was
4 >> suspended in the first place. You're taking every comment that's been
5 >> made against it as a personal attack and have been ignorant in *all* the
6 >> technical details.
7 > Well ... if the technical details are "it will cause the end of the
8 > world" it's hard to evaluate them to more than "random noise that can be
9 > ignored". I really don't see how such an overlay would cause more
10 > problems than providing the ebuilds unsorted, untested and without any
11 > QA checks in bugzilla (which is official hardware, eh?). If you had
12 > looked at sunrise recently you'd have noticed that those that work on it
13 > try to do their best and reach a quite high quality standard. So you get
14 > fixed, quality checked ebuilds, dev candidates and happy users.
15
16 If all you saw was a bunch of 'noise' then I'm afraid you're not seeing
17 the whole picture then. I admit there was *some* noise, but a good chunk
18 of it had excellent technical details. I fail to see how your
19 assessment is factual until you prove to me exact technical points that
20 were viewed as 'end of the world noise'. If its that hard to evaluate,
21 then perhaps you should ask your peers on their opinions on the
22 technical details. It never hurts to get a second opinion on something
23 if you're unsure.
24
25 >> If you would open your eyes and mind a little you'll
26 >> see that there are better ways to making your project work better.
27 > I could say the same to you - there's always room for improvement.
28
29 I'm not the one making excuses about facts and calling it 'noise'
30 without proving it as such.
31
32 >> I
33 >> don't think continuing it on unofficial hardware without fixing the
34 >> details is the best idea.
35 > That's the only way to not have it die due to ressource starvation. Get
36 > the people to not work on it for 3 months and noone will remember that
37 > it even existed (which might be the goal of some)
38
39 What the heck does resource starvation have to do improving the project
40 idea and fixing it? Moving it and 'calling it good' isn't the same as
41 'lets stop this whole thing and look at all the points made by our
42 developers'. If you really think that the project will die in 3 months
43 because its not online, then perhaps you should reconsider the
44 scope/goal of the project. You can accomplish a lot if you work out the
45 RFC for the idea ahead of time. It would have solved all the issues
46 brought up in the last few weeks instead of this constant bickering and
47 childless recants. What hurt will happen if you halt the project for a
48 month or so to come up with a better idea? I'd say if we could come up
49 with a better solution that makes us all happy, lets do it.
50
51 >> You're just digging your hole deeper and not
52 >> fixing the issues we had in the first place. Please reconsider what
53 >> you're doing.
54 >
55 > I think the strong reactions from people like jakub (which now force
56 > the java overlay to do a stupid move just because otherwise they get
57 > problems with bugs!?) show that we have a strong disagreement here
58 > with one side responding to every demand and the other side just making
59 > more demands. But eh, I'm not even part of Sunrise, so I probably
60 > shouldn't even care.
61
62 You wouldn't have to deal with the 'demands' if you had come up with an
63 RFC in the first place and ironed out the details. Instead you've taken
64 a good chunk of everything mentioned as a wrong implementation and
65 decided that its noise and ignored it completely. Has the idea of "Hey,
66 a lot of people think we're doing this the wrong way. Maybe we should
67 stop the project, work out the details like we should have, and possibly
68 regain some trust within our developer community? Then after that, we
69 can open it back up again?" crossed your mind?
70
71 I fail to see the logic in this attempt of ignoring technical details.
72 If you don't know how to communicate well in a technical discussion,
73 just say it or look to your peers for help. There's no need in coming up
74 with these outlandish assumptions to make it look like you're trying to
75 contribute to the technical discussion. I have yet to see any of your
76 responses to show that you have any intentions on dealing with the
77 technical discussions. The more I see is you trying make a fight out of
78 this while my goal is to iron out the technical details before it goes live.
79
80 Yes, sometimes it takes a while to get that done, but doesn't it make
81 sense to do it right the *first* time than do deal with the crap you've
82 delt with in the last few weeks? This all could have been avoided if you
83 had written out an RFC and asked for comments on it *before hand*. Don't
84 you agree?
85
86 And please please please ... Keep your responses to a technical level
87 and don't bring in personal issues. I have tried to keep my reply with
88 that in mind. If you have personal issues with my reply, then please
89 reply to me in private as we don't need to have all of -dev seeing those
90 issues.
91
92 That is all :-)
93
94 --
95 Lance Albertson <ramereth@g.o>
96 Gentoo Infrastructure | Operations Manager
97
98 ---
99 GPG Public Key: <http://www.ramereth.net/lance.asc>
100 Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742
101
102 ramereth/irc.freenode.net

Attachments

File name MIME type
signature.asc application/pgp-signature