Re: Conflicts between developers and policy
The text under discussion, as written by Philip Hands and Buddha Buck, and posted in total by Manoj Srivastava is: ___ Policy should be followed, except where a discussion about the clause in question is still ongoing, in which case the maintainer may indulge in a policy violation if they feel it is a technically superior approach. When policy is being violated in this manner, this fact should/must be documented in the bug tracking system, on the appropriate Debian mailing lists, and in the changelog of the package violating policy, including information on what policy is being violated, and why. Any permanantly accepted policy violations (such as the dynamic library managing programs being shipped statically linked) should/must be documented in the policy manual, including an explanation of why the policy exception was granted. __ Concerning the first paragraph, Raul Miller commented: Manoj Srivastava [EMAIL PROTECTED] wrote: Policy should be followed, except where a discussion about the clause in question is still ongoing, in which case the maintainer may indulge in a policy violation if they feel it is a technically superior approach. Hmm.. this is actually an important and interesting concept. In effect, you've elevated a technically superior approach to policy status, and delegated all of policy to a mere plan for achieving that. What you've left out is what the technically superior concept approaches. Could you perhaps suggest what it is that could be used to distinguish between worthwhile and non-worthwhile forms for technical genius? Your objection is to the use of the admittedly subjective criteria if they feel it is a technically superior approach. Would the (slightly) more objective criteria if they feel that strict adherence to the policy would jeopardize system integrity or weaken package usability.? I don't know if that quite captures what we want, but it is an idea. Also, when I said should/must, I meant one or the other, but I wasn't sure which would be appropriate. Upon reflection, I think they should be musts. -- Buddha Buck [EMAIL PROTECTED] Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects. -- A.L.A. v. U.S. Dept. of Justice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Buddha Buck [EMAIL PROTECTED] wrote: Your objection is to the use of the admittedly subjective criteria if they feel it is a technically superior approach. Would the (slightly) more objective criteria if they feel that strict adherence to the policy would jeopardize system integrity or weaken package usability.? This is better, but I feel as if it's still lacking something. Remember that (a) we are preparing packages for a wide variety of systems, (b) we've claimed that what we build now we'll support upgrading from in the future, (c) we're also concerned with the matter of boot strapping onto systems which previously didn't have debian (boot disks, ...), (d) we're trying to provide some level of interoperability with non-debian systems (that's why we talk about fhs), (e) we're at least considering different kinds of installation mechanisms (among other things, for the people who want to put together several hundred copies of the same installation). Plus we're talking about putting together administrative tools, to make life simpler for the end user who might be frustrated at the way one conceptual activity requires studying some wide variety of package documentation (most of which may be irrelevant to that user). The point is: we've got a wide variety of goals; debian-policy is a fleshed-out statement of those goals. What you're essentially saying is that the expression of the goals must be pursued or debated, but even though you're prescribing when and how the debate should occur I doubt that a new maintainer is really going to comprehend what we mean by system integrity and package usability unless it's fleshed out a bit. If we're going to adopt this concept of policy must be followed or debated I think we need a debian-meta-policy which documents for newcomers what we think we're trying to do so that they can make reasonable choices about which is appropriate, and when. -- Raul, struggling to avoid long discussion of use-cases and failure modes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul The point is: we've got a wide variety of goals; debian-policy Raul is a fleshed-out statement of those goals. I think you are taking policy where it should not go. The Social contract, the DFSG, and the ilk are a statement of our goals, the constitution represents the rights and duties of the entities in the project, and the Policy documents list the dos and don't of designing and implementing debian packages. This is the first I have heard of our Policy documents being goals, and I disagree. manoj -- Miniscribe's troubles are daunting. The company has floundered in its attempt to settle 13 shareholder lawsuits, filed after a panel found that previous managers circumvented financial controls and resorted to shipping bricks and unfinished drives to shore up sagging revenue figures. Miniscribe Prognosis Is Hopeful, E. E. Times, Jan 15, 1990, pg 67 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: This is the first I have heard of our Policy documents being goals, and I disagree. Policy, by its very nature, lies somewhere between goals and procedures. While the DFSG and Social contract are very good, they don't say a lot about the technical aspects of what we're trying to achive. Neither does the constitution, for that matter. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
'From Bill Leach [EMAIL PROTECTED]' Manoj; The 'Social Contract' and the 'DFSG' are indeed goal statements. However, they are goal statements of a very imprecise nature. They are not 'working documents' they are rather more like 'lofty ideals'. Ideals that don't necessarily mean precisely the same things to different people EVEN when different people 'enthusiastically pledge their support' and make claims as to how these documents 'spell out' common goals. The various 'technical guidlines' indeed ARE the 'working documents' of the Debian goals. They deal with goal issues that are both explicit and IMPLICIT in the Debian project. I feel that this whole discussion has been fraught with 'missunderstanding'. My personal view of your position for example is that while you have at times made statements that 'sounded to me to be very autocratic' (and I am sure from some of the responses that you have received that they sounded that way to others as well); and yet overall the impression that I have is that you do NOT view the 'guidelines' as an 'inflexible straightjacket' upon developers. I further believe that the basis for your statements is two fold: 1) Never publicly 'belittle' the developer governing documents. [Probably because to do so would tend to give the impression that ignoring the conflicts and problems that such documents have and do attempt to address would ultimately be a disaster for the project] 2) 'Regulations' in the governing documents ARE NOT absolutes and just as is true for any other aspect of the project, they are subject to revision and (hopefully), improvement. a. It is highly unlikely that ANY one developer will know ALL of the reasons why a particular decision was made. b. It is even less likely that a single developer will know all of the potential impacts that would be caused by a change. c. Only by first rigorously attempting to comply with 'guidlelines', including seeking opinions of other developers and then still finding that existing policy is an impossible or at least unreasonable restriction will any meaningful improvement to the regulating documents occur. Thus, there is a hugh difference between a developer 'violating' policy AND filing a bug against the policy and one that quietly 'just does their own thing'. I personally would suggest that a developer be allowed to 'violate' policy after attempting to follow policy has failed but then be expected to be cooperative in 'hammering out' a new policy as well as changing the package (if required) to comply with the final decision. I doubt that it is a real good idea to become too specific and too detailed in policy. An obvious problem of course is in deciding what is 'too' and what is 'not enough'. It is probably almost as important to be sure that every requirement that is imposed is indeed necessary as well as to ensure that what is required is no more than is necessary. Since much of the policy has evolved, the 'reasons behind the reasons' may never have been addressed. Within a project like Debian there are many 'standards' that have to be set ONLY because chaos would ensue otherwise. My Brit friends continually remind me of the classic example. There is essentially nothing sacred about driving on the 'right' side of the road but evenyone on particular road had better agree on the 'standard'. On Sat, May 02, 1998 at 02:31:04PM -0500, Manoj Srivastava wrote: Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul The point is: we've got a wide variety of goals; debian-policy Raul is a fleshed-out statement of those goals. I think you are taking policy where it should not go. The Social contract, the DFSG, and the ilk are a statement of our goals, the constitution represents the rights and duties of the entities in the project, and the Policy documents list the dos and don't of designing and implementing debian packages. This is the first I have heard of our Policy documents being goals, and I disagree. manoj -- best, -bill [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] from a 1996 Micro$loth ad campaign: The less you know about computers the more you want Micro$oft! See! They do get some things right! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Thu, Apr 30, 1998 at 06:36:37PM -0400, Dale Scheetz wrote: On Thu, 30 Apr 1998, Marcus Brinkmann wrote: While I agree with much of what you say about the need for policy to be clear, I will continue to urge caution when being dictatorial about policy. I only disagree with Manoj's characterization of my position. I have never said Ignore policy if it suits you. What I have called for is a reasoned application of The Policy Statement, which represents the current set of written policies. When I wrote I agree with Manoj, I meant his technical position, not the way he interpreted the position of you or other people. However, I think you know that already... For example, the stripped binaries rule in the policy statement is fine with me. I don't see it as broken the way Manoj has suggested, because we have an unwritten policy against delivering broken packages. I see the unwritten policy as having a higher priority than the stripped binaries policy as written. Dwarf, I really enjoy learning. Reading the Debian list, I learn more than I would learn elsewhere. Reading Stroustrups fantastic book about the C++ programming language, I learn a lot. Reading the policy manual I learn a lot of things about making a distribution. I'm not very experienced (I have two years or so experience with Linux, and one year of it with Debian). I try to do it right, but I'm sure I'm messing up things quite often. I try my best, but if the policy manual says I have to strip binaries, I'll strip them, as it sounds correct. Obviously, I do not maintain a package where this does not work, but I would like to *know* about the exceptions, so that I am aware of them. [snipped] I do not comment on the changelog issue. In general, the policy should be unambigouus (little room for interpretation avoids confusion. This does not mean that there is no flexibility, but the policy should state it where other solutions are okay, too), and exceptions should be recorded. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, James == James Troup [EMAIL PROTECTED] writes: James Manoj Srivastava [EMAIL PROTECTED] writes: Well, it was gfetting frustating, what with being in the middle of two conversations, one with Dale and James, who are of the opinion that policy is a guideline, and not a set of rules adopted by the project James Again, please don't misrepresent my position like this. I made James one rash comment which I later retracted (see previous James message), and I haven't been actively involved in this James ``conversation'' since I posted my retraction on 1998-04-23. True enough. You have really not been as radical as I have made you out to be. However, I think, the point is that it could well be some one else in the future who is not quite as reasonable as you have been. We do need a statement saying that the project has indeed adopted this policy document, and the ``policy'' nomenclature is not a ``mistake''. manoj -- America has been discovered before, but it has always been hushed up. Oscar Wilde Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale While I agree with much of what you say about the need for Dale policy to be clear, I will continue to urge caution when being Dale dictatorial about policy. Dale, I think no one is trying to be dictatorial about policy. Phillip said it best; policy is suppposed to be followed unless it is wrong. If it is wrong, it is appreciated if you correct it. Not everyone has the grasp of the subject as the person pointing out the error of policy, so amending policy is really just being co-operative. Why are you fighting this? Dale For example, the stripped binaries rule in the policy Dale statement is fine with me. I don't see it as broken the way Dale Manoj has suggested, because we have an unwritten policy against Dale delivering broken packages. I see the unwritten policy as having Dale a higher priority than the stripped binaries policy as Dale written. You know that the stripped binary rule has exceptions. I did not. Why not put a statement in the policy describing when the rule does not hold? (Some would say not correcting policy is elitist and hoarding knowledge). Dale While policy only states that the upstream changlog will be Dale named changelog, I see the policy of least surprise as Dale allowing me to include a link for ChangeLog so that those who Dale are expecting that will find it. A strict reading of the Policy Dale Statement might not lead others to this conclusion, but I don't Dale see that as broken. I think then it is definitely unclear, and an ambiguous policy statement is a broken policy statement. manoj -- ...It is sad to find him belaboring the science community for its united opposition to ignorant creationists who want teachers and textbooks to give equal time to crank arguments that have advanced not a step beyond the flyblown rhetoric of Bishop Wilberforce and William Jennings Bryan. Martin Gardner, Irving Kristol and the Facts of Life, The Skeptical Inquirer, Vol. XII No. 2, ppg. 128-131 Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Conflicts between developers and policy
I have generally found that policy is actually decided by discussion on the policy lists, and I do not agree with your characterization that the multi-maintianer issue had obviously not reached a consensus. There were objections, but (apart from you, who were silent) the objectors did seem to be coming around to having on maintainers address on the package. Moreever, in absence of a technical committee to help resolve issues, fiat by a balanced policy manager was the best we could do. I am, personally, appalled at the attacks on the Policy manager. For the most part, in my opinion, he has been doing a good job I quite agree. He seems to be a reasonable fellow. Ian to the status of law. This is clearly inconsistent, No ot os not. Policy can be influenced by anyone joining the policy group, which is open to everyone. The technical committee is a cabal which the unwashed masses have little say in selecting. Maybe I am being naive, but I thought policy constitutes at the very least a set of handy guidelines for a Debian developer. Of course, for a package to be (and remain) successful it needs to be maintained properly, but to be considered for inclusion it doesn't seem unreasonable to ask a package maintainer to follow these guidelines, if only for sake of consistency - especially when those guidelines have been evolved from reasonable debate (and are open to change, by the same method). Presently, policy -is- open to change, because there is this list. Now there's talk of a 'constitution' and a 'technical committee' whose status and function is to me rather unclear. While the policy list is maybe not really the appropriate list to discuss a constitution nor to discuss the functioning of 'governing bodies', one would expect at least a separate list to discuss matters of change in the way internal matters are handled. For lack of a better place, I would say the policy list would be the place to discuss these, because, in a sense, this definitely influences any guidelines handed to Debian developers. At the very least, they would have to be non-contradictory! I do not, at present, have time to subscribe to the developer's list, but I am still interested in the way Debian handles things on a more global level. That's why I read the policy list. I would therefore request to either create a new list, meant for matters related to how Debian is being run, like a 'constitution' or a 'technical committee' or to move discussion of meta-matters to the policy list, as this is not really a -technical- issue and it is my understanding that the -devel list is a technical list. But correct me if I am wrong. I find having a constitution sprung on me out of the blue, as well as the forming of a technical committee whose authority is unclear rather unsettling and contrary to the open way things have been handled so far - rather un-Debian, so to speak. Ronald -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: We do need a statement saying that the project has indeed adopted this policy document, and the ``policy'' nomenclature is not a ``mistake''. We have one -- Ian made it. You've been objecting to it. [Actually, we have many such statements, go look at the web site. Or do we need something in the constitution before you'll accept the web site?] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Ronald van Loon [EMAIL PROTECTED] wrote: I find having a constitution sprung on me out of the blue, as well as the forming of a technical committee whose authority is unclear rather unsettling and contrary to the open way things have been handled so far - rather un-Debian, so to speak. For what it's worth, these are the same issue, since that committee is described in the constitution. More generally, as we've gotten more organized, and acquired more documentation, we've had a problem where people haven't been able to keep up on reading all that documentation. And, yes, that's a rather unsettling issue. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On 1 May 1998, Manoj Srivastava wrote: Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale While I agree with much of what you say about the need for Dale policy to be clear, I will continue to urge caution when being Dale dictatorial about policy. Dale, I think no one is trying to be dictatorial about policy. When you say the policy MUST be followed to the letter, I can view that as nothing less than a dictatorial attitude. Phillip said it best; policy is suppposed to be followed unless it is wrong. If it is wrong, it is appreciated if you correct it. I am a maintainer who chooses not to spend my time in the policy group, but prefers to spend what little time I have working on my package responsibilities. One of the things that has bothered me about your position on this matter, is that you seem to think that maintainers who don't get involved in the policy discussion are shurking their duties, while I don't. Not everyone has the grasp of the subject as the person pointing out the error of policy, so amending policy is really just being co-operative. I thought that was what the policy group was there for. I have alwasy assumed that this kind of work was their responsibility. As a developer, I use the policy statements to help me decide on particular issues of packaging. How is it that I am now the responsible party for fixing a policy that I don't see as broken? Why are you fighting this? The only thing I am fighting is the oppressive attitude that you have been expressing about the Policy Statement. Dale For example, the stripped binaries rule in the policy Dale statement is fine with me. I don't see it as broken the way Dale Manoj has suggested, because we have an unwritten policy against Dale delivering broken packages. I see the unwritten policy as having Dale a higher priority than the stripped binaries policy as Dale written. You know that the stripped binary rule has exceptions. I did not. So, why am I responsible for your ignorance? Why not put a statement in the policy describing when the rule does not hold? (Some would say not correcting policy is elitist and hoarding knowledge). I have no problem with the policy statement containing such statements. In fact I have argued on several occasions that policy needs to always have and explanation for its existance, and a priority level for dealing with conflicting policy statements. My only problem is when you make it my responsibility to correct the policy statement. Dale While policy only states that the upstream changlog will be Dale named changelog, I see the policy of least surprise as Dale allowing me to include a link for ChangeLog so that those who Dale are expecting that will find it. A strict reading of the Policy Dale Statement might not lead others to this conclusion, but I don't Dale see that as broken. I think then it is definitely unclear, and an ambiguous policy statement is a broken policy statement. Then fix it, if you think it is broken, and stop chastizing me because we currently live with a less than perfect Policy Statement. From my point of view, I follow policy when I deliver a working unstripped binary instead of a broken stripped one. I also think that I have followed policy when I add a link that provides ChangeLog for those expecting it. If you don't think so, then fix it to your satisfaction. I will not object. Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, I think we are getting nowhere fast. Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale On 1 May 1998, Manoj Srivastava wrote: Dale, I think no one is trying to be dictatorial about policy. Dale When you say the policy MUST be followed to the letter, I can Dale view that as nothing less than a dictatorial attitude. Both Phillip and Budha have proposed riders to that bare statement. I think you are just trying to be confrontational here. Dale I am a maintainer who chooses not to spend my time in the policy Dale group, but prefers to spend what little time I have working on Dale my package responsibilities. One of the things that has bothered Dale me about your position on this matter, is that you seem to think Dale that maintainers who don't get involved in the policy discussion Dale are shurking their duties, while I don't. You do not have to be subscribed t policy to amend it. Just send mail to the policy group, and ask you be CC'ed to replies. We are genrally nce people who CC with a passion. BTW, I do think maintainers who ignore policy for their own packages but can't send a email message explaining the reason to the policy list *are* shurking their duties. There are times when real world matters intrude, and people have to temporarily withdraw from the project (I left for a few months in the fall of '96, and took back kernek-package when I felt I had time to fulfull my duties as a maintainer). Not everyone has the grasp of the subject as the person pointing out the error of policy, so amending policy is really just being co-operative. Dale I thought that was what the policy group was there for. I have Dale alwasy assumed that this kind of work was their responsibility. The policy list is mere mortals too. If you find a flaw in the policy (a flaw is having to ignore policy for your package since ``obviously'' your package is an exception, or a flaw in policy is when following policy shall break packages) you send a email to the policy list. If you are too busy to send email, I submit you are too busy to be a maintainer at the moment, and you should seek co-maintainers to lighten your load. Dale As a developer, I use the policy statements to help me decide on Dale particular issues of packaging. How is it that I am now the Dale responsible party for fixing a policy that I don't see as Dale broken? If you find that following policy shall break packages, I think you are indeed responsible for pointing this out. (See? I thought such co-operation was obvious, too). Dale So, why am I responsible for your ignorance? Cause, O fount of wisdom, us unworthy developers beseech thee. If you find something that others are ognorant of, especially if you have to flout policy in your packages in order not to break your package, please, please, let the rest of us know. Not all of us are as able as you are. Dale My only problem is when you make it my responsibility to Dale correct the policy statement. You found the flaw. No one else seems to have. If you do not correct it, who will? (Frankly, I am dissapointed by this argument). I think then it is definitely unclear, and an ambiguous policy statement is a broken policy statement. Dale Then fix it, if you think it is broken, and stop chastizing me But you are the one who knows what is broken and what is the right thing to do, since you have done The Right Thing for your packages. Dale because we currently live with a less than perfect Policy Dale Statement. From my point of view, I follow policy when I deliver Dale a working unstripped binary instead of a broken stripped one. No, you ignore a broekn policy directive to strip a binary. And despite knowing policy is flawed, you do not wish to share your expertise and allow others to benefit from your wisdom. What are you gunning for, a promotion? manoj -- The lion and the calf shall lie down together, but the calf won't get much sleep. -- Woody Allen Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Raul == Raul Miller [EMAIL PROTECTED] writes: Raul Manoj Srivastava [EMAIL PROTECTED] wrote: We do need a statement saying that the project has indeed adopted this policy document, and the ``policy'' nomenclature is not a ``mistake''. Raul We have one -- Ian made it. You've been objecting to it. A statement of opinion from a developer (note that Ian did not speak as a leader fiat) has no more value that another developer that says it is not so. I say it is not so. So there. Raul [Actually, we have many such statements, go look at the web Raul site. Or do we need something in the constitution before you'll Raul accept the web site?] Correct. Ian said that policy can not state that policy should be followed, since the constitution does not say that. There fore we can not follow the web site either. How come you did not object to Ian's statement that policy can not say that policy should be followed unless so authorized by the constitution? Is it just me you argue with? manoj -- We will be better and braver if we engage and inquire than if we indulge in the idle fancy that we already know -- or that it is of no use seeking to know what we do not know. Plato Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, This, I like. __ Policy should be followed, except where a discussion about the clause in question is still ongoing, in which case the maintainer may indulge in a policy violation if they feel it is a technically superior approach. When policy is being violated in this manner, this fact should/must be documented in the bug tracking system, on the appropriate Debian mailing lists, and in the changelog of the package violating policy, including information on what policy is being violated, and why. Any permanantly accepted policy violations (such as the dynamic library managing programs being shipped statically linked) should/must be documented in the policy manual, including an explanation of why the policy exception was granted. __ manoj -- Perfection is achieved only on the point of collapse. Parkinson Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Policy should be followed, except where a discussion about the clause in question is still ongoing, in which case the maintainer may indulge in a policy violation if they feel it is a technically superior approach. Hmm.. this is actually an important and interesting concept. In effect, you've elevated a technically superior approach to policy status, and delegated all of policy to a mere plan for achieving that. What you've left out is what the technically superior concept approaches. Could you perhaps suggest what it is that could be used to distinguish between worthwhile and non-worthwhile forms for technical genius? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Again, this happens not to be the case. I was perfectly happy letting policy be policy until a well respected senior Debian developer made statements to the effect Go right ahead and violate policy. Thats what I do And another respected developer chimed in with how their pacvkage would break if they followed policy, and so they have been happily ignoring it. Where the hell were you then with this stuff about policy being ``generally accepted'' and all? huh? Indeed, I'd forgotten about that. And you're right, in those cases we did need to fix something. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj, Was my previous mail really that annoying ? If so, I apologise profusely (I was fairly tired at the time I wrote it, so may have started to be rather more argumentative that I meant to be) I think we actually hold fairly similar opinions about this subject. Did you ever see my previous attempt to calm this discussion down a bit ? No one said policy is all encompassing. It does not have any loopholes. Errors of omission shall always exist. Not errors of commision. I thought you had by implication. I was clearly wrong, sorry. That's probably what gave rise to my extreme characterisation of your arguments. Philip In either case, having a policy statement that claims to be Philip the final authority will gain us nothing, and could be Philip actually harmful. I disagree. It would have stopped at least one person, namely, me. Fair enough, lets put it in then ;-) Anyway, I think you've started being just a little argumentative now, since I don't believe that you, or anyone else for that matter, wants to violate policy in a destructive way. You seemed (to my tired eyes) to be accusing people of objecting to: Policy should be followed, except where a discussion about the clause in question is still ongoing, in which case the maintainer may indulge in a policy violation if they feel it is a technically superior approach. James Troup, Dale Scheetz, or anyone else have a problem with this ? My only objection was that there was no need to include a clause like that in policy, because it is self evident. This discussion has conclusively proved me wrong about that, so lets put such a clause in policy. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Philip == Philip Hands [EMAIL PROTECTED] writes: Philip Manoj, Was my previous mail really that annoying ? If so, I Philip apologise profusely (I was fairly tired at the time I wrote Philip it, so may have started to be rather more argumentative that I Philip meant to be) Well, it was gfetting frustating, what with being in the middle of two conversations, one with Dale and James, who are of the opinion that policy is a guideline, and not a set of rules adopted by the project, and you and raul, who are of the opinion that no one needs defend policy or say that it should be folllowed, since that is self evident. I may have over reacted to being the lone voice crying in the wilderness bit. Philip I think we actually hold fairly similar opinions about this Philip subject. Did you ever see my previous attempt to calm this Philip discussion down a bit ? I think we all hold views that are pretty close to each others. The de'il is in the details ... Philip Anyway, I think you've started being just a little Philip argumentative now, since I don't believe that you, or anyone Philip else for that matter, wants to violate policy in a destructive Philip way. well, not really. Philip You seemed (to my tired eyes) to be accusing people of Philip objecting to: Philip Policy should be followed, except where a discussion about the Philip clause in question is still ongoing, in which case the Philip maintainer may indulge in a policy violation if they feel it Philip is a technically superior approach. I think this would indeed satisfy all of us. This statement put policy as something we all collectively have agreed to follow, and yet rtecognizes that at time policy may be in error, and allows people leeway to correct policy, and allow it to evolve and converge to correct behaviour. manoj -- Once I was a tadpole, in the beginning of the begin; Then I was a toadfrog with my tail tucked in. Then I was a monkey in a banyan tree; Now I'm a professor with a Ph.D. --Anonymous creationist's view of evolution Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] writes: Well, it was gfetting frustating, what with being in the middle of two conversations, one with Dale and James, who are of the opinion that policy is a guideline, and not a set of rules adopted by the project Again, please don't misrepresent my position like this. I made one rash comment which I later retracted (see previous message), and I haven't been actively involved in this ``conversation'' since I posted my retraction on 1998-04-23. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Thu, Apr 30, 1998 at 04:06:44AM -0500, Manoj Srivastava wrote: Hi, Philip == Philip Hands [EMAIL PROTECTED] writes: I may have over reacted to being the lone voice crying in the wilderness bit. I prefer to keep away from such discussions until the air cleaned up a bit, but for the sake of the people who count votes here are my 0.02$: I think the policy should be strictly followed. Exceptions to and errors in the policy should be reported as a bug and properly included/fixed. The policy should include a rationale where the reason is not obvious. It should make clear what parts are required (must) and which are common practice (should). I prefer a must over a should. People should not be angry when policy is wrong for them, but they should happily work on the policy. The policy is not something that is forced on the developers by some higher person, but something the developers force on *themselves*. You can only experience real freedom if you feel the border. In short, I agree with Manoj. Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Thu, 30 Apr 1998, Marcus Brinkmann wrote: On Thu, Apr 30, 1998 at 04:06:44AM -0500, Manoj Srivastava wrote: Hi, Philip == Philip Hands [EMAIL PROTECTED] writes: I may have over reacted to being the lone voice crying in the wilderness bit. I prefer to keep away from such discussions until the air cleaned up a bit, but for the sake of the people who count votes here are my 0.02$: I think the policy should be strictly followed. Exceptions to and errors in the policy should be reported as a bug and properly included/fixed. The policy should include a rationale where the reason is not obvious. It should make clear what parts are required (must) and which are common practice (should). I prefer a must over a should. People should not be angry when policy is wrong for them, but they should happily work on the policy. The policy is not something that is forced on the developers by some higher person, but something the developers force on *themselves*. You can only experience real freedom if you feel the border. In short, I agree with Manoj. While I agree with much of what you say about the need for policy to be clear, I will continue to urge caution when being dictatorial about policy. I only disagree with Manoj's characterization of my position. I have never said Ignore policy if it suits you. What I have called for is a reasoned application of The Policy Statement, which represents the current set of written policies. For example, the stripped binaries rule in the policy statement is fine with me. I don't see it as broken the way Manoj has suggested, because we have an unwritten policy against delivering broken packages. I see the unwritten policy as having a higher priority than the stripped binaries policy as written. While policy only states that the upstream changlog will be named changelog, I see the policy of least surprise as allowing me to include a link for ChangeLog so that those who are expecting that will find it. A strict reading of the Policy Statement might not lead others to this conclusion, but I don't see that as broken. I am willing to let those more interested in the location of comas etc. Luck, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul Manoj Srivastava [EMAIL PROTECTED] wrote: Why should you make your package conform? Raul Because it's the right thing to do. If we all did the right thing we would not need a policy or a constitution, would we now? This is a weak argument. Since the policy document have no more standing than, say, The flight of the Bumble Bee, all this means is that the tech committee pointed to a set of rules somewhere, entirely at theur whim, and said YOU! MORTAL! Follow THAT! Raul Since when is The flight of the Bumble Bee the right thing to Raul do? Since I decided on it. What is to prevent me? Raul I think now you're objecting to Ian's recursive explanation of Raul what policy is. For a better explanation, consult a good Raul dictionary. According to him, policy is a set of technical specifications and procedures that the developers are expected to use. The Constituition does not say so, nor the policy itself, all we have so far is one persons expectations (note: he did not speak as a project leader then). Please point the clause to me that I should use the help of a a dictionary to elucidate for my feeble intellect. That has been my point. If the Policy documents have no standing, especially in the defining document that awards authority, then the technical committee can bring in any reference they choose fit, not just the policy documents. (Like the MS OS manuals ;-) Raul You mean like their entire background of technical expertise? Raul Oh, the horror! What technical expertise? The Chinese emperors also extolled the virtues of the selection process for the mandarins, until it fell into rapid decay. I would rather have a set of standards to lean on, and point to, rather than depend on the supposed technical excellence of a body that does not yet exist, and whose composition one can not control. Raul People who aren't competent to distinguish between worthwhile Raul references and garbage aren't going to be good tech committee Raul members just because you've reclassified policy as some kind of Raul law. But at least they can do less damage through their incompetence because we shall always have policy. Also, the policy is likely to be more open and more stable (it is less likely to be affected by cabalistic tendencies than the tech committee. This is too much power in the hands of too few. Especially since the developers have no say in who constitutes the board. How answerable are they to the rest of the developers anyway? Raul I missed this one myself, when I was reading over the draft Raul constitution: Raul If the Technical Committee and the Project Leader agree they may Raul remove or replace an existing member of the Technical Committee. Cabal. Cronyism. Raul Of course, the developers can provide override decisions for Raul both the tech committee and for the leader... Does that mean the developers can stop the appointmen tech committee members? Cool. What about delegates and so on? Raul But the real thing that will keep us honest is the outside Raul world. When does the outside world decice on internal policy matters? When did the outside world ever make anyone conform to the www policy? I would rather be able to point to the policy documents as a kind of limit to the powers of the technical committee. And have the developers have some say in the shaping of the policy documents. Raul Huh? Are we even talking about the same document here? What do you mean? I have initiated discussions that led to modification of policy documents, yes. Raul What are you thinking? I want a simple statement that says: Policy is to be followed, with certain riders. manoj -- When you stay on the tracks, ignoring the facts, you can't blame the wreck on the train. from the song, You Can't Blame . . Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Please point the clause to me that I should use the help of a a dictionary to elucidate for my feeble intellect. Policy: 1. a plan of action; way of management; It is a poor policy to promise more than you can do. The tight-money policy was also reducing the pressure on prices (Time). 2. practical wisdom; prudence: In this ... he was actuated by policy rather than sentiment (Edward A. Freeman). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Raul Since when is The flight of the Bumble Bee the right thing to Raul do? Since I decided on it. What is to prevent me? This epitomises the point you insist on missing here. What prevents you, is YOU. If it turns out that you are a painful git who just wants to throw a spanner in the works, then there would very soon be a consensus to expel you from the project, otherwise you will do the right thing, because it is the right thing, no coercion required (or available as it happens). I want a simple statement that says: Policy is to be followed, with certain riders. [Oxford English Dictionary] policy[1]: noun. prudent conduct, sagacity; course or general plan of action (to be) adopted by government, party, person etc. In other words, the fact that we are calling this a ``Policy'' rather than a ``Hovercraft'' implies that it would be prudent for the party in question (i.e. Debian developers) to use this document as a plan of action. Therefore any statement to that effect within the policy, would be redundant. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Philip == Philip Hands [EMAIL PROTECTED] writes: Philip [Oxford English Dictionary] policy[1]: noun. prudent conduct, Philip sagacity; course or general plan of action (to be) adopted by Philip government, party, person etc. Raul Miller [EMAIL PROTECTED] also quoted things similar. So, we have officially accepted and ratified the Policy documents, I take it, and I just missed the party? If the project has indeed ``adopted'' the Policy documents, I have nothing further to say. I just wish you guys had brought this up when people were fighting the Policy tooth and nail. If we have not adopted policy, then quoting the lexicon is a meaningless play on words; and even though they be named policy, they are evidently not. Which is it? (can't have it both ways, folks). manoj -- Wear me as a seal upon your heart, as a seal upon your arm; for love is strong as death, passion cruel as the grave; it blazes up like blazing fire, fiercer than any flame. [Song of Solomon 8:6 (NEB)] Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Philip [Oxford English Dictionary] policy[1]: noun. prudent conduct, Philip sagacity; course or general plan of action (to be) adopted by Philip government, party, person etc. Raul Miller [EMAIL PROTECTED] also quoted things similar. So, we have officially accepted and ratified the Policy documents, I take it, and I just missed the party? If the project has indeed ``adopted'' the Policy documents, I have nothing further to say. I just wish you guys had brought this up when people were fighting the Policy tooth and nail. If we have not adopted policy, then quoting the lexicon is a meaningless play on words; and even though they be named policy, they are evidently not. Which is it? (can't have it both ways, folks). Are you suggesting that we should interpret the meaning of the policy differently depending upon whether it has been adopted by the project ? If that is the case, we can never adopt it, since the act of adoption would (according to you) change it's meaning, and therefore it would no longer be the document we decided to adopt. I would say that it is self evident that a policy document should accurately reflect one's intent, and that people should generally abide by it. I would also say that there is no need to adopt it in any formal way, since the constructive thing to do is to follow it where appropriate, and fix it otherwise --- what other use would we have for a policy document ? Regardless of any adoption of policy, I will still reserve the right to apply my judgement to the way I construct packages, and I would hope you would too. Are you suggesting that you would do something destructive if it were allowed by policy ? Do we really have to close all loopholes, or can we rely on one another to be reasonable and constructive, without needing a watertight policy with which to cudgel one another ? People that are going to be destructive: a) wouldn't join Debian in the first place, b) wouldn't care about policy even if it were ratified, and c) could just be expelled from the project if they don't mend their ways so why start writing rules with a sub-text of ``you developers are a bunch of untrustworthy skumbags'', when we can rely on one another to be reasonable instead ? If you treat people like children, they will tend to act like them. Let's decide to be adult about this instead. Cheers, Phil. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Someone (I don't have the list archive handy here so I can't remember who) said on the firewalls list recently that security policy (but I think it also is valid for debian policy) should be regarded as a cache of good, well thought out decisions. Policy represents the collective wisdom of a lot of smart people who have thought out some of the downstream consequences of doing particular things and found that some ways of doing things are better than others. Thus developers should follow policy for their own sakes, because it is likely to work out better for them in the long run. If a developer comes across a case where the policy is incorrect (leads to consequences which are a Bad Thing) then they should not just ignore the policy but try to explain their particular case and get the overall policy updated for that case - thus ending up with a better policy and saving someone else from having to go through the same process. John Lines -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Philip == Philip Hands [EMAIL PROTECTED] writes: Raul Miller [EMAIL PROTECTED] also quoted things similar. So, we have officially accepted and ratified the Policy documents, I take it, and I just missed the party? If the project has indeed ``adopted'' the Policy documents, I have nothing further to say. I just wish you guys had brought this up when people were fighting the Policy tooth and nail. If we have not adopted policy, then quoting the lexicon is a meaningless play on words; and even though they be named policy, they are evidently not. Which is it? (can't have it both ways, folks). Philip Are you suggesting that we should interpret the meaning of the Philip policy differently depending upon whether it has been adopted Philip by the project ? Well, policy means something which has been adopted by a body. Hace we actually done so? Am I saying we interpret the contents of the policy documents differently? no, but the significance of the policy documents definitely shall change. Philip If that is the case, we can never adopt it, since the act of Philip adoption would (according to you) change it's meaning, and Philip therefore it would no longer be the document we decided to Philip adopt. That is not what I said. I said we cannot in all honesty call something policy unless it has been adopted by the project; so I am objecting to the NAME of the ``policy'' docuents. Unless you aver that indeed, the project has adopted policy. Philip I would also say that there is no need to adopt it in any Philip formal way, since the constructive thing to do is to follow it Philip where appropriate, and fix it otherwise --- what other use Philip would we have for a policy document ? If we all actually agree to this, then that would be tantamount to adopting policy. Philip Regardless of any adoption of policy, I will still reserve the Philip right to apply my judgement to the way I construct packages, Philip and I would hope you would too. Philip Are you suggesting that you would do something destructive if Philip it were allowed by policy ? No, Assuming I knew better. We are supposed to generally treat policy as correct, and as wisdom handed down by technically competent people. There are lots if people who would follow something blindly. Philip Do we really have to close all loopholes, Yes. Philip or can we rely on one another to be reasonable and Philip constructive, without needing a watertight policy with which Philip to cudgel one another ? Philip so why start writing rules with a sub-text of ``you developers Philip are a bunch of untrustworthy skumbags'', when we can rely on Philip one another to be reasonable instead ? Having an ANSI C standard does not mean us C programmers are, and I quote, a bunch of untrustworthy skumbags:, unquote. This line of argument is puerile. Philip If you treat people like children, they will tend to act like Philip them. Let's decide to be adult about this instead. I am glad ISO does not listen to you. manoj -- Time flies like an arrow, fruit flies like a banana. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj suggests on the one hand that there is too little control Ian over the Technical Committee, and then on the other hand that we Ian should elevate policy (which is currently decided on by fiat by Ian one person, in cases where they choose to do so) I have generally found that policy is actually decided by discussion on the policy lists, and I do not agree with your characterization that the multi-maintianer issue had obviously not reached a consensus. There were objections, but (apart from you, who were silent) the objectors did seem to be coming around to having on maintainers address on the package. Moreever, in absence of a technical committee to help resolve issues, fiat by a balanced policy manager was the best we could do. I am, personally, appalled at the attacks on the Policy manager. For the most part, in my opinion, he has been doing a good job. Ian to the status of law. This is clearly inconsistent, No ot os not. Policy can be influenced by anyone joining the policy group, which is open to everyone. The technical committee is a cabal which the unwashed masses have little say in selecting. Ian and anyway, as Raul says, there is plenty of opportunity to Ian override the Technical Committee. That is open to interpretation, is it not? Ian But the key point is this: the proposed constitution is now being Ian discussed on debian-devel and will soon be voted on. Please note that the debian-devel list has always been cc-ed to until you removed it from the headers. Why is this discussion any less valid for the purposes of modifying the constitution? This is aimed not as a proposed amendment, but to raise an issue and test the waters. If anything, I think people should consider this aspect of the constitution. Ian _That_ document is what will define the answer to what power is Ian ultimately held by whom, not any flameage here or anything Ian written into the policy manuals themselves. Labelling a discussion not going in the direction you wish as flameage is sheer demagoguery. If people reading this consider this issue to have any merit, they shall vote accordingly on the constitution. manoj -- My boss just told the quote-of-the-day(TM) after talking to our friendly IBM salesguy who said: You've got be careful about getting locked into open systems. Heh! Why don't I trust these people? :-) Ian Dickinson ([EMAIL PROTECTED]) Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Well, policy means something which has been adopted by a body. Hace we actually done so? Am I saying we interpret the contents of the policy documents differently? no, but the significance of the policy documents definitely shall change. Er... debian-policy is a distillation of debian efforts for quite some time. Until you decided that it was somehow bogus, I would have said it was fairly well accepted as debian policy. [The exceptions would be where people weren't aware of it.] And, near as I can tell, the reason you becaome so combative about debian policy being debian policy was that Ian Jackson made a statement to the effect that it was sufficient for policy to be policy. Frankly, it seems like you either weren't paying attention, or didn't understand. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul Manoj Srivastava [EMAIL PROTECTED] wrote: Well, policy means something which has been adopted by a body. Hace we actually done so? Am I saying we interpret the contents of the policy documents differently? no, but the significance of the policy documents definitely shall change. Raul Er... debian-policy is a distillation of debian efforts for Raul quite some time. Until you decided that it was somehow bogus, *I* decided it was bogus? This is rich. You have evidently ot being paying attention on Debian policy lists at all. Raul I would have said it was fairly well accepted as debian Raul policy. [The exceptions would be where people weren't aware of Raul it.] This happens not to be the case. Raul And, near as I can tell, the reason you becaome so combative Raul about debian policy being debian policy was that Ian Jackson Raul made a statement to the effect that it was sufficient for policy Raul to be policy. Again, this happens not to be the case. I was perfectly happy letting policy be policy until a well respected senior Debian developer made statements to the effect Go right ahead and violate policy. Thats what I do And another respected developer chimed in with how their pacvkage would break if they followed policy, and so they have been happily ignoring it. Where the hell were you then with this stuff about policy being ``generally accepted'' and all? huh? I started this effort to have policy more strongly ratified due to my alarm at Go ahead and violate policy advice, which, by the way, you did not object to. Your reason let us leave things as they are, since we all know and respect policy are demonstrably bogus. Raul Frankly, it seems like you either weren't paying attention, or Raul didn't understand. Selective memory is indeed useful. You, sir, are sadly behind the times here. manoj -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo its use. Galileo Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. I do think this leads to a dilution of technical discipline. And we already have way too many open bug reports; people do not seem to want to fix ``real'' bugs, and ``mere'' policy reports would be seen as fluff. Policy is a kind of statement of our understanding of our ideals or goals. You know very well that people already have a great respect for debian policy -- it's the clearest explanation of what needs to be done. I don't think that we can make policy enforcement stronger except by picking at trivial issues -- we already have a variety of ways where someone can pick up from a maintainer who isn't able to properly deal with a package. Anyways, before you go trying to fix the too many outstanding bug reports problem, don't you think you should do some work on finding out why the situation exists? [This is the first time I've heard that it's because policy isn't enforced strongly enough, so I think that's bogus.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Bob Hilliard [EMAIL PROTECTED] wrote: I think the problem has arisen because 1) the policy documents have not sufficiently delineated the difference between prescriptive (shall, must) provisions and (strong) recommendations (should, must), and 2) because some (many?) developers disagree with some policy provisions and feel that they have had insufficient input in the process of formulating policy. Why do you think that these are the reasons? You might be right, but I'd like to know your reasons before agreeing that these are the primary reasons for bugs not being fixed. Personally, I'd far more likely suspect that people feel they need to better understand policy before tackling their packages. I think lintian is a great tool for dealing with this kind of problem. I think we could do more in that direction (I'd like to see some kind of compatibility checklist for people to use to rate their own packages in areas that are outside the scope of lintian). Or, sometimes there's some policy requirement that's very difficult to meet, so you might put off dealing with the package till you can put enough time into it to address that difficulty. The only real general way to address this is by getting help (for example, a non-maintainer release). Again, I think lintian is a good example of a way to help the maintainer. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Raul Miller [EMAIL PROTECTED] writes: Why do you think that these are the reasons? You might be right, but I'd like to know your reasons before agreeing that these are the primary reasons for bugs not being fixed. There are a nuamber of sub-threads in this thread using the same header. My posting was written before I saw the one that discussed open bugs. The problem that I was referring to was the disagreement between those who felt policy should be a binding document, and those who think policy may be ignored when it is inconvenient. I have no opinion regarding the reason or reasons for the large number of open bugs, and think that they are irrelevant to the subject that was being discussed. Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40LB9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Bob Hilliard [EMAIL PROTECTED] wrote: There are a nuamber of sub-threads in this thread using the same header. My posting was written before I saw the one that discussed open bugs. The problem that I was referring to was the disagreement between those who felt policy should be a binding document, and those who think policy may be ignored when it is inconvenient. Oh. oops. sorry about that. I think the issue you're talking about is related to our general structure: we're a group of volunteers, and we need to work on a best effort basis. Which is to say, if there's some part of the policy that you can't figure out how to comply with without breaking something, do your best and then we'll look at converging with policy. Note that before a package gets put on the archive, the archive maintainer gets a chance to do some basic checking, and may reject it with a specific complaint. So maybe you'd like to think of this as your policy enforcement mechanism. [But the bug reporting system is a part, too, as is the policy creation people, and everything else.] Anyways, when you talk about making policy binding, you really need talk about making practice binding, too. [And current practice is, basically: policy is the most coherent document describing how we do things. Policy doesn't need power, it needs to be correct.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. I do think this leads to a dilution of technical discipline. And we already have way too many open bug reports; people do not seem to want to fix ``real'' bugs, and ``mere'' policy reports would be seen as fluff. Raul Anyways, before you go trying to fix the too many outstanding Raul bug reports problem, don't you think you should do some work on Raul finding out why the situation exists? [This is the first time Raul I've heard that it's because policy isn't enforced strongly Raul enough, so I think that's bogus. As a point of clarification: I dod not say I am going to go about fixing the huge number of bugs problem; I just keep reports on my packages down, sorry, that is all I have time for at the moment. Secondly, I did not suggest that lack of adherence to policy is the reason for too many open reports; you did. I too find that statement suspect. I ofer no reason for the number of bugs open; I merely note that there are. My contention is that by making the requirement to adhere to policy nebulous, and handing policy to trigger happy bug filers, without specifying any means of enforcing policy or even requiring that policy be enforced shall further engorge our bug database. I am talking of future practices, not current ones. manoj -- The time is right to make new friends. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Guy == Guy Maor [EMAIL PROTECTED] writes: Guy Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hmm. I think I like the idea of the policy documents being the law, Manoj and the technical committee like the justices, who lay down Manoj interpretations (which are referred to latter as and adjunct to Manoj prior law). Guy The committee does more than interpret. They can decide that a Guy debated section of policy is completely wrong and choose a Guy compromise which reverses it for example. Well, I guess I am uncomfortable with that. I mean, there is going to be this godly set of people who make technical decisions that I, a mere mortal developer, have to live by -- They have to be bloody good for me to put that much blind faith in any such body. I think there are not enough checks and balances to limit the powers of the technical committee. Manoj I still find the wording confusing. All that policy can say is Manoj whether something conforms to or does not conform to policy. Guy Yes, specifically it can not say that... Oh, I thought that is what Ian said. But then, going back, Ian So what power does a policy document have, in and of itself ? Ian Answer: just the power to declare what is and is not policy. I see there is a difference. So the policy documents just say what is policy. Whether something conforms or not is a matter of interpretation. Manoj policy ought to (should) be followed (is that not an oxymoron?). Manoj I am not required to follow it, and yet it is authoritative to bug Manoj filers; I an see a lot of contention developing there. (and again, Manoj the tech committee is brought in.) Guy Yes, that's why Ian proposed defined qualifiers for the various Guy policy sections. We (developers) just assume that policy is Guy correct until the tech committee tells us otherwise. Huh? We are debating this, are we not? I say that developers should follow policy, and you say that developers need not follow policy, and then again, you say developers take the policy as gospel. I am confused. What is your stance, then? Should developers treat policy as correct, and follow it, or they should treat policy as correct, and not follow it, or they should ignore policy, or I am so confused ;-) Guy If, for example, I choose to violate policy, I had better have a Guy really good reason. In most cases it's clear to all concerned Guy that the reason is valid, and we have to amend policy, or that Guy I'm wrong and should make my package conform. If I'm really Guy stubborn and insist that my reason is valid, I can ask the tech Guy committee to make a decision. They might say that that section Guy of the policy is correct, and I should conform, or they might Guy agree with me. Why should you make your package conform? There is nothing that says you have to follow policy. Can the Tech committee make me do whatever they darned well please? Since the policy document have no more standing than, say, The flight of the Bumble Bee, all this means is that the tech committee pointed to a set of rules somewhere, entirely at theur whim, and said YOU! MORTAL! Follow THAT! That has been my point. If the Policy documents have no standing, especially in the defining document that awards authority, then the technical committee can bring in any reference they choose fit, not just the policy documents. (Like the MS OS manuals ;-) This is too much power in the hands of too few. Especially since the developers have no say in who constitutes the board. How answerable are they to the rest of the developers anyway? I would rather be able to point to the policy documents as a kind of limit to the powers of the technical committee. And have the developers have some say in the shaping of the policy documents. As it stands, the technical committee has way too much power. Guy So we really just continue debating policy as we always have Guy been. Manoj who likes the quiet certitude of the ISO standards Guy Putting the policy in that light really does put too much power Guy in the policy maintainer's hands. Not as much as in the hands of the tech committee. manoj -- If life had a vomit meter, we'd be off the scale. Joe Bob Briggs Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Manoj Srivastava [EMAIL PROTECTED] wrote: Why should you make your package conform? Because it's the right thing to do. There is nothing that says you have to follow policy. Can the Tech committee make me do whatever they darned well please? Well, they certainly can't make you read the constitution drafts... Since the policy document have no more standing than, say, The flight of the Bumble Bee, all this means is that the tech committee pointed to a set of rules somewhere, entirely at theur whim, and said YOU! MORTAL! Follow THAT! Since when is The flight of the Bumble Bee the right thing to do? I think now you're objecting to Ian's recursive explanation of what policy is. For a better explanation, consult a good dictionary. That has been my point. If the Policy documents have no standing, especially in the defining document that awards authority, then the technical committee can bring in any reference they choose fit, not just the policy documents. (Like the MS OS manuals ;-) You mean like their entire background of technical expertise? Oh, the horror! People who aren't competent to distinguish between worthwhile references and garbage aren't going to be good tech committee members just because you've reclassified policy as some kind of law. This is too much power in the hands of too few. Especially since the developers have no say in who constitutes the board. How answerable are they to the rest of the developers anyway? I missed this one myself, when I was reading over the draft constitution: If the Technical Committee and the Project Leader agree they may remove or replace an existing member of the Technical Committee. Of course, the developers can provide override decisions for both the tech committee and for the leader... But the real thing that will keep us honest is the outside world. I would rather be able to point to the policy documents as a kind of limit to the powers of the technical committee. And have the developers have some say in the shaping of the policy documents. Huh? Are we even talking about the same document here? The developers have some say. Furthermore, if they're particularly displeased with the quick resolution they can override any decision of the Technical Committee (or of the Leader, for that matter). Here's a couple other statements which somewhat limit the powers of the tech committee: Then Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. What are you thinking? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian According to the proposed constitution, the policy documents do Ian not of themselves have any power to override a developer's Ian decisions. I think that to allow this would be to hand far too Ian much power to the policy editor(s), so I think this situation Ian should be preserved. The policy editor is supposed to be someone who starts discussions about policy, and incorporates the consensus into the document itself. I suppose a formal process could be worked out, but, by and large, this works quite well. There also is a process to get policy amended, in case the developers feel the policy editor has exceeded their authority. In the light of this, I find the statement about too much power to the policy editor, umm, unconvincing. Ian If Christian or anyone else disagrees they should take the matter Ian up on debian-devel, where the proposed constitution is being Ian discussed. I have copied the developers list on this. Ian The question then arises: what does it mean when something is Ian policy ? Answer: policy is a set of technical specifications and Ian procedures which developers are expected to use to make Ian decisions, which people reporting bugs can refer to as Ian authoritative, and which bodies like the Technical Committee will Ian refer to (though not unquestioningly) when asked to adjudicate. So, people may report bugs for policy violations, and when it comes to adjuducation the Technical committee refers to this, but apart from that, Policy has as much relevance as Wodehouse? Ian So what power does a policy document have, in and of itself ? Ian Answer: just the power to declare what is and is not policy. I find the intent quite unclear. Is policy like a standards document? Are individual maintainers at liberty to flout, say, the WWW standard, of the file system standard? Can my package start modifying /var/lib/dpkg/status at will? I mean, if policy has no power whatsoever exept say this does not conform, where exactly does that leave us? I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. manoj -- I asked you not to have a spaz attack in tx.general, BUT NO Karl, via John Belushi Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava wrote: I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. Ian didn't mention an enforcement policy, because that is already clearly mentioned in the constitution---the technical committee. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Mark == Mark Baker [EMAIL PROTECTED] writes: Mark On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava Mark wrote: I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. Mark Ian didn't mention an enforcement policy, because that is Mark already clearly mentioned in the constitution---the technical Mark committee. Hmm. I think I like the idea of the policy documents being the law, and the technical committee like the justices, who lay down interpretations (which are referred to latter as and adjunct to prior law). I still find the wording confusing. All that policy can say is whether something conforms to or does not conform to policy. And while we are picking nits, there is not statement anywhere that policy ought to (should) be followed (is that not an oxymoron?). I am not required to follow it, and yet it is authoritative to bug filers; I an see a lot of contention developing there. (and again, the tech committee is brought in.) I guess I mistrust an unknown set of powers-that-be rather more than a known quantity. [I am aware this is irrational]. manoj who likes the quiet certitude of the ISO standards -- It turned out that the worm exploited three or four different holes in the system. From this, and the fact that we were able to capture and examine some of the source code, we realized that we were dealing with someone very sharp, probably not someone here on campus. Dr. Richard LeBlanc, associate professor of ICS, quoted in The Technique, Georgia Tech's newspaper, after the computer worm hit the Internet Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
I'm not a debian developer, merely an interested lurker (I will almost certainly become a developer sometime). Apologies if you think I'm speaking out of turn. --On Mon, Apr 27, 1998 2:47 pm -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hi, Mark == Mark Baker [EMAIL PROTECTED] writes: Mark On Mon, Apr 27, 1998 at 01:49:33PM -0500, Manoj Srivastava Mark wrote: I understand that one may want a little more leeway than say the policy documents are writ in stone (I personally prefer that), but to deny that and make no mention of any mechanism of enforcement of policy is disquieting. Mark Ian didn't mention an enforcement policy, because that is Mark already clearly mentioned in the constitution---the technical Mark committee. Hmm. I think I like the idea of the policy documents being the law, and the technical committee like the justices, who lay down interpretations (which are referred to latter as and adjunct to prior law). I still find the wording confusing. All that policy can say is whether something conforms to or does not conform to policy. And while we are picking nits, there is not statement anywhere that policy ought to (should) be followed (is that not an oxymoron?). I am not required to follow it, and yet it is authoritative to bug filers; I an see a lot of contention developing there. (and again, the tech committee is brought in.) No contention at all. Developers are not required to follow policy. But, reports are filed for policy deviations, thus putting pressure on to adapt either policy or the developer ;) as necessary. The reports will remain until someone closes them - so they are a reminder of all extant violations (rather, all extant violations that bother people). Indeed, if I (as a hypothetical developer) were to violate policy, I might even, at the same time, file a bug report against myself, explaining why I did it, and what changes to either the world at large or debian-policy would fix it. This system makes sense to me. I guess I mistrust an unknown set of powers-that-be rather more than a known quantity. [I am aware this is irrational]. In effect, in means that the first level of enforcement of policy is the general Debian community. I think this is good. If things get out of hand, then presumably the leader or the committee step in to give a definitive answer. manoj who likes the quiet certitude of the ISO standards Jules Bean who likes the bright future of a communal democracy... /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Cc: Debian Developers list debian-devel@lists.debian.org, Debian policy list debian-policy@lists.debian.org From: Manoj Srivastava [EMAIL PROTECTED] Date: 27 Apr 1998 14:47:23 -0500 Lines: 44 Hi, Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. I think I like the idea of the policy documents being the law, and the technical committee like the justices, who lay down interpretations (which are referred to latter as and adjunct to prior law). Exactly. I think the problem has arisen because 1) the policy documents have not sufficiently delineated the difference between prescriptive (shall, must) provisions and (strong) recommendations (should, must), and 2) because some (many?) developers disagree with some policy provisions and feel that they have had insufficient input in the process of formulating policy. Christian has started the process of rectifying the first item. I believe the remedy for the second point is _not_ to make policy some vague advisory document. I believe the remedy is to establish a more formal policy making process. It would probably be necessary to provide for some type of super-majority to establish prescriptive policy provisions, with, perhaps less support required for suggestive provisions. In some cases it seems that some developers have failed to read the lists for some lengthy period of time, then found that policy provisions had been adopted that they find objectionable. A formal policy making process should provide for a process to change it when the developer community agrees it is desirable. Bob -- _ |_) _ |_ Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) Palm City, FL USAPGP Key ID: A8E40EB9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conflicts between developers and policy
Hi, Jules == Jules Bean [EMAIL PROTECTED] writes: Jules I'm not a debian developer, merely an interested lurker (I will Jules almost certainly become a developer sometime). Apologies if Jules you think I'm speaking out of turn. Jules --On Mon, Apr 27, 1998 2:47 pm -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Jules No contention at all. Developers are not required to follow Jules policy. But, reports are filed for policy deviations, thus Jules putting pressure on to adapt either policy or the developer ;) Jules as necessary. The reports will remain until someone closes Jules them - so they are a reminder of all extant violations (rather, Jules all extant violations that bother people). Hmm. I do think this leads to a dilution of technical discipline. And we already have way too many open bug reports; people do not seem to want to fix ``real'' bugs, and ``mere'' policy reports would be seen as fluff. I guess I am leaning mre towards a codification of laws (like hammurabi [I am unsure of the english spelling of his name]), while the opposition is opting for the chinese predeliction of trusting humans rather than laws; and trusting on the selection process to ensure that the people chosen shall be more adaptive and can adjust to cases on merit; historically, that has been subject to abuse; and even bodies of good men (soryy, ladies) have been know to decay; a codified system of rules is more stable against the ravages of time. manoj -- What matters is not the length of the wand, but the magic in the stick. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
