Re: CVS commit: src
On Tue, Jan 18, 2011 at 07:06:52AM +0200, Jukka Ruohonen 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. 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. I think that's a vast exaggeration. Then again, maybe you think I'm part of the problem? If one can not use his or her own discretion with what must be one of the most trivial files in the system, there is something fundamentally wrong. It is easy to block and freeze things (even by an user) simply by posting regularly to tech-userlevel@ just to show that there was no consensus. The things that appear trivial from a technical perspective are also commonly the things that are most visible in people's day-to-day use of the system. Of course something like operator, which many people refer to regularly, is going to concern them more than stuff deep in the kernel. And in that context, proposing gratuitous changes with no clear rationale is guaranteed to cause a fuss. Understanding how this works is essential to working on the visible parts of the system. Blowing off concerns people raise just because you think their concerns aren't important (and hence bikeshedding) is not the right approach; neither is skipping the review entirely. It's perfectly possible to propose things on tech-userlevel and get them agreed on. It just requires doing a little more planning up front to make sure the proposal has clear motivations and benefits and addresses likely concerns. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src
On Tue, Jan 18, 2011 at 09:15:27AM +, David Holland wrote: It's perfectly possible to propose things on tech-userlevel and get them agreed on. It just requires doing a little more planning up front to make sure the proposal has clear motivations and benefits and addresses likely concerns. As Kamp ends his pamphlet, the things seen in tech-userlevel@ are a sure way to scare of potential new contributors. Blowing off concerns people raise just because you think their concerns aren't important (and hence bikeshedding) is not the right approach; neither is skipping the review entirely. The NetBSD projects WWW page has been very successful at gaining attention of new people. However, I would advice anyone to think very carefully before spending six months in a project only to see it ruled down by a vicious jury of grumpy old men whose only argument is usually some trivial detail -- or even more pathetically, I do not like it, I strongly object, this is how it has always been done. The coin has two sides, and in my opinion this is far more destructive side of the blowing off concerns. And if you think that this is not a problem, there are at least dozen examples of this phenomenon in the past couple of years. Cheers, Jukka.
Re: CVS commit: src
On Tue Jan 18 2011 at 11:34:23 +1100, Simon Burge wrote: Log Message: Remove /usr/share/misc/operator. 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. 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. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys
Added Files: src/sys/compat/common: kern_select_50.c Builds of most m68k ports failed since sys/syscallargs.h requires sys/sched.h for cpuset_t. Should we add it to all sources that include syscallargs.h, or just add sys/sched.h into $sysarghdrextra in sys/kern/syscalls.conf? Some other files still include sys/mount.h and sys/sched.h only for syscallargs.h. --- Izumi Tsutsui
Re: CVS commit: src/sys
On Wed Jan 19 2011 at 01:10:10 +0900, Izumi Tsutsui wrote: Added Files: src/sys/compat/common: kern_select_50.c Builds of most m68k ports failed since sys/syscallargs.h requires sys/sched.h for cpuset_t. whoops ... Should we add it to all sources that include syscallargs.h, or just add sys/sched.h into $sysarghdrextra in sys/kern/syscalls.conf? Some other files still include sys/mount.h and sys/sched.h only for syscallargs.h. I like self-contained headers, so sysarghdrextra has my vote. Do you want to do the change and test, or should I? (on a slight tangent, it is annoying to have MD differences in header auto-inclusion, the most famous one being atomic.h included by x86 pmap.h) -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys
I like self-contained headers, so sysarghdrextra has my vote. Me too. Do you want to do the change and test, or should I? Please do. (I just see you added sysarghdrextra in cvsweb ;-) I'll test it and cleanup other files later. --- Izumi Tsutsui
Re: CVS commit: src/sys
On Wed Jan 19 2011 at 01:33:51 +0900, Izumi Tsutsui wrote: Do you want to do the change and test, or should I? Please do. (I just see you added sysarghdrextra in cvsweb ;-) I'll test it and cleanup other files later. I test-built mac68k GENERIC and committed the fix. -- älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Re: CVS commit: src/sys/kern
On Tue, Jan 18, 2011 at 05:33:05PM +, Antti Kantee wrote: Module Name: src Committed By: pooka Date: Tue Jan 18 17:33:05 UTC 2011 Modified Files: src/sys/kern: syscalls.conf Log Message: Make syscallargs.h include sys/sched.h for cpuset_t typedef for the benefit of ports where it does not get typedef'd via autoinclusion of other headers. Isn't is better to to add a local definition for the struct, and then use that instead of the typedef? Any code that cares about the actual struct will have included the header that contains the real definition. David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src
On 01/18/2011 02:15, David Holland wrote: On Tue, Jan 18, 2011 at 07:06:52AM +0200, Jukka Ruohonen 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. 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. I think that's a vast exaggeration. Then again, maybe you think I'm part of the problem? If one can not use his or her own discretion with what must be one of the most trivial files in the system, there is something fundamentally wrong. It is easy to block and freeze things (even by an user) simply by posting regularly to tech-userlevel@ just to show that there was no consensus. The things that appear trivial from a technical perspective are also commonly the things that are most visible in people's day-to-day use of the system. Of course something like operator, which many people refer to regularly, is going to concern them more than stuff deep in the kernel. And in that context, proposing gratuitous changes with no clear rationale is guaranteed to cause a fuss. Understanding how this works is essential to working on the visible parts of the system. Blowing off concerns people raise just because you think their concerns aren't important (and hence bikeshedding) is not the right approach; neither is skipping the review entirely. It's perfectly possible to propose things on tech-userlevel and get them agreed on. It just requires doing a little more planning up front to make sure the proposal has clear motivations and benefits and addresses likely concerns. There is a fine art between listening to everybody and getting things done. When you are listening to people and they are reasonable, then the process works out well. If the conversation becomes circular, then you need to thank them for their opinion and move forward. Sometimes moving forward means that you go with a majority viewpoint if the minority can't articulate a good technical reason for the objection. Other times moving forward may mean abandoning your plans. Still other times (and this is usual), your plans are modified based on input you received. The more you fight the process, the more the process will fight you and you'll have an unsatisfactory outcome. Knowing how to balance this all, as well as having the patience to practice this dance, can be difficult to know at first, but often the rewards are better in the end. Unfortunately, the delayed gratification necessary to do this often matches poorly with the desire to scratch an itch and move on. Warner
