Re: Release-critical bugs, and #97671
Anthony Towns writes (Re: Release-critical bugs, and #97671): I still haven't had a chance to properly think about the whole serious and -policy and whatever issues, so I'm still not making substantive comments about this. Right, well, no-one seems to be telling me what to do, so I'll reassign the bug to bugs.debian.org, project and you and the DPL can argue it out. Have fun :-). Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
On Sat, Jul 06, 2002 at 01:33:56PM +0200, Josip Rodin wrote: Branden has suggested that we make a release-critical tag that we would automatically add to all bugs filed with severities currently marked RC, and the release manager would later be able to strip off these as needed. I still haven't had a chance to properly think about the whole serious and -policy and whatever issues, so I'm still not making substantive comments about this. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian Jackson writes (Re: Release-critical bugs, and #97671): The Technical Committee has passed the following resolution, regarding the dispute surrounding Bug#97671 and the proper use of the Severity tag and other BTS features: ... We therefore recommend that * The bug system administrators and/or the project leader or some other delegates appointed by the project leader decide on the proper use of the bug system features. I'd therefore like to formally request that the bug system administrators and/or the project leader take responsibility for this issue. I have spoken informally to one of the bug system administrators on IRC, and was advised that they wish to avoid process and political questions and want to just keep the software working. Therefore, I'd suggest that the project leader ought to consider the question, or delegate it. Should I reassign the bug report to the `project' pseudo-package ? Or is there some other pseudo-package for the project leader ? Thanks, Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Ian Jackson) writes: No-one has commented to say they object to us punting on this one, so I hereby call for a vote on the resolution I proposed on Monday. If anyone votes against, or proposes an amendment, I'll probably withdraw the resolution so we can talk about it. Ian, I agree with your assessment of the situation, and support the resolution. Bdale -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE9H9szZKfAp/LPAagRAvt7AJ4sQ/LxMXlbjjC1p6sTlrD0GzMr4gCfUoJ0 JR1HAYYtjaQUF4Cra8pKAcM= =jEpn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Jason Gunthorpe writes (Re: Release-critical bugs, and #97671): On Wed, 26 Jun 2002, Ian Jackson wrote: No-one has commented to say they object to us punting on this one, so I hereby call for a vote on the resolution I proposed on Monday. If anyone votes against, or proposes an amendment, I'll probably withdraw the resolution so we can talk about it. I think this is just fine. I agree that it is not fitting for the ctte to decide how the project should use the current BTS features. Right. I take it we're to interpret that as a vote in favour ? (Obviously I vote in favour too.) Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian Jackson writes (Re: Release-critical bugs, and #97671): I therefore hereby propose the following resolution of the Technical Committee: (Full resolution below.) No-one has commented to say they object to us punting on this one, so I hereby call for a vote on the resolution I proposed on Monday. If anyone votes against, or proposes an amendment, I'll probably withdraw the resolution so we can talk about it. Ian. -8- We note that * This dispute contains both technical and process (ie political) elements; however, it has not been possible to identify a clear technical dispute which as at the heart of the problem. * The heart of the problem seems to be a disagreement over the proper use of various tagging features of the bug tracking system. This is a process matter. * We do not feel that this decision is within our normal remit; the constitution suggests that the project leader and delegates would be responsible. * The bug system administrators would seem to be the most relevant delegates. * We are not sufficiently united in our opinions that we feel that the Committee should issue any formal advice or opinion. * Should a disputed technical question be raised, we would be happy to answer it. We therefore recommend that * The bug system administrators and/or the project leader or some other delegates appointed by the project leader decide on the proper use of the bug system features. -- Ian Jackson, at home. Local/personal: [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.chiark.greenend.org.uk/~ijackson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
On Wed, 26 Jun 2002, Ian Jackson wrote: No-one has commented to say they object to us punting on this one, so I hereby call for a vote on the resolution I proposed on Monday. If anyone votes against, or proposes an amendment, I'll probably withdraw the resolution so we can talk about it. I think this is just fine. I agree that it is not fitting for the ctte to decide how the project should use the current BTS features. Jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
This discussion makes it clear to me that the decision here is not technical, it is a question of process. As such it should be made by the project leadership and/or bug tracking administrators. I therefore hereby propose the following resolution of the Technical Committee: We note that * This dispute contains both technical and process (ie political) elements; however, it has not been possible to identify a clear technical dispute which as at the heart of the problem. * The heart of the problem seems to be a disagreement over the proper use of various tagging features of the bug tracking system. This is a process matter. * We do not feel that this decision is within our normal remit; the constitution suggests that the project leader and delegates would be responsible. * The bug system administrators would seem to be the most relevant delegates. * We are not sufficiently united in our opinions that we feel that the Committee should issue any formal advice or opinion. * Should a disputed technical question be raised, we would be happy to answer it. We therefore recommend that * The bug system administrators and/or the project leader or some other delegates appointed by the project leader decide on the proper use of the bug system features. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Manoj Srivastava writes (Re: Release-critical bugs, and #97671): Ian Jackson [EMAIL PROTECTED] writes: But, that doesn't mean that the severities need to remain set by those objective criteria. Someone other than the submitter, with a greater overview of the whole package or distribution, might have a better idea, and might reasonably apply subjective judgement. To what end? Why make the objective criteria malleable? When one discards objective criteria for classifying bugs, one merely opens the door for more disruptive disagreements between reporters, and even fellow maintainers. With around a 1000 developers and counting, there is unlikely to be agreement amongst developers. Perhaps this will be an aside, or an attack on a straw man, but: I seem to get the impression that you want to try to generally reduce subjective judgements, and discretion. I think this is a deeply flawed goal. We rely absolutely on the good judgement of our maintainers and other members of the project, and I don't see how it could be any other way. If it were possible to produce a good distribution without using the judgement of good people, it would be a lot easier, it's true, but I think it's not at all possible. Any attempt to do this will result in a tendency towards blind application of rules, rather than detailed understanding of particular cases, which seems to me to be the very opposite of what is required when doing system integration. The hard bits of system integration are all about special cases. We have plenty of mechanisms for helping people excercise judgement wisely, and in extremis we also have the Technical Committee, who can overrule something that is sufficiently clearly a mistake. I think we should be relying on these. I think the best way to resolve arguments is to make sure that it is clear in whose bailiwick a certain decision falls, and having a well-functioning escalation procedure, rather than trying to make every decision objective. So, on to the actual question at hand, here: you want to try to make the bug severity criteria objective. What purpose do you think the severity classification serves ? It seems to me that Branden was trying to use it the BTS to help manage his worklist, and that he wanted to use the severities to do so. This is, it seems to me, exactly what the severities were originally intended for, and if we think that that's what they're for, it seems clear that the package maintainer is generally authoritative for the severity of a bug. Your recollection may disagree with mine, but if so I'd like you to go into more detail about what the purpose was/is. You say: [The severity] represents impact on the system. It categorizes the bug. It helps people understand potential damage the bug could cause, at a glance. It keeps packages out of testing. Releases occur farly seldom, and whether a certain version of a package is releasable or not is of importance to a small number of people for relatively short intervals of time. I think these are all different and in some cases conflicting functions. * If the severity is supposed to be objectively determined by the policy manual, I don't see how it could represent impact on the system; furthermore, depending how you interpret `impact on the system' it might well correspond fairly closely to a notion of how high a priority the bug was on a notional todo list. * Clearly it `categorises the bug' - that's tautological for a classification. But *why* is the categorisation useful ? You could categorise bugs by the hair colour of the first submitter, which would be an objective classification but not particularly useful :-). * Using severities to keep packages out of testing is using them to keep a certain kind of releaseability information; not releasability into stable, but nevertheless a releaseability. Furthermore, reading between the lines, I get the impression that the release manager doesn't deal with this particular question. If indeed this is what's going on then it's not surprising we have a conflict, because we have a decision whose owner is not clear. When you bring in policy conformance, and RCness, the maintainer may no longer be the one with the best knowledge of the issues. Also, just because a person is the maintainer does not mean they are more knowledeable than the reporter. (I would prefer not to name names here). This is true, of course, but I think that any attempt to fix this by trying to remove subjectivity is doomed. You can't save clueless maintainers' packages by giving them a rulebook to follow, and clueful maintainers will spend all their lives arguing with the rulebook. If a maintainer is not up to scratch then you should appeal their mistakes to the committee, or offer to take over the package, or perhaps even prepare a rival version of the package and allow the committee to decide between them (or carry out some other
Re: Release-critical bugs, and #97671
Manoj Srivastava writes (SuperCite undone): Ian Jackson [EMAIL PROTECTED] writes: But, I can see that you might want to avoid too much discretion being exercised by bug submitters. Discretion is not quote how I would describe bug severity escalation, but yes, bug severities ought to be as objective as we can make them. I don't think this quite follows, as you put it here. I agree that it's unhelpful to rely on submitters' judgement to accurately prioritise bugs, and that a good way to help submitters do a useful thing is to give them objective criteria. But, that doesn't mean that the severities need to remain set by those objective criteria. Someone other than the submitter, with a greater overview of the whole package or distribution, might have a better idea, and might reasonably apply subjective judgement. Indeed, I think the argument you make later leads on to a different conclusion. You say: [The] RM decides on a case by case basis [whether a bug is unreleaseable], and factors in the time left to release, this is the hardest criteria to achieve, and indeed, we should not even try. So, you think that the bug severity should not be used to record the bug's releaseability. The question is then, what other useful information can we use it to record, or are we trying to use it to record, in a way that supports everyone in our work ? My understanding of the main way we treat the BTS is that we use it to store our todo list - both the whole project's, individual maintainers'. For some bugs, namely approximately the ones corresponding to the current definitions of severity levels grave and critical, it is very important to the whole project to get them fixed, because they have bad effects which spread far beyond frequent users of the package. These bugs are high-priority work items for the whole distribution. For most other bugs, the package maintainer, and other people closely involved with the package, are in the best position to decide which bugs are the most serious and which should be worked on first. If, then, we are not to encode in the BTS severities the releaseability of bugs, but instead use them to prioritise work, it seems clear that at least for bugs which are not `critical' or `grave', the package maintainer should have discretion. This discretion can't sensibly be eliminated by specifying the relative (or absolute) priority of bugs in the policy manual and BTS instructions, because those documents can't capture all of the relevant circumstances. Do you follow this argument ? Do you agree with it ? As you can probably tell, I think I'm still feeling my way around this issue. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj Srivastava writes (SuperCite undone): Ian I don't think this quite follows, as you put it here. I agree Ian that it's unhelpful to rely on submitters' judgement to Ian accurately prioritise bugs, and that a good way to help Ian submitters do a useful thing is to give them objective criteria. So far, so good. Ian But, that doesn't mean that the severities need to remain set by Ian those objective criteria. Someone other than the submitter, Ian with a greater overview of the whole package or distribution, Ian might have a better idea, and might reasonably apply subjective Ian judgement. To what end? Why make the objective criteria malleable? When one discards objective criteria for classifying bugs, one merely opens the door for more disruptive disagreements between reporters, and even fellow maintainers. With around a 1000 developers and counting, there is unlikely to be agreement amongst developers. When you bring in policy conformance, and RCness, the maintainer may no longer be the one with the best knowledge of the issues. Also, just because a person is the maintainer does not mean they are more knowledeable than the reporter. (I would prefer not to name names here). Ian So, you think that the bug severity should not be used to record the Ian bug's releaseability. Indeed. Ian The question is then, what other useful information can we use it to Ian record, or are we trying to use it to record, in a way that supports Ian everyone in our work ? It represents impact on the system. It categorizes the bug. It helps people understand potential damage the bug could cause, at a glance. It keeps packages out of testing. Releases occur farly seldom, and whether a certain version of a package is releasable or not is of importance to a small number of people for relatively short intervals of time. I think we should stop overloading the BTS for a TODO list for the project and developers. In this day and age we have better tools both for personal todo lists, and groupware products for the project. If the project thinks it is so important, why do we not set up a wicki? or other such tool? It is easy enough to do so. Ian For some bugs, namely approximately the ones corresponding to Ian the current definitions of severity levels grave and critical, Ian it is very important to the whole project to get them fixed, Ian because they have bad effects which spread far beyond frequent Ian users of the package. These bugs are high-priority work items Ian for the whole distribution. Quite so. And a maintainer should not have the discretion to junk the objective criteria and label them wishlist on a whim, ot because they do not want to work on it, or it is too hard to fix right now. Ian For most other bugs, the package maintainer, and other people Ian closely involved with the package, are in the best position to Ian decide which bugs are the most serious and which should be Ian worked on first. Quite so. And if they do not violate policy must directives, for the most part they can. Ian If, then, we are not to encode in the BTS severities the Ian releaseability of bugs, but instead use them to prioritise work, it Ian seems clear that at least for bugs which are not `critical' or Ian `grave', the package maintainer should have discretion. Why? Apart from using the BTS as a poorly designed groupware TODO list (I say this, even though I designed policy proposals on top of the BTS, and I know the pitfalls of doing so), this does not seem to be useful. Indeed, by making the classification criteria fuzzy, we reduce the utility of the severity, I think. I mean, important is more or less left to the maintainer. normal i catch all. wishlist and serious should still be left objective. I can see things built on top of a new BTS that would benefit from well defined classification of bugs. Ian Do you follow this argument ? Do you agree with it ? As you can Ian probably tell, I think I'm still feeling my way around this issue. I do follow the argument, but I do not agree, I think we should stop overloading the BTS, and use it for the primary purpose _first_, especially if it causes friction between reporters and maintainers about the severities. And it shall, I fear. manoj -- (null cookie; hope that's ok) 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: Release-critical bugs, and #97671
It's not clear to me why tech-ctte discussions seem to not get cc'ed to the appropriate bug number properly. See also the discussion for the pcmcia-cs bug, much of which happened on the list rather than in the bug report. On Sat, Apr 27, 2002 at 01:34:26AM +0100, Ian Jackson wrote: But, the idea in the policy manual is that a `must' is a rule for which there are not expected to be exceptions; it doesn't touch on how damaging a breach of the rule is. Uh, this is completely incorrect. See policy section 1.1, Scope. In this manual, the words _must_, _should_ and _may_, and the adjectives _required_, _recommended_ and _optional_, are used to distinguish the significance of the various guidelines in this policy document. Packages that do not conform to the guidelines denoted by _must_ (or _required_) will generally not be considered acceptable for the Debian distribution. Non-conformance with guidelines denoted by _should_ (or _recommended_) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. Guidelines denoted by _may_ (or _optional_) are truly optional and adherence is left to the maintainer's discretion. The number of times this gets misinterpreted is an obvious indication that it was a mistake to do things via policy in this way, but it's nevertheless the way it is for now. Part of the dispute seems to stem from this discrepancy. The bug in question is agreed by everyone to be a violation of a `must' in policy, but not to make the package unsuitable for release. I'm sorry I don't have a catchy way of phrasing this, but it *is* a bug that makes the package unsuitable for release, it just so happens that it's going to get released as is now anyway. serious is a severe violation of Debian policy or any other problem, which makes the package unsuitable for release. Absolutely unconditionally _no_. This leaves the definition of serious a matter of judgement on behalf of the submitter which makes managing the release an order of magnitude more difficult. 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 pgphKWSRkT5jn.pgp Description: PGP signature
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Looking at the situation, I think that the definition of `serious' bug Ian report is rather unhelpful and does not match up with the use of Ian `must' or `required' in policy. Incidentally, I think the serious severity was invented as a way of describing policy violations; which make the above statement, umm, not the correct inference. manoj -- Humans are communications junkies. We just can't get enough. Alan Kay 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: Release-critical bugs, and #97671
Anthony Towns writes (Re: Release-critical bugs, and #97671): On Sat, Apr 27, 2002 at 01:34:26AM +0100, Ian Jackson wrote: But, the idea in the policy manual is that a `must' is a rule for which there are not expected to be exceptions; it doesn't touch on how damaging a breach of the rule is. Uh, this is completely incorrect. See policy section 1.1, Scope. You're right. My apologies for assuming I knew what it would say without reading it. Manoj Srivastava [EMAIL PROTECTED] writes: ] The core error is that bug severities should not be rigidly ] connected to release criticalness. *THAT* is the place where we need ] to make case by case, subjective decisions Let me just see if I can get some common ground here. Does everybody agree that it's not possible for the policy manual to correctly specify in advance whether a particular policy violation will actually mean that a package should definitely not be released ? (I'm going to call this whether the bug is `releaseable' or not, to avoid getting tangled in an argument over the definition of `release critical.) In this case then there are several pieces of different information which we might record in the BTS severity field: (a) The package maintainer's idea of how urgent/important the bug is (b) The release manager's idea of whether the bug is releaseable (c) Something specified by the policy manual Now there is a relationship between (a) and (b): since the release manager decides whether a bug is releaseable, and the package maintainer should really be trying to deal with the unreleaseable bugs first in order to get the package into the distribution, you can encode both (a) and (b) in an appropriate set of severity levels: divide the severity levels firstly into unreleaseable and releaseable, and then have a number of levels of each. That leaves us with (c) as the other option. I admit that I don't understand the reasoning behind this at all. Surely since the policy manual speaks in terms of generalities, anything it says about classes of bugs is by and large going to need interpretation/discretion anyway. I don't see the value of recording a purely mechanical class in the BTS. Now, that's not to say that the policy manual can't have something to say about what's likely to be a releaseable bug - thus leading one to consult the policy manual when assigning severities in the (a)/(b) model - but it clearly can't have the last word. (It seems to me that the `must's in the policy manual ought to be interpreted this way.) AJ also wrote: I'm sorry I don't have a catchy way of phrasing this, but it *is* a bug that makes the package unsuitable for release, it just so happens that it's going to get released as is now anyway. I hope you won't mind me saying so, but this sounds confused to me. Surely if the bug makes the package unsuitable for release, that *means* that we ought not to release it ? Conversely, if we decide that the package is better off released even with this bug, it means that we've decided that the bug is releaseable, given all the circumstances ? A bug's releaseability can of course change depending on lots of external factors. serious is a severe violation of Debian policy or any other problem, which makes the package unsuitable for release. Absolutely unconditionally _no_. This leaves the definition of serious a matter of judgement on behalf of the submitter which makes managing the release an order of magnitude more difficult. Well, the current wording sort of does that too: serious is a severe violation of Debian policy (that is, it violates a must or required directive), or, in the package maintainer's opinion, makes the package unsuitable for release. But, I can see that you might want to avoid too much discretion being exercised by bug submitters. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Looking at the situation, I think that the definition of Ian `serious' bug report is rather unhelpful and does not match up Ian with the use of `must' or `required' in policy. What makes you say that? Serious is defined as a violation of a must or required directive of policy; I fail to see how this could not match up with the use of `must' or `required' in policy; they are identical ways of saying the same thing. Ian The idea in the BTS seems to be that a serious bug is one which Ian makes a package unsuitable for release. This is where the disconnect is. The release manager decides what is or is not fit for release. The general guideline is that a violation of a must directive in policy is likely to be cause for the release manager to reject the package. The final decision lies with the release manager. Ian How about if we change the wording in `Severity levels' in the BTS Ian documentation (http://www.debian.org/Bugs/Developer#severities). Ian Currently it says: Ian serious Ian is a severe violation of Debian policy (that is, it violates a Ian must or required directive), or, in the package Ian maintainer's opinion, makes the package unsuitable for Ian release. Ian How about: Ian serious Ian is a severe violation of Debian policy or any other problem, Ian which makes the package unsuitable for release. This is bogus. You have changed a stright forward, objective criteria for a serious bug, softening it to where it has no meaning. The output of your program makes my nose twitch, this is obviously a problem, and this bug is thus critical. Ian This definition makes `serious' correspond identically to the Ian package's suitability for release. It avoids defining `severe' Ian violation of policy as a violation of a `must'; that seems to me to be Ian the core error. This change would avoid violations of exceptionless Ian policies (which are of course always bugs) always being treated as Ian release critical even if they're unimportant. No, the core error is that you are taking away from the release manager the task and responsibility of determining release criteria. Did you ignore everything that I and aj wrote? Would you please catch up instead of jumping in late, and ignoring the advances and arguments already made? The core error is that bug severities should not be rigidly connected to release criticalness. *THAT* is the place where we need to make case by case, subjective decisions Ian If you and Anthony agree then maybe we should see if we can get that Ian changed. If you disagree I'm sure you'll let us know :-). I strongly object to turning the criteria upside down and creating a situation where bug severities are even more subjective. This is a far worse situation than we find ourselves in now. manoj -- A lady with one of her ears applied To an open keyhole heard, inside, Two female gossips in converse free -- The subject engaging them was she. I think, said one, and my husband thinks That she's a prying, inquisitive minx! As soon as no more of it she could hear The lady, indignant, removed her ear. I will not stay, she said with a pout, To hear my character lied about! Gopete Sherany 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]
