Re: please vote...
Hi,
>>"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
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 <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: