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 |