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

Re: Bug#13287: less uses /usr/bin/editor without it necessarily being there.

>>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:

Dale> I believe that Policy is important enough that concesus is
Dale> required.

	Quite so. 

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
Dale> adequate.

	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:srivasta@acm.org>
Mobile, Alabama USA            <url:http://www.datasync.com/%7Esrivasta/>

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: