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.
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: 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: CVS commit: src
On Tue, Jan 18, 2011 at 11:42:29AM +0200, Antti Kantee wrote: > Speaking as a member of core, but voicing my personal opinion. > > Please, roughly in the following order, > > 1) stop proposing changes without impact > >every proposal should be about fixing a real problem. removing >operator cannot be justified by disk space waste or duplicate >information going stale. If there is envisioned impact -- i'm having >trouble coming up with even a fictional case here -- it needs to be >included in the proposal. > > 2) stop making changes which do not fix problems > >every change can create a problem, so if a change does not work toward >fixing a problem, the change itself is a problem. > > 3) stop opposing changes without reason > >This is a live OS, there are changes. if you want everything to stay >like in NetBSD 1-4-U, use cvs export -D. If you oppose a change, you >need to present a case for a non-trivial problem created by the change. >It is unnecessary to call on procedular problems when it is obvious >that a discussion can never reach an agreement (cf. "1"). > > > There are no winners here. In general I agree but I have some quibbles: (1) I would say more important here is to account for the full impact of the change you're proposing. The problem with removing the extra copy of operator is that it *does* have a substantial impact, a negative impact, on people who are used to typing "more /usr/share/misc/operator". The problem is not that removing the extra copy serves no purpose; the problem is that the benefit is miniscule and the cost is not. Failure to take account of the social/user impact of proposed changes is, I'd say, the primary cause of long bikeshed threads. A change that *really* has no impact, like renaming local variables for clarity inside compat_irix, doesn't need to be discussed; it can just be made. (2) I would also say that every change should have a *purpose*. Not every valid purpose is solving a problem, except in a vacuous or tautological sense. More importantly though, if proposing something, it's important to state and clearly articulate the purpose. Failure to explain what you're trying to accomplish (and why that requires the change you're proposing) results in lots of unhelpful suggestions. (3) When a discussion reaches the state where agreement becomes impossible is precisely the time it's most important to follow procedure, IOW, take it to core. Also, "this proposed change serves no purpose, not even code cleanup" is a valid reason to oppose. -- David A. Holland dholl...@netbsd.org
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 Barrett 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 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 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 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 10:31 AM, Alan Barrett 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
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)
