Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 01:53:58PM -0400, Joey Hess wrote: Take shoop benchmarks (this is an old shoop tree I had lying around): bash: 1000 shoop 1st-stage resolver method calls : 0:05.51 ash : 1000 shoop 1st-stage resolver method calls : 0:01.33 bash: 1000 shoop 2nd-stage resolver method calls : 0:08.33 ash : 1000 shoop 2nd-stage resolver method calls : 0:02.23 bash: 1000 shoop 2nd-stage(nocache) resolver method calls : 0:08.19 ash : 1000 shoop 2nd-stage(nocache) resolver method calls : 0:02.27 (On a TM5800 with the cpu set to run at 333 to 533 mhz.) Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
On Fri, Jun 21, 2002 at 06:05:39PM -0400, Clint Adams wrote: sake. I understand the alleged benefits of ash (small, loads faster on a slow/small memory machine). Why would I, Debian user, benefit from being able to run pdksh as /bin/sh? (Remembering that standards compliance, in and of itself, does not give me a sexual thrill.) I answered this explicitly already. It gives you a smaller, faster-loading shell and it supports brace expansions, which are the number one bug filed against #!/bin/sh scripts. As far as I can tell there are two possibilities here: (a) it is pdksh or posh, and it already works at least as well as ash on the various #!/bin/sh scripts in Debian, or (b) it is pdksh or posh or similar, and it doesn't yet work as well as ash on the various #!/bin/sh scripts in Debian, due to various POSIX extensions that we use and it doesn't support In (a)'s case, this means that we can just say Actually, as it turns out, we don't merely support ash and bash as /bin/sh at present, actually we lucked out and we already support ash, bash and pdksh! and have no more problems continuing to support pdksh as we're going to have continuing to support ash. If this is the case, then there's *still* no value in minimising /bin/sh: we can get the smaller-faster-loading-more-reliable-shell that you're talking about without having to fix all your various bugs. Whichever shell you're talking obviously already supports kill -9, type and command, and whatever other useful features that we currently use and you want us to stop using. If this is supposedly the case, it'd be helpful to know which shell this is, and if it does actually work as well as you're hypothesising. So, if someone needs to run a low-memory machine in production, [...] In (b)'s case, on the other hand, you _can't_ run whatever shell you're talking about on a production, because it _doesn't_ work as well as ash, and this entire line of argument's erroneous. Is this not an answer? Well, no, it really isn't. If some shell already works better with than some other supported shell in practice, then it's supported de facto -- continuing to support it doesn't require signficant changes to current practice, by definition. As such, it doesn't make sense to use that as an argument about why we should change current practice. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpgl01DfMsVr.pgp Description: PGP signature
Re: RFD: Essential packages, /, and /usr
Any chance of a rerun with posh (sources are in queue/new and readable) or pdksh? I don't think you'll be able to gauge posh that way; shoop isn't POSIX-compliant. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
As far as I can tell there are two possibilities here: (a) it is pdksh or posh, and it already works at least as well as ash on the various #!/bin/sh scripts in Debian, or It is pdksh. (b) it is pdksh or posh or similar, and it doesn't yet work as well as ash on the various #!/bin/sh scripts in Debian, due to various POSIX extensions that we use and it doesn't support It is posh. Well, no, it really isn't. If some shell already works better with than some other supported shell in practice, then it's supported de facto -- continuing to support it doesn't require signficant changes to current practice, by definition. As such, it doesn't make sense to use that as an argument about why we should change current practice. So now the arbitrary criterion is breaks on less scripts than ash? gnumail won't run if /bin/sh is ash. The gnumail maintainer should a) make the script POSIX-compliant b) make the script a #!/bin/bash script c) do neither and complain ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFD: Essential packages, /, and /usr
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden If: Branden * Release critical bugs are _very_ rare.; and Branden * Release critical bugs should be the domain of the Release Manager, Branden Then we really don't need a tight connection between the Branden serious severity and release-criticality at all. Branden Release-criticality can be a tag -- whether that is Branden expressed in debbugs along with security, moreinfo, Branden patch and so forth or in a webpage like bugscan is Branden immaterial. Branden This tag -- no matter how it is expressed -- is the Release Branden Manager's domain. People can propose that a bug be treated Branden as release-critical and, perhaps, if it seems warranted, we Branden can make this a debbugs tag and possibly automatically set Branden it for all critical, grave, and serious bugs. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. If a bug is truly a showstopper for a Branden release, we don't release with it. We either wait, fix the Branden bug, or drop the package. I find myself in strong and vehement agrement with Branden on this point. manoj -- I think the sky is blue because it's a shift from black through purple to blue, and it has to do with where the light is. You know, the farther we get into darkness, and there's a shifting of color of light into the blueness, and I think as you go farther and farther away from the reflected light we have from the sun or the light that's bouncing off this earth, uh, the darker it gets ... I think if you look at the color scale, you start at black, move it through purple, move it on out, it's the shifting of color. We mentioned before about the stars singing, and that's one of the effects of the shifting of colors. Pat Robertson, The 700 Club Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#97671: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 02:02:00AM -0500, Manoj Srivastava wrote: Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden * Release critical bugs are _very_ rare.; and Branden * Release critical bugs should be the domain of the Release Manager, Branden Then we really don't need a tight connection between the Branden serious severity and release-criticality at all. Sorry, but this doesn't follow. Treating serious as a severity or a tag is largely immaterial, and the fundamental point of the serious severity or tag is as an aid to release management. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. No, it's not. In reality, things have always just been ignored, rather than being formally stripped of release-criticality. I find myself in strong and vehement agrement with Branden on this point. Branden brought up a number of interesting and good points (and, even better, simple) in the discussion he's referencing, but it was at the end of a pretty long winded and vicious argument about the referenced bug, and there was too much of an agree to anything just to get this over with on my behalf. Which isn't to say I don't agree with much of it, but I need some time to sit and look at this calmly before I can have a considered opinion on it. OTOH, there is one part that I have had plenty of opportunity to think about: and personally I don't believe debian-policy should have _any_ influence over the severity of a bug. If there're already good reasons for increasing the severity of a bug without policy, then that's good enough. If there aren't, policy shouldn't be forcing them on people. There're plenty of ways we can improve Debian without raising the members of the policy list as being better or more powerful than other developers. Beyond _all_ other things, this is the major problem with the serious severity and release-critical bugs (and debian-policy@) at the moment. And as much as I'd like to be able to say it's better to have -policy be better and more powerful than the release manager for general democratic and consensus principles, I'm sorry, but it simply hasn't worked, and I'm yet to see *anyone* even remotely interested in making it work. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``BAM! Science triumphs again!'' -- http://www.angryflower.com/vegeta.gif pgpweSghV8iHS.pgp Description: PGP signature
Re: Bug#97671: RFD: Essential packages, /, and /usr
On Sat, Jun 22, 2002 at 09:29:42PM +1000, Anthony Towns wrote: Sorry, but this doesn't follow. Treating serious as a severity or a tag is largely immaterial, and the fundamental point of the serious severity or tag is as an aid to release management. That may be its intent, but apparently that's not how it's being used a large proportion of the time. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. No, it's not. In reality, things have always just been ignored, rather than being formally stripped of release-criticality. My statement does not assert that the Release Manager has undertaken any formal procedure. I'm saying that it is the case that a bug isn't de facto release critical if the Release Manager doesn't treat it thus. And as much as I'd like to be able to say it's better to have -policy be better and more powerful than the release manager for general democratic and consensus principles, I'm sorry, but it simply hasn't worked, and I'm yet to see *anyone* even remotely interested in making it work. I think these are largely orthogonal issues. Debian Policy is a great tool, but ill-suited to determining release viability for an individual package or for the distribution as a whole. In my opinion and experience, a Debian Policy is better suited to establishing and enforcing objective criteria that ultimately serve to improve the quality of Debian packages, and of the distribution as a whole. Due to the objectivity and specificity of the criteria it establishes, it is easy for a large number of people to participate in the process of crafting Policy in a democratical and consensus-driven manner. Release management is a highly subjective process -- at least the way Debian does it -- because we always settle for something significantly less than perfection (IMO that's a good thing). The establishment of subjective criteria for good enough is often influenced by external factors like upstream releases, security issues, Debian's non-package infrastructure (automated security builds, the mirror network, etc.) and the date on the calendar. Due to that, I think it makes more sense for release management by an individual or a small team of people who work together well. The bottom line for me is that it's difficult to achieve consensus on subjective issues. I think our approach to the twin nemeses of policy and release management need to reflect this fact better than they do at present. -- G. Branden Robinson| Debian GNU/Linux | If encryption is outlawed, only [EMAIL PROTECTED] | outlaws will @goH7Ok=q4fDj]Kz?. http://people.debian.org/~branden/ | pgpV6Xktse9NC.pgp Description: PGP signature
