Hi, >>"Dale" == Dale Scheetz <[EMAIL PROTECTED]> writes:
Dale> We also have the power to reject the proposal, or make any Dale> requirements we see fit. That was made just as clear to you Dale> during the preliminary discussion. I think I object to ``make any requirements we see fit'' bit. Seems like an cop out to me. >> Dale> As one of the two proposed candidates for the chair of this committee, I Dale> would point out several points: >> >> Actually, all memmbers are proposed chairs. You are merely one >> of two who got a vote. And until you are elcted, and possibly even >> then, I don't think it gives you any special voice in a technocal >> discussion. >> Dale> I was voicing my opinions as a proposed chair. Nothing more. Dale> As noted in my reply to the original request, the alternative Dale> channels for correcting this screw-up have not been exercised. >> >> Point out where it says the alternative channels have to be >> exercised. I must have missed it in readin the constituion, and we >> did, after all, decide we did not need any special procedures. Dale> This isn't a special proceedure. This is simply a statement Dale> that other channels are available for resolving this issue and Dale> that this committee is a "last resort", not a dictatorial Dale> authority for pushing through policy. You are saying that the ctte can be only called in when a general resolution has failed? In that case the committee should be disolved, as it serves no useful purpose. I fail to see what other channels you se as available for this. Dale> I submit that your proposal is self evidently biased. I would Dale> judge myself unable to make reasonable representation for an Dale> "opposing" idea as well. This was not a slur of your skills or Dale> morals. I made only one proposal -- the overview of other proposals was something that had been submitted by aj on the -policy list. If we all are biased, you should send email to Chris Waters, who is the major oppostion to the symlinks proposal. Dale> The current "problem" has been caused by a recent policy Dale> decission that was malformed. "Thou shalt be FHS compliant" is Dale> not, and never should be considered, an adequate policy I'll bite. For the most part, the FSSTND was mandated similarly, though that is ot by itself a good argument. Secondly, there is little point in duplicating any of the material in the FHS, Thirdly, picayune details do not belong in the policy, details are often left for the developers in question to resolve. Fourthly, it was assumed that since the FHS discussion went off without a hitch, there was collective mindshare invested in the move to FHS, Fifthly, it was assumed (incorrectly, it appears) that any details that need go into policy would be ironed out non-controversially, as have a number of other changes required for the move. Dale> statement. I suggest that the policy group remove such Dale> statements, and replace them with "In order to become compliant Dale> with XXX, developers will need to impliment the following Dale> proceedures ... I strongly object to any recommendation putting low level detail like this by default into the policy document. It is already large enough that silly little details should be left out, only major cross-package issues belong in policy. Micro management by policy is neither desirable, nor is it likely to be good for the project. >> Are you trying to make this committee make an advisory >> statement like that? Dale> No, I was pointing out the flaw in policy that lead to the current Dale> problem. The simple solution is to repair the flawed policy. You opinion. In my view, a seriously flawed opinion. And, pardon me, but seeing how quiescent >> You have missed the point. It is not ``least surprise'', it is >> that the documentation would not be present in any one location >> during the transition (potato is likely to be released in that >> period). The symlinks make it possible to point the users first to >> /usr/doc, as they are used to, and to /use/share/doc, when the >> transition is over. Dale> Sounds like least surprise to me, and it doesn't resolve it, Dale> only pospones it for a future time. No. It would not matter if all packages could move magickally to using /usr/share/doc, in which case no symlinks would be required, or proposed. Least surrise would require the symlinks in either case. >> Dale> 2. Do Nothing: While not well represented, seem to be strong enough to Dale> block the symlink proposal. >> Dale> a. Is there really a problem? >> >> Yes. A user visible lack of a single point to find >> documentation of packages has been judeged to be a serious problem. Dale> Maybe by you, but to me this isn't even a technical problem, much less Dale> serious. A simple documentation solution designating the details of the Dale> change seems to solve this "problem" much easier than a complex symlink Dale> solution. Then you are at odds with everyone who has spoken on the -policy list, and on the IRC. >> Your opinions about the policy group, while amusing, have no >> real bearing on the request before the committee. Should you feel the >> need to vent your dissatisfaction with the incompetence of the polciy >> list, please take it to personal email, or to the list itself. >> Dale> You may find it amusing that this committee has gotten itself Dale> into this mess, I don't. The fact that you seem unwilling to Dale> take any responsibility for the situation puts me in less of a Dale> state of mind to try and help you out of the muck you in which Dale> you are currently stuck. I am stuck? *I* am stuck? You have serious ego problems, it seems. The project is stuck , not I. And responsibility without power is silly. What responsibility? I have no special power in the policy mailing list, and can't be expected to have any more responsibility thatn any toher member. Dale> The fact that the policy group is unwilling to support your proposal, Dale> dispite the problems created by the new FHS policy, suggests that the Dale> proposal is flawed. Rubbish. You do not seem to be aware that the policy group is designed for non-controversial amendments to policy. It is not designed for sound, but unpopular, technical amendments. There is no power given to the policy group to implemnt technical solutions that may be unpalatable to more than 4 members of the policy group. If you think that because a proposal is unpopular, it must be flawed, you should seripously reconsider your acceptance of the char of this committee. Dale> The fact that you are unwilling to present a reasonable counter Dale> proposal leaves the Technical committee with nothing to Dale> deside. We are NOT an instrument for pushing through proposals Dale> that do not pass ordinary creation processes within the In other words, you want a general resolution protocol. Deciding technical policy by popularity. If that is what Debian is reduced to, we shall indeed see quality plummet. I can't believe you said that. Dale> group. Our sole reason for existance is to provide a mechanism Dale> for resolving a deadlock between two opposing positions. You Where does it say that in the powers of the ctte? Where are you getting this stuff? Dale> have only proposed one option, leaving the committee no choice Dale> but to reject your request and suggest that you return to the Dale> constitutional means for resolving such questions...a vote. I think that is you think that a vote is the correct way toi decide technical policy, you should resign from this committee. Sorry, but voting for technical policy is a really bad idea. manoj -- "Flight Reservation systems decide whether or not you exist. If your information isn't in their database, then you simply don't get to go anywhere." Arthur Miller Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E