[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 10:31 AM, Alan Barrett <apb%cequrux.com@localhost>
> On Tue, 18 Jan 2011, Jukka Ruohonen wrote:
>> On Tue, Jan 18, 2011 at 11:34:23AM +1100, Simon Burge wrote:
>> > Why was this removed when there was an active discussion about removing
>> > it where no concensus was reached? ÂThis sort of thing where commis
>> > occur before a discussion is finished seems to be occurring more and
>> > more often.
> I don't care much about /usr/share/misc/operator, but I do care about
> people making changes without discussion, or making changes with too
> little discussion, or making changes that go against the consensus of
> the discussion.
> I would like to see this change reverted, becasue it was made with
> too little discussion.
>> Maybe because the whole tech-userlevel@ mailing list has become
>> poisonous? ÂI know several people who abstain from posting anything to
>> the list because of the nature of the list and these discussions.
> If you are not willing to discuss changes, or pay attention to other
> people's opinions, then you are part of the problem.
> You don't have to agree with everybody, but you do need to pay attention
> to the discussion. ÂIf no clear consensus emerges, or if the consensus
> is opposite from your preferred outcome, then you may appeal to core to
> make a decision.
Let me say it this way, if will will spent months in clueless
discussion about thinks like remove misc/operator we will not do any
e.g. Lua it took one year to discuss everything and it was major PITA
for almost everyone.
We need some proper way how to evaluate changes, discussion about them
is clearly not good way. Because most of best developers are not
talking in those never ending mail threads. In practice most active
never ending mail writers contribute very small or zero amount of
code. I really don't think that their opinion should be taken serious.
If they really want to have NetBSD done by their way they should start
contributing, just talking is not going to fix anything.
E.G. Example scenario Dev A wants to add new feature, software
whatever he spent his time on it, developing, testing preparing and
sends patch to tech-userlevel@ where it starts never ending discussion
about it how it slows build on 20years old vax(replace with anything
with < 128Mb ram). After few weeks of waiting Dev A doesn't have
attitude to work on his patch anymore and he is totally pissed of by
trying to explain that we really need to move forward. In the result
we will lost (maybe good maybe wrong patch), contributing developer
and onlyone who wins are those who a priori hates any change.
Truly I haven't seen any discussion which had more than 10mails where
clear consensus was made. Thats not going to happen.
Main Index |
Thread Index |