[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: please vote...

>>"Dale" == Dale Scheetz <dwarf@polaris.net> 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

 "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   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Reply to: