Re: unreproducable bugs
On Sat, Jul 16, 2005 at 01:14:07AM +0100, Rich Walker wrote: Yes, to rely on 1300 developers to all think of your cunning method of solving a problem clearly makes sense. After all, to *write down* a technique that solves the problem, and make it available to all of them would stilt their creativity, hinder their intellect, and prevent the development of a consistent style! I'm pretty sure I've come across this as a guideline in the maintainer docs, if not as a hard-and-fast rule. -- Jon Dowland http://jon.dowland.name/ PGP fingerprint: 7032F238 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On 20050717T213903-0700, Thomas Bushnell BSG wrote: Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: On 20050716T195244-0700, Thomas Bushnell BSG wrote: That's a far cry different from someone wanting to enforce a requirement. Who, in this thread, is this hypothetical someone? Right. Manoj asked: why should we have a requirement? Someone said here's why! and I am simply pointing out that you can get what he wanted without a requirement. My mistake then. My other comments, not directed at you, still apply, though. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: unreproducable bugs
On 20050716T195244-0700, Thomas Bushnell BSG wrote: That's a far cry different from someone wanting to enforce a requirement. Who, in this thread, is this hypothetical someone? As far as I can tell, this thread started with a simple question: is there a policy for a certain thing? There were a couple of honest responses, Then we have a lot of whining about how the younglings cannot think for themselves from people who should know better, and a mini-flamewar based on those thoughts, but I haven't seen anyone talking about enforcing anything, until now. Where did the old-fashioned practice of reading comprehension and assuming good intentions (instead of stupidity or malice) go [1]? (No, this isn't directed solely, or even mainly, at you:) [1] Yes, there are situations where you should assume malice, but debian-devel discussions aren't one of them - and there is no situation where assuming stupidity is better than assuming good intentions. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: unreproducable bugs
On Sun, 17 Jul 2005 10:11:34 +0300, Antti-Juhani Kaijanaho [EMAIL PROTECTED] said: On 20050716T195244-0700, Thomas Bushnell BSG wrote: That's a far cry different from someone wanting to enforce a requirement. Who, in this thread, is this hypothetical someone? As far as I can tell, this thread started with a simple question: is there a policy for a certain thing? There were a couple of honest responses, Then we have a lot of whining about how the younglings cannot think for themselves from people who should know better, and a mini-flamewar based on those thoughts, but I haven't seen anyone talking about enforcing anything, until now. Where did the old-fashioned practice of reading comprehension and assuming good intentions (instead of stupidity or malice) go [1]? (No, this isn't directed solely, or even mainly, at you:) A little reading comprehension on your part would help a bit here. Hint: dict policy would help. The discussion started wuth a wuestion of _policy_. Once you comprehend what that word means, you'll see what Thomas meant. manoj -- What a COINCIDENCE! I'm an authorized SNOOTS OF THE STARS dealer!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 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: unreproducable bugs
On 20050717T025707-0500, Manoj Srivastava wrote: A little reading comprehension on your part would help a bit here. Hint: dict policy would help. The discussion started wuth a wuestion of _policy_. Once you comprehend what that word means, you'll see what Thomas meant. I distinctly remember you arguing that Policy is not a stick to beat people with. How then, in your opinion, could the mere mention of the word policy imply wanting to enforce anything? Assume the best possible motivations, please. In this case, it could go a long way if people would read policy as the DDR when such a reading makes a question make perfect sense (and, if they must, politely correct the error). Some people actually did that. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: unreproducable bugs
On Sun, 17 Jul 2005 11:35:14 +0300, Antti-Juhani Kaijanaho [EMAIL PROTECTED] said: On 20050717T025707-0500, Manoj Srivastava wrote: A little reading comprehension on your part would help a bit here. Hint: dict policy would help. The discussion started wuth a wuestion of _policy_. Once you comprehend what that word means, you'll see what Thomas meant. I distinctly remember you arguing that Policy is not a stick to beat people with. How then, in your opinion, could the mere mention of the word policy imply wanting to enforce anything? I can see what you mean about reading comprehension. I say that when people want to put things into policy to beat people in the head with. You see, then something is in policy, you are supposed to pay attention to it, since otherwise there is no point in having a policy at all. Secondly, not all policy in the world, or even in Debian, is in the Debian technical policy document; indeed, the unadorned word policy still has meaning, commonly accepted as in the wider world. Assume the best possible motivations, please. In this case, it could go a long way if people would read policy as the DDR when such a reading makes a question make perfect sense (and, if they must, politely correct the error). Some people actually did that. Yeah, it could also go away if people read policy to mean the movie I saw yesterday. However, if you want to communicate, people need to have a common understanding of what a word means. Unless, like Clinton, your sentences depends on what the meaning of the word is is. As to good intentions, the road to hell is paved with good intentions; and the good intent is no reason to suspend critical thinking. manoj -- It will be advantageous to cross the great stream ... the Dragon is on the wing in the Sky ... the Great Man rouses himself to his Work. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 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: unreproducable bugs
On Fri, Jul 15, 2005 at 01:54:48PM -0400, kamaraju kusumanchi wrote: Manoj Srivastava wrote: On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Dont know about others. But whenever I post some question on irc or a mailing list the most frequent answer is 'it is there in the policy', 'go by the policy', 'read the policy' etc., Similar answers would have made other people think that all Debian maintainers/developers should go by the policy and only by the policy. I'd suggest checking the usual suspects (Policy, DevRef, NM Guide, etc) before asking questions. Then, when people give you those sorts of answers, you can confidently say no it's not, go eat your hat. - Matt signature.asc Description: Digital signature
Re: unreproducable bugs
Antti-Juhani Kaijanaho [EMAIL PROTECTED] writes: On 20050716T195244-0700, Thomas Bushnell BSG wrote: That's a far cry different from someone wanting to enforce a requirement. Who, in this thread, is this hypothetical someone? Right. Manoj asked: why should we have a requirement? Someone said here's why! and I am simply pointing out that you can get what he wanted without a requirement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote: [cranky but funny stuff] If there ever is a blackball commitee, Manoj of all people belongs on it. :-) Cheers, - Michael
Re: unreproducable bugs
Rich Walker [EMAIL PROTECTED] writes: Yes, to rely on 1300 developers to all think of your cunning method of solving a problem clearly makes sense. After all, to *write down* a technique that solves the problem, and make it available to all of them would stilt their creativity, hinder their intellect, and prevent the development of a consistent style! If you want to write down a technique and recommend it to your fellow developers, please, by all means, do so. That's a far cry different from someone wanting to enforce a requirement. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unreproducable bugs
Hi, is there a policy for bugs which are unreproducible? I mean how long this kind of bug should be open? There are bugs who are unreproducible for over a year and the version increased to a major version during the time. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
Hi, is there a policy for bugs which are unreproducible? I mean how long this kind of bug should be open? There are bugs who are unreproducible for over a year and the version increased to a major version during the time. I tend to request the user for more info with the new version; so add a +moreinfo, and send a mail to the user that if the user doesn't respond within a reasonable timeframe (say 2 months), it will be closed. It should work; it's not easy to really fix a bugreport which is unreproducible and the reporter is no longer able to respond. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
Hi, * Junichi Uekawa [EMAIL PROTECTED] [2005-07-15 16:12]: is there a policy for bugs which are unreproducible? I mean how long this kind of bug should be open? There are bugs who are unreproducible for over a year and the version increased to a major version during the time. I tend to request the user for more info with the new version; so add a +moreinfo, and send a mail to the user that if the user doesn't respond within a reasonable timeframe (say 2 months), it will be closed. It should work; it's not easy to really fix a bugreport which is unreproducible and the reporter is no longer able to respond. Yes that would make sense. But what about documentating this so it don't have to be just a feeling of the maintainer that it is time to close it? Maybe in the developers reference? Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: Hi, is there a policy for bugs which are unreproducible? I mean how long this kind of bug should be open? There are bugs who are unreproducible for over a year and the version increased to a major version during the time. Regards Nico Umm, no. It is left to the discretion and judgement of the developer. Like others in the thread, I, too, tend to ask the submitter if the bug can still be reproduced, and, if so, to resubmit a log to see if any additional information has turned up. What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? manoj -- After the correction has been found to be in error, it will be impossible to fit the original quantity back into the equation. --anonymous Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 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: unreproducable bugs
Manoj Srivastava wrote: On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? manoj Dont know about others. But whenever I post some question on irc or a mailing list the most frequent answer is 'it is there in the policy', 'go by the policy', 'read the policy' etc., Similar answers would have made other people think that all Debian maintainers/developers should go by the policy and only by the policy. just my 2 cents raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
Hi, * Manoj Srivastava [EMAIL PROTECTED] [2005-07-15 20:08]: On Fri, 15 Jul 2005 15:42:44 +0200, Nico Golde [EMAIL PROTECTED] said: Hi, is there a policy for bugs which are unreproducible? I mean how long this kind of bug should be open? There are bugs who are unreproducible for over a year and the version increased to a major version during the time. Regards Nico Umm, no. It is left to the discretion and judgement of the developer. Like others in the thread, I, too, tend to ask the submitter if the bug can still be reproduced, and, if so, to resubmit a log to see if any additional information has turned up. Yes thats what i would do too but I have seen alot of bugs where the emailaddress isn't actual anymore. What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? no of course not but it would be good to have a reference value. Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpLbiHVCrEFI.pgp Description: PGP signature
Re: unreproducable bugs
On Fri, Jul 15, 2005 at 08:11:15PM +0200, Nico Golde wrote: no of course not but it would be good to have a reference value. it seems something that would be most appropriate as a guideline supplied in the debian developers' reference. sean -- signature.asc Description: Digital signature
Re: unreproducable bugs
Hi, * sean finney [EMAIL PROTECTED] [2005-07-15 20:43]: On Fri, Jul 15, 2005 at 08:11:15PM +0200, Nico Golde wrote: no of course not but it would be good to have a reference value. it seems something that would be most appropriate as a guideline supplied in the debian developers' reference. yes i suggested the same in my second mail. regards nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpSiXy93p1ek.pgp Description: PGP signature
Re: unreproducable bugs
On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Welcome to the software industry in 2005. If you haven't yet encountered a senior software engineer with three degrees and a six-figure salary who couldn't debug his way out of a paper bag, you work in a very different part of the industry than I do. [Note that I am not accusing Nico or anyone else in Debian of fitting this description.] The threshold at which it is actually rather improbable that one totally lacks the capacity for independent judgment seems to be principal engineer -- a director equivalent in many large companies. I have worked with a number of junior staff whose performance exceeded my expectations for their level of seniority -- including at least one guy with a so-so high school education who was more able than several MSCS's I have known -- but they are very much the exceptions rather than the rule. It's not the lack of (programming or human) language skills that's the problem -- it's the lack of thinking skills. I don't know if they can be taught, but they certainly aren't being taught. This problem is endemic in the US educational system -- reputed to be worse in California than almost anywhere else, even most of the Deep South -- and if my personal experience is any guide there are a few other countries that are in similar positions. Formal evaluation processes don't seem to do jack to keep the nitwits out. The only thing I've ever seen work is a self-selected review team with anonymous blackball authority and a few seriously cranky members. That, of course, has its own problems; but it does work, at least for a while. Cheers, - Michael
Re: unreproducable bugs
On 15-Jul-05, 11:12 (CDT), Manoj Srivastava [EMAIL PROTECTED] wrote: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Probably the growing number of users and other maintainers who argue, re-open bugs, etc. etc. etc. unless you can prove that your judgement is enshrined in policy. Or maybe I'm just getting cynical. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
Michael K. Edwards [EMAIL PROTECTED] writes: On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Welcome to the software industry in 2005. [snip] Yes, to rely on 1300 developers to all think of your cunning method of solving a problem clearly makes sense. After all, to *write down* a technique that solves the problem, and make it available to all of them would stilt their creativity, hinder their intellect, and prevent the development of a consistent style! Sheesh, next you'll be arguing in favour of personal indentation styles! cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote: Michael K. Edwards [EMAIL PROTECTED] writes: On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Welcome to the software industry in 2005. Yes, to rely on 1300 developers to all think of your cunning method of solving a problem clearly makes sense. After all, to *write down* a technique that solves the problem, and make it available to all of them would stilt their creativity, hinder their intellect, and prevent the development of a consistent style! I am having a hard time reading this as anything but a non sequitur. Personally, I prefer for a solution to be demonstrated to work, both socially and technically, before it is enshrined in policy. Drafts are, of course, welcome at any stage. Rough consensus and running code. YMMV. Sheesh, next you'll be arguing in favour of personal indentation styles! Well, yes -- as long as the indent / emacs-mode / vim-mode incantations that reproduce them are well documented, preferably in a magic comment at the end of each file. :-) Cheers, - Michael
Re: unreproducable bugs
Michael K. Edwards [EMAIL PROTECTED] writes: On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote: Michael K. Edwards [EMAIL PROTECTED] writes: On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Welcome to the software industry in 2005. Yes, to rely on 1300 developers to all think of your cunning method of solving a problem clearly makes sense. After all, to *write down* a technique that solves the problem, and make it available to all of them would stilt their creativity, hinder their intellect, and prevent the development of a consistent style! I am having a hard time reading this as anything but a non sequitur. Umm; it follows more from Manoj's comment than yours. Personally, I prefer for a solution to be demonstrated to work, both socially and technically, before it is enshrined in policy. Drafts are, of course, welcome at any stage. Rough consensus and running code. YMMV. You scale an organisation, I understand, by removing the *need* for everyone in it to be a genius at everything it does. Hence the comment about the US army: designed by genius to be run by sergeants. There does seem to be a lot of discussion on the debian groups about policy. If Debian is lucky, or well-managed, then it is the process you are describing. If it is unlucky, then it is a bunch of rule-lawyers having fun. Sheesh, next you'll be arguing in favour of personal indentation styles! Well, yes -- as long as the indent / emacs-mode / vim-mode incantations that reproduce them are well documented, preferably in a magic comment at the end of each file. :-) Exactly: that and an indent script in the checkin routine remove any issue. See how that compares to policy, which is hopefully implemented in such a way as to be mechanically testable? cheers, Rich. Cheers, - Michael -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote: I am having a hard time reading this as anything but a non sequitur. Umm; it follows more from Manoj's comment than yours. Ah. OK. Personally, I prefer for a solution to be demonstrated to work, both socially and technically, before it is enshrined in policy. Drafts are, of course, welcome at any stage. Rough consensus and running code. YMMV. You scale an organisation, I understand, by removing the *need* for everyone in it to be a genius at everything it does. Bingo! You also take care not to formalize unduly, or you get a sclerotic bureaucracy. Hence the comment about the US army: designed by genius to be run by sergeants. As a close associate of several sergeants in the US Army, I question only the designed by genius part. Given what armies do for a living, Darwinian selection is probably also a factor. :-) There does seem to be a lot of discussion on the debian groups about policy. If Debian is lucky, or well-managed, then it is the process you are describing. If it is unlucky, then it is a bunch of rule-lawyers having fun. Don't knock rule-lawyers, just ignore them until they produce something you can tolerate. And keep your eyes open for things that you don't want to agree with but that happen to reflect a real-world truth of which you were previously unaware. Kinda like real lawyers, actually. Well, yes -- as long as the indent / emacs-mode / vim-mode incantations that reproduce them are well documented, preferably in a magic comment at the end of each file. :-) Exactly: that and an indent script in the checkin routine remove any issue. As long as it's purely advisory, please -- no tool is perfect (although TeX is damn close). See how that compares to policy, which is hopefully implemented in such a way as to be mechanically testable? To within certain limits, as demonstrated by lintian and linda -- up there with dpkg and debhelper in the pantheon of Debian's contributions to the world. Not quite on par with the DFSG, but that's only to be expected; the DFSG is not intended to be testable by a machine that is less than Turing-complete. :-) Cheers, - Michael
Re: unreproducable bugs
Michael K. Edwards [EMAIL PROTECTED] writes: On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote: I am having a hard time reading this as anything but a non sequitur. Umm; it follows more from Manoj's comment than yours. Ah. OK. Should have sent two postings :- Personally, I prefer for a solution to be demonstrated to work, both socially and technically, before it is enshrined in policy. Drafts are, of course, welcome at any stage. Rough consensus and running code. YMMV. You scale an organisation, I understand, by removing the *need* for everyone in it to be a genius at everything it does. Bingo! You also take care not to formalize unduly, or you get a sclerotic bureaucracy. Given the difficulty of getting agreement in this place, I think that unlikely. (As a practicing SubGenius, I like to think of the ornery, cussing Debian, up there with the Two-Fisted Jesus, and the Butting Buddha. Others may have other views) Hence the comment about the US army: designed by genius to be run by sergeants. As a close associate of several sergeants in the US Army, I question only the designed by genius part. Given what armies do for a living, Darwinian selection is probably also a factor. :-) Helps. The British Army likes to send officers out in front - produces lots of dead heroes in the upper classes, as well as reducing incidence of fragging... By the way, a spot of Google produces: Child (1984) cited A machine designed by geniuses to be run by idiots, Herman Wouk, The Caine Mutiny, on the organization of the wartime US Navy. [snip sane remarks] Exactly: that and an indent script in the checkin routine remove any issue. As long as it's purely advisory, please -- no tool is perfect (although TeX is damn close). See how that compares to policy, which is hopefully implemented in such a way as to be mechanically testable? To within certain limits, as demonstrated by lintian and linda -- up there with dpkg and debhelper in the pantheon of Debian's contributions to the world. Not quite on par with the DFSG, but that's only to be expected; the DFSG is not intended to be testable by a machine that is less than Turing-complete. :-) I get asked from time to time by academics for interesting projects for their students. I think I now have another: Implement a system capable of using standard AI techniques to process the (a) existing judgements and (b) content of debian.legal such that it can issue plausible analysis of a new software license... cheers, Rich. Cheers, - Michael -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unreproducable bugs
On 7/15/05, Rich Walker [EMAIL PROTECTED] wrote: (As a practicing SubGenius, I like to think of the ornery, cussing Debian, up there with the Two-Fisted Jesus, and the Butting Buddha. Others may have other views) As a practicing Episcopatheist, I like to murmur, There is no God, and debian-legal is her Prophet. ;- Helps. The British Army likes to send officers out in front - produces lots of dead heroes in the upper classes, as well as reducing incidence of fragging... Yes, indeed. Dead heroes are the safe kind, from a political point of view. The US, with a little help from its foes, is currently engaged in producing an alarming number of one of the unsafe kinds: living but multiply amputated and/or addled by massive brain trauma. Ooh -- I didn't notice your .sig before I wrote that. Synchronicity? :-/ By the way, a spot of Google produces: Child (1984) cited A machine designed by geniuses to be run by idiots, Herman Wouk, The Caine Mutiny, on the organization of the wartime US Navy. I do like a man who cites his sources. I get asked from time to time by academics for interesting projects for their students. I think I now have another: Implement a system capable of using standard AI techniques to process the (a) existing judgements and (b) content of debian.legal such that it can issue plausible analysis of a new software license... Plausible? No problem -- in the trade we call that a pseudo-random number generator. Hard to implement without infringing some patent the USPTO issued last week, though ... Cheers, - Michael
Re: unreproducable bugs
On Sat, 16 Jul 2005 01:14:07 +0100, Rich Walker [EMAIL PROTECTED] said: Michael K. Edwards [EMAIL PROTECTED] writes: On 7/15/05, Manoj Srivastava va, manoj [EMAIL PROTECTED] wrote: What's with the recent push to get every little things written down into policy, so the developer no longer is required to have an ability to think, or exercise any judgement whatsoever? Welcome to the software industry in 2005. [snip] Yes, to rely on 1300 developers to all think of your cunning method of solving a problem clearly makes sense. Good god. If anyone thinks that handling a long open unreproducible problem in the ways mentions is cunning method, I think they better look at a nice long apprenticeship before aspiring to be a DD. After all, to *write down* a technique that solves the problem, and make it available to all of them would stilt their creativity, hinder their intellect, and prevent the development of a consistent style! If we have to create a written document to spoon feed people solutions to trivial problems, the project is doomed anyway, and nothing really matters. manoj who can't believe we have sunk this low -- Reality is bad enough, why should I tell the truth? Patrick Sky Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 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: unreproducable bugs
On Sat, 16 Jul 2005 01:43:46 +0100, Rich Walker [EMAIL PROTECTED] said: You scale an organisation, I understand, by removing the *need* for everyone in it to be a genius at everything it does. Hence the comment about the US army: designed by genius to be run by sergeants. Ah yes. How does one handle long open unreproducible bugs after a few releases -- the work requiring genius. Who am I to stand in the way of changing times? Since I have been around longer than most people in Debian, here is my terribly clever best practice for a critical process that debian developers are supposed to practice frequently -- very frequently (the recommended rate is about 15-20 repetitions per minute), namely, breathing. That this is a critical process is clearly demonstrable, and that there needs to be strict guidelines on the rate at which it is practiced is also of prime importance. Raising the rate too high results in a deprecated condition called hyper ventilating. The side effects can be light headedness -- consider the harm if the entire project failed to follow the guidelines. The effects on the project can be even more pronounced if a majority of the developers were so lax as to not practice this activity for even as short an interval as, say, 5 to 10 minutes. The effects would be felt even more in small teams, like, say, security, or ftp-masters, if they grow this lax. So, having given the rationale for the importance of this best practices document snippet, allow me to present the best practice itself: (details in http://www.mtsu.edu/~jshardo/bly2020/respiratory/ventilation.html) At the start of the cycle, remember to relax the Dome-shaped skeletal muscle that forms floor of thoracic cavity. Diaphragm relaxes shortens pleural cavities, thus decreasing intrathoracic volume. Lungs elastically recoil, chest wall abdominal organs help compress lungs, increasing alveolar pressure air flows out. External intercostals relax, ribs sternum move downward inward, decreases anterior-posterior diameter. Air flows out. This is a Passive process. Hold for a short time. Due to the recomeded period of this activity, it is not recommended that you hold for more than a second or so. Contraction of diaphragm causes it to flatten lengthen the pleural cavities, thus increasing intrathoracic volume. Lungs expand, decreasing alveolar pressure within lungs atmospheric air flows in. Contraction of external intercostal muscles pull ribs sternum upward outward, increases anterior-posterior thoracic diameter by 20%. Air flows in. This is the active part of the process. It is imperative that Debian developers remember to invoke this active process several times a minute. Laxity in this can severely hurt the project. Indeed, failure to follow this policy may result in an RC bug or orphaning of all the packages held by the lax developer. manoj -- Just remember: when you go to court, you are trusting your fate to twelve people that weren't smart enough to get out of jury duty! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 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]
