Re: CVS commit: src/usr.bin/pwait
In article 20150303071552.gc27...@britannica.bec.de, Joerg Sonnenberger jo...@britannica.bec.de wrote: You are missing the most important part of my mail: why did this not go to tech-userlevel first? If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already have the rest of the p* programs which originated in Solaris, we were missing this one, so it made sense to me to add it. christos
Re: CVS commit: src/usr.bin/pwait
For actionable items: pwait: Should I remove pwait or leave it? Are there any features you want added? In general: Should we have more concrete commit rules, or do we prefer that current status quo which is to leave things to people's judgement and occasionally backout things when people chose incorrectly according to consensus? christos
Re: CVS commit: src/usr.bin/pwait
On Tue, Mar 03, 2015 at 03:58:56PM +, Christos Zoulas wrote: For actionable items: pwait: Should I remove pwait or leave it? Are there any features you want added? Bring it up on tech-userlevel. In general: Should we have more concrete commit rules, or do we prefer that current status quo which is to leave things to people's judgement and occasionally backout things when people chose incorrectly according to consensus? I fully agree with Greg, the unwritten rule always was bring up bigger changes first. A good rule of thumb is the question what is the long term impact. A new tool (just like a new external API) comes with a lot of strings attached... Joerg
Re: CVS commit: src/usr.bin/pwait
chris...@astron.com (Christos Zoulas) writes: If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already have the rest of the p* programs which originated in Solaris, we were missing this one, so it made sense to me to add it. We do sort of have a rule, which is that significant changes need discussion. I would say adding programs to base always counts. Other than that, it's trickier, but if there's a reasonable likelihood of a valid objection, I'd say it's over the line into signficant/discuss. pgp7H4fsvfMbX.pgp Description: PGP signature
Re: CVS commit: src/usr.bin/pwait
Am 03.03.15 um 14:35 schrieb Greg Troxel: chris...@astron.com (Christos Zoulas) writes: If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already have the rest of the p* programs which originated in Solaris, we were missing this one, so it made sense to me to add it. We do sort of have a rule, which is that significant changes need discussion. I would say adding programs to base always counts. Other than that, it's trickier, but if there's a reasonable likelihood of a valid objection, I'd say it's over the line into signficant/discuss. Adding new stuff bears a low risk of breaking existing stuff, so I think it does not need discussion all the time.
Re: CVS commit: src/usr.bin/pwait
Am 03.03.15 um 21:32 schrieb Greg Troxel: Marc Balmer m...@msys.ch writes: I meant that adding to base was discuss-worthy because there's a bloat or necessary question, not because of risk of breakage. Sure. So how much bloat is pwait? Is it a huge piece of software or a small utility? I think that matters a bit. Posting a note that says I would like to add X, and here's why, and my comments on the bloat/necessary tradeoff. takes only a few minutes (assuming well-formed thoughts already). If there's no grumbling in 48-72h, that's fine. It's not like this sort of review/comment costs a lot or really gets in the way - new programs in base are pretty rare. I don't think pwait is a big deal. I do think that in general we have too much commit first, argue about appropriate later. I think you contradict yourself, when you say a) new programs in base are pretty rare, and b) we have too much commit first, argue about appropriate later. While in some cases it makes sense to discuss changes, be reminded that a TNF membership also comes with the privilege to commit. There is no rule that such commits have to be discussed upfront. And for commands that are, in your words no big deal, I think there is not much gain in disussing them ad nauseam before just and simply adding them. Absolutely nothing is wrong, otoh, to first send a note to the appropriate mailing list. I am just claiming here that this is not mandated. Correct me if I am wrong.
Re: CVS commit: src/usr.bin/pwait
Am 03.03.15 um 22:03 schrieb Greg Troxel: Marc Balmer m...@msys.ch writes: I think you contradict yourself, when you say a) new programs in base are pretty rare, and b) we have too much commit first, argue about appropriate later. Both are true; some/most commit first discuss later isn't about new programs. While in some cases it makes sense to discuss changes, be reminded that a TNF membership also comes with the privilege to commit. There is no rule that such commits have to be discussed upfront. The point is that in theory that we are a group cooperating to do something. That should drive our norms. You are right that we don't have a real rule. Often when changes are proposed there are no comments, or a few questions that lead to better commit messages. And when there's a big argument, that's a clue that the discussion really should happen. What I'm trying to say is that in a non-trivial number of situations, more propose/discuss would be good. I agree with that. Remains to decide if with the case at hand we had a non-trivial situation or not. It's not up to me to decide, though I tend to classify it as trivial.
Re: CVS commit: src/usr.bin/pwait
Am 03.03.15 um 21:22 schrieb Greg Troxel: Marc Balmer m...@msys.ch writes: Am 03.03.15 um 14:35 schrieb Greg Troxel: chris...@astron.com (Christos Zoulas) writes: If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already have the rest of the p* programs which originated in Solaris, we were missing this one, so it made sense to me to add it. We do sort of have a rule, which is that significant changes need discussion. I would say adding programs to base always counts. Other than that, it's trickier, but if there's a reasonable likelihood of a valid objection, I'd say it's over the line into signficant/discuss. Adding new stuff bears a low risk of breaking existing stuff, so I think it does not need discussion all the time. I meant that adding to base was discuss-worthy because there's a bloat or necessary question, not because of risk of breakage. Sure. So how much bloat is pwait? Is it a huge piece of software or a small utility? I think that matters a bit.
Re: CVS commit: src/usr.bin/pwait
Am 03.03.15 um 16:58 schrieb Christos Zoulas: For actionable items: pwait: Should I remove pwait or leave it? Are there any features you want added? no. In general: Should we have more concrete commit rules, or do we prefer that current status quo which is to leave things to people's judgement and occasionally backout things when people chose incorrectly according to consensus? no stricter rules are needed. common sense is enough. we don't need a source code police force, neither a SWAT team.
Re: CVS commit: src/usr.bin/pwait
Am 03.03.15 um 17:49 schrieb Joerg Sonnenberger: On Tue, Mar 03, 2015 at 03:58:56PM +, Christos Zoulas wrote: For actionable items: pwait: Should I remove pwait or leave it? Are there any features you want added? Bring it up on tech-userlevel. In general: Should we have more concrete commit rules, or do we prefer that current status quo which is to leave things to people's judgement and occasionally backout things when people chose incorrectly according to consensus? I fully agree with Greg, the unwritten rule always was bring up bigger changes first. A good rule of thumb is the question what is the long term impact. A new tool (just like a new external API) comes with a lot of strings attached... Adding a new command is in no way a bigger change. don't like the new command? don't use it, then.
Re: CVS commit: src/usr.bin/pwait
Marc Balmer m...@msys.ch writes: Am 03.03.15 um 14:35 schrieb Greg Troxel: chris...@astron.com (Christos Zoulas) writes: If we want to make every single change to go through tech-userlevel, we should institute a rule to do so. To my knowledge we don't have yet such a rule. We already have the rest of the p* programs which originated in Solaris, we were missing this one, so it made sense to me to add it. We do sort of have a rule, which is that significant changes need discussion. I would say adding programs to base always counts. Other than that, it's trickier, but if there's a reasonable likelihood of a valid objection, I'd say it's over the line into signficant/discuss. Adding new stuff bears a low risk of breaking existing stuff, so I think it does not need discussion all the time. I meant that adding to base was discuss-worthy because there's a bloat or necessary question, not because of risk of breakage. pgpSkT3o7R8yK.pgp Description: PGP signature
Re: CVS commit: src/usr.bin/pwait
Marc Balmer m...@msys.ch writes: I meant that adding to base was discuss-worthy because there's a bloat or necessary question, not because of risk of breakage. Sure. So how much bloat is pwait? Is it a huge piece of software or a small utility? I think that matters a bit. Posting a note that says I would like to add X, and here's why, and my comments on the bloat/necessary tradeoff. takes only a few minutes (assuming well-formed thoughts already). If there's no grumbling in 48-72h, that's fine. It's not like this sort of review/comment costs a lot or really gets in the way - new programs in base are pretty rare. I don't think pwait is a big deal. I do think that in general we have too much commit first, argue about appropriate later. pgpjC8D8gagfc.pgp Description: PGP signature
re: CVS commit: xsrc/external/mit/MesaLib/dist/src/mesa/main
Christos Zoulas writes: Module Name: xsrc Committed By: christos Date: Tue Mar 3 21:32:27 UTC 2015 Modified Files: xsrc/external/mit/MesaLib/dist/src/mesa/main: imports.h Log Message: xmmintrin.h is a gcc-specific header it is? -rw-r--r-- 1 mrg wheel 27578 Feb 12 07:49 src/external/bsd/llvm/dist/clang/lib/Headers/xmmintrin.h .mrg.
re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon
Taylor R Campbell writes: Module Name: src Committed By: riastradh Date: Tue Mar 3 13:57:20 UTC 2015 Modified Files: src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c Log Message: radeon_fence_wait returns 0, not positive, on success. i haven't confirmed yet, but i suspect this change breaks radeondrmkms. latest kernels are no longer enabling DRM in X for me, and we end up with no KMS enabled, and really really slow access.. the console seems fine, and the Xorg.0.log file is identical upto the point it says direct rendering isn't working and gives up: [75.407] drmOpenByBusid: drmGetBusid reports pci:0001:02:00.0 [75.408] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS [75.408] (II) Loading sub module shadow the next line is normally: [68.095] (II) Loading sub module dri2 i'll test which exact change broke things this evening. .mrg.
Re: CVS commit: xsrc/external/mit/MesaLib/dist/src/mesa/main
On Wed, Mar 04, 2015 at 09:19:01AM +1100, matthew green wrote: Christos Zoulas writes: Module Name:xsrc Committed By: christos Date: Tue Mar 3 21:32:27 UTC 2015 Modified Files: xsrc/external/mit/MesaLib/dist/src/mesa/main: imports.h Log Message: xmmintrin.h is a gcc-specific header it is? -rw-r--r-- 1 mrg wheel 27578 Feb 12 07:49 src/external/bsd/llvm/dist/clang/lib/Headers/xmmintrin.h Even ICC supports it :) Joerg
Re: CVS commit: src/usr.bin/pwait
Date:Wed, 4 Mar 2015 00:13:01 +0100 From:Joerg Sonnenberger jo...@britannica.bec.de Message-ID: 20150303231301.gb13...@britannica.bec.de | It comes with a maintainance price. Add something better a version later | and it is significantly harder to get rid of the once shiny toy. Taken even part way towards its extreme, this says that nothing new can ever be added until it is known to be perfect - information that cannot be obtained until it is added and used. When coupled with some requirement that there be some degree of consensus amongst developers the whole thing becomes impossible to ever achieve. Just trust the developers to make reasonable choices - any that make a habit of recklessness should simply be turfed out. If a developer thinks something is reasonable, and needed, and worth adding, then let it be added. If someone else believes there is a better solution, then allow the original to be modified/updated/replaced (ie: no ownership ego on the first method) - hopefully before the new functionality becomes part of a new release. Of course, developers also need to assess the costs of making errors, and seeking advice if they're not sure - that's part of avoiding becoming reckless. But not every change or addition warrants that. For system calls (including ioctls etc) real care needs to be taken to avoid adding backwards compatibility costs forever - for commands, this is less important, as if a new method provides a mechanism to achieve the same functionality as the command being replaced (eg: if some new command were to do what pwait(1) offers - perhaps in a different way) then backwards compatibility handling is trivial - just needs a small script to replace the C command using the new tool to achieve the result however is to be done, along with a man page addition telling people to migrate away. On the change in question - I don't personally have any need for it in the form it currently exists - but that's not any kind of argument against it. On the other hand, what I do really need in this area, is the ability to wait for any one of a set of processes to exit (and to tell me which one, status is less important, as I'll get that when I do a regular wait anyway). That is, I have scripts that start a number of processes, and as each finishes, start a replacement (until the work is done). Currently that turns out to be hard (writing at sh level - it is trivial in C or similar) as the wait builtin either waits for everything, or requires knowledge of which process (or job) is to finish next. If it were possible to modify pwait to exit when any of the processes in its arg list exited (and print which pid that was) it would make something that is currently very difficult become much easier. kre
Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon
Date: Wed, 04 Mar 2015 09:24:22 +1100 from: matthew green m...@eterna.com.au Taylor R Campbell writes: Module Name: src Committed By: riastradh Date: Tue Mar 3 13:57:20 UTC 2015 Modified Files: src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c Log Message: radeon_fence_wait returns 0, not positive, on success. i haven't confirmed yet, but i suspect this change breaks radeondrmkms. It does, and that breakage should be fixed by: https://mail-index.netbsd.org/source-changes/2015/03/03/msg063651.html
re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon
Taylor R Campbell writes: Date: Wed, 04 Mar 2015 09:24:22 +1100 from: matthew green m...@eterna.com.au Taylor R Campbell writes: Module Name: src Committed By:riastradh Date:Tue Mar 3 13:57:20 UTC 2015 Modified Files: src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c Log Message: radeon_fence_wait returns 0, not positive, on success. i haven't confirmed yet, but i suspect this change breaks radeondrmkms. It does, and that breakage should be fixed by: https://mail-index.netbsd.org/source-changes/2015/03/03/msg063651.html indeed, this fixes it for me. i thought i had tested it but i only had rev 1.7. thanks, and sorry for the noise! .mrg.
Re: CVS commit: src/usr.bin/pwait
On Tue, Mar 03, 2015 at 09:13:31PM +0100, Marc Balmer wrote: Am 03.03.15 um 17:49 schrieb Joerg Sonnenberger: On Tue, Mar 03, 2015 at 03:58:56PM +, Christos Zoulas wrote: For actionable items: pwait: Should I remove pwait or leave it? Are there any features you want added? Bring it up on tech-userlevel. In general: Should we have more concrete commit rules, or do we prefer that current status quo which is to leave things to people's judgement and occasionally backout things when people chose incorrectly according to consensus? I fully agree with Greg, the unwritten rule always was bring up bigger changes first. A good rule of thumb is the question what is the long term impact. A new tool (just like a new external API) comes with a lot of strings attached... Adding a new command is in no way a bigger change. don't like the new command? don't use it, then. It comes with a maintainance price. Add something better a version later and it is significantly harder to get rid of the once shiny toy. Joerg
re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon
Taylor R Campbell writes: Module Name: src Committed By: riastradh Date: Mon Mar 2 17:53:00 UTC 2015 Modified Files: src/sys/external/bsd/drm2/dist/drm/radeon: radeon_fence.c Log Message: Return the error if there is one in radeon_fence_wait_seq. Don't just always say we succeeded! To generate a diff of this commit: cvs rdiff -u -r1.5 -r1.6 \ src/sys/external/bsd/drm2/dist/drm/radeon/radeon_fence.c this is infact the problem change -- reverting back to radeon_fence.c 1.5 gives me (mostly) working drm again. .mrg.
re: CVS commit: xsrc/external/mit/MesaLib/dist/src/mesa/main
On Mar 4, 9:19am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: xsrc/external/mit/MesaLib/dist/src/mesa/main | | Christos Zoulas writes: | Module Name:xsrc | Committed By: christos | Date: Tue Mar 3 21:32:27 UTC 2015 | | Modified Files: | xsrc/external/mit/MesaLib/dist/src/mesa/main: imports.h | | Log Message: | xmmintrin.h is a gcc-specific header | | it is? /usr/include/gcc-4.8/xmmintrin.h | -rw-r--r-- 1 mrg wheel 27578 Feb 12 07:49 src/external/bsd/llvm/dist/clang/lib/Headers/xmmintrin.h Should it be exposed to the implementation? christos
Re: CVS commit: src/usr.bin/pwait
On Mar 3, 8:35am, g...@ir.bbn.com (Greg Troxel) wrote: -- Subject: Re: CVS commit: src/usr.bin/pwait | We do sort of have a rule, which is that significant changes need | discussion. I would say adding programs to base always counts. Other | than that, it's trickier, but if there's a reasonable likelihood of a | valid objection, I'd say it's over the line into signficant/discuss. This is what I mean: sort of == yes, but it is probably unwritten (ok fine) I would say == my interpretation of the rule christos
