Re: Bug#13287: less uses /usr/bin/editor without it necessarily being there.
>>"Dale" == Dale Scheetz <firstname.lastname@example.org> writes:
Dale> I believe that Policy is important enough that concesus is
Dale> This is a general problem for others as well. We have longwinded
Dale> discussions on a "given thread" that tend to diverge off into
Dale> several directions. One or another of these "sub threads" looks
Dale> like the resolutions to some, while another appears to fix it
Dale> for others. Some see no resolution and go back to business as
Dale> usual. This creates far too much confusion. Pointing to the
Dale> Policy manual as the "definative" answer isn't necessarily
That is where the policy weekly reports come into play. The
policy reports are the policy editor perception of the consensus
reached on the working lists. Any objections should be noted then,
before it becomes policy.
I can see some merit in wider dissemination of the weekly
report, with the caveat that all discussion is redirected to the
policy lists (say, we have a weekly summary on the debian-devel, but
the list does not get overwhelmed with the discussion).
Dale> The only recourse that I have is to go "read" the policy manual
Dale> every week or two to see if there is anything that has
Dale> changed. I don't have the time, or inclination to subject myself
Dale> to that, so I end up finding out about policy from a bug
Dale> report. This just doesn't work well for me...sorry.
Well, this is a separate problem, and this should be addressed
separately. The issue is proper dissemination of new policy when it
is created -- is this an infrequent enough event that the changes be
posted on the debian-devel mailing list? (I think so).
Having a separate changelog available from the policy site
shall also help.
>> The decision has been made. If we allow everyone to come back and
>> challenge decisions made on the policy list (which they *choose*
>> not to subscribe to), we shall have no lasting decisions ;-(.
Dale> If we don't allow the established policy to be challenged then
Dale> nothing changes. There is no such thing as a "lasting
Dale> decision". As times, or circumstances change, so must policy.
The challenge should be on technical grounds, not on I wasn't
there when the policy was decided and I want to participate now
grounds. How have the circumstances changed? I have seen nothing so
far that was not already hashed in the original debates.
Dale> Declaring all those not subscribed to the policy list (or any
Dale> other list, for that matter) as being "uniterested parties"
Dale> doesn't deal with the problem in a fair or adequate fashion. I
Dale> have never agreed with the "list proliforation" that has been
Dale> used to solve the volume problem. In particular I believe that
Dale> policy issues should be discussed on debian-devel, as they are
Dale> "meta-technical" issues that impact all developers.
Umm. I think the list proliferation was generally agreed to. I
never liked it either, but I think that one has to compromise at
time, espescially when one has a minority viewpoint. Whether we like
it or not, the policy list *was* created. We have to live with it
To address your concerns, a weekly report should be adequate
for FYI purposes.
>> This has already been hashed once, I do not feel I've the energy
>> to get into this again.
Dale> OK, so what was the decission?
I thought that the decision is reflected in the policy manual
;-). ;-) ;-)
"To program is to understand." Kristen Nygaard
Manoj Srivastava <url:mailto:email@example.com>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .