Re: CVS commit: src/usr.bin/pwait
On Wed, Mar 04, 2015 at 08:10:57AM +0700, Robert Elz wrote: > Date:Wed, 4 Mar 2015 00:13:01 +0100 > From:Joerg Sonnenberger > 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. *sigh* I was asking about requesting feedback before adding new components. That doesn't mean the new component has to be perfect, but it should demonstrate a need and give others a chance to make sure it is not too restricted to be useless for related problems they know about. I have been asking this before, exactly because I don't like having to maintain lousy interfaces like strtonum long term. New programs are no different. People love to kill such requests as color decisions. It is more a basic case of "step back, let it settle for a moment and give others a chance to shime in". I'm not a proponent of "base must be minimal" nor do I belong to the "base must have a kitchen sink". I've written on tech-userlevel what problems I have in this very area and why this tool doesn't help. I believe a better solution can cover both needs, but now it looks like we will maintain a new script interface with very limited functionality. Joerg
Re: CVS commit: src/usr.bin/pwait
Date:Wed, 4 Mar 2015 00:13:01 +0100 From:Joerg Sonnenberger 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/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/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
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 21:22 schrieb Greg Troxel: > > Marc Balmer 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 22:03 schrieb Greg Troxel: > > Marc Balmer 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:32 schrieb Greg Troxel: > > Marc Balmer 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
Marc Balmer 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. pgpDBVZSB_uo3.pgp Description: PGP signature
Re: CVS commit: src/usr.bin/pwait
Marc Balmer 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: src/usr.bin/pwait
Marc Balmer 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
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
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
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 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
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
In article <20150303071552.gc27...@britannica.bec.de>, Joerg Sonnenberger 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
On Tue, Mar 03, 2015 at 02:35:49AM +, Christos Zoulas wrote: > In article <20150303003710.ga20...@britannica.bec.de>, > Joerg Sonnenberger wrote: > >On Mon, Mar 02, 2015 at 04:43:39PM -0500, Christos Zoulas wrote: > >> Module Name: src > >> Committed By: christos > >> Date: Mon Mar 2 21:43:39 UTC 2015 > >> > >> Added Files: > >>src/usr.bin/pwait: Makefile pwait.1 pwait.c > >> > >> Log Message: > >> Add pwait, from FreeBSD > > > >Please don't just import programs without asking for feedback on the > >appropiate lists. For example, why does this program not have a timeout > >option? I guess I am not the only programmer here with a process monitor > >written based on kqueue and *this* tool has both ugly warts (matching > >against /proc for Solaris compat, seriously?) and limitations. > > It is easy enough to add (the timeout). Even if we add it, we would > add it post import to keep local differences separate. The solaris > compat is not even documented (was it worth removing? I don't think > so). It is a useful tool and this code provided a nice starting > point. > > I was actually thinking about the timeout implementation (using the > kevent timeout or using SIGALRM) and I have not decided yet. What do > you think? You are missing the most important part of my mail: why did this not go to tech-userlevel first? Joerg
Re: CVS commit: src/usr.bin/pwait
In article <20150303003710.ga20...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Mon, Mar 02, 2015 at 04:43:39PM -0500, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Mon Mar 2 21:43:39 UTC 2015 >> >> Added Files: >> src/usr.bin/pwait: Makefile pwait.1 pwait.c >> >> Log Message: >> Add pwait, from FreeBSD > >Please don't just import programs without asking for feedback on the >appropiate lists. For example, why does this program not have a timeout >option? I guess I am not the only programmer here with a process monitor >written based on kqueue and *this* tool has both ugly warts (matching >against /proc for Solaris compat, seriously?) and limitations. It is easy enough to add (the timeout). Even if we add it, we would add it post import to keep local differences separate. The solaris compat is not even documented (was it worth removing? I don't think so). It is a useful tool and this code provided a nice starting point. I was actually thinking about the timeout implementation (using the kevent timeout or using SIGALRM) and I have not decided yet. What do you think? christos
Re: CVS commit: src/usr.bin/pwait
On Mon, Mar 02, 2015 at 04:43:39PM -0500, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Mon Mar 2 21:43:39 UTC 2015 > > Added Files: > src/usr.bin/pwait: Makefile pwait.1 pwait.c > > Log Message: > Add pwait, from FreeBSD Please don't just import programs without asking for feedback on the appropiate lists. For example, why does this program not have a timeout option? I guess I am not the only programmer here with a process monitor written based on kqueue and *this* tool has both ugly warts (matching against /proc for Solaris compat, seriously?) and limitations. Joerg
