Changes made with too little discussion
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. --apb (Alan Barrett)
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 10:31 AM, Alan Barrett a...@cequrux.com wrote: 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 real work. 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. -- Regards. Adam
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 11:31:27AM +0200, Alan Barrett wrote: 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. For the record, I made the commit only to raise these points, not because I would care whether /usr/share/misc/operator exists or not. If you are not willing to discuss changes, or pay attention to other people's opinions, then you are part of the problem. Is it mandatory to subscribe to these lists? 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. Being naive as I am, I believe a software project can adopt healthier and more productive software engineering practices. Unfortunately many people are too blind to see any problems. - Jukka.
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 11:13:15AM +0100, haad wrote: Truly I haven't seen any discussion which had more than 10mails where clear consensus was made. Thats not going to happen. It is possible and it has happened. IMHO it clearly depends on the quality of the original proposal/question. In this case there was no real proposal, so there won't be consensus. Martin
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 12:20:40PM +0200, Jukka Ruohonen wrote: Being naive as I am, I believe a software project can adopt healthier and more productive software engineering practices. If you want to change established procedures, change them first. Do not explicitly violate them and hope for them to be bend after the fact. Besides that: what pooka said. Martin
Re: Changes made with too little discussion
On 01/19/2011 03:13, haad wrote: On Wed, Jan 19, 2011 at 10:31 AM, Alan Barretta...@cequrux.com wrote: 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 real work. Then maybe it is a dumb-ass idea. I'm sorry to be blunt, but if you propose something that will have a month of discussion for something trivial, then you are doing it wrong. e.g. Lua it took one year to discuss everything and it was major PITA for almost everyone. Again, maybe it was a dumb idea? Maybe it was poorly communicated? Either way, using this as an example might prove the point: you have to gather consensus for change and if you try to force it, then you are doing it wrong. 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. Then you are doing it wrong. In FreeBSD we have them all the time. I've seen them in NetBSD land too, so clearly, you aren't paying attention. Warner
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 11:13:15AM +0100, haad wrote: 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. This is a common perception around here, but it's not true. When there are open design questions and other unresolved issues, talking is how they get resolved. That is, if you know where you're going you can just go there, but if you don't, you have to figure out first, and having a bunch of smart people helping makes that a lot easier. Believe me. I've spent a long time working alone. (Granted, there's a point at which talk devolves into design by committee, but I don't think I've ever seen that in NetBSD.) *Conflict* arises mostly when one person is convinced they know where they're going, and it turns out that not everyone agrees with them. Sometimes this is because everyone else is wrong, but more often it's not. Sometimes it's because they haven't stated their case clearly, or didn't explain some important aspect up front. But often it's because they've overlooked something or even because they're pursuing a bad idea... that is, they're wrong. The most important lesson to learn in software is that it's ok to be wrong and that when you are wrong, the sooner someone notices the better. We all make mistakes; we all make lots of mistakes, all the time. (Writing this post was probably a mistake, for example.) The important part is to try to mitigate the consequences. Where I work we routinely see undergrads who not only haven't learned this lesson but are so hung up on the idea of their own awesomeness that they literally cannot say I was wrong. (And, also, frequently, I don't know.) Sooner or later they end up in difficulties. Truly I haven't seen any discussion which had more than 10mails where clear consensus was made. Thats not going to happen. If you don't read them, of course you won't see the ones where consensus appears. It does happen regularly. -- David A. Holland dholl...@netbsd.org
Re: Changes made with too little discussion
On Wed, Jan 19, 2011 at 08:16:41PM +, David Holland wrote: The most important lesson to learn in software is that it's ok to be wrong and that when you are wrong, the sooner someone notices the better. We all make mistakes; we all make lots of mistakes, all the time. (Writing this post was probably a mistake, for example.) The important part is to try to mitigate the consequences. There are roughly two kinds of people in this project. Those who like to code and those who like to write emails. I agree with Haad that some problems culminate to the certain aspects of micro-management, the right to complain, and lack of emphasis on healthy meritocracy. - Jukka.
Re: CVS commit: src/distrib/sets/lists
On Jan,Wednesday 19 2011, at 10:07 PM, Havard Eidnes wrote: Module Name: src Committed By: he Date: Wed Jan 19 21:07:18 UTC 2011 Modified Files: src/distrib/sets/lists/base: shl.mi src/distrib/sets/lists/comp: mi shl.mi Log Message: Mark the set list entries for librumpfs_zfs and librumpkern_solaris with the zfs attribute -- these are not built for a substantial portion of our ports. Ah thanks for fixing this ! Regards Adam.
